Losing steps on Z axis

[A_Camera]

Although it is capable of high pulse rates, there isn't any control on the CSMIO to limit max pulse speed. However, this doesn't matter. Pulse rate is decided by how fast the motor turns, and how many steps per rev. So, 5000mm/min axis with 5mm lead ballscrew means motor turns at 1000RPM (assuming direct or 1:1 belt drive). 200 steps per rev with 8x microstep setting (pretty typical) gives 3200 microsteps/rev, that is 3200 pulses/rev. So, that's 320000 pulses/min, roughly 5300 pulses/sec. Well within the capabilities of any of the usual drivers. It is possible for pulse rates and wait time between dir and step pulses to be a problem in some systems (e.g. where you can change pulse length) but these are fixed in the CSMIO firmware and seem to work well. I can't think of an obvious reason why you would want to pulse a stepper much faster than this; usually the reason for needing faster hardware is to cope with encoder pulse output from servo systems rather than open-loop steppers.

8x microstep = 1600 pulses/rev, not 3200... your steps per mm should be set to 320. Am I wrong about this?

Here is how I calculate this for my machine:

In my case, my machine is capable of 8000mm/min on each axis, though I limited the Z to 6000 mm/min. If all axes are moved at the top speed, that means a total of 22000 mm/min, which is equal to 366.7 mm/sec. Each mm requires 400 pulses (2000 per rev), so that speed requires 146666 pulses for all axes maximum speed, which is OK, since my drivers are capable of maximum 200 kHz. BUT... if I had dual screw on one axis I'd be driving with a total of 30000 mm/min, which is 500 mm/sec which would in my case require 200000 pulses and which is the maximum limit of my drivers. OK, I could change micro stepping to solve that, but never the less, it would make a huge difference.

The pulsing (kernel) frequency means that the (positive or negative) pulse width is equal (1/f)/2 => 2.5us for each pulse, regardless of the speed, if the frequency is set to 200 kHz. Of course, if I'd set my UC300ETH to 400 kHz kernel then I'd get 1.25 us pulses, and the opto couplers may not be able to cope with such short pulses, which is what I noticed. when I tested it out.

Never the less, of course if your speed is limited to 5000 mm/min on each axis then you have 15000 mm/min total speed, which is 250 mm/sec and that should be equal to (in your case) 320 x 250 = 80000 pulses/sec (80 kHz) so there is a large margin. But I don't know the CSMIO, so I don't know how that is generating pulses. I thought it works similar to the UC300EHT and you can set the kernel frequency.

[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