Go Down

Topic: Arduino hardware pulse counters? (Read 6750 times) previous topic - next topic

RayLivingston

Maybe you know exactly how to do this and you are just not telling us. But I have a sneaking suspicion that you don't.

What "other parameters" can another Arduino monitor that can usefully be compared with a pulse count?

If you can detect the pulses as they are sent to the motor and also detect the pulses from an encoder a simple AND logic gate (cost less than £1) could be used to detect a disparity between them - assuming, of course, that the number of step pulses per revolution is the same as the number of steps produced by the encoder. Even if there is a simple multiple between motor and encoder steps you could use logic gates to compare things and trip an alarm or shut-down. You won't have a pulse rate that causes problems for the speed of logic gates.

...R
It's not quite that simple.  The CNC controller is issuing step/dir pulses to drive the stepper motor.  Presumably his "feedback" is coming from an encoder on the motor, or perhaps a linear scale on the machine axis.  These two will almost certainly have different resolutions.  Then you have to account for the non-linearities in the stepper positioning, especially if it's micro-stepping (which it almost certainly is on a CNC machine).  Then there is the allowance for following error, due to inertia, load, etc.

This is basically a solution in search of a problem.  Everyone buys into the myth that stepper motors WILL always lose steps, which is simply wrong.  If a stepper system is losing steps, it is because it was not properly designed for the load, period.  Then they buy into the myth that servos will never lose steps, because they have encoders for feedback, so if you put an encoder on a stepper, you can get servo performance.  What they miss is the fact that servos have lots of reserve torque, so they can react to following error by increasing their torque output.  Steppers, OTOH, run at max torque all the time.  Once you get unacceptable following error, you're toast.  There is nothing you can do to recover, other than slow down the trajectory, which low-end CNC controller software (like Mach3, etc.) cannot do.  Thinking stopping the process when unacceptable following error is detected is naive, because by that point, the part is already scrap, as the tool is already off-position.

This topic comes up constantly on CNC forums, and it's a waste of time and effort.  Design the stepper system properly, operate it within its capability, and you will never lose position.  Anything else is a band-aid that does not address the root cause of the problem.

Regards,
Ray L.

kivig

What "other parameters" can another Arduino monitor that can usefully be compared with a pulse count?
Other parameters are not related to pulse count.
If you can detect the pulses as they are sent to the motor and also detect the pulses from an encoder a simple AND logic gate (cost less than £1) could be used to detect a disparity between them - assuming, of course, that the number of step pulses per revolution is the same as the number of steps produced by the encoder. Even if there is a simple multiple between motor and encoder steps you could use logic gates to compare things and trip an alarm or shut-down. You won't have a pulse rate that causes problems for the speed of logic gates.
While that would be a bullet proof real-time solution if done really accurately, what you described is not exactly simple too :) And it's not even that simple as there must be some filtering and/or tresholds, because even if there is no measurement introduced lag, mechanics lag behind actual pulses up to a half full step, encoder never will match exact step angles and distribution, pulse count per step must be configurable etc. Plus no diy "servo" or further reprogramming then.
As described above, I have already realized that at diy price point I probably won't find exactly matching solution, but real world kinematics sometimes are quite forgiving regarding milliseconds response takes.

Try researching the concept of PPM and how it relates to PWM for servo motors.
Not sure what you meant exactly. I have played a bit with PWM and RC servos, however this is a bit another case. Input is in pulses - no choice.

kivig

If a stepper system is losing steps, it is because it was not properly designed for the load, period.
Exactly. But it also happens in unexpected situations, like foreign body, power fluctuation, spindle stall (for cnc), and many other cases that without human attention can lead to lots of damage.

Then they buy into the myth that servos will never lose steps, because they have encoders for feedback, so if you put an encoder on a stepper, you can get servo performance.  What they miss is the fact that servos have lots of reserve torque, so they can react to following error by increasing their torque output.  Steppers, OTOH, run at max torque all the time.  Once you get unacceptable following error, you're toast.  There is nothing you can do to recover, other than slow down the trajectory, which low-end CNC controller software (like Mach3, etc.) cannot do.  Thinking stopping the process when unacceptable following error is detected is naive, because by that point, the part is already scrap, as the tool is already off-position.
Speaking of sevos - the only intention was to be able to use DC motor instead of stepper where nature of motion differs. Long ago I've made a proof of concept CNC with DC motors/homebrew encoders. Lots of mistakes, but with minute corrections, for the price it's unbeatable. BUT is driven only by arduino reading G-code from SD, as it can't accept pulses.
And no, the part is not already scrap. Not all defects are detrimental and if you cut 30 parts at once, one part doesnt' change much.

