RSLogix 5000 - Periodic or Continuous task?

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

Hi Daba,

thank you for your suggestion.

We are developing modules (motor, valves, etc.) under S88 standard. the aoiSystem module needs to pass the last scan time (if the process task is continuous type) or scan time (if the process task is periodic type) to tag stsData.stslastScanTime.

in valve module, valve traveling time counts up by adding last scan time (stsData.stslastScanTime). i.e. pvtTravelTmr := pvtTravelTmr + sysData.stsLastScanTime; and this is the purpose why we need to differentiate between coninuous and periodic (in this case, periodic and event are the same, so we don't need to differentiate periodic and event).

Regards

Simon
 
If you are using the value stsData.stslastScanTime to total up valve travel time, or motor run time, you will need more than the Program or Task scan time, you will need the total elapsed time since the previous scan. Maybe you should be capturing the CurrentValue from the WALLCLOCKTIME and finding the difference every execution. This should give you the total elapsed time since the last scan in microseconds.
 
My thoughts entirely, Brownhat.

Simon, you will never know the actual "valve travel time" from your calculations, only the time interval between writing the output tag to the database, and receiving the open or closed feedback into the database. These are factors outside your control, and as such ought to be discounted for s88.

Let's say your Output and Input modules RPI settings are 20mS (default value), then without using Event tasks driven by Input data change, and IOT instructions to update outputs immediately, your timing will be +/- 40mS. And as you'll be writing output tags at different times within your program scan, you'll need IOT instructions after every output is turned on or off. Just think of the loading on the I/O network this will cause.

IMHO this time is inconsequential to an actual valve, whose "repeatability" will be far greater than that.

Methinks you are trying to take things too far.
 
Last edited:
This should work for returning the elapsed time between execution of any continuous or periodic task, and it will work for event tasks as long at less than 35 minutes elapses between events. The elapsed time is in microseconds. This is the elapsed time between two scans of the task, not the scan time of the task. If you know this then does it really matter if the task is periodic or not?

It uses the task start time and saves this value as a reference time to compute the elapsed time the next time the task starts. It doesn't give you the configured period for a periodic task (besides, you know how to get that), but it does give the actual period.

This method relies on the fact that the CLX performs unsigned subtraction between numbers when overflow and underflow occurs. If it were any other AB plc then you would have to emulate unsigned subtraction which isn't difficult, but since the CLX does it for us, we won't bother. Also, if you might use the code in an event task where the time period is greater than 35 minutes then you are going to have emulate unsigned subtraction with a borrow from the MSW, which can be a real PITA.

//Data[4] is a DINT array
//Get the task start time as a 64 bit time value in microseconds.
GSV(Task,THIS,StartTime,Data[0]);
//On the first scan no reference time exists so we cannot calculate an elapsed time
IF (NOT S:FS) Then
//Compute the elapsed time. We will only concern ourselves with the least
//Significant DINT of the time reference and we will treat it as unsigned.
//If overflow/underflow occurs the result will be the result of an unsigned subtraction and will still be correct.
//Data[3] contains the time between two successive starts of the task in microseconds
Data[3] := Data[0] - Data[2];
End_If;
//Save the task start time as a reference for next time the task starts. Ignore MSW in Data[1]. We will only bother with the LSW.
Data[2] := Data[0]

I tested this on a CLX this morning and let it run through two rollovers of the LSW of the time reference.

It should give you what you need - but I agree with Daba that because of the asynchronous nature of your IO that the true actual valve travel time will be different. If you need to have accurate valve positioning then a valve position transducer is the way to go.
 
Last edited:

Similar Topics

Hello everyone, I am new to PLCs, what will happen if I set the Period of a Periodic task lesser than its execution Time for ControlLogix...
Replies
1
Views
1,602
Got into a bit of a debate the other day, and wanted to get some gurus' opinion/expertise on the subject. When duration of an output's ON (or...
Replies
9
Views
10,725
Hey all, Anybody have experience with RSLogix5000 Function Block Totalizing? Should a TOT function block be placed in a periodic task or...
Replies
2
Views
3,930
I am currently adding pide's to an existing RSLogix 5000 program (ver 13)for controlling our scrubbers. I am putting the pide's in a periodic...
Replies
18
Views
10,729
Hello all, I have a question in regards to RSlogix 5000. I am having issues with the program force closing when I try to make online edits. We...
Replies
0
Views
95
Back
Top Bottom