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

PCW wrote:

If this is a drive level issue, note that a 26C31 does not swing to 5V
and its output level is about 2 diode drops below 5V (3.6V) with a 5 mA load.

I connected the motor driver using +5V and A-.
 

Meister, if you were in Taiwan, I would definitely buy one for you. This Riocore ICEBreaker V1.0e circuit board should be a 2026 product; I bought it on Taobao in China in June 2026. At the time, I asked the China seller about a DM542 zero-point positioning error, and the China seller tested it and got the same result. He recommended I discuss it on the Linux CNC forum.  

PCW wrote:

If this is a drive level issue, note that a 26C31 does not swing to 5Vand its output level is about 2 diode drops below 5V (3.6V) with a 5 mA load.I have experience using some MESA control cards and connecting drivers, so I shouldn't have any technical difficulties connecting motor drivers.  

I have experience using some MESA control cards and connecting drivers, so I shouldn't have any technical difficulties connecting motor drivers.
 
 

viewsat wrote:

PCW wrote:

If this is a drive level issue, note that a 26C31 does not swing to 5V
and its output level is about 2 diode drops below 5V (3.6V) with a 5 mA load.
I connected the motor driver using +5V and A-.
 

Attachment not found

 

Yes, connected that way you would get close to 5V drive.

The issue with the 26C31 is that the high level drive does not swing to 5V
but the low level drive does swing close to 0V.

 

The Linux CNC FPGA control board I bought connects to the motor driver, and it works perfectly with the 74HC245.

There is no problem connecting the DM542 using the 74HC245.
 

The FPGA (3.3V) is directly connected to the 74HC245 (5V).
 

The problem has been resolved after adjusting the parameters of `joint` and `pid`.

I measured 0.2mm using a logic analyzer, which is not 64 steps.Tang Nano 9k riocore ,leadscwer=5mm,driver= 1600step/revScale_Out=320 ,1mm/320=0.003125mm/step0.2mm/0.003125=64step 
 

Deviations may occur due to the PID controller and the deadband; these shouldn’t exceed ±1.
If you then also take measurements using pendulum movements without setting the G64 parameter, the difference may be even greater.

If you’ve got a logic analyser, why didn’t you use it earlier to measure the pulses?
And if you’ve got something like that, you must have a multimeter too, yet you still haven’t measured the voltages at the DIR pin.
This is a hobby project; I’m really happy to help, but there are limits – especially when you keep posting such fragmented information in the thread.

The only thing I can say is, yes, there are definitely 1,000 bugs in Riocore and a lot of things could be handled better.
I try to implement it as best I can; when bugs are reported to me, I try to fix them as soon as possible.
But if neither DIR nor Scale were working here, you certainly wouldn’t be the only one to report it.

I’ve no idea how many people use Riocore – I don’t think it’s that many –
If I keep coming across new boards from all over the world that have been built specifically for Riocore,
then I suppose there must be one or two people using them.
and the complaints seem to be kept within reasonable limits.

The problem has been resolved after adjusting the parameters of `joint` and `pid`.

I apologize for asking so many questions.Strangely enough, the MESA7i92 which also has PID and  deadband, does not have output pulse count error. I'm a retired person in my sixties, and I only use CNC as a hobby now. I was so eager to ask because I discovered a problem with motor positioning. In my experience, I haven't encountered any open-loop pulse positioning errors with CNC controllers,so I only checked it with a logic analyzer yesterday,The number of pulses in an open-loop stepper motor must be absolutely accurate. Back in the early days of GRBL, I also found an operation that caused a crash, and I immediately notified the author. After confirming the error, he escalated it to a serious bug and fixed it( github.com/gnea/grbl/issues/238 )

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