Losing steps on Z axis

[Neale]

You are quite right - I can't do simple arithmetic! However, I believe that the motion controller drives all axes effectively in parallel, not serially. So if X and A and Y and Z all need to step one pulse, the motion controller will send simultaneous pulses to each output at the same time. So the maximum pulse frequency is the pulse frequency of the "fastest" axis. I think (from memory) that the CSMIO gives out 10usec pulses, which is more than the minimum that the stepper driver needs. The maximum clock frequency is related to the exact timing accuracy of pulses but I doubt that in practice you are ever going to generate stepping pulses at that frequency. I could probably drive my router directly from Mach3 and the parallel port with a 20KHz kernel speed; I don't want to do that but it would probably work.

I haven't looked at the pulse generation mechanism in Mach3 or the CSMIO, partly because I can't see inside the code! However, I have looked at something like GRBL, the Arduino-based motion controller. That works by calculating which axes need a pulse at every internal clock cycle and then loading a single output register with bits representing pulses on each channel. That seems to make sense, and I would guess that something similar happens in the other motion controllers. Cuts the required clock rates by a large amount with no loss of functionality.

[A_Camera]

You are quite right - I can't do simple arithmetic! However, I believe that the motion controller drives all axes effectively in parallel, not serially. So if X and A and Y and Z all need to step one pulse, the motion controller will send simultaneous pulses to each output at the same time. So the maximum pulse frequency is the pulse frequency of the "fastest" axis. I think (from memory) that the CSMIO gives out 10usec pulses, which is more than the minimum that the stepper driver needs. The maximum clock frequency is related to the exact timing accuracy of pulses but I doubt that in practice you are ever going to generate stepping pulses at that frequency. I could probably drive my router directly from Mach3 and the parallel port with a 20KHz kernel speed; I don't want to do that but it would probably work.

I haven't looked at the pulse generation mechanism in Mach3 or the CSMIO, partly because I can't see inside the code! However, I have looked at something like GRBL, the Arduino-based motion controller. That works by calculating which axes need a pulse at every internal clock cycle and then loading a single output register with bits representing pulses on each channel. That seems to make sense, and I would guess that something similar happens in the other motion controllers. Cuts the required clock rates by a large amount with no loss of functionality.

No, that's not the way it works. You must regard it as serial not parallel. If you need to move three axes 10 mm each in one second then that's the same number of pulses as moving one axis 30 mm in one second. Yes the move will be made in parallel but the number of pulses the motion controller must generate is three times more in the same time frame.

Edit:
I have to sleep on this and think about it. I may be wrong...

[Neale]

I can assure you that GRBL works by generating pulses for each axis simultaneously. I have read the code! I can't be certain for other motion controllers, but as an architecture it makes sense. After all, the output connections are in parallel and there is no electrical reason why one pulse must follow another rather than happen at the same time. What I don't understand is why things like the CSMIO can run so fast, much faster than necessary, if it is only used for steppers. Perhaps because of the custom hardware in the device?

Happy to continue the discussion when we have both had a night's sleep!

[m_c]

I've not looked at the code for GRBL, but from you're describing I'd guess they're using a set clock tick, and then scaling the required steps to that tick. What that means is the resultant pulses may not be optimally timed.

For example, if you have a 100Hz tick, and you need a 40Hz pulse train, that means you need to generate a pulse every 2.5 ticks. So you need to scale that to the available tick, which means over 10 ticks, you'd end up with 1001000100. You would end up alternating between 20 and 30 millisecond gaps between pulses.

Good motion controllers will nearly always use an FPGA to generate the required pulses, and will run using a very similar principle, but because with the FPGA you are programming logic gates directly (you're not relying on embedded code and additional hardware layers to process that code) they run far more efficiently, with far less latency. You also gain more flexibility, in that you can potentially use independent pre-scalers for each pulse channel, so pulses from different channels don't end up aligned, but at some point there will most likely be slight timing inconsistencies as not every potential output frequency can be matched precisely.

I'd like to be able to programme FPGAs, but all my attempts so far have ended up in frustration, as I struggle to get my head around VHDL or Verilog. It's one of these things I know what I'd like to achieve, however I've never found any good guides to explain the basics, or with examples that actually work :-/

[A_Camera]

I can assure you that GRBL works by generating pulses for each axis simultaneously. I have read the code! I can't be certain for other motion controllers, but as an architecture it makes sense. After all, the output connections are in parallel and there is no electrical reason why one pulse must follow another rather than happen at the same time. What I don't understand is why things like the CSMIO can run so fast, much faster than necessary, if it is only used for steppers. Perhaps because of the custom hardware in the device?

Happy to continue the discussion when we have both had a night's sleep!

So, the night is over ( was too short, as usual... )

Anyway, I was not questioning that the pulses are output in parallel, of course the pulses must be output in parallel otherwise the motion would not be synchronized. The question was more on how to calculate the pulse width needed to produce the parallel pulses. But... after a night sleep I am pretty sure I was wrong in my calculations regarding this. Of course it should be calculated using the maximum speed of one axis only. In my case the motion controller is capable of handling six motors at 400kHz kernel frequency, so it should be able to produce 1.25 us pulses on each of the six outputs in parallel.

Never the less, I posted this question on the product forum of my motion controller (CNC Drive UC300ETH) to get it sorted out and answered by the developers. I could also hook up an oscilloscope and measure it, but it is better if the developers answer. Also, if it is as I now think it is, then I will reduce the kernel frequency to 100kHz since there is no benefit of using anything more that 53.3kHz in my case because of the maximum speed of 8000 mm/min and the micro stepping of 10x I am using requires only 53.3kHz and the nearest above that is 100kHz kernel. It will make the pulse width twice as wide, which is good.

Edit:

OK, it is now confirmed by CNC Drive that the UC300ETH can output 1.25us pulses at 400kHz continuously on all six motor outputs in parallel, so as soon as I get home, I will set my kernel to 100kHz. No need, and no point for anything higher than that in my machine. Still have a VERY large margin to the maximum possible speed at this kernel frequency, which is well above the limitations of my machine.

[magicniner]

A trajectory planner is designed to work with the pulse delivery system available, if a designer only had the option of sequentially stepped axes that would influence the design of the trajectory planner rather than making generation of the required path impossible, at certain speeds there will be points on a given curve where synchronisation of pulses will not be optimal for generating the path and points where it will, the trajectory planner simply delivers the least worst pulse pattern possible.
From the point of view of generating smooth curved paths neither synchronised nor serial pulses would be an optimal method under all circumstances, in the real world with the pulse rates and given the inertia of the motors and machine it probably becomes irrelevant unless working with a perfectly rigid machine on detail which comes very close to the resolution capability of the machine,

- Nick