Leaderboard

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

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.

I understood some of those words...okay no I didn't.

When we talked about it I had multiple LabVIEW versions installed on my dev machine, but since then I've moved on to use separate VM's for the different LabVIEW versions. I do still have one laptop with multiple LabVIEW versions, used occasionally for building old SW packages, and this tool is very handy to have. /J

Thanks Brian!

Who likes to resurrect 6 year old posts...this guy. So over the years I've updated my LabVIEW Tray Launcher tool. It has very similar functionality as the one mentioned 6 years ago, but with some new features, and a few features that are the same but done better. Launching, killing, and restarting LabVIEW versions should work on all versions, but it is untested with 64 bit versions. It has been tested in 64 bit Windows, with 32 bit LabVIEW. Aborting VIs should work on all versions 2011 a newer. Older versions can be supported with more effort. Aborting VIs don't abort asynchronous clones. LabVIEW Run-time, or development 2011, 2012, 2013, or 2014 needs to be work. Others can be supported with more effort. By default opening VIs, and CTL files is done through this program and not LabVIEW. This allows these files to be opened in the right version. Other file types have varying level of support, but should work if they are added to the settings. If multiple versions of LabVIEW can open a file a dialog will show the available options. If only one version of LabVIEW can open the file it will open it with that version. If multiple versions of LabVIEW can open a file, but one is open already that can open it, it will open it with that version. If Shift is held when opening the file, a prompt will always be shown giving the option of what version to open it with. When opening the file VI Server is used, so unique server ports are needed between LabVIEW versions. If VIPM is configured and works, so should this. Pressing CTRL at the LabVIEW selection screen will open it in the default version of LabVIEW, or the oldest if the default isn't an option. This is all hosted on my personal site for now. It is a little large for a forum post, and the Code Repository blocks it, probably because it contains EXEs. So for now it will live on my site here.

Depends on your role in the house-building process. If I'm the carpenter I'll focus on how to use a table saw thank you very much. The architect isn't in much danger of cutting off his thumb because he was careless while sharpening his pencil. (Actually I agree with your statement--the language used to write an application is far less important than your average c++ developer would lead you to believe, and most software design principles are largely language agnostic. I just had an uncontrollable urge to poke my finger through the hole in your metaphor. ) -------------- To answer the OP, if we couldn't use LV anymore I'd probably switch over to C#.

[soapbox] The language used isn't all that important, really. It's just a tool. As an analogy, the knowledge of how to build a house is much more important, and harder to acquire, than the ability to use a table saw. In the same way, the knowledge of how to build a functioning system that includes software is more important than the tools you use. [/soapbox] Sorry, it leaked out. Joe Z.