[vinss1234]

Hi,

I am wondering if it is possible by just reading the G-code to know the position of the extremity of the tool at a specific time during milling phase ?

Is there some consideration to make depending on the machine ?

If you need me to clarify some point to answer, please ask.

Thank you.

[Jon.N.CNC]

Gcode is a list of positions, Getting familiar with the code is all that is required. You can simply add/subtract tool radius from the x or y values. But if your talking about how you find a position at say 1 min into program, gcode doesnt run on time it runs on feedrates, cant think as to why you would need to do this but, you would need to feed hold and take the position.

some cam simulations can show you position if you pause it but its very improbable or almost impossible to say the machine will be at the same position at that exact time as the machine controller will have smoothing and acceleration and deceleration variables that would be very difficult to simulate.

[vinss1234]

The reason is that I have an external device which make measure at a certain frame rate and I want to generate the position of each measure that wll be made during milling phase.

Will I be able just by reading the g-code to differentiate a milling phase from a re-positioning ?

And according to your answer considering speed and the device framerate, I could deduce the position (with a error margin coming from the acceleration) ?

Is there case where the position aren't written directly in the G-code ?

Thank for the help.

[sinha_nsit]

The control shows the position of the tool on the screen, in real time. It also highlights the block being executed.
Your purpose of measurement is not very clear.

[Jon.N.CNC]

What pc and motion controller are you controlling your machine with also because these things have buffers that fluxatute depending on how fast the code is being sent and this can effect the time the program takes also.

You are really barking up the wrong tree trying to gather positions based on time imo. It won't be the same every time you run the program. Are you trying to trigger something at a certain position? Because this can be done by inserting a run macro command in the gcode which can trigger a relay if it's a device you need to trigger.

Otherwise you would literally need to write a new programming code that is time based. Maybe you could call it tcode. Computer clocks are not very reliable though so you may want to run it timed to a clock pendulum.

[Jon.N.CNC]

The reason is that I have an external device which make measure at a certain frame rate and I want to generate the position of each measure that wll be made during milling phase.

Will I be able just by reading the g-code to differentiate a milling phase from a re-positioning ?

And according to your answer considering speed and the device framerate, I could deduce the position (with a error margin coming from the acceleration) ?

Is there case where the position aren't written directly in the G-code ?

Thank for the help.

You can differentiate between when the gcode is makid a rapid repositioning move to when it's milling by looking at the code. Just watch look at the z value. If z is lower than stock its milling. But it's pretty hard to keep up with at 100% speed so you use the back plotted window in your control software. Rapids show up as a different colour line.

[vinss1234]

Hi,

# Sinha_nsit
The purpose of measurement is to match a measure made by a camera with the position at which it have been made. The camera is connected to a computer and send picture at a predefined framerate. My plan was to give the g-code to the computer before recording with the camera and generate a list of position for each frame send by the camera to then match them together at run time.

#Jon.N.CNC
I don't try to trigger something at a certain position.

One of my goal by using the g-code to match positions with pictures is to make the system work on every milling machine running on g-code.

Have you an idea of how much the position could change between two execution of the same g-code ?

Does looking at the Z to differentiate milling phase from repositionning is the only solution or looking at the number after each G instruction could also work ?

Thanks a lot for the help.

[dpuch]

The G-code tells the machine what to do, and it is fairly easy to read. So from it you can figure out what the CNC will do. Syncing that to a video is a very different matter. How did you plan to distinguish when one line of g-code finished and the next started?

[Parlorcity]

Also, you need to keep in mind that one manufacturer's G code may not be the same as another's, so that the same program may do one thing on a Haas, but do something completely different on Brother.

[vinss1234]

#dpuch

The G-code tells the machine what to do, and it is fairly easy to read. So from it you can figure out what the CNC will do. Syncing that to a video is a very different matter. How did you plan to distinguish when one line of g-code finished and the next started?

