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

meister wrote:

bladekel wrote:

I tried it as you said but nothing changed.
Again receving "USRMOT: ERROR: command timeout" errors and couldnt control the LEDs.

 

    "rpi5": "true",
->
    "rpi5": true,


 

Thats the trick, thank you.
Its working now... 
 

soooooo, dev is merged to main, no way back

there are some big changes:

### Warning
* breaking changes, please open your config in rio-flow to fix/convert some stuff

### Gui
* new graphical config-gui: rio-flow
* removing old rio-setup

### Genaral
* move all stuff into plugins (boards/modules/breakouts)
* replacing modbus -> mbus/mbus_device/mbus_hy
* replacing i2cbus -> i2c/i2c_device
* better simulation
* test-tool is now based on the hal-component c-code

I am using a Raspberry Pi 5 with the LinuxCNC Debian Bookworm image.
I have configured the system to communicate over SPI.
I can move all axes, but when I run a G-code file, I experience a drift in all axes.

To troubleshoot the issue, I wrote a simple G-code program that only moves the X-axis: it moves 10 cm in the positive direction and then 10 cm in the negative direction.
I set this program to run continuously in a loop. In every cycle, a small shift occurs in the positive direction.
After 20 repetitions, I observed that this drift reached approximately 5 mm.
The start and end points of the program shift slightly in the positive direction with each iteration.
I have also tested it at very low speeds, but the result remains the same.

I am certain there is no mechanical backlash or electrical interference/noise.

I am attaching my configuration files. What do you think could be causing this?

bladekel wrote:

I am using a Raspberry Pi 5 with the LinuxCNC Debian Bookworm image.
I have configured the system to communicate over SPI.
I can move all axes, but when I run a G-code file, I experience a drift in all axes.

To troubleshoot the issue, I wrote a simple G-code program that only moves the X-axis: it moves 10 cm in the positive direction and then 10 cm in the negative direction.
I set this program to run continuously in a loop. In every cycle, a small shift occurs in the positive direction.
After 20 repetitions, I observed that this drift reached approximately 5 mm.
The start and end points of the program shift slightly in the positive direction with each iteration.
I have also tested it at very low speeds, but the result remains the same.

I am certain there is no mechanical backlash or electrical interference/noise.

I am attaching my configuration files. What do you think could be causing this?
 

For those who might encounter this problem, just like me;

This problem is caused by the dir_delay. 
Solved by increasing the dir_delay value.

meister wrote:

I'm trying to decide on a connection for my satellites

Ethernet or Firewire Cables, 5V or 24V ?

* RJ45 is cheaper, but could be confused with Ethernet
* FireWire uses thicker cablesCheaper
* satellite boards can be built using 5V, but 24V is practical for many sensors and limit switches
* RJ45 and 5V are compatible with Mesa-SmartSerial (except for the firmware)

Does anyone have any ideas?

I was going to ask you this very question, I would lean towards RJ45, tx with a gnd twisted pair, same with rx. Otherwise a properly shielded/grounded (at the source point only) cable over a short run, possibly with a bit of passive filtering. I think if either are kept as short runs and don't go looping around a spindle drive it should be OK. 

I think keeping the uart at 5v will save level shifting headaches, keep 24v on the machine hardware side of things. I have some PCB's turning up soon and I will try out the satellite expansions, looking forward to it

A little preview of what’s coming soon.
This will soon allow you to create a board from the flow config,
or at least a template.


->

->

->


 

It should be noted that Riocore can generate the gateware for the FPGA, as well as the complete LinuxCNC configuration (hal/ini/vcp).
In future, however, it will also be possible to build your own boards from this;
to this end, a KiCad template is generated, which can be turned into a complete board with relatively little effort.



already in dev branch, but still need some work:
* verify the kicad modules
* add more kicad modules
* some fixes while update the pcb