SLC 5/05 Scan Time vs Input Pulse

robertmee

Lifetime Supporting Member
Join Date
Feb 2008
Location
NC
Posts
1,940
I really wish the customer had taken my recommendation of using CLX...But neither here nor there...sigh

Okay, next problem. The customer installed several inductive proximity sensors picking up keyways on pump shafts. The problem is that the keyway is so small the pulse duration is smaller than the scan time (scan time currently 70 to 80 ms).

Normally, for zero speed detection I have a free running timer with a preset of X seconds. With a OSR on the Prox Pulse, I reset the timer. If the timer times out (DN), then declare a zero speed fault. This works until the pulse gets in sync with the scan time. Since the SLC only updates the Input Image table at the beginning of the scan, what happens is that by murphy's law, eventually the pulse syncs up enough with the scan time, that I'm missing the small pulse rise. So, the logic see's the Input off for many scans. Watching the timer accumulator, normally when out of sync, the value goes 0 - 1 each scan. However, when it finally syncs it will time up as high as 20 seconds (as high as I've gone so far to mask the issue). I've verified that the input is still flashing on the I/O module (non Remote I/O - Local Base so no RIO issues), so it is not a matter of missing the physical signal.

I've tried to use the immediate I/O Mask instruction, but all that does is move the point of updating the Input Image from the beginning of the scan to wherever the instruction is. Short of putting several of these sprinkled through the program with the same Alarm latching logic behind it, I'm drawing a blank. My suggestion is to install a half collar on the shaft so that we get 1/2 on, 1/2 off signal that should exceed the scan time of the processor. But I'm open to any software suggestions on how to attack this problem.

Thanks!
 
I have an application where I count teeth on a sprocket for a chain. I successfully use the IIM at several locations in the program for that. Be aware that the IIM does not come without some overhead penalty.

If you are using it for zero speed then use a TOF/TON combination. You can use the same timers at multiple places in the program.

a052008.JPG



If you place one near the beginning of the scan you do not need to use the IIM on that first instance. Alternatively, you can put it in just once in an STI.

A timer is just an instruction that operates on a memory address and unlike an output, placing multiple references to a timer address in a program is OK, in fact it improves the accuracy of the timer if you have a long scan time. I used 1 second preset in the example but choose an appropriate time for your needs.


Unless your pump shaft is turning slowly a half collar is not going to help much. At 1750 RPM the shaft completes a revolution in 34mSec. A half collar will give you a pulse that is 17mSec on, 17mSec off, still less than the scan time you gave us.
 
Last edited:
Thanks for the suggestions...Comments:

That's pretty much what I alluded to up above. Putting my IIM and Timer Logic in a few places throughout the program. I have 20 some odd pumps, so 20X those is not a minimal task, but if that's the case, then I might have to bite the bullet.

I like my zero speed detection logic better, as while it takes a OSR, it only uses one timer and I think accomplishes the same thing. The code is:

XIC O:3.23/1 BST TON T19:80 1.0 5 0 NXB XIC I:13.0/2 OSR B3:7/11 RES T19:80 NXB XIC T19:80/DN OTL B17:31/3 BND

Where, O:3.23/1 is the Run Command, I:13.0/2 is the Pulse, and B17:31/3 is the fault.

If you see some fault in the above that contributes to the issue then please elaborate.

Finally, the Motor is 1755 RPM, but the Pumps are on a 5:1 reduction gearboxes, so I'm only running pump shaft speeds of 350RPM or less (most motors are not running 100% speed). The prox is on the pump shaft not the motor shaft for true zero speed detection (coupling failure).

Lastly, is there any additional overhead of using an 0xFFFF mask, vs using the specific Input mask (IE 0X0001 for input 0)? While my program wouldn't care if the entire I/O word is updated, if it helps to target the specific Input, then I can adjust the masks. Right now the Inputs are scattered across three consecutive modules, so I'm using I:10 at 3 words, but I like your idea of including the IIM in the detection circuit itself.
 
Last edited:
I can't see how the mask value would change the overhead.

If you have to do that many inputs your best bet to minimize overhead is to arrange them consecutively on one 32 bit input card, unless you can group them then the overhead penalty is going to be huge. I realize it might be too late in the process to make that change.

I recommed that your alarm bits be put in just one place in the program scan, perhaps grouped in a subroutine. There is no need to sprinkle them around the program. Probably all you need with each IIM is just the logic to reset your free running timers.
 
If all these inputs are wired to the same Input module, couldn't you use the Discrete Input Interrupt so that any time there was a change of state on that one module you could run the logic for the zero-speed timers ?

