Home → Questions →

action type="schedule" -- parsing in tags

• Edit

Mark Histed

26 Mar, 2014 01:22 PM

Hi Chris,

I see in your examples that the "schedule" action takes a timebase suffix at the end of the delay param:
"500 ms" for example. I found some unique behavior when you use an expression in the tag.
For example: when schedDelayUs is 500000,
 delay="(schedDelayUs/1000.0) ms"
produces a delay of 500 ms, and
 delay="schedDelayUs/1000.0 ms"
produces a delay of 0 ms.

Perhaps you could document how these parameters are intended to be parsed? I didn't explore the space widely, just enough to fix the bug I am seeing.

Thanks,
Mark

• SchedParseTest.xml 4.16 KB

1. Support Staff 1 Posted by Christopher Sta... on 27 Mar, 2014 03:39 PM

   

   Hi Mark,

   The time unit suffixes are a feature of the expression parser. They're implemented as unary postfix operators, with precedence just above the unary prefix operators (+ - ! not). When evaluated, they have the following effect (where x is any expression):

   x us => x
   x ms => x * 1000
   x s  => x * 1000000
   

   The "unique" behavior you're seeing is the result of operator precedence, specifically the fact that the time suffix operators have higher precedence than any other operators. In the expression

   (schedDelayUs/1000.0) ms
   

   the parentheses cause schedDelayUs/1000.0 to be evaluated first, with the result being multiplied by 1000. On the other hand, in

   schedDelayUs/1000.0 ms
   

   the 1000.0 ms term is evaluated first, so the expression reduces to

   schedDelayUs/(1000.0 * 1000) == 0.5
   

   and your requested delay is actually 0.5 microseconds.

   There are a couple reasons why I've been hesitant to document or otherwise advertise this feature. First, implementing units as a shorthand for multiplication is kind of flaky. For example, the following expression is perfectly valid and evaluates to 5e12:

   ((5.0 ms) s) ms
   

   Second, time units are handled inconsistently in MWorks, and mixing different approaches can get you in trouble. For example, both the "wait" and "start_timer" actions accept an arbitrary expression (which can include time units) for their "duration" parameter, while also supporting a separate "duration_units" parameter. This means you can do something like

   <action type="wait" tag="Wait" duration="1.0s" duration_units="s"></action>
   

   which will result in a wait of 1000000 seconds.

   Hence, I'm not sure that anyone should be encouraged to use the time unit operators.

   Chris

   • Edit

2. 2 Posted by Mark Histed on 27 Mar, 2014 05:01 PM

   

   > Hence, I'm not sure that anyone should be encouraged to use the time unit operators.
   >

   Agreed.

   Thanks for explaining. I realized it was some sort of precedence issue. I got the time unit operators out of an example (the schedule_actions example?). I will avoid them from now on.
   It's perhaps worthwhile to document this lack of encouragement somewhere.

   Mark

   • Edit

3. Support Staff 3 Posted by Christopher Sta... on 29 Apr, 2014 07:52 PM

   

   Hi Mark,

   After thinking about (and using) the time unit operators some more, I'm finding that they are useful enough to keep around and even recommend.

   One place where I use them a lot is specifying parameters for I/O devices. For example:

   <iodevice type="nidaq" tag="nidaq" name="Dev1" update_interval="3ms" analog_input_data_interval="1ms" analog_output_data_interval="2ms" assume_multiplexed_adc="YES">
   

   Specifying the intervals with expressions like 3ms seems much nicer than the alternatives, namely omitting the units (3000) or giving them in a separate parameter (update_interval_units="ms").

   As another example, while writing tests for the wait_for_condition action, I found it very helpful to be able to write assertion conditions like

   now() - (start_time + 50ms) < 1ms
   

   While the issues I mentioned previously remain a concern, I now think the best course of action is to document the time unit operators properly and include an explanation of the potential pitfalls -- which is exactly what I was already planning to do, except for the part about discouraging their usage.

   Chris

   • Edit

4. 4 Posted by Mark Histed on 29 Apr, 2014 08:21 PM

   

   Thanks.
   Just so I am clear:
   In MWorks, I assume that "3ms" is an integer with value 3000
   and "3e3" is a float also with value 3000?

   M

   • Edit

5. Support Staff 5 Posted by Christopher Sta... on 30 Apr, 2014 01:52 PM

   

   In MWorks, I assume that "3ms" is an integer with value 3000 and "3e3" is a float also with value 3000?

   Correct. Also, 3.0ms is a float with value 3000.

   Chris

   • Edit

6. Christopher Stawarz closed this discussion on 14 Apr, 2015 05:15 PM.