If a stepper system is losing steps, it is
This topic comes up constantly on CNC forums, and it's a waste of time and effort.  Design the stepper system properly, operate it within its capability, and you will never lose position.  Anything else is a band-aid that does not address the root cause of the problem.
Yes, that's the intention - minimizing damage, when I can't eliminate the root of problem.

RayLivingston

Exactly. But it also happens in unexpected situations, like foreign body, power fluctuation, spindle stall (for cnc), and many other cases that without human attention can lead to lots of damage.
Speaking of sevos - the only intention was to be able to use DC motor instead of stepper where nature of motion differs. Long ago I've made a proof of concept CNC with DC motors/homebrew encoders. Lots of mistakes, but with minute corrections, for the price it's unbeatable. BUT is driven only by arduino reading G-code from SD, as it can't accept pulses.
And no, the part is not already scrap. Not all defects are detrimental and if you cut 30 parts at once, one part doesnt' change much.
Yes, that's the intention - minimizing damage, when I can't eliminate the root of problem.
So what are you using for the CNC controller?  If you just want to limit the damage to one part out of several on a fixture, you only need to track approximate position, feed that back periodically to the controller, and E-stop if the difference between the two crosses an threshold.  If you're using Mach3, you can do it in a simple macro.  If you're doing it with an Arduino, then your step rates are, by definition, pretty low, so the encoder pulse rate need not be all that high.  You don't need a high-count encoder.  You just need one whose resolution is at least about 2X the E-Stop threshold distance.

Regards,
Ray L.

kivig

#19
Jan 22, 2015, 06:56 pm Last Edit: Jan 22, 2015, 06:59 pm by kivig
So what are you using for the CNC controller?
I want to be able to switch CNC controllers freely.
If you just want to limit the damage to one part out of several on a fixture, you only need to track approximate position, feed that back periodically to the controller, and E-stop if the difference between the two crosses an threshold.
That's my intention, however it can be done a bit better with adaptive treshold (lower the speed more precisely deviation can be measured), however your word "approximate" just gave me an idea that I don't know how I missed before - a setting that turns on pulse count reduction. I'm sure there are ICs that might do that.

Edit: deam... It's late, so I'm thinking slowly :D Not so simple - pulses go also down not only up (direction pin).

Robin2

This is basically a solution in search of a problem.
Hear Hear

My "too simple" suggestion was put forward to elicit a response from the OP.

I want to be able to switch CNC controllers freely.
Where is the value in that to justify the cost of developing the monitoring system you are thinking of.

As I said in Reply  #7 this is not a simple problem and, frankly, if there is any chance of success it should be you teaching us.

You still have not given any indication of what data might be available against which the pulse count could be compared in order to detect an error condition.

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

kivig

#21
Jan 22, 2015, 09:17 pm Last Edit: Jan 22, 2015, 10:14 pm by kivig
Ok, so the plan is:
jumper selectable 4 bit up/down counter is fed pulse and direction,
most significant bit (giving 16x reduction) and direction is fed to attiny that counts via interrupt.
Resulting max pulse rate is 25kHz or 320 cycles per pulse on 8mhz atiny, minus interrupt execution (assuming 4us on mega, is it 64 cycles?). Leaving at least 20% for communication, thats about 200. Can 200 cycles be enouugh to do this:
Code: [Select]

long X;
rising_interrupt()
{
if(DigitalRead(A))X++;
else X--;
}

or am I missing something?

Then Attiny bit-bangs the X once in a while (10ms) to Mega.

You still have not given any indication of what data might be available against which the pulse count could be compared in order to detect an error condition.
Against encoder reading. Or did I misunderstood the question?
Where is the value in that to justify the cost of developing the monitoring system you are thinking of.
My goal is not (at least not yet) to create a stationary production line, rather have tools that can be freely hooked up in different combinations on occasional need. Thus compatibility comes before perfection.

Robin2

Quote
You still have not given any indication of what data might be available against which the pulse count could be compared in order to detect an error condition.
Against encoder reading. Or did I misunderstood the question?
That sounds pretty much the same as the suggestion I made in Reply #14 and which you dismissed in Reply #16 for several reasons which are probably quite sensible.

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

kivig

#23
Jan 23, 2015, 02:29 pm Last Edit: Jan 23, 2015, 02:34 pm by kivig
Against encoder reading. Or did I misunderstood the question?

That sounds pretty much the same as the suggestion I made in Reply #14 and which you dismissed in Reply #16 for several reasons which are probably quite sensible.

...R
I dismissed the use of hardware logic. Encoder will be read by Arduino, which will apply needed filtering in software to deal with arguments mentioned in reply #16.

Go Up