7i92 packet loss - query regarding HAL workaround

So I've finally made the step (pardon the pun) away from the parallel port and on to a Mesa 7i92, which I managed to get implemented and working on my machine over the weekend. A bit of faffing around trying to get the HAL and INI files built up and translated from my old parallel port config, but got there with a judicious bit of searching and reading up on the docs and here at the forum. Works great, which I'm really pleased with.

While I was researching how to configure the 7i92, I came across a comment by PCW regarding inserting the below bit of code into the HAL file to help combat following errors particular to the Mesa ethernet cards:

User Skunkworks also makes mention of this fix in one of his videos regarding the RPi4:



I tried the above HAL hack and was able to confirm that following errors I was previously getting while doing rapids at 4200mm/min went away. My following error (as seen on HalScope) reduced from a couple hundred millis down to less than 200micros. Note that at the time I was only testing to see how hard I could push my machine with the 7i92, as previously with the parallel port my highest speed was limited by the software step rate. In reality I wouldn't run my machine so hard, as I get some ugly resonances at 3600mm/min.

My question is: is there a reason why I shouldn't use the above HAL hack to get around following errors? Is there some kind of detrimental tradeoff I introduce by using it? My machine is just a basic step/dir open-loop stepper system, so following error is entirely an internal function within the LinuxCNC stepgen, rather than being a directly measured quantity based on actual machine position.

You should in general always use the DPLL with Mesa Ethernet cards to reduce the effect of jitter on the step generation fidelity (and encoder sampling jitter).

Thanks for chiming in, PCW.

I'm still curious though - am I sacrificing something in the machine operation (accuracy? speed? tolerance to comms issues?) by using this fix? On face value it seems like a bit of a miracle correction for a potentially show-stopping problem with fast motion. The fact that the fault (packet loss) manifests itself in a slightly left-of-field way (following error) could be a bit of a headscratcher if you were trying to diagnose why your machine is repeatedly halting.

If it wasn't for the resonance stalling issues I have with my particular setup I'd no doubt be pushing my rapid speeds much higher than they are now, which I couldn't have otherwise done without this fix.

There are no real downsides to using the DPLL.

For step generation, it reduces the stepgen position sample time variation from
perhaps a few 100 usec to less than 1 usec, this means a cleaner step pulse stream

I don't think you have packet loss (that would be quite unusual), There are other schemes
to deal with packet loss in hal. These are more useful in very noisy environments
or where you are running close to the maximum servo thread rate and wish to timeout
on rare long packet delays and just adjust the velocity on the next cycle (cycle skipping)

OK, sounds good, thanks for that.

Are there any other areas I should/could look into as a means of taming following errors in my open loop setup? PID tuning of the stepgen iteslf perhaps? I'm only thinking that if my setup or HAL config is less than optimal I may be just masking a real problem with the DPLL.

Or is it more a case of if this HAL tweak works there shouldn't be a need to fiddle any further?

You normally should not need to tweak, but if you want to fuss
around you can try adding a bit of FF2. FF2 needs to be set to the
time between reading the stepgen position and setting the stepgen
velocity, normally about .0001 + DPLL pre-read time so about 0.00015
in your case.

Also make sure that PID maxerror is set to 0

Just for interest, here's the differences I'm seeing with the various fixes and tweaks in place.

The G-code running on the mill during these scope captures is just the standard 'LinuxCNC' logo test program that loads on Axis startup. The large spike in each of the traces is the Y-axis Following Error as it rapids between the end of cutting the lower-case 'n' in 'LinuxCNC' to the start of the dot above the 'i'. This is where I found the biggest deviation while running this particular G-code.

Without any fixes or tweaks. Largest peak on the FErr spike is about 9 millis:


With PCW's 'latch all stepgen counts...' HAL fix. Largest peak is down to +/-80 micros:


With PCW's HAL fix plus the addition of FF2 = 0.00015 and PID max_error = 0. Largest peak is down to +40/-60 micros:


G0 rapids on my machine are 3200mm/min during these tests.

Looks like you could add a bit more FF2
(if you add too much, the steps will reverse polarity)

(Not that this will make any actual difference since motor and
mechanical errors are much larger that this)

Just for the hell of it.

FF2 = 0.0002:


FF2 = 0.00025:


FF2 = 0.0003:


So, I'm starting to see the peak inversions somewhere around FF2 = 0.0002 and 0.00025.