Mesa Card Basics

All LinuxCNC motion hardware is real time so as I said the only limitation is that the accuracy
of some operations like probing and homing without using index is limited to velocity *
servo thread period (usually 1 ms). This is typically not an issue because the final velocity can be quite low
as the distance covered by the final latch move is small.

On Mesa hardware, the stepgen is a digitally controlled rate generator. At ever servo thread
invocation (typically 1000 times a second),  LinuxCNC reads the current stepgen position
from the hardware and compares it to the actual commanded position and makes corrections in the rate 
to keep the step generation in sync with LinuxCNCs commanded position. This typically
keeps the external step generation within a small fraction of a step of the commanded position.
 

Thank you for the explanation.
Just for a short conclusion in other words. LinxCNC "works" together with mesa HW like a "closed loop regulator". Linux "controlles" the executed steps donbe by mesa in the servo thread and corrects if necassary?
If this is the case I can estimate the error during milling and probing.

PCW wrote:

You would normally choose a latch velocity low enough that the 1 ms (max) sampling uncertainty causes a minimal position error when probing.

I pondered this truth at one point recently, and did some experiments.  I wondered if the "signal lag" due to communications and HAL processing (I needed to add a noise remover[1] and mux[2] to my probe inputs, so I was at around 10ms of lag at the time, assuming each HAL component added at least one servo-loop of lag) was reducing precision here and causing the motion to continue past the actual probe point, and wondering how fast I could probe without destroying my toolsetter (testing delayed while toolsetter repaired) limited by this lag and deceleration limits.

My first findings were that the HAL lag was significant and I had to limit "fast" probing to 6in/m or so, which made me wonder: I have the axis accel limited to reduce overshoot at the tool[3], but is there a way to override that when probing or homing so I can stop faster?  Does homing use the joint accel limit instead of the axis accel?  Can accel be changed by gcode or HAL?

My second findings were thus: if I probe towards and capture the result, then probe away at the same speed and capture *that* result, and average them, I get results that are more consistent and less dependent on probing speed.  If this makes sense, one could drastically reducing probing time, but "probe slow enough" is just so much easier

Does it sound like I understand what's going on?  Is there any value in pursuing the dual-probe-average method?

Is HAL lag impacted by the order in which stuff is listed in the config files?  It would suck if I were calculating the probe signal just *before* reading the 7i76


[1] Aluminum extrusion CNC with 7i76 here, and sometimes the ATC actions vibrate the frame enough to trigger the toolsetter.  Bad for normal operation, good for detecting failed tool releases
[2] I change the noise limits and/or disable the toolsetter based on the machine's XY position, as a "fix" for the above.
[3] the servos can stop on a dime, but the rest of the machine is limited by its strength and momentum.
[4] I really like the Mesa products, and really appreciate the work you folks have put into them
 

There should be no more than 1 ms in hal/LinuxCNC lag at a 1 ms servo thread rate.
if the probe signal goes through multiple hal components, they need to be addf'ed to the
servo thread in processing sequence or you will add additional pipeline delays.


That is, the sequence should be:

hardware read
process-0
process-1
process-2
motion
hardware write

PCW wrote:

if the probe signal goes through multiple hal components, they need to be addf'ed to the
servo thread in processing sequence or you will add additional pipeline delays.
 

Ah!  I think I guessed that order was significant, I didn't realize it was official.  Or at least "official".
That leads me to a follow-up HAL question (sorry for the thread drift).  Can I add the same component twice?  I mean, with different names, so I don't need one central "and2" with a dozen instances, I'd rather have each function/section add its own components as needed and in the right order.
If not, getting things in the right order across all components might be difficult.

Do the rest of my ponderings still apply, since I'm using dbounce and it delays the signal ?

Thanks!

Yes, you can "addf" the and2 functions separately. This isn't true for all HAL components, some have a single read and/or write thread for all instances.

But for and2 you could have:

It is possible to retrospectively add functions in a position other than the end, if you really need to:



This seems to be less well documented than one might wish. Possibly it doesn't work properly. I think that positive numbers are position from the start and negative position from the end.

github.com/LinuxCNC/linuxcnc/blob/master...cmd_commands.cc#L318