Speed Sensing

[Big John T]

I use the following code to determine if a driver has stopped turning. The driver has a target on the shaft and a prox on the housing so the prox is on half the time and off half the time as the shaft is rotating. As the screw gets torqued the shaft stops and either the prox is on or off long enought to time out one of the timers.

Is there a way to do this with one timer?

Is there a better way?

Thanks
John

 

[widelto]

Why .25 seconds as basetime, this means that your program is only capable of detecting low speed when speed is lower than 240 rpm, my guess is if you increase basetime to 1 second or greater is much better.

 

[PeterW]

You can do it with a single timer, by resetting the timer if the drive output is off and on a one-shot of the falling and rising edges.

Run the timer when the output is on.

If the timer times out the drive has stopped.

 

[TConnolly]

Is there a way to do this with one timer?

Is there a better way?

I think the way your are doing it is just fine. Chances are you aren't pressed for memory and one timer is not going to make a lot of difference. Its clean and easy to understand.

But, to answer your question, I think you could do it using oneshots and a single off delay timer. The one shots detect the leading and falling edge of the prox target and reset the TOF

XIC I:1/0 OSR B3/100 OTE B3/101
XIO I:1/0 OSR B3/102 OTE B3/103
BST XIC B3/101 NXB XIC B3/103 BND TOF T4:1 .01 25 0

Since T4:1 is an off delay timer, if the DN bit is set you are still moving. When its clear, you are stopped.

You have to be careful with falling edge oneshots constructed with the ONS instruction on 1747 platforms because they create a pulse on the first scan, though its probably not a problem in this application, it could be in others. Add to that the fact that some people have difficulties with off delay timers and it might obfuscate the function of the software.


(edit: I need to type faster, I see Peter beat me to it.)

 

[Big John T]

Why .25 seconds as basetime, this means that your program is only capable of detecting low speed when speed is lower than 240 rpm, my guess is if you increase basetime to 1 second or greater is much better.

I'm detecting that the shaft is not moving and .25 seconds is plenty long to determine that the shaft is no longer moving. I'm not trying to determine speed with this. These machines have a 6 second cycle time...

Edit: I might have mislead you with the title. We call them speed sensors but really they should be called stopped sensors!

John

 

[rsdoran]

I don't know about better

Here is what I cam up with off top of my head.

As I see this, timer will start timing when Driver_ON is energized. As long as the prox is sensed "rotating: it will reset the timer, not allowing it to time out. If it stops rotating then timer will NOT reset and you can use Timer Done as needed.

I was slow, I think this is basically what Peter said.

 

[Big John T]

Peter and Alaric thanks for the reply. I'm always trying to find better (easier to understand and document) ways to program. I try and avoid one shots just for the reason that they might act different on different platforms.

Thanks for the ideas...

John

 

[TConnolly]

I'm always trying to find better (easier to understand and document) ways to program.

Well, if you ask me, what you already have is pretty easy to understand.

 

[Big John T]

Well, if you ask me, what you already have is pretty easy to understand.

Thanks Alaric, Every now and then you go fishing to see if someone has come up with a better way to do something.

Thanks
John

 

[Ken M]

I love it, Alaric!

it might obfuscate the function of the software

That's exactly what words like obfuscate are there for! Nice one,


Ken

 

[Steve Bailey]

If your driver happens to stop in a position close to the edge of the target AND the tuning of the driver is such that when it stalls it oscillates enough to make/break the prox sensor, the logic will not detect a stalled condition.

If you think that's a possibility, you will need mount a second prox so that you generate a quadrature pulse train from the two. With that, you can detect both speed and direction and signal "Done" when the timer(s) time out or when direction reverses.

Just being anal when I should probably be doing something more constructive.

 

[Big John T]

If your driver happens to stop in a position close to the edge of the target AND the tuning of the driver is such that when it stalls it oscillates enough to make/break the prox sensor, the logic will not detect a stalled condition.

If you think that's a possibility, you will need mount a second prox so that you generate a quadrature pulse train from the two. With that, you can detect both speed and direction and signal "Done" when the timer(s) time out or when direction reverses.

Just being anal when I should probably be doing something more constructive.

That is a very real problem for this type of application. I hate to add more proxes to the all ready croweded area of the drivers but that might be the only way to prevent the pulsing of the prox in that situation.

Edit: perhaps I could add a debounce timer to prevent pulsing?

Thanks
John

 

[Steve Bailey]

If finding room to mount two prox switches is a problem it might make more sense to install a low-PPR quad encoder. If you can keep the PPR and speed low enough, you won't need a high speed counter module.

 

[Big John T]

I'll look into that Steve, thanks for the reply

Thanks
John

 

[Big John T]

rsdoran thanks for the code, I just noticed it in the fast posting fury goning on...

John