Re: Losing steps on Z axis
Quote:
Originally Posted by
Arzo10
Ok so, a couple of weeks ago i changed my stepper driver to a totally different one that was in it.
Yesterday I tried doing a halftoner tool path (loads of z movements)
Halfway through i notice hey this looks abit deep here. So i checked and i had lost like 18mm. So ok i zero and try again. Same thing happens.
Run a profile cut today on some small items and i lost 2mm
I have tried decreasing acceleration and velocity on the z axis in Mach 3
This didn't work.
Checked all set screws and bolts on z everything is tight.
Is this just totally the wrong driver or what is happening here it is driving me bonkers please help.
I think you need to give more info ie links to drives and motors etc pics would help as well
Re: Losing steps on Z axis
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?
Re: Losing steps on Z axis
As Neale says, it does sound like a step/direction timing issue.
What make/model are the old and new drivers?
What controller are you using?
If you're not sure, post up some pictures.
Re: Losing steps on Z axis
Quote:
Originally Posted by
Neale
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?
Re: Losing steps on Z axis
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.
Re: Losing steps on Z axis
Quote:
Originally Posted by
Arzo10
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.
Re: Losing steps on Z axis
Quote:
Originally Posted by
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.
This seems to have fixed the problem :-) thanks alot
Re: Losing steps on Z axis
Quote:
Originally Posted by
A_Camera
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.
Re: Losing steps on Z axis
Quote:
Originally Posted by
Neale
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.
Re: Losing steps on Z axis
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.
Re: Losing steps on Z axis
Quote:
Originally Posted by
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.
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...
Re: Losing steps on Z axis
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!
Re: Losing steps on Z axis
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 :-/
Re: Losing steps on Z axis
Quote:
Originally Posted by
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!
So, the night is over ( was too short, as usual... :saturn: )
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.
Re: Losing steps on Z axis
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
