7i96S custom bitfile: 4x PktUART V3 on P1 (3x Modbus + 1 full-duplex link) + St

Hi Peter,

I am building a small 3.5-axis mill/drill with a 7i96S and five STEPPERONLINE A6-RS servo drives (step/dir + Modbus RTU). Current setup: LinuxCNC 2.9.10 uspace on Debian 13 (PREEMPT_RT), 7i96s_pktv3.bin flashed. hm2_modbus to one A6 on TB2 works without errors (115200 8N1, rxdelay 40 / txdelay 45 / icdelay 20, about 7 ms per single-register read at 1 ms servo period).

I would like to ask for a custom bitfile with the following configuration.

TB2 and all on-board I/O: identical to 7i96s_pktv3
- StepGen 0-4 (X, Y, Z, W, spindle), QCount 0 with index (spindle), PktUART V3 on TB2 with internal TXEn, SSR, OutM, InM, PWM unchanged.

P1 (W6 set to GND, a small interface board sits directly at the header):


Notes:
- All PktUARTs V3. No TX enable pins on P1: the three Modbus ports use RS-485 transceivers with automatic direction control (e.g. MAX13487E); the lever link (PktUART 3) is full-duplex RS-422 with the driver permanently enabled, 2-5 Mbit, one packet per servo period in each direction.
- Instance numbering as in the table, please: PktUART 0 stays on TB2 (so existing configs keep working), StepGen 5 and QCount 1 are the highest instances, so I can turn them into GPIO with num_stepgens=5 / num_encoders=1 when they are not needed.
- If it does not all fit into the T20, please drop in this order: QCount 1 first, then PktUART 4, then StepGen 5. PktUARTs 1-3 are the ones I really need.

Questions:
1. Does this fit (5 PktUART V3 in total, 6 StepGens, 2 QCounts)?
2. hm2_modbus without a TX enable pin: is the receiver masked while we transmit (RXMASK driven by the internal drive enable), or should the transceiver's receiver be disabled during TX to avoid the echo?
3. Lever link: for full-duplex use I plan to set the drive enable bit statically and the auto bit off in my own HAL component. Is that the right way with PktUART V3, or would you configure it differently?
4. Is the 7I87 expected to be available again?

If it is easier for you, I can also build it myself with Efinity from the 7i96s sources - in that case a hint which PIN file to start from (PIN_7I96SD_PKTV3?) would be much appreciated.

Thank you very much for your support,
Thorsten

 

1. Fits easily

2. Yes, RX is masked during TX (if enabled by the driver and pretty sure hm2-modbus does this)

3.  Not sure, if hm2_modbus knows how to do full duplex, but yes at the PktUART level, you would just assert
TXEN permanently

4. We should have more 7I87s in 2 weeks


Note that normally only one PktUART is used (since you can have multiple MODBUS devices on one RS-485 bus)
so you may well uncover some bugs...

 

Hi Peter,

thank you very much for the bitfile - and for the incredibly fast support, that was a really nice surprise!

7i96sd_pktv3x5 is flashed (user area, verify OK) and readhmid matches your pin file.
I ran a short bench test of everything in halrun (LinuxCNC 2.9.10, 1 ms servo thread, nothing connected to P1 yet), and all of it works:

- all modules show up in HAL: 6 stepgens, 2 encoders, pktuart.0 to .4, InM, SSR, OutM, PWM
- stepgen.05 on P1: 2010 counts in 2 s at 1000 steps/s
- GPIO IO36/40/41/42: output low/high with read-back OK, pull-up high as input
- with config="num_stepgens=5 num_encoders=1", IO34/35 and IO37-39 become normal GPIO
  (output/read-back OK), so the optional functions can be switched off without a new bitfile
- hm2_modbus with 5 instances at the same time (pktuart.0 to .4): instance 0 (one A6 drive on TB2)
  stays error-free, instances 1-4 just report timeouts as expected since nothing is connected there
