hooovahh

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.

Did you recently buy LabVIEW? If so it comes with one year of SSP support which comes with some real good self paced online training. Other than that there are several other free resources out there. Here are some. NI Learning Center NI Getting Started -Hardware Basics -MyRIO Project Essentials Guide (lots of good simple circuits with links to youtube demonstrations) -LabVEW Basics -DAQ Application Tutorials -cRIO Developer's Guide Learn NI Training Resource Videos 3 Hour LabVIEW Introduction 6 Hour LabVIEW Introduction Self Paced training for students Aside from that the best way I learn, is to use the function on the palette one by one and see how they work. Be sure and read the help on each function too. Open the Context Help (CTRL+H) and hover over the function.

It's basically the same on both targets. I've worked with XNet on PXI, and embedded cDAQ running the Linux RT OS and both work pretty well, with a few database functions not being supported. The RT may have some more limited database functionality (like not allowing to import or export databases) but for the most part things just work the same. These will return an error stating they aren't supported if this is the case. One thing that might help make your development easier is to deploy the database to the RT target using the XNet Database Editor software. From there go to File >> Manage Aliases, and here you can connect to a remote target (given an IP address) and then deploy a database from your host to your target. I think you can also add a database if you have the XML file on the target and invoke the Add Alias function. After that just add your target in a LabVIEW project, connect to it, and you should be able to run the VIs you already have written.

Here is an example of an asynchronous VI running, and having user events send data back. https://forums.ni.com/t5/Example-Program-Drafts/Non-Blocking-Multibutton-Dialog-Box/ta-p/3509941 But I think a simpler design would be two while loops, that communicate to each other with a couple of queues. In 2016 there is channel wires that could be useful too. Then your one while loop can be dedicated to just doing PLC stuff, and the other is for UI updates, and interactions with the user.

Okay great, thanks for testing this out, I just assumed it would work since it was putting multiple images in the EXE so why shouldn't it be reference like the multiple images in LabVIEW's EXE.