Chris_Collier

Verbally: Choose a threshold where your true/false value will be determined, then for each pixel, compare to that threshold. If it's above the threshold, it's one value (True/False), and if it's below the threshold it's the other (False/True). You get to decide which makes the most sense if they are equal.

I think our decision to no longer use TestStand stems from our need to run requirements-driven tests. The sequencer engine we have built takes requirements-level data and translates that to our test system for stimulus application and response measurements. No one at our location was knowledgeable enough to create a similar system so that the only thing we had to change while running a TestStand sequence was to point to the new requirement (no change to the test sequence run through TestStand or the modules TestStand calls). I have a bit of a deeper understanding of how TestStand works now, but am still not comfortable enough with it to create this type of system. One of the reasons I wouldn't want to create sequences in TestStand for each unit is that it isn't a very straight-forward system to use. I don't want to have all of the test engineers on my team required to know TestStand intimately, just as I don't want them to have to know LabVIEW intimately. Everyone should know the basics, a few should have a deeper understanding of the system as a whole, and at least one person knows the whole system intimately. If sequences were translated from our requirement documents to TestStand sequences, everyone on my team who creates unit tests (which is everyone on my team) would need to know TestStand. With our current engine, they need only know Excel. If there were more in-depth classes for how to make higher level architectures work in TestStand, and if TestStand didn't require a menu 3-deep for common functions, I might be more inclined to use it.

It is advisable to make the events handled by the Event structure as short of execution time as possible - it should only handle the fact that the user event occurred, not all of the things which come after the user event. Pass appropriate data to another loop to handle it properly. If you find yourself in a situation where you need to be able to access UI artifacts at all times, set up your event case not to lock the panel (add case/edit event case, un-check "Lock panel").

One thing you could do is have a configuration file with specific titles for each filename. When you pass your build off to your co-worker, they can fill in the absolute file name (or you could make a flag to allow for relative to the project, if you want to) and work with it having those VIs wherever they want, and you shouldn't need to change your code no matter how often they move the VIs.

I'm not sure I understand the setup - do you have code you can post which shows what's going on, or images if you can't share code?

Since you're using the USB-6343 to read analog signals from your measurement devices, you will need the DAQmx toolkit installed. After you install this, you should be able to access the "Create DAQmx task" and "DAQmx Read" functions (either you can look for these on the right-click pallets, or you can ctrl-space, then type in the name). Using these commands, and reading the available "help" (ctrl-h, then hover over the item you want help with), you should be able to determine how to get the analog measurements you need.

You have to edit the properties of the file itself.

You could write a script which runs during build which sets the strict type-def to a standard type-def, then reverts to strict after the build. See here: http://zone.ni.com/reference/en-XX/help/371361H-01/lvconcepts/running_vis_before_after/

I think the "Show front panel when loaded" is where your issue is stemming from. This will show the UI as soon as LabVIEW loads the VI into memory. Having this in the built version allows the splash screen to show a little sooner, as you don't have to wait for your program to begin running for the splash to occur - it just needs to be loaded into memory. Perhaps you can have it set as not show when loaded while in development environment, then add a function to the build process which sets this property true for the built function?

Does the mechanism have to be a shared variable? I'm currently working on testing out some TCP protocols for distributed user-interfaces, allowing one of the UIs to be on the local system. You would need to specify your data transfer protocol/how to parse messages to give you the data that you need, but it should work on any system which has TCP capabilities. This would allow for data transfer to programs other than those on the same machine as well. If you create a TCP listener in the software receiving data, then you create a TCP connection to the IP address "Localhost" and the port specified by the listener, you should be able to open a string-based communication channel. I haven't worked a lot with LabVIEW's network shared variables, because I like to know how stuff works (as much as possible). I also like being able to extend those solutions beyond LabVIEW, in case that becomes necessary. Hopefully that gives a few ideas!

Not really enough information for me to feel confident in purchasing tickets. This is also my assumption. Mine is the last comment on that thread, and it is from a couple days ago (not much time, I know), but the comment before mine is from almost two weeks ago. The comment before mine insinuates the question of "what is the actual schedule", but I thought outright asking might prove more informative.

There seems to be a dearth of information around this year's summit, and since there seems to be little information on the CLA forum at NI, I was hoping someone (*nudge* AQ) might be able to share schedule info (either here or at the NI forum) so that tickets could be purchased and reservations made with confidence. Thanks, -Chris Collier

Does this work: http://www.ni.com/example/30051/en/ It says it works on all LabVIEW versions post-2011, but I've not tried it.

Something you might look at is the window properties for the VI you want to have pop up. With the VI open either press ctrl-i or File-->VI Properties, then under "Category" choose "Window Appearance".

I would think it should look something like this. I've not tried running this... You will need to ensure all children you want as children of the inserted class are in memory before running this, though I believe anything in an open project is in memory. I hope this helps!