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

DIR/PULSE issue resolved, thank you!! (2026-08-19)

viewsat wrote:

meister wrote:

All my positive terminals are connected to the purple cable via a thin wire.

Dirhold isn’t the problem; it really is the voltage that’s coming through – there was a clear difference between 3.3V and 5V.

My connections are like in your image, but with EN connected.

You could use a multimeter to check what voltage is coming through your DIR pin.
 
I suspect that when the DIR signal starts acting, it might not follow the set dirhold wait time, outputting PULSE before the process is complete. When encountering a motor driver with a slow dirhold response, this results in an invalid PULSE output. It's strange that increasing the dirhold value doesn't solve the problem; this is a problem I don't understand.
 

You can check that Dirhold is working using Testbench and by monitoring it on an oscilloscope or logic analyser.
It worked for me with the default settings, but it’s certainly better to set it to the manufacturer’s specifications to be on the safe side.


(cd riocore/plugins/stepdir/ ; make)



In my tests, the problem only occurred at 3.3V;
if you Google ‘DM542 problem’, you’ll find lots of reports of the same issue.[/quote]

meister wrote:

viewsat wrote:

meister wrote:

All my positive terminals are connected to the purple cable via a thin wire.

Dirhold isn’t the problem; it really is the voltage that’s coming through – there was a clear difference between 3.3V and 5V.

My connections are like in your image, but with EN connected.

You could use a multimeter to check what voltage is coming through your DIR pin.
 
I suspect that when the DIR signal starts acting, it might not follow the set dirhold wait time, outputting PULSE before the process is complete. When encountering a motor driver with a slow dirhold response, this results in an invalid PULSE output. It's strange that increasing the dirhold value doesn't solve the problem; this is a problem I don't understand.
 




You can check that Dirhold is working using Testbench and by monitoring it on an oscilloscope or logic analyser.
It worked for me with the default settings, but it’s certainly better to set it to the manufacturer’s specifications to be on the safe side.


(cd riocore/plugins/stepdir/ ; make)

In my tests, the problem only occurred at 3.3V;
if you Google ‘DM542 problem’, you’ll find lots of reports of the same issue.


I apologize for asking so many questions. I always use 5V to power the 74HC245 and the driver. If there's a problem, usually adjusting the DirHold time is all that's needed. When I use a Mesa 7i92 + 74HC245 (5V) + DM542 (pulse=10, DirHold=25), everything works perfectly, and it correctly returns to the zero position. However, when I switch to a Tang Nano 9k+ + Riocore + 74HC245 (5V) + DM542 (pulse=10, DirHold=25), it fails to return to the zero position, and adjusting the DirHold time doesn't help.

 

DIR/PULSE issue resolved, thank you!! (2026-08-19)

Sorry for my poor English – enjoy it; it’s the first and probably the last video in which I’ll try to speak English.

www.youtube.com/shorts/u9xUOXN080M

Well, yes, blue is a 3.3V level, as I measured it directly at the FPGA pin

tommylight wrote:

I have never written anywhere that I forbid anyone to do anything.
I wrote that modifying Chinese electronics is a bad idea, which is true for several reasons.
Cheap PCBs do not tolerate re-soldering very well, the copper peels off from the substrate, even if something works well immediately after such an operation, there is no guarantee that it will work after a month or a year.
Is there any prohibition against writing about it?

---

PC817 is a strange chip that works in a strange way.
First of all, it is an analog circuit, not a digital one.
Secondly, the input is controlled by current, not voltage, and the output forces current, not voltage.
In addition, the frequency response strongly depends on the input current, a small current means a small propagation time, but also a small output current.
The chip can work really fast (several dozen kilohertz), but then it may not drive the next stage with a small current.
However, when driven by high current, it may have problems already at a few kHz.
There must always be some compromise, assuming that the designer knew what he was doing and did not assume that if the PC817 withstands 50 mA, 20 will be fine...

PC817 is a strange chip that works in a strange way.
First of all, it is an analog circuit, not a digital one.
Secondly, the input is controlled by current, not voltage, and the output forces current, not voltage.
In addition, the frequency response strongly depends on the input current, a small current means a small propagation time, but also a small output current.

Not really strange at all, almost all transistor/Darlington output optocouplers function this way
and this type optocoupler is by far the most common.

Logic optocouplers also typically have current inputs (since the input  of most optocouplers   is simply a bare LED)
but differ in having a voltage output.
 

DIR/PULSE issue resolved, thank you!! (2026-08-19)
I used this inexpensive DM542 only for testing RioCore, not for an actual CNC machine tool. The circuit modifications are for technical discussion only, please don't mind. I'm showing four sets of drivers in the photos, but only this inexpensive DM542 has a problem, hence this discussion. Strangely, increasing the dirhold value doesn't solve the problem; I really can't understand this. However, this inexpensive DM542, when used with the same settings on a MESA7I92, shows no positioning error. This inexpensive DM542 was taken from my existing engraving machine for testing.
 

DIR/PULSE issue resolved, thank you!! (2026-08-19)
DIR use pc817 Error!


DIR modified 6N137 ok!!

viewsat wrote:

I'm showing four sets of drivers in the photos, but only this inexpensive DM542 has a problem

A long time ago, 3xTB6560 drivers were popular and I had them too.
There, PC817 supported not only dir inputs, but also step inputs. There were problems with this, but the chips were in sockets and it was easy to replace them with selected ones and it worked somehow.
So there are only two options:
1. Your driver is faulty.
2. This type of driver is poorly designed.
Either way, the cause is not to be found in riocore.