@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

@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

@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

@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

I did see the code for the analog output, but my sensor is digital.

I had thought about moving the Z axis but the way my probe works it is important that the bed is moving when the probe is turned on.
I will try getting the distance and see if I can drop the speed and turn on the probe when we hit the dive distance.

Right now I am trying to understand the code enough to feel comfortable making the changes.

Thanks

I think it might be for digital differential analyzer, see https://en.wikipedia.org/wiki/Bresenham%27s_line_algorithm
and https://en.wikipedia.org/wiki/Digital_differential_analyzer_(graphics_algorithm)

The machine I am using homes the Z at the top, then does Z probing. I wanted to turn on the Z probe and then slow down the probing as the Z axis got close to the bed. I will see if I can figure out to find the correct DriveMovement object for the Z axis and get the height.

Thanks

Is it possible to get the current machine position before a move is completed?

Also out of curiosity what does the DDA stand for?

Have you picked out an RTOS?

First I want to thank you guys for all the hard work and excellent coding that was put into this project.

I am looking through the source code, starting to understand what is going on, specifically with with respects to bed leveling. A

As I understand the code for bed leveling a state machine runs in the Gcodes:Spin() function which handles the moves related to bed leveling. As I understand the code, please correct me if I am wrong:

1. The GCodes class basically fills in a RawMove structure for the next move
2. the Move class then consumes the RawMove structure and issues the movement

For bed leveling the GCodes:Spin() state machine is used to handle the multiple moves required for bed leveling. I was wondering (again assuming my understanding is correct) if it would be cleaner to have middle layer, kind of a motion planner, which would do the bed leveling state machine. Again since I am a newbie to the code and based on the nice level of abstraction already done I assume this was thought of and was not done for some reason hence I wanted to understand more.

thanks
Trampas