Arduino hardware pulse counters?

Projects Programming
1

Hi,
I'd like to intercept and count pulses sent to a stepper driver.
That's up to 400Khz (200-300 actually, but I'd like to be higher end proof) on 3 to 6 channels of pulse_pin + direction_pin.

I've read some tutorials on timers but they all concentrate on outpting, like PWM.
Are the hardware timers capable of up/down-counting depending on direction flag?

Assuming this will take most of Atmega2560 performace resources, is there some way of transmitting gathered information to another Arduino? I mean if timers are taken, will anything else still work?

2

Not every pin of the ATmega2560 is available : arduino.cc/en/Hacking/PinMapping2560

A timer can use an input pin, but not automatically decrement or increment.
The direction pin could trigger an interrupt to change the decrement/increment, but that might be too slow.

Also 3 to 6 channels is too much, I think. You need extra hardware that behaves like the hardware of a stepper driver. I have no idea what kind of hardware that could be. Making something with logic requires time to develop, perhaps there is a counter chip with I2C ? I don't know.

When timers are busy, the ATmega "cpu" has nothing to do. In a real situation, often interrupt are generated by the timers, and those interrupts can keep the "cpu" busy.

3

kivig:
I'd like to intercept and count pulses sent to a stepper driver.

If all you want to do is count pulses you would not need a timer. If you want to time the pulses, that is a different matter.

Perhaps if you explain what you are trying to achieve it would enable you to get better advice.

Can't you use the software that is creating the pulses to keep a count?

You have not said what you mean by "gathered information".

...R

4

kivig:
I'd like to intercept and count pulses sent to a stepper driver.
That's up to 400Khz (200-300 actually, but I'd like to be higher end proof) on 3 to 6 channels of pulse_pin + direction_pin.

400 kHz is pretty fast.

As the overhead of interrupt-handling is about 4µs, and 400000*4µs = 1600000 µs= more microseconds than one second has, nothing will work at that speed, if it is based on interrupts.

Without using interrupts I only know about the possibility, to use one timer and pin set up for "counter with external source". So this would be a timer that counts up not from the controller frequency, but from an external frequency on the counter pin.

I don't know, if any of the Arduino boards support twor or more such counters, but UNO and MEGA support just one counter with external source, I think.

5

Arduino Uno's MCU has 2 independant timer, each one can have its own external clock.
But one is a 8-bit timer and the other is a 16-bit timer so for the first one, you'll have to deal with an over flow at about 1500 Hz: that should be OK to deal with that overflow with interrupts.

6

Peter_n:
Making something with logic requires time to develop, perhaps there is a counter chip with I2C ? I don't know.

Hmm, guess I'll investigate if such sophisticated exist. Thanks.

jurs:
I don't know, if any of the Arduino boards support twor or more such counters, but UNO and MEGA support just one counter with external source, I think.

That's disappointing, I thought there are 6 timers 4 being 16 bit on Mega.

jurs:
As the overhead of interrupt-handling is about 4µs

That's some useful information. Thanks.

Robin2:
You have not said what you mean by "gathered information".

Send current pulse count of all channels to another Arduino.

Robin2:
Perhaps if you explain what you are trying to achieve it would enable you to get better advice.
Can't you use the software that is creating the pulses to keep a count?

I want to make a middle-man device between computer or another G-Code processor, that will compare pulse count to real positions via encoders and measure applied forces to issue stop if anything goes beyond limits with stepper motors or act as "servo processor" in case of DC motors.

--
So performance is a real issue then. Could it be solved with ArduinoDUE? Until now it was lying on a shelf as UNOs and Megas were enough, so picture with it's interrupts and timers is completely black for me :slight_smile:

7

kivig:
That's disappointing, I thought there are 6 timers 4 being 16 bit on Mega.That's some useful information. Thanks.

It has: http://www.atmel.com/Images/doc2549.pdf

I know it's a huge PDF with many pages, but that's actually your Bible as soon as you're trying to push things deeper than what the native Arduino's interface allows.
You always have to refer to your MCU's datasheet when it comes to knowing what your MCU is able to do, and how to do it :wink:

8

kivig:
Send current pulse count of all channels to another Arduino.

