hooovahh

An expert could probably do it in a day or less. Someone new to LabVIEW might spend months and not get anywhere. It really depends on experience level and training. Think of it less as a front panel and more of a test application. How long would it take for someone to come up with a test application in other programming languages? Well if they have no experience in any programming language I'd say a very long time. The easiest solution is usually the least modular, scaleable, reusable, extensible, and eventually the most bug ridden and hardest to manage because requirements will change.

Dynamic (or semi-dynamic) UIs in LabVIEW can be a pain for sure. Years ago I attempted something called Multi Panel Interface. Don't look into using it, it was just a proof of concept. But my point is that the amount of development in making this UI was a decent amount of work. For this I'd suggest starting with just one UI that combines all three views of a single signal into a window. Then you can use a transparent tab with each of the three UIs that you have now on their own separate tab. Your code can run and update the UIs on all three tabs all the time, but the user will only be shown one at a time depending on what they selected at the start. Next I'd look into using this in subpanels. So your one UI that works on a single signal can be reentrant and spawn all the clones you need. For your single UI that beings them all together you can have 8 subpanel controls that get moved and resized with property nodes. Or another solution might be to create 8 separate VIs each with one more subpanel than the previous, and depending on the number of channels selected, that VI can be selected. The benefit of this is you can have them all evenly spaced with splitting panes and have them fit to the pane so resizing of the main UI is already taken care of for you. Without this resizing would have to involve looking at the new UI size and resizing all the subpanels with properties again.

Thanks but I don't know everything. The community as a whole knows way more than just myself about the best ways to do things. Post here, or at the NI forums if you have question about the pros and cons of solving a problem a particular way.

Why thank you. I've been using LabVIEW pretty much daily since college in 2004. If you do anything that long, and that often, you get pretty good. I often make the comparison to a welder. If you started mig welding in 2004 your first welds probably look pretty terrible (just like my code). But after doing it daily for 13 years you had better be pretty good. Then there's the fact that I actually enjoy programming in LabVIEW so I seek out new techniques and keep up with the community. Anyway enough about me. OpenG is a fantastic set of tools that every developer should have available to them. They are licensed under BSD which is a pretty relaxed license stating you can use it or modify it however you want, with only a few minor caveats. The code has been used and tested since version 5 (or older), but hasn't had any major updates in a while. Some of the most valuable are under File I/O, Array, and the Variant Configuration. Having a single function that saves a front panel to a file, and loads a front panel from a file can be very useful. Global variables aren't the only way to pass data around to other parts of the application. Native globals have their place but often times a more manageable solution is to use a functional global variable, VIG, or action engine. http://forums.ni.com/t5/LabVIEW/Community-Nugget-4-08-2007-Action-Engines/m-p/503801#M240328 http://www.labviewing.com/fgv-in-labview/ http://forums.ni.com/t5/Example-Programs/Basic-Functional-Global-Variable-Example/ta-p/3503982 Like in this case I could see an action engine that has a Load, Save, Read, and Write method. Other options for passing data can involve references like a queue, or in modern versions the channel wires.

I found several other suggestions. Control labels should be unique Control terminal labels should always be seen. Overuse of local variables Use of native global which doesn't seen necessary here Use of scalar data when you want it to grow as needed (meaning arrays should be used) Use of sequence structure Attached is a re-write that uses a state machine and no local or global variables. For the saving and loading I highly recommend getting the OpenG Configuration File palette which allows saving any data time into an INI file, in this case I saved the Y C and Row Names. I also added the Add button which makes a new row. If you don't have the OpenG you can replace this with your own custom VIs that reads and write arrays of strings. Subvi_WCS Hooovahh Edit2.vi

Seems to work for me. There is quire a bit of inefficient ways of doing things, but the work of clicking Set Y or Set C does set the cell value leaving the rest. Am I misunderstanding what it should do? EDIT: Okay I see the problem. So in case 1 of the sequence structure add a Transpose 2D array after the second build array, if you probe this you'll see the array only has two rows but 6 columns which is the opposite of what you want. Then the next issue is in case 2 where every time the VI runs you are initializing the array (outside the sequence structure) be be empty. What you probably want is to use a local variable on the WCS and wire it to the shift register in case 2. Then the newly loaded (and transposed) values will be used and will be replaced when you click Set.

What have you done? Post your code, show what you've tried and explain where you are having issues. Beyond that here is some code that is a marquee with scrolling letters. http://forums.ni.com/t5/Example-Program-Drafts/Moving-Message-Board-Example-Code/ta-p/3494437 http://forums.ni.com/t5/LabVIEW/Labview-Marquee-Help/td-p/2716369 And in the future be sure and use a more descriptive title explaining what you are doing instead of saying Hi.

That's how I do it on my Linux RT based cDAQ. Drop down a System Exec function and give it this string on the input to the Command Line: unzip "%s" -d "%s" Where the first %s is the path input to the zip you want to unzip, and the second is the path input that is the directory of where you want the zip to be extracted to. Looking at my code I also provide the Working Directory as the folder that the zip resides in but I think that is unnecessary. It is a bit disappointing the NI and OpenG compression utilities don't work on the Linux RT, but wrapper VIs could be made on the system exec and get similar functionality. If you SSH into the system you can get help on the unzip and zip functions showing the various command line options.

Version 1.4.1 is on the tools network. I just opened VIPM and it told me there was an update for the UI Tools package. The version listed here on LAVA still looks like 1.4.0.