A neat way I've attacked the zero-speed pulse problem is when I used the 100DSA starter auxiliary modules on DeviceNet; you can program a "DeviceLogix" object to capture pulses as short as 1 ms and do the timeout logic onboard. Not applicable here, regretfully.
 
Alaric said:
I can't see how the mask value would change the overhead.

If you have to do that many inputs your best bet to minimize overhead is to arrange them consecutively on one 32 bit input card, unless you can group them then the overhead penalty is going to be huge. I realize it might be too late in the process to make that change.

Yes, wayyy too late

I recommed that your alarm bits be put in just one place in the program scan, perhaps grouped in a subroutine. There is no need to sprinkle them around the program. Probably all you need with each IIM is just the logic to reset your free running timers.

All the alarm bit logic is in one ALARM subroutine. Right now the Timer is part of the rung logic as noted above.
 
Eddie Willers said:
If all these inputs are wired to the same Input module, couldn't you use the Discrete Input Interrupt so that any time there was a change of state on that one module you could run the logic for the zero-speed timers ?

A neat way I've attacked the zero-speed pulse problem is when I used the 100DSA starter auxiliary modules on DeviceNet; you can program a "DeviceLogix" object to capture pulses as short as 1 ms and do the timeout logic onboard. Not applicable here, regretfully.

Unfortunately, I had no say in the PLC layout or installation, only the programming, so the inputs are scattered across three 16pt modules.
 
Yes, wayyy too late
Man, I don't know what to say, sometimes life sucks. o_O

I do have a suggestion for an entirely different kind of solution. It would not be dependant on the scan rate. Turning a pump produces a load on a motor. If the shaft coupling breaks or if the pump runs dry or if the pump inlet or discharge valve is closed then the load on the pump motor changes in a dramatic and measurable way. http://www.loadcontrols.com makes a module specifically for detecting these kinds of changes by monitoring the motor.

If the motor is on a drive (I assume they are from your earlier comment) and if the drives are networked to the PLC then you can query the drive to find out what the motor load is, no additonal sensors required. If the drives are not networked its an option you might still want to check into.
 
Last edited:
They are on Powerflex 70's so I do sense the load via DataLink A1 over RIO. I alarm on high amps, but I could certainly add low amps (broken coupling). I also have disconnect aux's that alarm too. The only issue with using low amps is that every alarm has to be tailored to the motor load, speed, and nominal operating amps. So, in the future when those change due to process changes, there may be the instance of nuisance trips.

I think the most viable solution is to put a 1/2 collar on the shaft instead of sensing the keyway. At worst case of 600 RPMs that's (Check my math):

600 Rev/Min * 1/60 Min/Sec = 10 Rev/Sec or 1 Rev per 100 ms. So, I'd get a pulse of 50ms long. Since all my alarms are in one JSR, I could simply call the JSR once 1/2 way through the scan, and then a second time at the end with a single IIM preceding the JSR. How does that sound? That give me upto 100ms scan time coverage, which I'm well below right now.
 
If you do decide to read data back from the drive, instead of using amps get the power value back from the drive. Power is load linear, while the amps curve is parabolic and has low resolution except when the motor is already near its rated load.

I'd call the JSR near the beginning of the scan while the last IO read is fresh, then again half way through. It probably doesn't matter except that by doing it at the end you would do an IO update when one is about to happen again anyways.
 
Last edited:
Alaric said:
If you do decide to read data back from the drive, instead of using amps get the power value back from the drive. Power is load linear, while the amps curve is parabolic and has low resolution except when the motor is already near its rated load.

Okay, now you're gonna make me dig out my power theory book ;) I tried searching for a good white paper link but no luck.

I'd call the JSR near the beginning of the scan while the last IO read is fresh, then again half way through. It probably doesn't matter except that by doing it at the end you would do an IO update when one is about to happen again anyways.

Good Idea.
 

Similar Topics

I have a slc 552 which uses up to 220 ms in scan time. Memory used 7990 and 2070 memory free. There is some indirect programming in the code. Will...
Replies
9
Views
2,740
Scan question for ton timer If a TON is on a output branch and rung is true. The next branch has a XIC contact off of that .DN bit to an OTE The...
Replies
6
Views
8,051
SLC 5/04 Does anyone know what the typical scan time is for the Compute instruction? The manual states "The execution time of a CPT instruction...
Replies
24
Views
5,883
I just changed out an AB 5/04 to a 5/05 on one of my lines. I had the program all configured offline, loaded into a new 5/05 chasis, powered down...
Replies
10
Views
5,714
Hi, I've inherited an old machine that makes widgets. it runs well at 300Widgets per min, but any higher it gets flakey. This is a scan time...
Replies
31
Views
10,048
Back
Top Bottom