You could not possibly send the count value after every single pulse at 400kHz.

I want to make a middle-man device between computer or another G-Code processor, that will compare pulse count to real positions via encoders and measure applied forces to issue stop if anything goes beyond limits with stepper motors or act as "servo processor" in case of DC motors.

It seems to me that this is a very sophisticated concept that would not be easy to implement even with a fast enough microprocessor.

For example, given that you can't send the count value after every pulse (if the pulses are fast) how can you decide when to send the count values so that they have some meaning for your "protection" system.

The normal arrangement would be for the computer generating the step pulses also to monitor the encoder pulses so that it can immediately see a discrepancy.

...R

9

It would be a nice addition to the Bus Pirate : a stepper up/down sniffer.
http://dangerousprototypes.com/docs/Features_overview

10

Sacha22:
It has: http://www.atmel.com/Images/doc2549.pdf

Thanks.

Robin2:
You could not possibly send the count value after every single pulse at 400kHz.

Of course not :slight_smile:

Robin2:
For example, given that you can't send the count value after every pulse (if the pulses are fast) how can you decide when to send the count values so that they have some meaning for your "protection" system.

Well, polling at 100Hz would be good enough. Mechanical end will not be able to stop immediately anyway, so even a 50ms lag is not a huge difference for stop signal. Precision in total pulse count however is important. And yes, of course time tolerances are seriously smaller for "servo" idea, but then again - millisecond doesn't change much in the world where object has some mass and inertia :slight_smile: So if I'll be able to push pulse polling to 400Hz it'll be more than enough.

Robin2:
The normal arrangement would be for the computer generating the step pulses also to monitor the encoder pulses so that it can immediately see a discrepancy.

Yes, but also normal arrangement would mean specialized software and limited flexibility. Here I'd be able to use - PC with any software, GRBL, USB G-Code interpreters etc.

11

kivig:
Of course not :)Well, polling at 100Hz would be good enough.
......
Yes, but also normal arrangement would mean specialized software and limited flexibility. Here I'd be able to use - PC with any software, GRBL, USB G-Code interpreters etc.

Maybe my mind is still in first gear this morning ...

Even if you count the number of pulses in 10 millisecs and send that number to the PC I can't figure out how you can use that number to decide whether the machine needs to be switched off.

...R

12

Robin2:
Even if you count the number of pulses in 10 millisecs and send that number to the PC I can't figure out how you can use that number to decide whether the machine needs to be switched off.

Well the whole idea is:
The pulse count gets sent to another Arduino that monitors some other parameters also and sends a standard emergency stop button command if it notices a discrepancy that is so huge the time lag could not be at fault (probably machine is about to crash) or when particular axis stops for a few milliseconds it is able to see precisely if there is any deviation (workpiece is about to be compromised). In case computer doesn't respond to stop it was probably at fault and Arduino trips the power switch.

13

Ok, so timers can't go up/down, and from what I've been able to find it seems DUE has about the same interrupt overhead as Mega.
Guess I'll have to cut on expectation of 400 or even 200Khz to make it work at all.

So I'm thinking about feasibility of setting up an attiny85@8MHz per channel to count via interrupt and report through I2C which it seems to have.
Unfortunately I haven't had a lot to do with I2C so the question is - will interrupts loading processor on 40-80% affect ability to use I2C?

14

I'd like to intercept and count pulses sent to a stepper driver.
That's up to 400Khz (200-300 actually, but I'd like to be higher end proof) on 3 to 6 channels of pulse_pin + direction_pin.

Try researching the concept of PPM and how it relates to PWM for servo motors.

EDIT: Sorry, was thinking of servo motors.

15

kivig:
Well the whole idea is:
The pulse count gets sent to another Arduino that monitors some other parameters

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

16

Robin2:
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.

17

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

Other parameters are not related to pulse count.

Robin2:
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 :slight_smile: 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.

dlloyd:
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.

18

RayLivingston:
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.

RayLivingston:
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.

RayLivingston:
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.

19

kivig:
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.

20

RayLivingston:
So what are you using for the CNC controller?

I want to be able to switch CNC controllers freely.

RayLivingston:
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 :smiley: Not so simple - pulses go also down not only up (direction pin).