Data Server: Why does my clock time triggers fail occasionally when under a minute?

Potential Symptoms

Why does my clock time triggers fail when under a minute?
 

Environment

Product Family: Sports Software and Controller
Product: Data Server
Components: Automated data triggers
Control System:

Cause

Triggers based on clocks can fail for a few different reasons. Here are potential causes: 

1.  Some clock times shift in the ERTD stream depending on hours, minutes and seconds left (see fields 1 and 3 before and after the 1 minute mark):
Machine generated alternative text: Field* Nam  Main czck  Main czck Time  Main ouvTOD Iti 59  Main  Main )  Main OuvTOO

2. All Sport clocks update every tenth of a second when under the 1 minute mark. Complex trigger logic can take longer than a tenth of a second to evaluate all of the conditions and branches. The data can't be updated while conditions are being evaluated, so ERTD changes get put into a queue for triggering logic to run against. To avoid risk of evaluating old data that has been in the queue for a while (when data is received faster than processed) the queue size has been set to 1 so the latest data replaces the currently queued data ensuring the next iteration of triggering logic runs against the most current data.

Because of this, while evaluation of a packet containing "0:50.1" the packet with "0:50.0" may be skipped because "0:49.9" arrived prior to 50.1 completing its work. So if a condition checking for Clock = "0:50.0" could fail to trigger.

3. Other causes:
  • UDP packets are not guaranteed delivery, especially in control rooms with an old or poor network setup under heavy load, and therefore triggering may not always receive an ERTD packet containing a specific value you're looking for, like "11:00.0".
  • An old computer may not have the memory and processing power to handle running logic at tenth of a second speeds.
  • If you have a lot of triggers and a complex set up, there may be a point where you cannot keep up with data coming in every tenth of a second.

Resolution

1. Use clock fields that don't shift when tenths of a second is shown (fields 2 and 4) and understand the formatting differences that some clock fields have depending on the situation.
Note: Be aware that leading and trailing spaces are removed from data fields prior to comparing against your custom field.

2. My clock time trigger still fails under a minute and I'm using fields that don't shift the minutes values within the ERTD.
 
All Sport clocks update every tenth of a second when under the 1 minute mark. Complex trigger logic can take longer than a tenth of a second to evaluate all of the conditions and branches. The data can't be updated while conditions are being evaluated, so ERTD changes get put into a queue for triggering logic to run against. To avoid risk of evaluating old data that has been in the queue for a while (when data is received faster than processed) the queue size has been set to 1 so the latest data replaces the currently queued data ensuring the next iteration of triggering logic runs against the most current data.
Because of this, while evaluation of a packet containing "0:50.1" the packet with "0:50.0" may be skipped because "0:49.9" arrived prior to 50.1 completing its work. So if a condition checking for Clock = "0:50.0" could fail to trigger.
 
A variety of things can be done to make triggers more efficient.
  1. Consider using a custom DID to break data fields into parts that don't change as oftens. i.e. create a Minutes field and Seconds field (or Seconds Tens-Digit field). This allows you to wrap your trigger into a 'Changes' trigger that can exit out early if the minutes value of the clock doesn't change and avoid evaluating all of the conditions every second or tenth of a second. Note: Custom DIDs should only be imported into and used by Data Server (not Content Studio or anywhere else)
 
