ControlLogix GSV Recommendations

[MarkusAurelius82]

Hello,
I'm working with a CLX L72 CPU. I am using several GSV instructions in my program for communication health monitoring within my DLR network. I have some experience with GSVs and I know they are processor intensive. My program has around 220 GSVs and I don't notice any slow-downs when working here in my lab. But my concern is will this change when I have real-world IO connected out in the field?

Is it necessary to stagger the execution of GSVs? Should I spread them out across multiple Periodic Tasks and set the times accordingly? Right now I have them all in one Periodic Task set to 10 seconds.

Does anyone have any first-hand experience or recommendations when using this many GSVs throughout a program?

Thanks in advance.

 

[jkerekes]

WOW! That's a lot of GSVs! I've only use at most a handful, like four. Why so many? What are you trying to do. It would be best to put them in a periodic task at a slow rate.

 

[MarkusAurelius82]

The reason for so many GSVs is that we're monitoring the health of each and every IO and ENET module. And 3 attributes are required: EntryStatus, FaultCode, and FaultInfo for each module. Therefore there are 3 GSVs per module. After a few 13 slot racks, it starts to add up!

Right now, they are all in a periodic task. But even at that, the GSVs will still be executed at roughly the same time no matter how long the period time is set to.

I thought about possibly having multiple routines and putting timers in front of the JSRs to stagger them (using prime numbers for timer presets so they won't trigger at the same interval).

Any other thoughts or recommendations would be great!

 

[dcooper33]

An L72 is blazing fast, but even so 220 GSV's is quite a load. I would not do that all at once, even if it's only every several seconds or so.
If it were me, I would set each of your 13 racks up as subroutines in a somewhat faster task, say 50ms or so. I would have a count in the scheduler that increments from 1 to 13. When count =1, call JSR for chassis 1 sub, and so forth. Then within each sub, have a second count that increments each scan. When the inner count = 1, execute GSV's for card 1 of that chassis. When all cards in chassis "n" are checked, set a bit that increments the chassis count.
This way, you are only executing 3 GSV's per period. You may need to figure the maximum interval between health checks of a module, then divide by number of modules to get your task rate, I don't know what your requirements are. I do know that some GSV's can take up to a few hundred uSecs each.
I can't remeber the exact name of the white paper, I think it is something like 1756-M087, but in any case it is a spreadsheet issued by RA that gives the execution times of the CLX instruction set by PLC model and firmware. It will help you get a good estimate of the load this task will put on you processor.

Good luck

Cheers,
Dustin

 

[MarkusAurelius82]

I would set each of your 13 racks up as subroutines in a somewhat faster task, say 50ms or so. I would have a count in the scheduler that increments from 1 to 13.

Thanks for the feedback. But I don't quite understand what you mean when you say "in the scheduler".

Then within each sub, have a second count that increments each scan.

Do you mean have a counter (CTU) in an unconditional rung that would count each scan?

 

[daba]

Thanks for the feedback. But I don't quite understand what you mean when you say "in the scheduler".

Do you mean have a counter (CTU) in an unconditional rung that would count each scan?

The "scheduler" would be created by what is coded in the periodic task....

Each time the task is run, increment a count, and on each count value, go and service xxx number of GSVs.

e.g. Say you could live with 22 GSVs being executed each time the periodic task executes, then you would need a count of 10,

or,

e.g. Say you could live with 10 GSVs being executed each time the periodic task executes, then you would need a count of 22.

You are still executing 220 GSVs but you are "spreading the load" across several scans of the periodic task.

If you do go down this route, and use a counter to determine which group of GSV's to execute, remember to include an OTU of the counter's .CU bit, otherwise the counter will not count after it's first scan. This is because the counter will never see the rung go false... Resetting the .CU bit "fools" the counter into thinking it is seeing a false-to-true rung transition.

 

[Paullys50]

The reason for so many GSVs is that we're monitoring the health of each and every IO and ENET module. And 3 attributes are required: EntryStatus, FaultCode, and FaultInfo for each module. Therefore there are 3 GSVs per module. After a few 13 slot racks, it starts to add up!

You don't need to run each GSV all the time, start with the EntryStatus, if that is fine there is no reason to execute the other two.

I do something similar, but I only check the faultcode only if the previous GSV EntryStatus indicates a problem. I don't bother with the faultinfo. It's a compromise, gives you more info to display on the SCADA screens, but given the added load who wins?

See where you can cascade the GSVs so at most you only have 13 GSVs constantly monitoring the EntryStatus. Do a search on the Rockwell knowledge base, they give some examples.

 

[dcooper33]

Thanks for the feedback. But I don't quite understand what you mean when you say "in the scheduler".

Do you mean have a counter (CTU) in an unconditional rung that would count each scan?

1. By "in the scheduler" I mean the main routine of the program in your periodic task. This routine is the one that is called unconditionally each time the program is called, and all subroutines are called from within it.

2. IMO you don't need a CTU for this, since it will be unconditional. Just do ADD Card_Count 1 Card_Count on each scan. When Card_Count = # of the last card in given chassis, then you want to reset the count (CLR Card_Count or MOV 0 Card_Count)

+1 on Paully's suggestion about monitoring EntryStatus. When you have this many cards to monitor, optimization is a big concern.

 

[bimini3]

I also use a lot of GSVs to monitor communication and hardware health. The first thing I do is a GSV to get the "LED_Status" of the main CPU "MODULE". If it is anything but 0 there is an I/O or communication problem somewhere in the system and then I drill down with additional MSGs to locate the problem.

If there are a lot of MSGs, I will set up a sequencer/scheduler to poll only 1 or 2 MSGs each scan to prevent loading down the communications network. There are many way of doing a sequencer just use your favorite method.

 

[Paullys50]

I also use a lot of GSVs to monitor communication and hardware health. The first thing I do is a GSV to get the "LED_Status" of the main CPU "MODULE". If it is anything but 0 there is an I/O or communication problem somewhere in the system and then I drill down with additional MSGs to locate the problem...

Sure about this??

From the help file:

(Granted I am looking at a ControlLogix project at the moment)
---------------------------
LEDStatus
INT
GSV
Specifies the current state of the I/O LED on the front of the controller.


Value 0
LED off: No MODULE objects are configured for the controller (there are no modules in the I/O Configuration section of the controller organizer).

Value 1
Flashing red: None of the MODULE objects are Running.

Value 2
Flashing green: At least one MODULE object is not Running.

Value 3
Solid green: All the Module objects are Running.