RSLogix 5000 - Periodic or Continuous task?

[simonwxx]

Hey guys, I wanna to write a bit of code to return value to show if the task is in periodic or continuous mode? is there a tag in RSLogix 5000 to return value of task type? cheers!!!

Simon

[Ken Roach]

You could use a GSV instruction to read the Task object, and grab the Rate or the Priority.

The Rate will be the scheduled interval between executinos for a Periodic Task. I don't know what it will be for the Continuous Task.

The Priority will be the priority level you assign to a Periodic Task. It might be 10 or 11 for the Continuous task, since it is the lowest priority level task and can be interrupted by anything.

This seems an unusual thing to need in logic. What is the reason for having this information as a controller tag ?

[simonwxx]

I've tried GSV using Rate. but since rate is the scan time for periodic task, even if it is set to be continuous task, using rate will still show the default periodic task. So i think can't not tell the task type by using rate. I'll try priority later on, thanks mate.

they reason behind this is, we are developing an AoiSystem module, we need to get the last scan time if it is in continuous task, and to get rate (scan time in periodic) if it is in periodic task. So the program should be able to tell the type of the task... that's what we are aiming for.

[rdrast]

Originally Posted by simonwxx

I've tried GSV using Rate. but since rate is the scan time for periodic task, even if it is set to be continuous task, using rate will still show the default periodic task. So i think can't not tell the task type by using rate. I'll try priority later on, thanks mate.

Are you positive? The Cyclic task always seems to have a rate of 10,000 usec, but all of my periodic tasks show their actual rates, none of which is set to 10,000 usec.

I guess you could also look at the "INSTANCE" member of the Task Object, by default, there is always a cyclical task, so unless someone does something convoluted, it should always be Cyclical task instance == 1. Other tasks are numbered sequentially as they are created.

Really though, if it's that critical to you, I'd ignore everything alltoghether, and just maintain a delta of microseconds between successive calls of your AOI. The "StartTime" member of the task object gives two DINT's of the start time of the task in microseconds. Initialize on the first pass, then just calculate the elapsed microseconds between calls.

[TConnolly]

There does not always have to be a continuous task. Nor will the continuous task always be the first one. I just tested it with a GSV on one of my CLXs and the continuous task is instance 2. So I don't think that is going to work for all cases.


When Rockwell came to town for CATM a few months back in one of the training classes the instructor demonstrated the task monitor and showed that changing the continuous task to periodic could actually make it run faster. The continuous task is constantly interrupted and on his demo it was taking about 12 mS to scan. He converted it to a 10 ms periodic task and it ran in a couple of milliseconds without all the interruptions the continuous task gets. Then he set the task rate to 5mS, more than doubling the rate at which scans were made, yet the task monitor showed the processor still had plenty of time to do everything else because it wasn't spending so much time on task switching overhead. So there could be some very good reasons to not even have a continuous task in the program. I've come across a couple of programs like that.

ETA: here is something interesting... If I look at one of my CLXs that has 4 programs under the main continuous task and I add up the max scan times of each of the four programs I get 3.9ms. But if I look at the continuous task scan time it shows 10 to 11 mS. That means that for at least 6-7mS of every scan of the continuous task the processor is doing something else.

[daba]

If you put the AOI calls inside the respective Tasks, instead of all together in one task, then you will already know what type of task it is.

[simonwxx]

Originally Posted by rdrast

Are you positive? The Cyclic task always seems to have a rate of 10,000 usec, but all of my periodic tasks show their actual rates, none of which is set to 10,000 usec.

here is a bit of code I wrote previously to differentiate continuous and periodic tasks from initial requirement:

if sysData.stsPowerUp  then
              gsv(task,this,MaxScanTime,ScanTime);
              gsv(task,this,Rate,ScanPeriod);
              gsv(task,this,MaxInterval,IntervalTime[0]);
             if (ABS((IntervalTime[0] - ScanTime) * 1.0 /  IntervalTime[0]) <= 0.01) then // within 1% difference  
                         sttContinous  := 1;
                         sttPeriodic  := 0;
              end_if;
             if (ABS((IntervalTime[0] - ScanPeriod) * 1.0 /  IntervalTime[0]) <= 0.01) then // within 1%  difference
                         sttContinous  := 0;
                         sttPeriodic  := 1;
              end_if;

however, it can be wrong under 2 circumstances:
1. Task in Continuous mode

If ScanPeriod (no matter it is set to be continuous or periodic type, ScanPeriod = periodic scan time) is set to be close enough to IntervalTime[0], 2nd IF statement will be true, sttPeriodic will be set to 1.

2. Task in Periodic mode
if periodic scan time has big difference to MaxInterval time, for example, IntervalTime[0] =503.908ms ScanPeriod = 100.000 ms, then IntervalTime[0] - ScanPeriod) * 1.0 / IntervalTime[0] = 0.8

