Solving the USB Latency Dogma for HMI/MPG: Technical Feedback Request

unknown wrote:

So.....you are wanting testers for a closed source hardware project
What's in it for the testers ?

 

I don't want you to be my free testers. 
To do this project I came up with, I first experimented on a breadboard and then created the PCBs with the features I wanted. Unfortunately, I made some youthful mistakes in hardware development... trivial but significant...
I redid the PCB designs but haven't ordered them from the service yet. For now, I've already spent enough money on a "gamble." 
If you want, there are some kits that need fixing, so it would arrive with various jumpers soldered on the fly.
In any case, the eval version is fully functional like the final one, but it doesn't have all the peripherals enabled. 

COFHAL wrote:

Thanks, I had an error in the rules file, that's why that error appeared.

Thanks COFHAL! You're right, I found the typo in the README and demo files. I missed a curly bracket in thepart of the udev rule.I've just pushed the fix to the repository. This is exactly why community feedback is so important! Now everything should set up correctly with a simple copy-paste.

Another error I found is in the io_decoder-keymap.cfg file. In the example, there are comments with #, and when LCN is run, errors appear. I deleted all the extra lines and only left the lines that assign keys to the inputs.

Hi everyone,

I’ve just released version 1.1.0 of the io_decoder driver. This update focuses on architectural stability and addressing initial feedback from the community.

What's new in v1.1.0:

Asynchronous Threading: I have moved the keyboard emulation logic (uinput) out of the Real-Time HAL thread and into a dedicated user-space thread. This ensures that any system-level delay in processing keystrokes will never interfere with the real-time performance of the CNC HAL components.

Config File Optimization (Credits to COFHAL): Following COFHAL's feedback regarding parsing errors with comments and blank lines, I have refined the io_decoder-keymap.cfg structure. I've implemented a stricter formatting requirement to keep the driver lightweight and added clear instructions within the config file to prevent GUI warnings.

Full English Translation: The source code and all comments have been fully translated to English for better accessibility.

Clean Exit: Improved the cleanup routine to ensure proper thread termination and resource release upon hal_exit.

You can find the updated source code, documentation, and the new pre-packaged ZIP on GitHub and the project landing page:

GitHub Repository: github.com/bobwolfrst/io_decoder-linuxCNC Project Page & Downloads: bobwolfrst.github.io/io_decoder-linuxCNC/

A big thanks to COFHAL for the valuable feedback. I’m looking forward to hearing from more testers about how the new threading model performs on different hardware setups!

Happy milling!

I think I need to apologise, I'm currently testing a working serial/USB setup.
Not simple IO, 1kHz loop 3-axis stepper real-time control.
But I can't quite believe it yet, still have a lot to test.

I actually wanted to try building something for the RPI serial port, small and cheap, but for development I have it on the PC with USB/serial, and the bloody thing works.

www.youtube.com/shorts/y8dZws3POOs

Unfortunately, the test quickly shows why it is not a good idea to do something like this:
This is why USB is not suitable for real-time applications, as there is no guarantee that all data will be available within a certain time frame.

But my actual goal is to run the whole thing on the Raspberry via serial port, using RS422.

not knowing how you print your message but how much of your main loop taken up by printing your message? It might not be as bad as you think.
Maybe an exercise for halstreamer?

This issue originated from LinuxCNC and occurred nine times within ~30 minutes.

not sooo bad

Hi everyone, I’ve been away for a few days focusing on the hardware side of the project.

Regarding meister's tests: they are very interesting! They confirm exactly why io_decoder is specifically designed for HMI (MPG, buttons, and operator panels) rather than real-time axis control.

While a 100-200ms jitter is critical for stepper motor timing, it is virtually imperceptible for an operator pressing a 'Coolant' button or turning a feed-override knob. By moving the logic to a dedicated user-space thread in v1.1.0, we ensure that even these USB latencies never interfere with the core LinuxCNC Real-Time performance.

Small update: I’ve just ordered a very limited run of 5 'Ready-to-Use' hardware kits (Core + IN/OUT expansions) for those who want a plug-and-play experience without the hassle of SMD soldering. I'll have them in my hands soon for final testing.

If anyone is interested in being one of the first 5 'beta-testers' for the official hardware, stay tuned!