OpenG "Periodic Trigger" function -- off-by-one bug?!?

[Kevin P]

Attached is a simple test vi.  Whatever value N you enter for "period (ms)", the "Triggered" boolean will actually fire with a period of N+1 msec.

 

Looking over the block diagram of the function, it appears to me that the ">" comparison should instead be ">=".   I expected to find some prior discussion about this, but was surprised to find nothing.  Another screenshot is attached to show my comments on the OpenG block diagram.

 

 

-Kevin P

 

openg periodic trigger off-by-one demo.vi

[egraham]

That's a good catch. I never use this function for millisecond accuracy, but it's drifting by about a millisecond every time it elapses.

[hooovahh]

Is there a reason you are using this function and not the native "Elapsed Timer" express VI?  I've never used the OpenG function and wasn't sure where one would be better suited than the other.

[Kevin P]

Fair question.  Reasons are probably mainly habit and history, not a careful evaluation and decision.  

 

Habit - having been a long-time DAQ user, I've studiously avoided the DAQ express vi's b/c they were rarely suitable, often inefficient, and always opaque.  Once in the habit of avoiding *those* express vi's, I've tended to avoid all other express vi's as well.  The only exception has been the neighboring floating point 'Time Delay' express vi.

 

History - for a long time the floating point time functions were quantized at about 16 msec resolution on Windows machines.  I guess that maybe changed around the time of Windows 7?  I had built up a history of not relying on on built-in floating point time when I wanted msec-level precision in my timestamps.

 

When I found the issue, I made up a function that behaves like "Periodic Trigger" but which is based on the newly-exposed "High Resolution Relative Seconds".   Not sure I can argue that the extra resolution is really necessary, but given the choice I'd rather have more than less.  

 

I just ran a quick test of the native express vi "Elapsed Timer" and I'll be durned if it doesn't seem to exhibit the same high precision.  I may well switch over and use it all the time, once I kick the tires a bit more to make sure it doesn't carry too much cpu overhead.   Thanks for the nudge.

 

 

-Kevin P

[hooovahh]

No problem.  I know the stigma around express VIs very well.  To be honest I only use two express VIs in a very large amount of my own code.  The Elapsed Timer, and the File Dialog.  When I do use them, I try to always view them as a normal subVI and remove the label.  Still for these two functions, the simple stuff just works.  Sure it doesn't have a pause resume feature, but when I need that I'll start with the Express VI, convert it to a normal VI, and then add that funcion.

 

I try to use the native functions first, then OpenG, then other 3rd party tools, then I'll write my own if none of these options fit my needs.  I'm sure others prefer similar chain of tools.  There are goofy times that maybe the native solution works, but only for half the cases in which I need to remember what ones work in what cases and what ones don't.  Like it is nice that there is now a native "Get File Extension" under File I/O.  Too bad it only supports the path data type, and not the string like OpenG.  In this case a path to string conversion can fix it but there are several examples of this type of partial overlap in functionality.