SLC5/04 First scan 993ms every time???

BUMP:rephrased:

One more try...

What would cause an extremely high First scan time?

I have a CPU that has always has a 992 to 996 ms first scan time every time it goes to (remote) run mode, and I have studied it closely.

I am still baffled as to why, after finding a First_Scan driven loop in the original code and working it completely out of the code, in addition to massive amounts of logic overhaul, the First scan time remains unchanged.

The SLC 5/04 scans at 25-50 ms all other times. The watchdog is set for 1000ms. It has never "watchdog" timed out in my nine months here! I have seen it hit 996 a few times after amonth of daily checking. Happens every morning on power up, as well as returning to remomte run mode via RSLogix500...every time First_Scan is true, the max reading hits within 8ms of the watchdog, I clear it, and it never again goes above 50 until the next First_Scan.

I suspect it could be I/O or comms related?

There is a pretty heavily populated devicenet control network and around 20 local slots in use. All 30 are enabled.

There are only two nodes on the local DH+ (PV1000 standard, 500ms scan freq. ~300 tags, ~50 alarm bits)

There is also a Net-ENI module connecting it's CH0 to the engineering lab network which could be a factor?

I am at home so I can't post the code...

Tomorrow I may do that...I can't stand a unsolved puzzle!

Any ideas AB experts?

Hi Paul,

I am NOT a expert but I was waiting for the program (Monday), you said you were going to post it, I would like to try it.

Have you tried it with another CPU? could it be just the CPU? or hardware issue I/O update slow on the backplane??

Okie,

Is it actually 900+ mSec? I would try to measure to confirm it's not a reporting problem.

Set an immediate output at the beginning and then reset(immediate) on the beginning of next scan.

Nick

Yes, it is really nearly one second.

When in front of it with my laptop, I can see the delay after going to run mode before the outputs light up...

I have nevr seen a SLC do this...

Code tomorrow...

Here's the SLC file:

OkiePC said:

Here's the SLC file:

Click to expand...

Here's a WAG. Is it possible that the copies to MO for the Dnet card are holding things up because the Dnet card needs to start up as well?

allscott said:

Here's a WAG. Is it possible that the copies to MO for the Dnet card are holding things up because the Dnet card needs to start up as well?

Click to expand...

The D-Net network is my strongest suspect, partially because I am fairly new to devicenet, and this one is pretty elaborate...

Well for s & g's yank the card out, modify the program appropriately and try it.

Maybe try just AFI'ng the copy statments and see what that does.

Is this actually causing a problem or are you just curious?

allscott said:

Is this actually causing a problem or are you just curious?

Click to expand...

No problems...just curious...sorry I didn't say that 1st...I hate not having total understanding of everything I touch...

I ran this on the emulator and it was about 90ms. I would guess that as mentioned above, that the DeviceNet Scanner in slot #25 is the issue. That can't be emulated, so the scan may get stuck waiting for the DNet card to wake up. Each of those COP instruction in LAD 8 that accesses the M files causes what amounts to an interrupt.

You might try a different staging of your COP instructions. For example, create an N75 data file and do the following:

LAD 8 Rung4 COP #N22:0 to #N75:0 LEN 2
LAD 8 Rung5 COP #N35:0 to #N75:2 LEN 4
LAD 8 Rung6 COP #N35:10 to #N75:6 LEN 4
LAD 8 Rung7 COP #N35:20 to #N75:10 LEN 4

Then COP #N75:0 to M0:25.0 LEN 24

This way you are writing to the M file once instead of four times. If you can do that throughout the PLC, you will use extra memory, but it should hopefully improve your overall scan time a bit.

OG

Just as another thought, I haven't tried this before, but you could create a sort of subroutine scan time timer.

If you put a RTO instruction on the first rung of LAD8 with an OSR ahead of it. That should get you the scan time from one scan only, and that would be the first scan. You would have to manually toggle the OSR to test it a second time.

Haven't tried it, but it sounds like it would work!!

OG

Operaghost said:

I ran this on the emulator and it was about 90ms. I would guess that as mentioned above, that the DeviceNet Scanner in slot #25 is the issue. That can't be emulated, so the scan may get stuck waiting for the DNet card to wake up. Each of those COP instruction in LAD 8 that accesses the M files causes what amounts to an interrupt.

You might try a different staging of your COP instructions. For example, create an N75 data file and do the following:

LAD 8 Rung4 COP #N22:0 to #N75:0 LEN 2
LAD 8 Rung5 COP #N35:0 to #N75:2 LEN 4
LAD 8 Rung6 COP #N35:10 to #N75:6 LEN 4
LAD 8 Rung7 COP #N35:20 to #N75:10 LEN 4

Then COP #N75:0 to M0:25.0 LEN 24

This way you are writing to the M file once instead of four times. If you can do that throughout the PLC, you will use extra memory, but it should hopefully improve your overall scan time a bit.

OG

Click to expand...

Thanks, my counterpart wrote the Dnet interface, and I did the barcode interface to the HMI and the sorting logic.

I never really questioned the Mfile copies. I will when I get time, try consolidating the copies and see what impact it has on 1st scan.

I wouldn't think consolidating the copies would have any effect. If the program is waiting for the copy to finish it is waiting for the first copy to finish. Making the first copy longer won't help your first scan cycle time. Consolidating the copies will, however, slightly decrease your normal scan time since you don't have the overhead related to multiple M-file accesses.

I haven't looked into this real closely but could ytou try using the I:25/0 bit to condition your M-file copies? That should prevent copy attempts until the SDN is up and alive.

Keith

I think devicenet is the most likely culprit here. When a devicenet module is first scanned it will do a bunch of memory addressing each time for each node(at least that's my understanding of the situation).
I would suggest talking with someone at AB about this but I'm fairly sure that I've read that somewhere in the distant past.

Another thought, make sure none of your individual devicenet drops are more than 6 meters in length, I know from experience that this can cause issues (although I doubt this will affect scan times).
In the meantime, I'm trying to find reference material for devicenet first scan times (I've got a real bug up my a$$ about this one now)!

I will have to try Keths suggestion first, since I don't have to stop program mode.

I haven't had a chance to try the consolidation...too busy reworking a salt dispenser SLC & PV+ which was left by the OEM half-integrated with our existing meat blender SLC. They managed to make a batch of unsalted sausage last Sunday with two new operators, and e-stop exactly when the target was made plus all sorts of PanelView fatfingering.

I had to spend 3 hours recording all the possible causes, when I could have written a whole new sequencer and been done...The boss whated CYA and a band-aid, no rewrite, but quick, so I will spend a few days making it rock solid after the patches we added today.

Ugghhhh...two Mondays already this week!

And Opera, you know it might be the 2nd scan or the 3rd, or the 27th. I wrongfully assumed first scan, I do know that as quick as it starts Run mode from RSLogix I can punch in a 0 entry for max scan and it is after the spike...

I may add a scan coutner and FIFO the scan time into a few registers

Let it run until scan time GEQ 500 and stop for me.