Yeah it is unchanged from the version posted in the thread I linked to from over a year ago. But I still had plenty of people find that thread, and then try using all the broken versions so I figured I'd get around to putting in the code repository. Glad you like it, hopefully some day we won't need it.

View File XNode Editor 8 Years ago the first version of the XNode Manager was posted to the code repository in an attempt to allow the editing of XNodes. Being a fan of XNodes, but knowing that the XNode Manager is pretty limiting because of its age, I set out to make a new version with similar functionality. The XNode Manager had a blank XNode, and blank Abilities that it just made copies of. This is fine but then the abilities and XNode are quite old. There were many new Abilities added since version 8.2 and you can't add them using the XNode Manager. My XNode Editor reads your LabVIEW resource and populates the list of abilities to create from the ones that are possible to create. Then VI server is used to create the XNode, State control, and Abilities. This sets up the connector pane like it should and should work with all future versions of LabVIEW, until NI changes something that breaks it. It also reads in the XNode Ability descriptions to help understand how to use the new ability VIs. In addition to being able to create and edit XNodes, you also can edit the XNode icon, and description, along with adding any new abilities. Be aware this uses several private functions, and several undocumented features that could be potentially bad. I did a decent test to make sure memory leaks weren't a problem and I made several XNodes and Abilities and it seems stable. But at the end of the day if it blows up and crashes, don't be surprised, you've been warned. The original thread with discussion and progress on this tool was started here. Submitter hooovahh Submitted 03/15/2017 Category XNodes LabVIEW Version

Neat concept. One of those reuseable functions I've had for a while can get all references to controls on the FP given a VI reference, and the name of the control. This works alright, but the control references are of the control class and not the more specific class like String Control. I improved on this with an XNode that still does searching for controls based on their labels, but you can specify the control class to cast it to. Still in some cases I think I like yours better. If I needed to do an operation on all booleans I'd use mine since it returns an array of references, but yours is pretty damned simple.

But yes your points are valid about the classless nature of my example. VIMs (which can work better with classes) might open this up to a few more possibilities where XNodes fail. And as for the UI I had never thought of that, and never thought I needed it, but I admit I could see a few places where that type of functionality could be useful.

Oh but they could. Look at my circular buffer XNode example. It is an XNode but it could still be used as a VIM. It bundles a DVR with some information, and the data type you want, and then the other functions change the data type of a control or indicator, based on the DVR. So what you have is an Init function where you define the data type (like obtain queue) and then the read returns that same data type (like dequeue)

Yeah VIMs feel like they solve at least some of the features you want in the linked idea. But in the current implementation I think the math still might have coercion taking place. NI is investing in VIMs, and I have hopes we'll see something official from NI. But until then you can make and use VIMs with the understanding that the technology is private, and may change with future version of LabVIEW.

I don't organize the BBQ but help out where I can. I contacted the main organizer from last year but haven't heard back yet. Regardless I'm booked for NI Week so I'll be there.

Well I imported an LDF and the frames in the XNet Database editor show that some use the LIN Chucksum of Classic, and some Enhanced. But in both cases, and with creating a new frame, this drop down is disabled. So it appears XNet supports it, but I don't know how to set it. You may end up finding more help over on the Automotive subforum on the dark side. Oh and it looks like there is a property for this but I've never used it.

There is also a subforum over on JKI for State Machine Objects, but it sure looks empty. You might find some support over there too. http://forums.jki.net/forum/64-jki-state-machine-objects/

Not that I know of. I'm guessing someone with more site control could potentially do it, but I can't. Just forgetting that this site exists and leaving your account forever is probably fine. I know I'm probably signed up for 50 or so forums on the net for various things, and I probably regularly use 3.

Is this just detecting a rising and falling edge? The OpenG boolean palette has Boolean Trigger, and there is an NI function Boolean Crossing. Beyond that you can do the same thing with a feedback node and a compound arithmetic function configured correctly.

Crosspost

It probably isn't going to be easy doing it yourself. The simple touch screens I've used just simulate mouse interaction so multiple touches get registered as multiple mice, but there are several caveats associated with it. I'd suggest looking into one of the toolkits for this type of thing. I've never used one but it is where I'd start if I had to do anything advanced. I thought NI had one but I can't seem to find it. http://sine.ni.com/nips/cds/view/p/lang/en/nid/212474

Is this EXE ran on the same exact PC that the EXE was made on? Because that doesn't seem right if it is. I'd suggest doing a repair install of DAQmx and see if it resolves it. Even so the best course of action when making an EXE is to also make an installer. This is because when making the installer you can choose to include all the external NI dependencies like DAQmx, VISA, NI-DMM, NI-XNet, etc. In newer versions of LabVIEW it can detect what installers it needs to include and select them by default. Then you can take this one installer (which might be a bit big) and install it on any computer which has no previous NI software, and your application should run.

Just using scripting. If you have a folder of VIs you want to check for you can use the Recursive File List, looking for all *.vi files. Then in a for loop get the path of each, and use the Open VI Reference. Then you can look at the Execution >> Is Reentrant, and even Execution >> Reentrancy Type to state if it is shared or preallocated. Be sure and close the VI reference after this. If you have a VI and you want to travers down into it, you can use a Static VI reference and plop in your VI. Then using property nodes get the block diagram, and this reference can return all SubVIs as an array which you can again iterate over.