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!

I've seen behavior A almost explicitly with VIs set to "shared clone reentrant execution", and behavior B almost explicitly with VIs set to "preallocated clone reentrant execution" (nomenclature from 2013). I had assumed that this setting was what caused each of these behaviors.

Here's the solution I was suggesting

How are you creating a K-map from an array of numbers? I assume each bit represents the state of a variable. Are they being OR'd, AND'ed, XOR'd? How do you know how to build your map from the array? What statement are you trying to map? ETA: Also, did you know you can make a 2-D array of LEDs on your front panel by dropping an Array control (ctrl-space "Array"), then placing an LED control inside that control? This way your K-map will be a nice grid, but you will have to address the array through the array tools (build array, replace array subset, etc...). if you make a 4x2 2D array of booleans on your block diagram (place an array constant and boolean constant inside that, or use "Create array" with a boolean input, then drag the "size" section down by 1 and wire a constant of 4 into the first size input and 2 into the second), you can address individual cells of that array, and set new cells each run through the FOR loop. Use Shift registers to hold data from loop to loop, and 0-indexing to address the correct LED (e.g. ABC' would be 2,0; A'B'C would be 0,1). Now all you need to do is change from numbers to indices and you have your built map.

The runtime engines will coexist well together. Some drivers sets will not - be sure you can find drivers supported by both engines, if you need the same functionality on both builds, as (afaik) you can only have one set of drivers for each instrument type (e.g. XNET, DAQ, DMM, etc...)

"Launch" - I believe this refers to LabVIEW starting. If you're running an executable, it would be when that executable is opened. "Open" - This is when a specific VI (or control, though there're not many things that happen when a control is opened) is started (double click on it in a project or in a file system folder), and you can see its front panel on your user-interface. "Call" - When something is executed from the block diagram of another executing VI. "Loaded" - Things are loaded into memory at different times. Anything in the direct hierarchy of a VI is loaded when that VI is opened and loaded (If you open "Main", it and all of its sub-vis and their dependents will be loaded into memory). For dynamically loaded VIs, when the code which loads the VI (not runs) executes, it is loaded into memory. I hope this clears up any confusion.

One note: you will want to move your location back to where it should be if you're decimating (multiply by the decimation factor). There're a couple other logic things which are also redundant. The biggest time sink would probably be polling your controlls. Try this version (it's in 2013). And of course I didn't test my code properly, and it seems to run more slowly than yours... I'll have to dig more deeply into why... Peak Finder 2013.zip

For most of my cRIO applications, I've been able to deploy all software onto the cRIO and control it through an RS-232 command/reply interface with commands general enough they can utilize most of the I/O for the system, but narrow enough that only intentional misuse would be able to do anything destructive with the signals. Thankfully, I'm mostly working with test equipment, and the systems which are controlling the tester through RS-232 are behind quite a bit of firewall. If I were in a different environment (Ethernet connection preferred, non-controlled engineer interacting with my interfaces), I would look into encrypting/decrypting command/response pairs, having the embedded software interface be less generalized, and each command only able to perform tasks which will not hurt the system or endanger anyone (with a much larger set of commands needed). Reducing the scope of "acceptable" commands (case-sensitive, defined command length, etc...) would also reduce someone attempting random commands' ability to tamper with the system. Depending on the application, I might use a cloud service. I would just assume that the controller of the cloud service had access to all information stored there, no matter the encryption level.

To beat a dead horse: You live in a land where people speak English. Everyone around you speaks English, so it's totally ok if you don't learn another language. If you want to visit another place where people speak a language completely foreign to you (let's say Japan), if you want to communicate effectively, you may want to learn that language first. You'll find things you've never considered doing, like having no future tense, or conjugating adjectives, common place in this new language. There are things which can be communicated much more effectively there, but some things you won't be able to say at all, or will take forever to explain. Do you have to learn Japanese? Not really, I'm sure people there would love to practice English, and you could get by. Would it help you understand their point of view? Probably.

My first attempt at this would be to have an accessor which does the translation between coordinate systems - anything talking to the accessor will use the bottom-left origin coordinates, but the accessor will output the image as LabVIEW would read it (with the upper-left origin).

Since this is for a presentation at a User Group meeting, I wanted to keep as much of the code to standard LabVIEW install as possible (for those who inherently dislike plugin tools for whatever reason). This should make it so that anyone with the correct version of LabVIEW will be able to review the code off-the-shelf. That being said, I think I'll look into the JSON package for my own work. Thanks for the link!