Losing steps on Z axis

[Arzo10]

Had a similar problem when I set up my new router. Checked all mechanical components, made sure no slippage anywhere. Still lost z position. Not sure how your drivers are connected but I would double-check polarity of step signals between BOB and driver. When you changed the driver, did you also have to make any changes in Mach3 (or other motion control software) - like step signal polarity or z direction? That was my problem - driver is triggering on wrong edge of step pulse and the end result is that you lose one step every time you change direction. Doesn't really show up on a simple xy profile cut but once you get a lot of z movement, that's when you see the effects. If that is the problem, fix is very easy.

So, how's the driver connected, and did you change anything when you swapped drivers? What were old and new drivers?

Hello, yes i had to change the direction​ when i put the driver in the previous was a leadshine DM856 and the new one i put in was one from cnc4you
Cwd556. Now what i will say is I did have to change the steps per unit but nothing else was changed. From changing the driver what i did notice was the sound of the z going up and down was considerably louder?

[Neale]

I understand that you are using a CSMIO motion controller. In all other respects, this is a good thing - I use one myself! However, assuming that it uses differential signalling to the driver (which is also a good thing) then it is very easy to get, literally, your wires crossed. Quick way to check is to go into Mach3 -> ports and pins -> motor output and click the Step Active Low box (changes from red cross to green tick). This is exactly equivalent to swapping the wires between CSMIO and the driver. Just do this for Z, if the other two axes are OK. Then do another test.

This is my red-face moment - despite working very carefully, when I wired my control box I managed to get these exact same connections swapped myself. However, as I say, if this is the problem (no guarantees but it sounds very familiar) then this will fix it. Then you can go back and recheck your "steps per" settings as these might have been affected by the problem. If this is not the problem, then nothing bad will happen and you can put the Mach3 setting back as it was and look further for the problem. However, this is so easy to do and check that it's worth taking a few minutes to try it first.

[Arzo10]

I understand that you are using a CSMIO motion controller. In all other respects, this is a good thing - I use one myself! However, assuming that it uses differential signalling to the driver (which is also a good thing) then it is very easy to get, literally, your wires crossed. Quick way to check is to go into Mach3 -> ports and pins -> motor output and click the Step Active Low box (changes from red cross to green tick). This is exactly equivalent to swapping the wires between CSMIO and the driver. Just do this for Z, if the other two axes are OK. Then do another test.

This is my red-face moment - despite working very carefully, when I wired my control box I managed to get these exact same connections swapped myself. However, as I say, if this is the problem (no guarantees but it sounds very familiar) then this will fix it. Then you can go back and recheck your "steps per" settings as these might have been affected by the problem. If this is not the problem, then nothing bad will happen and you can put the Mach3 setting back as it was and look further for the problem. However, this is so easy to do and check that it's worth taking a few minutes to try it first.

This seems to have fixed the problem :-) thanks alot

[A_Camera]

Hello, yes i had to change the direction​ when i put the driver in the previous was a leadshine DM856 and the new one i put in was one from cnc4you
Cwd556. Now what i will say is I did have to change the steps per unit but nothing else was changed. From changing the driver what i did notice was the sound of the z going up and down was considerably louder?

I don't know the DM856 or the Cwd556, but if you are using CSMIO then I think one problem can be the pulsing frequency. If I am not wrong, CSMIO is capable of running much faster than 200kHz and most drivers can only handle maximum 200kHz pulsing. Perhaps that was not an issue with the DM856, but may be an issue with the Cwd556. I know I can run my DQ542MA at 400kHz, even though they are also only for 200kHz, but since I occasionally experienced some issues when I ran them outside the specs, I reduced back to 200kHz and my problems were gone. So, have a look at your pulsing frequency and reduce to 200kHz if set higher. Also check the specs of Cwd556 regarding this, and keep your pulsing at or below that level.

[Neale]

I don't know the DM856 or the Cwd556, but if you are using CSMIO then I think one problem can be the pulsing frequency. If I am not wrong, CSMIO is capable of running much faster than 200kHz and most drivers can only handle maximum 200kHz pulsing. Perhaps that was not an issue with the DM856, but may be an issue with the Cwd556. I know I can run my DQ542MA at 400kHz, even though they are also only for 200kHz, but since I occasionally experienced some issues when I ran them outside the specs, I reduced back to 200kHz and my problems were gone. So, have a look at your pulsing frequency and reduce to 200kHz if set higher. Also check the specs of Cwd556 regarding this, and keep your pulsing at or below that level.

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.

[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!