This board is for PLC Related Q&A ONLY. Please DON'T use it for advertising, etc.
|Try our online
PLC Simulator- FREE.
Click here now to try it.
New Here? Please read this important info!!!
|August 19th, 2009, 07:31 AM||#16|
Join Date: Aug 2009
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).
|August 19th, 2009, 08:00 AM||#17|
Join Date: Mar 2007
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.
|August 19th, 2009, 09:35 AM||#18|
Lifetime Supporting Member + Moderator
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 by daba; August 19th, 2009 at 09:48 AM. Reason: explain
|August 19th, 2009, 03:36 PM||#19|
Lifetime Supporting Member
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 is a DINT array
//Get the task start time as a 64 bit time value in microseconds.
//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 contains the time between two successive starts of the task in microseconds
Data := Data - Data;
//Save the task start time as a reference for next time the task starts. Ignore MSW in Data. We will only bother with the LSW.
Data := Data
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.
True craftsmanship is only one more power tool away.
That's the beauty of processors, they don't have emotions they just run code - The PLC Kid.
Last edited by TConnolly; August 19th, 2009 at 03:42 PM.
|Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)|
|Thread||Thread Starter||Forum||Replies||Last Post|
|Logix 5000 PID Instruction in a COntinuous Task||plcnovel||LIVE PLC Questions And Answers||29||August 13th, 2007 12:11 PM|
|RSLogix 5000 FB Totalizing - Periodic or Main Task||BillRobinson||LIVE PLC Questions And Answers||2||May 24th, 2007 11:35 AM|
|rslogic500 /controllogic 5500||mgomezov||LIVE PLC Questions And Answers||23||June 14th, 2006 11:36 PM|
|RSLogix 5000 V15 Features||Samneggs||LIVE PLC Questions And Answers||18||April 20th, 2006 05:45 PM|
|PIDE's in periodic tasks RSLogix 5000||BENNY||LIVE PLC Questions And Answers||18||August 25th, 2005 11:06 AM|