Hello,
I have a main scan interval that monitors TCP/IP data coming in every 500ms. In the first SlowSequence scan I have a code like shown below to trigger the execution of additional code contained within a WaitTriggerSequence in a second SlowSequence.
SlowSequence
Scan(1,Sec,1,0)
' **** I do some additional processing here before the ' evaluation below. ****
If TimeIntoInterval (5,60,Sec) Then
TriggerSequence (2,0)
EndIf
NextScan
EndSequence
SlowSequence
Do
WaitTriggerSequence
If BytesAvailable > 0 Then
' **** I do some additional processing here ****
Else ' when bytes are not available
CallTable ProcessData
CallTable TX_Status
EndIf
Loop
EndSequence
Now, these two tables that I called conditionally here do not have a DataInterval instruction and are driven by the call performed in this conditional loop. The problem that I'm having is that I noticed that when a clock set occurs, at any time during any interval, the code in the program is executed, including the call to the tables and data at that time is stored in the tables. As per my code, I expect these tables to store data once every minute, at five seconds past the top of the minute and they normally do. But, for example, if I manually click the Clock Set (from the Connect Window), 5 times within a one minute interval, the table stores data for those timestamps, like if the trigger was true every time during those. And I don't understand why is that happening. Obviously, the manual clock set was the way for me to confirm that this was happening since I noticed some unexpected timestamps in my data (coinciding with my automatic clock synch schedule).
Is the TimeInterval instruction valid inside the slow sequence? It works fine at all times except these cases, and is inside a Scan instruction so I imagine that it's okay. Now, as you can see, the call to the tables are inside a conditional evaluative statement, which to me it means that the clock set it's actually driving the execution of the code itself and it's not just a table storage response (due to not having a DataInterval instruction, as I initially thought).
Any insights?
Thanks,
Tatiana Bonilla
We need to examine your program a little closer to see exactly what might be going on. Could you send me a copy of your programs. My email address is gtroberts at campbellsci dot com.
-Gary
It looks like this is a bug in the current OS that Engineering will be fixing in the next release.
Here is the explanation from them:
“The WaitTriggerSequence instruction waits on an "event" that is set by the TriggerSequence instruction. (There is one of these "events" for each each slow sequence.) The "events" used is the same event that is used when the sequence is driven by Scan()/NextScan instead of by TriggerSequence, i.e., when inside of a slow sequence NextScan executes, it waits on the same event that WaitTriggerSequence waits on, and in this case the trigger of the event is when the interval of the scan expires.
Whenever the clock is set, the interval trigger is no longer a valid trigger to start the scan since we have the requirement to start the scan synced to real time, for example, at the top of an even minute or an even second. The scan interval for the scan when the clock is adjusted so that the next scan starts out correctly. Therefore when the clock is changed, we "trigger" all the slow sequence events (and the main sequence event) and the NextScan's that are waiting on the event when triggered, before starting the new scan, which they normally would do, look to see if the clock was changed and if so they re-sync to the new real time, i.e., establish the correct remaining time before the next scan is due to start, and then wait for that time before starting the new scan.
WaitTriggerSequence does not currently detect, as NextScan does, that it was triggered by the clock changing instead of by the TriggerSequence instruction, which is why the unexpected behavior happens. We will fix this in the next OS's by changing the WaitTriggerSequence to detect they were triggered by the clock changing and rather than allowing the program to move on to the next instruction simply re-enter its wait on the event state.
Thanks as always for bringing this to our attention and please pass this on to the forum.”
In the meantime, I will look your program over and see if we can find an alternate way of getting you what you need.
-Gary
Thank you for the prompt response!
One possible way to get around the bug would be to add a If NOT ClockCheck and a EndIf before the end of the loop (or a variant thereof ) to the SlowSequence. ie. (using the code listed above):
SlowSequence
Do
WaitTriggerSequence
IF NOT ClockChange
If BytesAvailable > 0 Then
' **** I do some additional processing here ****
Else ' when bytes are not available
CallTable ProcessData
CallTable TX_Status
EndIf
EndIf
Loop
EndSequence
or
SlowSequence
Do
WaitTriggerSequence
If BytesAvailable > 0 AND NOT ClockChange Then
' **** I do some additional processing here ****
Else ' when bytes are not available
CallTable ProcessData
CallTable TX_Status
EndIf
Loop
EndSequence
This would set it up so that if a clock change caused the trigger to be set, it would not process the items in the if/endif portion. The chances of a clock change happening and the 5 minutes after the hour trigger happening at the same time should be rare.
That should be the ClockChange instruction not Clockset. Sorry about that. Got my wires crossed.