Smart Steppers & CONN_LCD

[maxbots]

Re: Smart Stepper?

I am wanting to use four Smart Steppers, but I also want to keep the stock stepper ports. The comment from David in the thread linked above says you can use the CONN_LCD port to drive Smart Steppers. If I am willing to forego the enable pin, can I use this port to drive all four smart steppers? I am more familiar with ATMega-based boards, and I know on those there are only certain pins that you can cycle fast enough to work as the step pins, but I am not sure if that applies here as well. I'm also willing to use the other LCD port if necessary.

If this works, I plan on getting a PCB made to make connecting everything easier, but I just wanted to make sure this will work before putting any more effort into it. If so, are there any particular pins I should use for step vs. dir?

I would prefer not to resort to using the expansion header, just to leave as much future flexibility as possible.

Thank you!

[dc42]

You can only connect 2 external stepper drivers (including Enable pins if you want) to CONN_LCD (and 5 to the expansion board).

Caution, the SmartStepper has a design flaw that gives it a very long (and unknown) step-to-direction hold time. The symptom is layer shifts. To avoid this, I recommend you use half a 74HC74 chip to latch the DIR signal on the rising edge of Step before feeding it to the SmartStepper.

[maxbots]

Thanks for the reply, David.

Do you by chance know if the Mechaduino has the same problem?

[dc42]

@maxbots said in Smart Steppers & CONN_LCD:

Thanks for the reply, David.

Do you by chance know if the Mechaduino has the same problem?

The Mechaduino also doesn't latch DIR on the rising edge of Step. However, it uses interrupts to detect both step pulses and the direction signal; so if they have got the interrupt priorities right, they will process the direction signal first and get the right result.

[maxbots]

Thank you!

[Trampas]

@maxbots
The Smart Steppers use interrupts to process the direction change pin as well, but uses a timer/counter to handle the step pin. This results in the following timing requirements.

The issue with direction change is that it takes time to process the interrupt, aka interrupt latency. I have measured this to take less than 200ns, see table above. This is with the direction change interrupt having the highest priority such that it will even interrupt other interrupts.

Trampas

[dc42]

@trampas said in Smart Steppers & CONN_LCD:

The issue with direction change is that it takes time to process the interrupt, aka interrupt latency. I have measured this to take less than 200ns, see table above. This is with the direction change interrupt having the highest priority such that it will even interrupt other interrupts.

That's good news. Does the SmartStepper firmware ever disable interrupts, and if so, for how long?

[Trampas]

@dc42
The firmware does disable interrupts but only disables the one interrupt needed. For example if a mutex is needed between a timer interrupt handler then the only interrupt that is disabled is the timer interrupt, not global interrupts. Additionally the interrupt priorities are set with the direction interrupt being the highest priority, such that it can interrupt other lower priority interrupt handlers.

Thus asking how long the firmware disables interrupts is a loaded question as it depends on which interrupt is disabled. For the direction pin it is the highest priority and has the lowest interrupt latency and does not get disabled, this is how I can meet the above timing requirements.

With all this said the real world does come into play, and when wiring up the smart steppers most customers run wires between controller and smart steppers. These wires end up adding some capacitance to the step and direction pins. This capacitance slows the rise and falling edges of the step and direction pins based on the pin drive strength and load impedance.

The length for wires and the drive strength of the step and direction pin factors into the timing of the direction and step pins and is often the limiting factor.

I also find that a lot of people think running system at high microsteps is a good thing. Specifically with a lot of stepper drivers higher microsteps rates can create smoother moves, but does not increase accuracy. With the smart steppers the closed loop controller provides the smooth motion, and hence the microstep rate needs to be set to match machine accuracy requirement, usually no more than 16x microstepping and if machine is designed well it would have no microstepping, that is the machine would not count on microstepping for increased accuracy.

Running the step rate faster than machine accuracy required provides no advantages for the smart stepper.

I also find that many motion controllers try to change the step and direction pin at the same time, using one assembly instruction. For example they will set the GPIO port for the direction change and step using one instruction trying to increase speed. This can violate the timing requirements of even hardware based stepper driver chips, worse still is the line capacitance on the step and direction pins will dominate which pin changes first. This can create layer shifting issues as you have stated, even without the smart steppers.

A good motion controller will have some setup and hold time between direction change and step, a great motion controller will have this parameter settable.

Of course controllers like Duet are not designed for using external stepper driver boards. Hence often to use hardware for stuff it is not designed for requires some changes to the hardware or firmware, which is why open source projects like the Duet is great.

Trampas

[dc42]

@trampas said in Smart Steppers & CONN_LCD:

The firmware does disable interrupts but only disables the one interrupt needed. For example if a mutex is needed between a timer interrupt handler then the only interrupt that is disabled is the timer interrupt, not global interrupts. Additionally the interrupt priorities are set with the direction interrupt being the highest priority, such that it can interrupt other lower priority interrupt handlers.

What I should have asked is: does the firmware ever disable interrupts globally, by calling cpu_irq_disable (or cpu_irq_save), or __disable_irq, or any similar function?

@trampas said in Smart Steppers & CONN_LCD:

I also find that many motion controllers try to change the step and direction pin at the same time, using one assembly instruction. For example they will set the GPIO port for the direction change and step using one instruction trying to increase speed. This can violate the timing requirements of even hardware based stepper driver chips, worse still is the line capacitance on the step and direction pins will dominate which pin changes first. This can create layer shifting issues as you have stated, even without the smart steppers.

RRF doesn't do that. What is does is to generate the rising edge of all the step pulses required simultaneously. Then it computes the times that the next step pulses are due. If the next step pulses are in the reverse direction, it changes the direction signal at that point, taking care to satisfy the configured step-to-direction hold time if it has been configured. Then it generates the falling edge of the step pulse.

@trampas said in Smart Steppers & CONN_LCD:

Of course controllers like Duet are not designed for using external stepper driver boards. Hence often to use hardware for stuff it is not designed for requires some changes to the hardware or firmware, which is why open source projects like the Duet is great.

Yes it is! You can configure the step pulse width, step pulse interval, direction-to-step setup time and step-to direction hold time separately. But the user needs to know what values to configure, and the setup/hold times are relative to the rising edge of the step pulse.

[Trampas]

@dc42 said in Smart Steppers & CONN_LCD:
Yes it is! You can configure the step pulse width, step pulse interval, direction-to-step setup time and step-to direction hold time separately. But the user needs to know what values to configure, and the setup/hold times are relative to the rising edge of the step pulse.

That is awesome, the last I checked a few years back the Duet firmware was pulsing the enable pin for communication with the Trinamic drivers and thus the firmware had to be changed to make it work with the smart steppers. It is good to know this has been fixed.

Trampas

[Trampas]

@dc42
What I should have asked is: does the firmware ever disable interrupts globally, by calling cpu_irq_disable (or cpu_irq_save), or __disable_irq, or any similar function?

The global interrupts are not disabled in my code. There are certain actions that can cause a stall the processor, ie during flash writes, however these only happen when user initiates them by changing settings and not during normal use.

Trampas

[maxbots]

@dc42 Based on @Trampas comments here, would you say that this should address the concerns you raised with the Smart Stepper?

[dc42]

@maxbots said in Smart Steppers & CONN_LCD:

@dc42 Based on @Trampas comments here, would you say that this should address the concerns you raised with the Smart Stepper?

It all sounds good. I had a feeling that someone else had run into direction hold problems using a Smart Stepper, but I may be mistaken - perhaps it was a different device.