The result is > > 0.01
Then sttPeriodic will still be 0.


not sure if i made myself clear enough. cheers

[simonwxx]

Originally Posted by rdrast

I guess you could also look at the "INSTANCE" member of the Task Object, by default, there is always a cyclical task, so unless someone does something convoluted, it should always be Cyclical task instance == 1. Other tasks are numbered sequentially as they are created.

every plc program will have only one task which can be set to Continuous, is that right? if it is true, i can simply check if task instance == 1 to differentiate periodic and continuous task...cheers

[simonwxx]

Originally Posted by rdrast

I guess you could also look at the "INSTANCE" member of the Task Object, by default, there is always a cyclical task, so unless someone does something convoluted, it should always be Cyclical task instance == 1. Other tasks are numbered sequentially as they are created.

Hi Rdrast,

I've set the task to periodic and use gsv(task,this,instance,TaskInstance); command, the value of this instance, TaskInstance still == 1. see the attached pic. don't know why is that?
cheers

[simonwxx]

Originally Posted by rdrast

I guess you could also look at the "INSTANCE" member of the Task Object, by default, there is always a cyclical task, so unless someone does something convoluted, it should always be Cyclical task instance == 1. Other tasks are numbered sequentially as they are created.

Hi Rdrast, I've go two tasks, i set one to periodic and another continuous, tested. instance of periodic task = 1 and instance of continuous = 3. so i think continuous task instance may not necessary be 1 all the time.

[daba]

I'm sure the information you require must be in the Status flags somewhere, I'll try to determine it later when I'm on a real machine.

Anyway, here's a back-door method which may work.

If you SSV the watchdog of a task as zero, then the controller automatically assigns the following (Ref : 1756-QR107C-EN-P Page 6-24):-

Periodic 0.5 Sec
Continuous 5.0 Sec

(The manual does not indicate what the assignment would be for an Event Task).

So your routine could:-

GSV the actual watchdog setting and store it.
SSV 0 to the watchdog.
GSV the new setting, to determine task type.
SSV the original stored setting.

Convoluted, but sould work.

HTH

[rdrast]

Originally Posted by simonwxx

Hi Rdrast, I've go two tasks, i set one to periodic and another continuous, tested. instance of periodic task = 1 and instance of continuous = 3. so i think continuous task instance may not necessary be 1 all the time.

Aye, that has been pointed out to me. My error, I made the mistake of assuming it would always be present, but was shown cases where the cyclic task was deleted, then periodic tasks added, which changes the instance number.

[daba]

My guess it's going to be a (as yet un-documented) bit in the Staus DINT, or more likely, an attribute you could get with a CIP message to the controller (yes, the controller can read itself, Path = 1,[slot#] )

I'm still trying to find a list of CIP Class Instance and Attributes for the controller, does anyone have this, or know where it can be found?

After all, RSLogix5000 can read it, so it does give up it's secrets.

[simonwxx]

Originally Posted by daba

So your routine could:-

GSV the actual watchdog setting and store it.
SSV 0 to the watchdog.
GSV the new setting, to determine task type.
SSV the original stored setting.

Convoluted, but sould work.

HTH

Hey mate, sounds a good one, I've tried your method, and test it. seen the program can't catch 0.5 or 5 seconds value. It give me 0 value instead. below is my code.

[daba]

Yes, I discovered this myself, it returns the zero value you SSV.

I spoke with an ex-colleaguethat now works tech support, and he confirmed that a lot of info that could be got is unpublished, and not in the public domain - yet. If you must pursue this, then get in touch with application support in your country.

Having said that, I've re-read your original post, and admit to being a little confused as to what you actually do want.

we need to get the last scan time if it is in continuous task, and to get rate (scan time in periodic) if it is in periodic task

What exactly is it you want if the task is periodic ?
The periodic rate (the time interval between executions), or the periodic task scan time (how long the task takes to execute) ? If it is the periodic rate you want, then this is fixed by task configuration and will not change, unless you write a GSV to change it. If it is important that the periodic rate doesn't get changed, then you could write a GSV to set it in a protected routine.

Secondly, don't forget that the Continuous Task's Last Scan Time, will include all of the time that interrupting periodic tasks (or event tasks) take to execute during the continuous task scan. You have not mentioned these Event tasks, how do these figure in your data collection. Also the "System Overhead Time-Slice" setting will affect the scan time, especially when the option to use unused SOTS is checked on.

And finally, (and it has to be asked), how and why is this information so important to you? It is not a usual thing for the application to know about this level of detail about it's execution, the information is provided primarily for programmers/SI's to configure the controller, in order for the program to effectively achieve its function. Once set-up correctly, nothing is going to change it (barring a few exceptions.

I don't see how gathering this information is going to help.

regards, daba