- max. times: read ~200-220 us, write ~50 us, servo thread ~260 us with 1 instance and ~285 us with
  5 instances; no watchdog bite

My plan for testing the multiple Modbus instances with real hardware:

1. Breadboard 3.3 V RS-485 transceivers with automatic direction control on P1 for pktuart.1, .2 and .4 - one A6 drive on each port (the real P1 interface board comes later).
2. Run all hm2_modbus instances in parallel at 1 ms servo period, each polling a single register as fast as possible plus a larger diagnostic block once per second.
3. Long run (several hours, LinuxCNC + AXIS running) while logging error counters, cycle time per port and hm2 read/thread times.
4. Check that there is no echo with the auto-direction transceivers (RX masking), unplug/replug and power-cycle a drive to see how each instance recovers, and check the behaviour after a watchdog bite.

If you would approach this differently, or if there is something specific I should watch for with several PktUARTs/hm2_modbus instances, I'd be very grateful for any tips. I'll report the results here.

Thanks again 
Thorsten

Hi Peter,

as promised, here are the results of the bench test with all PktUART instances working at the same time.

Setup:
- LinuxCNC 2.9.10 uspace, Debian 13 PREEMPT_RT, Intel N150 (fixed at 800 MHz), hm2_eth, servo thread 1 ms
- pktuart.0 (TB2): on-board transceiver
- pktuart.1 and pktuart.4 (P1): small SP3485 auto-direction RS-485 modules, no TXEN pin
- 3 x StepperOnline A6-RS servo drives, one per port, Modbus RTU 115200 8N1, addresses 1/2/3, rxdelay 40 / txdelay 45 / icdelay 20
- pktuart.2 <-> pktuart.3 cross-connected at logic level; a small RT component on pktuart.3 acts as Modbus slave simulator (with fault injection) or as full-duplex loop partner
- in total 4 hm2_modbus instances in parallel plus one extra PktUART user
- test tooling vibe coded with Claude

Results:
- Endurance: one run of 2 h plus two earlier runs of 30 min each. The 2-h run had about 3.3 million Modbus transactions with 0 errors on all instances. Cycle 8 ms per drive (2 registers + status), 11 ms for the simulator. Servo thread tmax <= 260 us, no watchdog bite.
- RX masking without TXEN works with the auto-direction transceivers on P1, no echo problems.
- Isolation between ports: unplugging a cable, swapping two cables during operation or adding 1 ms response delay only affected the instance on that port. The others kept running without errors.
- Fault injection: timeout (110), CRC error (52), late answer (110) and exception (74) are detected correctly, only on the affected instance.
- Watchdog bite: all instances report a fault. After clearing has_bit and pulsing hm2_modbus.N.reset all ports run again, no PktUART reconfiguration needed.
- 9600 8E1 on one port next to 115200 8N1 on the others: no problems.
- 60-register read: 20 ms, 0 errors.
- Full-duplex P1 port (drive enable set statically, 2.5 and 5 Mbit/s): 1.8 million frames, 0 bad, 0 lost, while the Modbus instances ran in parallel without errors. My component counted one framing-error flag right at each session start, probably start-up, not investigated further.

Two hm2_modbus behaviours worth knowing (2.9.10, not related to the bitfile):
1. After 5 consecutive errors a command is disabled. It stays disabled even after the device answers again, until there is a rising edge on hm2_modbus.N.reset (or command.NN.reset). So an application needs its own reset logic.
2. An answer with a wrong slave address is not counted as an error, it is only logged and the request is resent (hm2_modbus.c, around line 1780). The HAL value then freezes silently while errors and fault stay 0. I monitor the age of each value for this reason.

Are these behaviours intended, or should I report them as an issue?

Limitations: bench setup only. Motors not energized (no PWM noise), short cables, one device per port. I have not run a test longer than 2 h with all ports in parallel.

So far the bitfile looks solid for my use case. Thanks again!

Thorsten

I would definitely post the two odd hm2_modbus behaviours as issues on the LinuxCNC github site.