PIO shift register data transfer timing.

[andrewmarles]

Just wondering if people have done much testing on the shift register code? Has anybody else run into any timing issues?

When I was testing my board in my 3 axis mill, I found that I was getting inconsistent steps. Digging a bit deeper I found that the setup/hold requirement of the 74HC595D might not always be met:

According to the datasheet, the HC595 needs the data clocked on the rising edge. PCB skew in this design is ~17 ps between clock and data so I do not believe it is a layout issue.

I added side-set delays to ensure that the clock and data are aligned correctly and slowed them down to ensure that the data transfer is robust. This should still allow for step rates around 300 KHz which is faster than most external drivers can handle. Since these delays are in the PIO they should not slow down the application.

[terjeio]

Just wondering if people have done much testing on the shift register code? Has anybody else run into any timing issues?

I have only tested with a scope - and I do not think many are using this driver as there are currently no breakout boards out in the wild unless Phil has shipped some of the test boards he made. Do you have one or have you made your own?

What kind of issues have you seen?

I added side-set delays to ensure that the clock and data are aligned correctly and slowed them down to ensure that the data transfer is robust.

Great - can you make a PR?

For now I'll test the current code with Phils board and my CNC machine simulator, I want to see if that would detect timing issues.

[andrewmarles]

Yes, I did my own RP2040 board. Still testing before I post the design. It uses the HC595D for step/dir and TCA9539 for aux IO. I will post a PR for the TCA9539 driver shortly as it is a very small change to get the outputs working with your PCA9654E code as a starting point.

[terjeio]

Thanks for feedback.

I am testing with the simulator now. There is a bug in driver.c that leads to extra step pulses beeing output on direction changes, I'll run some longer tests with the current PIO code before I check with your version.

[terjeio]

Removing this line

RP2040/driver.c

Line 546 in 2f62cde

step_dir_sr4_write(pio0, 0, sd_sr.value);

fixes the extra step pulses problem.

There is a remaining "bug" - setting the step pulse length and delay does work as I did not add the code required. To be fixed in the next build.

I ran a few tests with a 9000 line program without the step count going bad with the current PIO code, running a 10 hour test now. If this does not fail then the shift register timing is (close to) ok after all? Set-up time is 3ns according to my datasheet, a one (or two) cycle delay should be enough to get it well inside?

[andrewmarles]

I agree a shorter delay is probably sufficient, I just set it to max because I am conservative and don't need to run it at full speed for my slow milling machine. Maybe at some future point we can find a way to make it easier to configure at least at compile time - I know that for my machines I would set it up for the slowest timing that meets the performance requirement. But if you are running a laser or integrated drivers you would want higher step rates. I will try to get a board running with your fix and the tighter timing on my mill in the next few days and we can see if it seems reliable in that setting. Thanks for looking at this.

I had not come across something like your simulator board before, very handy tool.

[andrewmarles]

So I tried these changes on my milling machine this morning with the side set delays and the change to driver.c noted above. It is much better, I can jog in all directions now, but it appears that the machine is not getting consistent direction changes. I need to dig deeper to describe exactly what is missing, but as you run a program the x axis is missing direction changes and starts wandering off to one side. Also, I need to set the step invert on Y to get any movement at all on the X axis, which is clearly weird. This is even with the side-step delay set to maximum, so I don't think it is any kind of setup/hold problem. I think that the bit signals still aren't quite lining up correctly. I think it happens more when X and Y are moving together as I get an error 8 when homing if XY home together - the X axis doesn't pull pack correctly after the first search pass. But If I home the axes individually it is successful.

I am going to switch to a different setup with a smaller machine (at my desk) and also take another board and set it up on a logic analyzer so that I can dig into this more and help understand exactly where things are going wrong, at the very least I want to understand if it is something specific to my board.

[terjeio]

I have tweaked your PR so that clock and latch pulses are equal length and tuned them to make each transaction take about 0.8 µs. Minimum dir change to step delay cannot be shorter than this. I will soon commit the changed code.

FYI I have now run some 10h tests with an 8-bit Arduino Mega, this also ends up with a small and random number of erroneous step counts.

[Volksolive]

It could be nice to send directly step and dir to the board instead of G-code and bypass the planner / motion-control to see if there is any issue in the PIO code.
Anyway, it seems like all board have little deviation in all axis ..
Do you have a way to test your simulator ? Just to be sure that there is nothing there that could explain these errors.

[terjeio]

It could be nice to send directly step and dir to the board instead of G-code and bypass the planner / motion-control to see if there is any issue in the PIO code.

You can do that by setting up a stepper_t struct and calling hal.stepper.pulse_start(), possibly from a small plugin that adds a M-code?
However, I doubt it is the PIO code as all the drivers I have tested with show the same issue.

Anyway, it seems like all board have little deviation in all axis ..

Even legacy grbl on a Mega2560 shows this behaviour, what bother me a bit is that it is random.

Do you have a way to test your simulator ?

I think so, could start by feeding pulse trains to it. If it is a timing problem related to dricetion changes that could be harder to test for.
Currently I have a single sided prototype board with a bit of jump wires, I want to do the testing with a professional made board. I have to order some and get it done.

[andrewmarles]

With your CNC simulator, how do you determine your baseline/expected pulsetrain?

[terjeio]

@andrewmarles Currently I have only tested with running long gcode programs that starts from 0,0,0 and ends up back there. This should result in the simulator counters coming back to zero as well. I have run some straight cuts and short programs too to check that the count values are correct - these has not failed.

I have an Analog Discovery 2 that I believe can generate pulse trains and also count them, I could run some tests with that.