action type="schedule" -- parsing in tags

Mark Histed's Avatar

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

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

    Christopher Stawarz's Avatar

    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

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

    Mark Histed's Avatar

    > 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

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

    Christopher Stawarz's Avatar

    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

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

    Mark Histed's Avatar

    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

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

    Christopher Stawarz's Avatar

    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

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

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts

Generic

? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac