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.