Logix5000 Max Scan Time with GSV

alexbeatle

Member
Join Date
Feb 2010
Location
San Francisco
Posts
188
Hello,

I've setup a GSV to capture the PLC max scan time (Task\Rate), but what it gives me is actually much lower than that of the current scan time (Task\LastScanTime). Has anyone experienced this before?

Thank you.
 
Can you post an image comparison or the GSV you're calling?

Scan times aren't deterministic, so the usual scan rate should be lower than the occasional peak.
 
@JeremyM, those aren't occasional peaks. I'm constantly reading Task\LastScanTime and it's always in 20000s, but the Task\Rate keeps on staying at 7000.
 
Rate is the interval between successive executions of the task, LastScanTime is the time elapsed per execution of the task.

Try substituting MaxScanTime for Rate.
 
Last edited:
Rate is the interval between successive executions of the task, LastScanTime is the time elapsed per execution of the task.

Try substituting MaximumScanTime for Rate.

You mean, replace Rate with the MaximumScanTime?


I think there's a bit of confusion going on here. I'm comparing (see attached) to determine if the current scan time is critical.

scantime.png
 
Last edited:
Looking at your image, you need to replace the Rate attribute with MaxScanTime in the second GSV call in order to see that task's maximum scan time. Rate is not the maximum scan time.
 
Are these controllers executing the same code? Are they configured identically? Are they the same model? Firmware?
 
Are these controllers executing the same code? Are they configured identically? Are they the same model? Firmware?

Same controllers. Same firmware. Different code, but similar program function and size.

Running Logix5000 Task Monitor revealed the attached.

monitor.jpg
 
Last edited:
I can't be the only one in thinking that 100% cpu utilisation is a good thing - at least the cpu is doing processing of the application code rather than just sitting in a non-productive loop waiting for periodic or event task triggers.

There's another thread on here that suggests using a continuous task is wrong. Am I mad ?
 
It's not necessarily a good thing or a bad thing. It depends on the circumstance. In most cases it probably doesn't matter. In some cases it does.

Lets think though a few different situations. Would having a processor that runs twice as fast make your program perform better? The periodic and event driven tasks usually wouldn't be better. They would start executing at the same time, but would run through quicker, but I don't think that makes them better. The continuous tasks would execute more frequently. Would that make them function better? Maybe only parts of the continuous task provides better functionality by running faster. If there are parts that run better by running more frequently, then we can take them out of the continuous task and put them in a periodic task and run them at the appropriate frequency.

For example, how frequently does the logic that runs a motor starter and interlock need to run? Once every 10 seconds? Once every second? 10 times per second? As fast as possible? If you think as fast as possible is correct, but that turns out to be one every second to second and a half. I'd disagree. I like to see my downstream interlocks knock down the upstream equipment faster than that. I would say we should take these parts out of the continuous task that perform better by running more frequently and put them in a continuous task and run them at the period they need. If we have more processing time available, we could reduce the period further to make this specific program work "better". If your continuous task is completing in less than 1/10 of a second and nothing is in the continuous task that would preform better by running more frequently, then having a continuous task that runs more frequently, performance wise, it probably doesn't matter. And if it doesn't matter, running in a continuous is also not better. Its not bad either.

On the other hand, lets say we have a program that is running a bubble sort on an array of 5000 values. If this run in a periodic task, it could take a very long time to complete. If we ran in it a continuous task, it would complete much faster. If it was the only thing in the continuous task, it would complete even faster.

Of course if we had a system that would perform better by running the program faster, we could spend time optimizing the system, or we could by a faster processor (if there is one). Which is better or the other bad idea? It depends on the circumstances.

AB recommends that when designing the Plant PAX systems that we only using periodic and event driven tasks, and have the processor usage less than 50%. But then after the customer get the system, it is OK for him to make changes so long as they keep it under 75%. I see two benefits of doing things this way. 1) it is easy to see that your tasks are getting completed at the rate they need to run. 2) it is easy to see when your system is becoming loaded, and may need adjustment or upgrades. Even though most of the ControlLogix systems aren't Plant PAX system, their recommendations hold value.

Like most things in life, when achieving one goal, other things are effected. If we don't understand these other effects, we may make the right decision anyway. But I figure that's the difference between competence and lucky.
 
As Jeremy pointed out earlier, the Rate parameter is the time from the start of one scan of the task until the start of the next scan. So it is how often the task is scanned. Since you are using a periodic task (now) that rate will be fixed and unchanging. It has absolutely nothing to do with the actual scan time of the logic.

OG
 

Similar Topics

Hi! So my problem is a little funky, I had Studio 5000 v 24 and 30 installed, but forgot to install RSLogix (which I cannot go without). Is there...
Replies
2
Views
124
So I had an odd request from a customer for the above. I have written the logic and tested it all in one PLC with only using 7 outputs and 7...
Replies
15
Views
428
I'm a Siemens person, and this is one of my first AB programs. The customer wants everything programmed in Ladder. I have a lot of data (3...
Replies
14
Views
226
Good day everyone. if you have a logic for 3 pumps (lead/lag/off), would you please email it to me? I really appreciate it!
Replies
7
Views
220
Maybe this is just not possible, or maybe I am doing something wrong. Background; I have a data array of over 1500 products. For sorting I...
Replies
6
Views
765
Back
Top Bottom