In tame testing environments, it's easy to have packet loss rates lower than 1 in a billion. But in electrically noisy environments, it is not feasible to require 0% packet loss between LinuxCNC
and a hostmot2 ethernet card. At present, however, a single lost read request or read response packet causes missed realtime deadlines; a lost write packet can also have serious consequences (e.g., loss of the packet that sets the index-enable flag during homing could cause a machine to run into a hard limit)
- Allow hm2_eth to work properly even in the presence of low packet loss. "low" is not yet defined, but is perhaps 1/1000 or 1/10000.
- Don't miss realtime deadlines when a read response doesn't arrive
- Use a packet count register to detect lost write packets, and recover somehow
- Also make sure to discard any packet that has arrived too late (recv() to blackhole before sending read request?)
- what to do about reads and writes with side effects (not idempotent), such as UART FIFOs, index/latch enable writes, etc
- Allow hm2_eth to detect high packet loss in a way that can be hooked to the estop chain
- Allow the rest of linuxcnc to work properly
- Suppose a missed read packet causes position to be held for 1 servo cycle. pid will ramp its output inappropriately, and motion might signal a following error.
- Possibility 1: modify these components to behave differently when a lost packet is detected
- Possibility 2: modify hostmot2 so that it produces a fake updated position when a lost packet is detected
Linux iptables can simulate packet loss. For higher level testing, a stepper-type configuration can be used without attached hardware beyond the