AB SLC 5/04 slow scan missing sensor inputs

Join Date
Nov 2007
Location
london
Posts
68
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 issue.
The Scan time of the PLC is 20mS to 30mS. The sensors can be on for about 15mSec.

Is there a high speed area in the SLC 5/04 like OB35 in the Siemens S7 PLC's where I can put my counters to stop them getting missed?

any info gratefully received.
 
How many inputs do you need? There are some AMCI cards with build in hsc. There are a few others as well.
 
the Inevitable Question:

can you post your program? ...

other than that, (and besides the ideas from my distinguished colleague Jeff Kiper) you could also look into the DII and/or STI features ...
 
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 issue.
The Scan time of the PLC is 20mS to 30mS. The sensors can be on for about 15mSec.

Is there a high speed area in the SLC 5/04 like OB35 in the Siemens S7 PLC's where I can put my counters to stop them getting missed?

any info gratefully received.

There are a few things you can do.

Reorganize the program to improve Scan Time.

If the important Inputs are on the same Input Card, you can use a DII (Basically a Hardware Input). If they are DC Inputs, upgrade to a Fast Input Card along with the DII.

The SLCs have an Immediate Input Instruction IIM for Local Chassis Slots that updates the state of the Inputs.

Stu.....
 
One of the things I have done in the past is duplicate the input line multible times throughout the program. In your case you may be able to get away with doing it twice. Without seeing your program, I am not sure it this option would work.
 
You can use the IIM instruction and duplicate your counter in several places throughout your program. I've done that successfully in sprocket tooth counting applications before. But be warned, you pay an overhead penalty. You're overall scan time will go up, but the time between scanning the IO point of interest will decrease.
 
One of the things I have done in the past is duplicate the input line multible times throughout the program. In your case you may be able to get away with doing it twice. Without seeing your program, I am not sure it this option would work.

Unless using IIM instructions, that won't do a thing in the SLC/PLC series of processors (and most older processors) since they buffer I/O prior to scanning the ladder.

In any case, trying to respond to a 15ms event in a 30ms scan is simply not going to work without interrupt routines.
 
Well I've tried placing the offending input in every file 3 time each to see if it updates more often. I'm didn't think it would work as surely the input table only updates at the start of the scan, but desperation drove me on.

The input is I:3.1/6.

I've also tried putting the an input to a high speed card. I.11.0/3

Never got to a hi-speed, it starts rejecting cans at about 450cpm.

The scan time of the PLC is up to 30mS-40mS and a can passes about every 30mS

I've attached the program...
moz-screenshot.png
 
Well I've tried placing the offending input in every file 3 time each to see if it updates more often. I'm didn't think it would work as surely the input table only updates at the start of the scan...

Yes, your concerns are correct, the input image is only updated at the beginning of each scan, unless you put the IIM instruction before each examination of that input...

Be careful though...add the IIM instructions one at a time and keep an eye on your scan time...you might break something else in the process of fixing this problem (by increasing the overall scan time too much.)
 
Is this on a decorator of some sort?
You are using that input to also drive outputs? Guess what. Even if you do latch the input (via an DII routine or IIM instructions), you will still have issues with output timing.

Again... At the very least, you are going to have to strip down your time critical logic to the absolute minimum, and stick that into a separate ladder file, triggered as a DII (Discrete Input Interrupt) or perhaps STI, but I'm more inclined here to use the DII (Processor Status, DII/STI tabs).

You will STILL need to use FAST input and output modules.
The specifications (from the manual) of the IB32 input modules give a minimum signal on and off time of 3ms each for detection of a state change. That is 6ms per cycle. Add in the delay of your sensor.
The OBP16's are faster (1ms on, 0.1ms off), so should be okay unless they are driving other laggy external elements (relays, AC heaters, etc).

The SLC is a workhorse, not a racehorse, but you might be able to squeeze some more performance if you are careful.
 
To reliably detect an impulse with an ontime of 15 ms (and equal off-time, or longer, right ?), you need to read the input every 10 ms.
That just happens to be the fastest update time for the STI file.
In this file you need to use the IIM instruction for reading the input.

The high-speed input wont help unles the program can scan at the required speed. 15 ms is long enough for a regular input.

There are othe alteratives, for example using a counter card.
 
If you have RSLogix5000 already available to you, you might want to look at the cost of upgrading the machine to a CompactLogix, that should allow you to get a scan time that can work in your application with more room to spare in the future. AB does have their trade up program to help offset the cost of upgrading.
 
The program isnt so big.
And it is mostly boolean logic, counters and timers.
But in program file 2, there are 14 JSR to program file 3. And in file 3 there is a call to file 4. Is it necessary to update files 3 and 4 14 times per scan ?
In file 3 some outputs are updated, which indicates that something is programmed wrong, since the outputs are really only updated once per scan.
Also, there are so many timers, that I think this is also not right too. Timers should normally be updated once per scan - except for some special cases.

edit: I have a feeling that you can easily get the program down to below 10 ms.
Somehow the program is messed up in an attempt to improve the updates of i/o.
 
Last edited:
While we are at it:
What panel is it that you are using ?
Is it really necessary with the MSG to and from the panel every 640 ms ?
Not that it matters to the scan time (probably not), but on DH+ I would guess that it would be the most efficient to simply let the panel do the polling.
 

Similar Topics

I have an issue with an Allen Bradley SLC 5/05 program acting “slow”. A few months ago, I noticed an issue with a part of my PLC program not...
Replies
1
Views
1,305
I am upgrading one of our sites from Rsview32 to Factorytalk View SE Local Station on Win10 and I have the program all set up and switched over...
Replies
3
Views
4,049
I have a SLC 5/05 with really slow Ethernet comms. It is on a network with three Proface screens but comms is just as slow when I connect directly...
Replies
6
Views
3,887
hi you all i am dealing with this problem for 2 weeks with no results i have 4 slc's 5/05 and 1 micro 1100 with cimplicity all r ethernet...
Replies
12
Views
7,388
I have two SLC 500 5/05E processors on a subnet with a Delta motion controller. I am using OPC and Topserver for I/O comms and Wonderware for HMI...
Replies
4
Views
6,632
Back
Top Bottom