Mesa modbus and pktUart

I find that occasionally the FAULT pin is asserted for no discernible reason (other than FAULTCODE) and there is no way to clear it other than exiting and restarting linuxcnc. Is the faultcode an index to the list of messages defined in mesa_modbus.c? (I'm guessing it is, but would like it confirmed). Would it be possible to provide a means to reset the mesa_modbus component? (ie. a RESET input pin)
Jim
 

I think the last-error pin just reflects the last error,
It should not affect communications. The fault pin gives
the current communication status. A fault count pin
might be a nice addition.

With my test setup I start with an error code of 0 but
if I interrupt communications, the fault pin is asserted
the last error pin changes to 11 ("com timeout")
if i re-establish communications, the last error remains
11 but the fault clears, and communications are re-established

Do you have bias resistors on the 7I96S serial port?
These are needed for RS-485 communications to set
the undriven line state to idle:

1 GND
2 RX+,TX+ 330 Ohm pulldown to GND (1)
3 RX-,TX- 
4 RX+,TX+
5 RX-,TX1-   330 Ohm pullup to 5V (6)
6 +5V

Also you should use the 7i96s_pktv2 firmware
as it has an improved PktUART with better error resistance
and more accurate low baud rates.

EDIT:  I have found by torture testing (power cycling the modbus remote while running)
I can generate a unrecoverable (stack smash) error. I believe this is because when power cycling
many bogus RX characters can be generated and the number of RX characters exceeds the max
character limit in the .mod file

I have been able to work around this by setting the max character limit to the maximum (251)
but it should probably be fixed in the driver by truncating at the limit or some other validation method.
 

"if i re-establish communications, the last error remains
11 but the fault clears, and communications are re-established"
How do you re-establish communication? I find that once the FAULT pin is asserted. it no longer communicates with the VFD and I have to exit linuxcnc and restart. It would be nice to be able to programmatically restart communication, for example, by toggling a RESET pin. 
I have a 7i96 non S version. Does it still need the bias resistors?

The 7I96 also needs the bias resistors

Reset does not make much sense as communications should restart automatically
and if not, the reason should be determined and fixed.

On my setup I can unplug the serial connector get the expected fault
and it always reestablishes communications and clears the fault when
re-plugged.

Do you get any errors on the console when you get the unrecoverable
fault? (start LinuxCNC in a terminal)

Is it Linuxcnc that needs a restart or power cycling the VFD?

Are you using the V2 PktUART firmware: 7i96_pktdv2.bit

Ok, I better find some resistors then.
I did flash the 7i96_pktdv2.bit file. 
When the FAULT is active, there are no messages on the console, I just can't turn on the spindle. Restarting linuxcnc clears it without cycling power to the controller or the VFD. Maybe the problem is that I don't have the resistors, so I'll fix that first and go from there. Thank you for the info.

Another development in this saga. First of all, I updated to bookworm and kernel 6.3.0-rt11 according to rodw's instructions. I think the error-finishing-read errors are now gone. However, there is still something fishy with the mesa_modbus component. If the FAULT signal is not asserted, I cannot perform homing because there are constant joint.0 following errors. If I unplug the cable to the VFD with the modbus signals, thus causing FAULT to assert, the following errors disappear and I can perform homing. The frequency of the following errors is very close to the mesa_modbus update rate. To prove this, I halscoped the signals with the refresh rate at 4 Hz and again at 5 Hz. What I don't understand is why the joint.0.motor-pos-cmd has spikes. It should have nothing to do with modbus or spindle control.
Jim