Machine generated alternative text: Clo:k Changed  on 11  on 11  on 11  Play •500-55Y  Play on 11  Play am-353 on 11  Play '200-254 on 11  Play  Play coo-05Y  Ting  Recurring  CW:k =  Cl.:k Miwtø 2  CkKk 1  inu
  1. Set the SubTriggers to 'First' instead of 'All' on every parent trigger that should only have one of its sub triggers fire. This allows the logic to exit early and not continue to check all of the other sub triggers every time. For the example above, if the clock time changes to 5:24, it will play the content 500-559 on sign 11 and exit without checking for Clock Minutes = 4, 3, 2, 1 or 0. If SubTriggers was set to 'All' (as is by default) it would run through all of those checks even though we know they won't be true.
  2. When using SubTriggers set to 'First', order the conditions such that the most common is listed first and the least common is listed last to exit out early more often.
  3. The same set of triggers can be defined multiple ways, and with some thought you can simplify the number of checks (even though it's not always intuitive). The following triggers are identical in behavior but the second requires less logic:
Machine generated alternative text: to 59  O to 29  Clock  30 to 59  O to 29  MimJtes  CRX k 30 to 59  O to 29  MimJtæ = 2  30 to 59  Ck*k Seconds O to 29  30 to  C to 29  CICKk MimJtes = O  30 to sg  O to 29  Min OR sec-IOS-Digit Changes  Min OR sec-IOS-Digit Changes  O to 29  on 11  on 11  on 11  on 11  on 11  on 11  on 11  on 11  Recu m ng  on 11  on 11  Pla., •530-55* on 11  Play •soo-52Y or, 11  Play •43045Y  Pla., •400-42* on 11  Play 330-35*  Play •300-327  Play 230-25* on 11  Play '200-22* on 11  Play •130-15* on 11  •100-12* on 11  •030-05*  ODO.02Y on 11  MimJtæ = 5  MimJtes 4  Ck*k Minutes = 3  Minutæ= 1  30 to 59  Clock 5  Mim_'tz 4  MimJtes 2  Ck*k Minutes 1  Pla., •soo-S2Y on 11  300-32*  Play •zm-22Y  Play •100-12*  on 11  •530-55*  Play •43045Y  Pla., •330-359 on 11  Play 230-25* on 11  Play '130-15*  pm 00-057 on 11

3. Other resolutions:
  • Consider an analysis of your system's network to ensure it isn't having issues with dropped or delayed UDP packets. There are some techniques to help improve the performance of your network if this is the case.
  • Consider computer or network upgrades if you have an older system that is struggling to keep up.
  • Consider Simplifying/Removing unnecessary triggers to reduce stress on the system.

KB ID: 000019770


DISCLAIMER: Use of this content may void the equipment warranty, please read the disclaimer prior to performing any service of the equipment.

DAKTRONICS DOES NOT PROMISE THAT THE CONTENT PROVIDED HEREIN IS ERROR-FREE OR THAT ANY DEFECTS WILL BE CORRECTED, OR THAT YOUR USE OF THE CONTENT WILL PROVIDE SPECIFIC RESULTS. THE CONTENT IS DELIVERED ON AN "AS-IS" AND "AS-AVAILABLE" BASIS. ALL INFORMATION PROVIDED IN THIS ARTICLE IS SUBJECT TO CHANGE WITHOUT NOTICE. DAKTRONICS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING ANY WARRANTIES OF ACCURACY, NON-INFRINGEMENT, MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. DAKTRONICS DISCLAIMS ANY AND ALL LIABILITY FOR THE ACTS, OMISSIONS AND CONDUCT OF YOU OR ANY THIRD PARTIES IN CONNECTION WITH OR RELATED TO YOUR USE OF THE CONTENT. ADJUSTMENT, REPAIR, OR SERVICE OF THE EQUIPMENT BY ANYONE OTHER THAN DAKTRONICS OR ITS AUTHORIZED REPAIR AGENTS MAY VOID THE EQUIPMENT WARRANTY. YOU ASSUME TOTAL RESPONSIBILITY FOR YOUR USE OF THE CONTENT AND ANY LINKED CONTENT. YOUR SOLE REMEDY AGAINST DAKTRONICS FOR DISSATISFACTION WITH THE CONTENT IS TO STOP USING THE CONTENT. THIS LIMITATION OF RELIEF IS A PART OF THE BARGAIN BETWEEN THE PARTIES.

The above disclaimer applies to any property damage, equipment failure, liability, infringement, or personal injury claim arising out of or in any way related to your use or application of the content, whether such claim is for breach of contract, tort, negligence or any other cause of action.