Here is how I was thinking to do it :
For each line I will check :
- If the line change the position.
- If the motion is for repositionning or for milling.
- If its for milling, I will get the motion speed and with the framerate, the motion speed, the trajectory type, the start position and the end position I wlll generate the theoretical position between the start and the end (the camera is recording only during milling phase).

Does it seems viable or I forgot something ?

#Parlorcity

Also, you need to keep in mind that one manufacturer's G code may not be the same as another's, so that the same program may do one thing on a Haas, but do something completely different on Brother.

Is this true for other code than the Mxx one ? And if the difference in G-code are from one manufacturer to another the number of different scenario won't be that high considering only the main manufacturers. right ?

[sinha_nsit]

Would not work with canned cycles and complex macros.

[dpuch]

Most g-code and even some M code will follow the NIST standard (PDF) BUT are not required to do so. Also any codes not in that have been used for what ever the tool builder decides to assign it to. So most of the motion and cut moves will conform to the standard. There will be behavior differences though due to control differences sand parameters, and yes more complex code and macros will really be hard to deal with. But that is getting into making it a universal tool. Using it on your own machine(s) you will have a much smaller number of variables to deal with.

I still do not now how you will deal with video vs machine sync issues. How will you determine which line of g-code is being executed for a given video frame? SMTPE time code is a standard for video, but you would need to tie that to the g-code execution on the machine. That at least gives you a standard way to match up on the video side. But the CNC just does not have any normal way to output when a block of code was executed.

About the only way I can think of doing that is using dprnt before every move you want to tie to the video. Then what ever you have reading the rs232 dprnt output also marks that with the SMPTE code. That requires LOTS of extra lines for the dprnt output, and will also have a lag of at least a few ms on the rs232 output if that matters.

[vinss1234]

#sinha_nsit
Would not work with canned cycles and complex macros.
If the canned cycles are only for tapping, boring and drilling then it won't be a problem for me. For the maccros, I think by replacing the maccros call by the g-code, I could manage to solve the problem but thank you, I would have probably forgot considering this problem without you.

#dpuch
I haven't in sight an universal tool for the moment but still nice to know there can be differences between machine's g-code.

To sync video with machine here is how I was planning to do it with an example :
Take a linear movement from position A(0,0,0) to B(100,0,0) with a motion speed of 100mm/s. I know it will take one second for the tool to travel from A to B and my camera having a frame rate of 100fps, I will just create 98 points between A and B and match each frame with each point.

Anyway thanks to everybody for the help, it saved me tons of time and if you have better idea to output the position of the tool and matching it with a camera frame I would be grateful (the cnc is a Siemens by the way if someone have experience on those).

[109jb]

To sync video with machine here is how I was planning to do it with an example :
Take a linear movement from position A(0,0,0) to B(100,0,0) with a motion speed of 100mm/s. I know it will take one second for the tool to travel from A to B and my camera having a frame rate of 100fps, I will just create 98 points between A and B and match each frame with each point.

This is much too simplistic and will not work.

1 - You are not accounting for acceleration and deceleration of the machine. If the machine starts from rest, it will need to accelerate at the beginning of the move, and if the move changes direction, or stops afterward, the machine will have to decelerate. It cannot go from 0 to the program speed instantly. Some machines use simple linear ramp acceleration profiles, and others use much more complex S-curve ramp profiles. Every machine also has a different profile based on the mass being accelerated, the power from the axis motors, etc. You would have to account for this acceleration and in your description above you have not.

2 - if the machine operator decides that the machine is cutting too fast or too slow and uses the feed rate override.the speed no longer matches the programmed speed. How do you plan to account for that?

3 - Many machines don't achieve an exact feed rate due to math round off errors during trajectory calculation. So, if you program 100mm/s you may only get 99.3mm/s or 100.2mm/s.

[Mhoppe]

Just run all of your programs at 5% speed. That should yield the necessary temporal resolution to push acceleration/deceleration ramps below the noise floor of your measurements.