AB SLC 5/04 slow scan missing sensor inputs

[Struggling_forward]

I've looked in the RS500 help file and IIM does not exist as a topic.

what does it stand for? I'll look into that.

 

[sthompson]

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.

I believe it does make a difference, because my understanding is the SLCs do not have a separate Communications Processor. I agree with Jesper 100% on his previous post. JSR Instructions cause a Scan Time Hit. Was this out of desperation to try and catch the Input you were missing?

A lot could be done with the PLC Program to improve the Scan Time, and then use a DII and IIM, and you should be able to catch your Input Transitions. I do something similar with a Can Filler running at 750 CPM.

Stu....

 

[sthompson]

I've looked in the RS500 help file and IIM does not exist as a topic.

what does it stand for? I'll look into that.

Struggling:

Click on Help, then Instruction Help, the Click on IIM.

You can also look in Chapter 6 of the Instruction Reference.

http://literature.rockwellautomation.com/idc/groups/literature/documents/rm/1747-rm001_-en-p.pdf

Stu...

 

[Struggling_forward]

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).

Pasting (Discrete Input Interrupt) into the RX Logix help file brings up word not found. do you have a link to any more info on that and the DII/STI. I afraid I'm a newcomer to RS logix.

BTW, Its been lovely to use but for this.

 

[OkiePC]

Go to Processor Status, click on the DII tab, and then the Help button at the bottom of that window.

 

[JesperMP]

I would suggest to use STI in stead of DII, if an update time of 10 ms is sufficient.

Can you tell us about the 14 JSR to files 3 and 4 in file 2 ?

 

[rdrast]

What "Help" are you looking in?
MENU - Help | Instruction Help - Click on IIM:

Use with processors
Fixed, 5/01, 5/02 and MicroLogix 1000
SLC 5/03, 5/04, 5/05 and
Micro 1200 and 1500

All SLC and MicroLogix processors

(Parameters shown are examples only, your data will vary.)

Description

This output instruction allows you to update data prior to the normal input scan. When the IIM instruction is enabled, the program scan is interrupted. Data from a specified I/O slot is transferred through a mask to the input data file. This makes the data available to instructions following the IIM instruction in the ladder program.
The IIM operates on the inputs assigned to a particular word of a slot (16 bits maximum). For the mask, a (1) in an input’s bit position passes data from the source to the destination. A (0) inhibits data from passing from the source to the destination.
Note: Expansion I/O is not permitted with the IIM instruction.
...snip...

On exactly the same help window going to the "Search" tab, and typing in "DII" (those are I's, as in "India") brings up at least 8 hits.

And good call Jesper... All of those JSR's are going to suck up a lot of processor time. Especially nested the way they are.

 

[JesperMP]

Struggling_forward.

You really should focus on the 14 JSR's in file 2.
Why are there 14 calls ?

You cannot just call the same code in files 3 and 4 by STI or DII. you will get an overflow.
You will have to single out the code that is really necessary to update really fast.

I would as an experiment, simply cut down all the JSR from file 2 to file 3 from 14 to 1. Then see how the program behaves, and what scan time you get.

 

[OkiePC]

It's going to be tough to get under 15ms scan time even with the reduction in JSRs, but that is still a valid pursuit, and should buy enough scan time to allow the implementation of an interrupt routine for your high speed I/O

Switching to Compactlogix of Controllogix would definitely get you there.

 

[Struggling_forward]

Is this on a decorator of some sort?/quote]

Exactly that.

Struggling_forward.

You really should focus on the 14 JSR's in file 2.
Why are there 14 calls ?

Well I assume the previous elect sup put them in as an attempt to capture the elusive sensor. I left them in as I thought he must of known what he was doing being far more familiar with AB. Rockwell. I'll remove them and see what I get.

 

[Struggling_forward]

OK, its late here tomorrow I'll remove the JSR's

I'm wondering about the IIM instruction.

I'll us it as below.
I understand that it does not wait for the top of the scan before it updates the input table if you use IIM is this correct?

I want I:3.1/6 to update ASAP so If I put my IIM instruction just above the time I use the input, I'll catch it. have I got the mask right to capture only the bit I want or is it the inverse?

Ive added a pic of what I'm looking at...

 

[JesperMP]

It looks OK.

But.

If you have just one IIM, and it is in the regular program scan, then you wont have achieved anything else than how the program works without the IIM.

I suggest you check the scan time after you have cut down the JSR to just once in file 2.
If the scan time is 10 ms or less, then you are done.
If the scan time is still over 10 ms, then setup an STI file with an update scan of 1x10ms. In the STI file you must place the code that must update fast. Read the input once with IIM. Update the output once with IOM. keep the code as minimal as possible,

 

[Mickey]

Check your mask. See PDF below.

 

[JesperMP]

Just let the mask be FFFF.

 

[Ken Roach]

This application is ideal for the DII function.


I would delete all of the JSRs to Subroutine File 3, then configure the DII function to call File 3 on changes to inputs in Slot 11 (the ITV16 fast input module).

Here's a tricky thing: Input I:11/0 is used to run Counters both on its rising edge (Rungs 0,15,16,20,24,25) and on its falling edge (Rungs 9, 11, 14).

The DII function uses the Bit Mask and the Compare Value to decide whether to execute the DII on the rising edge or trailing edge of a signal from the designated Input module. You can't trigger the DII both on 0->1 and on 1->0 transitions.

So I would jumper I:11/0 to I:11/2 (currently unused), and replace I:11/0 with I:11/2 on Rungs 9, 11, and 14.

Then the Bit Mask will be 0000 0000 0000 1101 (binary) = 0x0D (hex) = 13 (decimal).
The Compare Value will be 0000 0000 0000 1001 (binary) = 0x09 (hex) = 9 (decimal).

Configure the DII as follows:

File Number S:46 = 3
Slot NUmber S:47 = 11
Bit Mask S:48 = Dh
Compare Value S:49 = 9h

This will greatly increase the performance of this subroutine and probably decrease the overall scantime of the controller.