Question on GCODE execution frequency

Dear All,

I have last year repaired an old CNC with a broken controller to linuxCNC + Mesa and it was easier than anticipated. And it runs really well. Thanks a lot for all your work developing linuxCNC!

I am now building another machine (I call it “splicer”). It’s a CNC controlled camera and does visual sampling. It’s intended use is to make post-linear perspective photography. I know, not really what LinuxCNC was intended for but it actually works well.

Splicer consists of three parts, camera, sample mover and controller

1. The camera is a monochrome line scan camera and two axis of motion. One (U) is for moving a RGBA filter in front of the sensor to do trichromatic full color images. The second camera axis (V) is for autofocus.
2. The sample mover moves an object in coordinated movements in front of the camera. It’s currently 3 axis, X / Y / C (rotation around Z). Planned for the future is also Z and possibly B (rotation around Y axis).
3. The controller is two computers. One running Windows, with a FPGA capture card receiving the image data from the line scan sensor. And one running LinuxCNC doing all the real-time motion and camera line triggering in coordination with the sample moves.

The “CAM” part I do in Blender. I wrote a simple python script that translates an animation in Blender to very stupid slow GCode so that I can do the animation work in Blender and then let it run for real on splicer.


And here comes the issue / question:

Linux CNC interprets a line of Gcode > does the move (of a few 1/100th of mm). > triggers a line recording. > Does the next move > triggers the next line. And so on.

The camera is a high speed camera with very short exposure times and in need of a lot of light. I can set the exposure time (per line) of my camera between 1.75 to 3270 µs. The example below read ~45000lx at the sample. (1* 300w led + 2* ~100w led lights). It starts to become unpractical to add more light.

At an exposure time of 3200µs, I can have a max. line frequency of ~300hz.

But if there are no big moves in the GCode. LinuxCNC will read more than 300 lines / s. (I know this is great for normal machines - but it’s an issue for me - this will overload the image acquisition.

Is there a way to limit the lines / s of gcode interpreted in linuxCNC?


Workaround A (tested):
In the blender python script (CAM-part) I calculate where unscientifically the delta of the current move and if it falls below a threshold, I add a G04 5ms dwell.
> works more or less.
> makes everything slow as I need to be overly conservative with my threshold.
> introduces vibration

Workaround B (in progress):
I realised yesterday, that there is G61. In the blender python script I can calculate a simplified time a move will need per axis. (Using the per axis acceleration / max velocity). If this time is below 3.5ms I can add a dwell.
> might be more efficient.
> will introduce vibrations as well.

Do you have any other ideas how to solve the issue?

Thanks a lot & have a great day,
Flo

For reference, a the beginning of a gcode file:
And an image of splicer:

Dear Andy,

I will look into G93, I was not aware of this. (cnc noob here).
It sounds like a solution as I can slow execution down.

FPGA-synchronisation:
No there is no problem there. I was not precise enough. The issue is that a second line get's triggered by the controller while the first line ist still being exposed. = line trigger to line trigger delay shorter than exposure time. And I need to prevent this from the controller side.

Vibration:
The sensor is 8k*1px. An square image is about 8000 lines wide. Stopping at every position makes the time needed to acquire an image too slow. Lot's of small steps with stops are an issue doe to the wobble. Photographing the objet in motion is less so. As the delta displacement during the exposure time is often smaller than a pixel. Or at least it's less disturbing visually.

Rigid Threading / Custom HAL component:
You are absolutely right on this. I know that this would technically be the right approach, will look into it how I can do this.
The issue (without yet researching it atm more in detail) is that the trigger frequency might need to change during even a linear move. While reading it again: I am probably wrong. This sounds like the possible approach. Fixing line acquisition frequency and calculating federate accordingly to the needed displacement. Will look into this.
I will also look into the custom HAL component approach. If I understand right, it's similar to my Option B, but properly solved on the controller side instead of the CAM side.

Thanks a lot for the ultra quick feedback!

Dear Andy,

Your help is very appreciated! I did not have the time yet to fully immerse myself into it. Will read into it tonight.

Reading quickly through HAL compile, this is incredible. LinuxCNC is so extremely open to accommodate custom problems.

Thank you!