LinuxCNC-RIO - RealtimeIO for LinuxCNC based on FPGA (ICE40 / ECP5)

Hi everyone,
First off, huge thanks to the @meister for the amazing work on RioCore and Rio Flow. It makes FPGA-based configurations for LinuxCNC much more accessible and structured!
I’m currently setting up a machine using RioCore with a Touchy interface and a physical control panel (hardware buttons, safety relays, etc.), and I have a couple of architectural questions regarding custom HAL management:
1. Loading Custom Real-Time Components in Main HAL (e.g., ClassicLadder)
Is there an intended workflow or plans to allow custom HAL code injection inside Rio Flow?

• Use Case: I need to load and thread ClassicLadder (
  Code:

  loadrt classicladder_rt ...
  , 
  Code:

  loadusr -w classicladder my_logic.clp
  ) to handle auxiliary machine logic and map FPGA inputs/outputs directly to 
  Code:

  %I
   and 
  Code:

  %Q
   points before the motion thread starts.
• Currently, modifying generated main HAL files requires re-editing them after each export. Would it be possible to have a persistent "User HAL Block" or a dedicated non-destructive include file in Rio Flow?

2. Managing Custom PostGUI Nets Without Being Overwritten
How should we best handle GUI-dependent nets across exports?

• Use Case: Connecting physical hardware inputs mapped in RioCore to GUI-specific pins like 
  Code:

  touchy.cycle-start
  , 
  Code:

  touchy.single-block
  , or 
  Code:

  halui.machine.on
  .
• Since these pins only instantiate after the display loads, they must live in the PostGUI phase. However, each time Rio Flow regenerates/exports the setup, the auto-generated PostGUI call chain (
  Code:

  postgui_call_list.hal
   / 
  Code:

  custom_postgui.hal
  ) gets wiped/reset.

Is there a recommended way to structure user-defined pre-GUI and post-GUI files so Rio Flow leaves them untouched, or is native support for custom code injection / user PostGUI nets planned for future releases?
Thanks in advance for any insights or tips on how you guys are handling this!

Hi Oxbown,
thanks

you can add your own .hal files to the call_list's:

$ cat Output/Tangbob/LinuxCNC/pregui_call_list.hal
source my_own_pregui.hal

$ cat Output/Tangbob/LinuxCNC/postgui_call_list.hal
source custom_postgui.hal
source my_own_postgui.hal

these extra source entries are not removed during generation


i add the 'touchy' prefix to POSTGUI_COMPONENTS (riocore/generator/hal.py),
now, all generated HAL entries beginning with ‘touchy’ should end up in the PostGUI HAL (in main and dev branch / git pull)

Unfortunately, I haven’t used ClassicLadder yet, so I can’t be much help there,
but it’s a good opportunity to mention a specific feature in Rio again

When specifying a signal source, you can use various logic and functions.



I think it’s a killer feature that doesn’t get nearly enough attention

you can start a demo configuration:
```
rio-generator -S riocore/configs/haldemo/virtual-signals-axis-pyvcp.json
```

Hi,
Thank you so much for the quick fix on the touchy prefix and for explaining the call_list mechanism! That makes managing external custom files much cleaner. Also, the virtual signals logic feature looks very neat and powerful—I'll definitely look into the demo.
Regarding signal assignment in Rio Flow: while having auto-detection via POSTGUI_COMPONENTS works great for standard prefixes, would it be possible to add an explicit target selector in the UI (for example, a dropdown or toggle in the HAL-Signals section to choose whether a connection belongs to Main/PreGUI or PostGUI)?
Having this option directly in the GUI would give maximum flexibility:

• It prevents having to hardcode every possible GUI/component prefix inside POSTGUI_COMPONENTS.
• It handles custom user interfaces, custom PyVCP/GladeVCP panels, or non-standard naming schemes seamlessly.
• It allows users to decide explicitly where each net lives directly from the Rio Flow design environment.

Thanks again for the great support and active development!

only in dev branch:

Dear meister, after adjusting the joint and pid values ​​correctly, I observed the DIR circuit of the DM542 with an oscilloscope and found that the PC817 was delayed by more than 60 usec. Setting dir_delay to 80 usec allowed it to correctly return to the zero position. I apologize for asking some silly questions a few days ago.
 
 

@viewsat you can tune the PC817 with lower resistance values on the transistor side, this produces a steeper slope