Advanced Search

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'll be using my Claude Code / Fusion to recreate the demo example, then if that goes well I may attempt a fairly simply layout that I was planning to do myself.

Like others, I've spent hundreds, perhaps thousands of hours of my life doing PCB layouts over the past 50-odd years, either personally or sitting alongside CAD jockeys. Good layout artists are a rare breed, yet few experienced engineers fancy spending their time simply laying out boards. If these agents can successfully acquire that knowledge and experience, perhaps we can end up with tools that deliver robust designs in record time. That's how technology moves forward in leaps and bounds.

NWE wrote:

Just today someone showed me a video of the latest Tesla car. Almost like science fiction but it is for real.

It is not real.
How can you believe that is a 2 ton car doing that?
That is a 20-40Kg heavy something that looks like a car.

@Muzzer introducing Hydrogen electronics prototyping.
Now THAT blows my mind.   Finally I run into an ai project that genuinely shocks me. I have spent many hours designing PCBs using KiCAD. Seeing the Hydrogen capabilities nearly makes my hair stand on end. I might cautiously try it out sometime.
Exciting times!

I think now I better understand some professional software developers' reactions to the ai craze, now that I personally see ai help draw a PCB. Can ai really get it right? That fast?

Just today someone showed me a video of the latest Tesla car. Almost like science fiction but it is for real.

NOT my stuff!!!
-
Bumped into this, clearly showing the reasons and the difference it makes using twisted pair wiring, especially for us using machines in high EMI noise environments with all the Plasma sources and VFD's and servos.

NWE wrote:

Same here. When I was new on Github I thought I could fork a project to my account to archive it. Nope one day I came back and discovered my unchanged fork had vanished along with the original author's interesting project.

GitHub is property of microsoft, and as luck would have i bumped today on a project that no longer exists there.
Bit by bit disappearing... and being used in windows as proprietary code. As is over 60% of win11, 45% of win10, etc etc from the network portion of Linux showed into win2k back then.

There is another version of the electronics stuff that also does boards and routing, but still in infancy, getting interesting for sure.
Damn it, i wasted countless days doing electronics when i was young, had to wait till summer to go to Croatia to buy parts and books and magazines, yet it never stopped me from doing ... everything. Youth today can not figure out how to open a barn door!
But can easily figure out how to press 20-30 times on random stuff on the phone to start a useless game!

Within the space of 10 days, there is an embryonic clone of Fusion bubbling away. No CAM yet - but give it time (another week??!).



What is staggering is how rapidly this stuff is coming out - and almost from nowhere.

And on a slightly different note, if you do your own circuit and PCB design, there are some pretty interesting tools coming along, also free to use:



Give these tools another year or two and they will become much more robust and dependable. Exciting times!

Hermle_Gerald wrote:

Die Ansteuerung +/- 10 scheint bei Linux nicht sehr verbreitet zu sein. Was spricht eigentlich dagegen? 

Das funkt wunderbar mit LinuxCNC, wir haben mehrere 15 ton machinen die +/- 10V nutzen.
Mixt niht diese sache, +/-10V funkt nicht nur mit dem DM servo treiber/motoren, ales anderes ist in ordnung.

Hi tuxcnc,You are absolutely right that the simulator cannot know which physical tool has been installed if that information is never provided.I think I didn't explain one important part of our concept clearly enough.The simulator is not intended to receive all its information exclusively from LinuxCNC. It should eventually have its own virtual machine operator interface.Think of a real CNC machine with a manual tool change.LinuxCNC requests T5, moves to the tool change position, and waits for the operator. But LinuxCNC cannot physically verify which tool the operator puts into the spindle.Our simulator should behave similarly.The user would be able to select and install a physical tool through the simulator interface. That tool could be T5, but it could also be T3 by mistake.The simulator would then use the actual geometry of the installed virtual tool, independently of the tool information stored in LinuxCNC.The same principle applies to workpiece positioning, tool lengths, and eventually fixtures and collisions.Of course, this requires a virtual tool library and an operator interface, neither of which is implemented yet.Your example of the M6 REMAP moving to a toolsetter is particularly interesting. The simulator already receives the axis movements through Stepper-Ninja, so those movements do not need any special G-code handling.Once we have physical tool geometry and a virtual toolsetter, we could also simulate the actual contact with the sensor and return its signal to LinuxCNC.I agree that additional communication might be useful for automatic tool changes and other machine functions. However, I would prefer to keep the original Stepper-Ninja protocol unchanged if possible, and investigate a separate interface for simulator-specific interactions.The main idea is to simulate the physical machine independently of the controller's assumptions, including situations where the operator makes a mistake.Thank you for challenging this concept. These discussions are very helpful for defining the architecture before implementing the next features.

Ich benötige 7 Ausgänge, 18 Eingänge, 3 Poti Anschlüsse. Wegen Reserve hätte ich noch gerne etwas mehr. 
Wenn die Maschine etwas bearbeitet. Muss das 100% passen. Einen Schrittverlust kann ich mir nicht erlauben. Das Ziel ist Oldtimer Motorblöcke nacharbeiten. Die Genauigkeit hat oberste Priorität. Geschwindigkeit ist mir nicht so wichtig. 
Daher möchte ich Close Loop. Die Ansteuerung +/- 10 scheint bei Linux nicht sehr verbreitet zu sein. Was spricht eigentlich dagegen? 

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

 

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...

 

I did soma latency testing and tuning. What helped most was to turn off hypertheading which reducedjitter from 30 to around 22 microseconds. Other bios settings like HPET off, EPU power saving, and cpu turbo on or off in my case made little to no difference. So did isolcpus, irqaffinity, nohz_full, and rcu_nocbs. rcu_nocb_pull yielded one microsecond less, so did setting sched_rt_rumtime_us to -1.

Please note RedHat warns to do this;

Issue

Is it safe to set /proc/sys/kernel/sched_rt_runtime_us to -1?

Resolution

In short, setting sched_rt_runtime_us to -1 can be extremely dangerous. A value of -1 means no limit. In other words, a "run-away" real-time task will be permitted to monopolise a CPU which could (potentially) lock up a system. The default value for sched_rt_runtime_us is 950000 or 0.95 seconds. Broadly speaking, this allows 0.05 seconds to be used by other non-real-time tasks (i.e. SCHED_OTHER) - a small window at which to recover a system.

The kernel parameter namely /proc/sys/kernel/sched_rt_runtime_us can be set between -1 and (INT_MAX - 1).

I left it at -1 anyway. In the end I was able to reduce jitter from sightly above 30 microseconds to just below 20. All test were done with one instance of glxgears running.

The cs-d508 driver reports by led signal when no motor or just one coil is connected. When good, all coils of both motors have a resistance of 2 ohms , they should have 1,8 according to the data sheet. Inductance is perfectly 5 mH. Damaged coils in my case still show a resistance of one Ohm. Maybe this is just enough for the driver not to notice any problem like a short circuit or similar.. I had motors in the past seeing similar temperatures that did not fail that quickly.