Jump to content

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


Recommended Posts

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

post-2744-0-99188400-1424965299.gif

  • Like 1
Link to comment

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

Link to comment

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.