hooovahh

View File LabVIEW Tray Launcher This application is designed to help manage a system, that has multiple versions of LabVIEW installed. It does this by adding an icon in the system tray for launching any version of LabVIEW installed. This may work with 64-bit versions of LabVIEW but it has never been fully tested. It has several other features which are useful when having multiple versions of LabVIEW installed. Launch any version of LabVIEW installed from the system tray icon. Kill or restart any version of LabVIEW running from the system tray icon. Abort all VIs running in all versions of LabVIEW from the system tray icon. (not asynchronous clones at the moment) Abort all private context VIs from the settings dialog found by double clicking the system tray icon. (not asynchronous clones at the moment) Control what version of LabVIEW is used on opening a VI or LabVIEW file. (File Extension support in the configuration dialog) Configuration can chance the behavior of this but by default it will ask what version of LabVIEW to open a VI in if more than one version can open it. By default a VI set to Run On Open will always ask what version, and if you would like to run it on open or just open it. Shift can be held when opening a VI to always be asked what version to use. CTRL can be used to select the default option which is generally the last version used. By default if only one version of LabVIEW is running, and it can open the VI, then it will be opened in that version. Other file extensions can be selected after the install. Read the Readme Usage for more information on how this works. For this software to function properly, at least one LabVIEW Run-time, or development needs to be installed which is version 2011 or newer. The source includes all versions from 2011 to 2017. The installer includes the builds from all versions 2011 through 2017. An AutoIt script and source are included which selects the right EXE based on what version of the run-time engine are installed. This is why multiple versions are included in the installer. Also for VI Server functions to work properly each version of LabVIEW needs to be configured to have TCP/IP configured and a unique port. This is all done automatically through VIPM so my suggestion is to configure all versions of LabVIEW through VIPM, at which point this tool should work. Some features of this will work without this enabled but not all of them. This is the LabVIEW Tray Launcher, originally discussed and developed in 2009 here. A fully built installer for version 1.5.0 can be found here. Just download the installer and run it. It should add all the needed files to the Program Files directory, and edit the registry if you allow it during the install. Submitter hooovahh Submitted 02/06/2018 Category *Uncertified* LabVIEW Version

I have some nice configuration managing code. Where I define the VI names which are like sections in an INI file, and then the control values themselves are what is read and written to the INI file where each control is a key. There are also methods to tell the VI values have been changed, because maybe other things like tables or trees need to be updated based on the change. This works real well for basic things and adding a checkbox or a debug setting that is then a value that can be read globally in the application is a snap. But as you noticed complicated structured, or large structures cause issues. I use the OpenG Variant INI functions which flattens larger structures into somewhat readable sections in the INI but adds many lines to the file and slows down reading and writing a lot. I added an ability to read or write a key as a binary blob so it will look like Debug=89FJD82JKSKFK2I. Which isn't as useful and thought about re-writing using the MGI INI functions. I've been meaning to transition to SQLite, or possibly TDMS since our test data is in TDMS, and being able to embed the tester configuration, along with the test sequence, and test data into a single file is an attractive idea but just haven't had the time at the moment.

I posted this behavior on the dark side.

Uh...so has anyone noticed VIPM getting uninstalled after upgrading LabVIEW to SP1? Program Files (x86)\JKI\VI Package Manager folder only contained the INI file with an entry for a recent file. The last mod time on the file was right around the time I upgraded to SP1. Seems odd and all I did was reinstall VIPM and I seem good.

Thanks, just downloaded and installed. I installed SP1 then found the F1 patch using the NI Update Service but couldn't find it with a google search. Sure looks like lots of attention on VIMs in that f1 patch. Couldn't find the SP1 release notes yet but the one cool new feature that I need to figure out how to abuse use is the VIM overriding in classes. There are two pretty good examples that explain how this new feature works. <labview>\examples\Malleable VIs\Class Adaptation\Malleable VIs - Class Adaptation.lvproj <labview>\examples\Channels\Replacing The Function At The Heart Of An Algorithm At Run Time\Replacing The Function At The Heart Of An Algorithm At Run Time.lvproj I guess I'm going to struggle a bit with how I should use this feature. I get that this is like dynamic dispatch, except that the inputs/outputs don't have to match in their data types with other classes, and maybe that alone should be a good reason to use it...what I really wouldn't mind seeing is someone doing a plugin architecture, using these VIMs. Maybe combine this with PPLs? Then build classes, that are unrelated, but can be called...or maybe these classes are related so normal dynamic dispatch works for when data types do match (and allow for a UI in the class to be shown or inserted) then VIMs for when they don't? I need to experiment a little more like if classes can be loaded from a file, and then called into a VIM...I think that would work just fine now that I think about it... Edit: Okay plugin architecture could work, but you still need a parent class which has all the closures (wrong term?) defined. Then on loading of the class it needs to be to the parent, and have dynamic dispatch turned on so the child function is loaded. Might seem like a lot of extra work, and empty classes whos purpose is to define things that honestly could be better defined if classes were related. Useful but maybe not where I thought.

If AQ were here he might say something like "This is why these features aren't officially in LabVIEW yet" I too have noticed that the brokenness when sometimes wiring the Must Match one way versus the other. I am in the beta but honestly don't remember seeing if this worked better, and couldn't say if I did know. Just wait a couple months hopefully 2018 will be released at NI week. As for the type def I think it is functioning the way it should. One common use I've heard mentioned is you may want a function to work if the input is a 2D picture control but behave differently if the input is a string. Well those both coerce to the same data type, but the Must Match will reject one or the other based on the input.

Seems like this could be discovered with a google search.

I promise I haven't been working on this for 5 years. But I thought I'd come back with something new that I think is a bit better in some ways and a bit worst in others. This method works a bit better when it comes to encapsulation. I wrote a single Image Grid class that can be created, updated, and destroyed. When creating it you specify the Subpanel that it should be inserted into. This means that we can likely turn this into an XControl one day. The previous method of having parent/child windows floating around that needed to be resized and moved, complicated that encapsulation and likely never could have been in an XControl. Resizing in my opinion is done better here too. Instead of generating a resize event, and then having to resize each window, we just let LabVIEW take care of it. LabVIEW is pretty good at resizing when using panes and having a single object fit to that pane. So when a resize occurs the only thing that is done is the optimal number of rows and columns are calculated and if there is no change then nothing else needs to happen in the G code. Minimum pane sizes are used so that hopefully things don't get too small if the subpanel is set to fit to the pane. Now the new limitations...this is limited to the number of subpanels I made and at the moment this is 20 rows, and 20 columns. It is possible I could have gotten creative and generated all the prime number of subpanels, and then used dynamic subpanel subpanel insertion to get an unlimited number but wow that sounded difficult. I figured how often will I need more than 20 rows or columns? Another limitation is at the moment you cannot add or remove images without closing the session and opening a new one. The properties of each image can be manipulated quickly by providing the index, and the new Caption, Disabled Status, Image Path, or Background color (alpha layers supported BTW). Also no way to modify the caption other than the text. I'd like to add a hide/show ability and a way to change font size. Anyway source is 2015, uses OpenG and here is a video. It is slightly smoother to resize than it looks in the video. https://www.screencast.com/t/qdZMxBuzprH Image Grid Subpanels Of Subpanels.zip

Are you asking about how to use UART on a myRIO? Someone already mentioned using the express VI, but here is a video demonstrating it. You may also be interested in the myRIO Essentials Guide, which has videos and instructions on how to connect to various sensors.

This advice is based on the fact that other Linux RT devices enumerate USB to Serial converters without any additional work. https://forums.ni.com/t5/NI-Linux-Real-Time-Documents/USB-Devices-tested-on-NI-Linux-RT-myRIO-cRIO-9068/ta-p/3522002 Every USB to serial converter I've tried has worked in my 9134 (mix of Prolific and FTDI). I've also seen posts where people talk about plugging in Arduinos to a MyRIO which enumerated as a VISA device, but again I have no experience with this.

Oh there are plenty of USB to Serial converters that will show up and work and you can use them using the standard VISA calls. There are also UART TX and RX converters to RS-232 like the MAX232 or the one you linked to. But is your device actually RS-232 serial? I'm not so certain but again I've never used that hardware. Read up on the documentation. Either way you can come up with something that works.

Crosspost I've never used this product, or MyRIO at all, sorry.

Have you thought about the fact that this might not be related to LabVIEW at all? Look at the Windows system event logs and see if there is something happening around the time of the crash. Is there any unknown devices in device manager? Is there any devices that might have the wrong driver loaded? Not a lot to go on here but I'm pretty certain I've ran LabVIEW programs in 7 Ultimate but don't have one on hand to test with at the moment. Oh and how about disabling a bunch of NI startup services and programs and seeing if it is more stable?

Not that there isn't valuable information to be pulled from this code, but in the last 8 years many things have changed in LabVIEW to make this process easier. First there is native recursion, as well as indexing and conditional tunnels instead of nested loops. But there is also the Traverse for GObjects on the palette under Application Control >> VI Scripting. Getting references to controls based on the given label is done with a vi in the vi.lib TRef Find Objects By Label.vi in \vi.lib\Utility\traverseref.llb\TRef Find Object By Label.vi and is added to the palette with the Hidden Gems package. Then there is my attempt at doing this with an XNode posted here. You may want to look into using one of these functions from NI, or one written with modern techniques. They have better performance, and probably more features.

If you are looking to protect your IP you can apply a block diagram password. Hackers have ways of defeating them but it will keep out the majority of developers from copying your code.

I was suggesting just use the TortoiseSVN client, and not bother with any other toolkits. JKI and ViewPoint make a couple and while they work fine, I generally just am more comfortable using Windows Explorer. That is again for all things other than a rename, which I have used ViewPoint for, but I try to just avoid renaming unless necessary. As for the lock commit of controls. One thing that helps with this (but I'm not sure eliminates it) is making sure all VIs are set to "Separate compiled code from source file". There is some code that will perform this on a project or folder of VIs, here is a start. This should be on for all SCC options for a couple reasons. I still think that if Dev A edits a type def control, then all the other VIs that use it will have unsaved changes for Dev A. But if Dev B is working on a VI that uses that control, then Dev A has no obligation to update that VI, save, and commit it. They just have to edit the control and commit. Once Dev B does an update and gets the new control, the VI they can edit will have unsaved changes at which point they should save it and commit. In practice this ends up with alot of "Continue Saving Without Prompts" for Dev A (since they can't get locks on those VIs which are effected by the control edit

No advice in the merge topic other than don't do it. LabVIEW files are obviously binary in nature, and merge doesn't work well. That being said some developers do implement a merge paradigm in LabVIEW and SVN. LabVIEW has some file compare tools to see what changes have changed from one revision to another but I have no idea how well they work in a SCC. SVN also can work in the Lock/Commit paradigm where VI files will be read-only until you have requested a lock from the server (look into needs-lock). At which point you can edit the file and commit changes but no one else can. If they attempt to get a lock SVN will say what user has the lock at which point you can ask them if they are still working on it. Dividing up the application into code modules and assigning a developer their set of code usually minimizes the number of times you need to ask a developer about their part of the code, but it happens. BTW I just suggest Tortoise SVN, which is the Windows Explorer extension. If the file is read-only, LabVIEW will complain when you go to save, at which point a save dialog will come up. From here you can right click the file and choose to get the lock, cancel the save dialog, and resave the VI (which shouldn't be read-only any more). Some other toolkits help in things like a rename. If you need to rename or move a file, then LabVIEW needs to be aware of the change (the project and files that link to it) and SVN needs to know it was renamed. Some of these 3rd party tools like ViewPoint can do this but it is generally a pain. As for file structure. Code that is reuse, and not part of the project needs to be found by a single common location. My advice is either the vi.lib or user.lib. You take your common code, package it up with VIPM, and then have all your project code link to that common stuff there. The source to the VIPM packages can be in a separate reuse SVN repository, but your code only ever links to the code from the installed location of user.lib. It can be more steps to make changes, since instead of changing the code in user.lib you should change the package source, build a new package, release it, then install it. Where previously you would be just used to editing the VIs as they are. Another alternative I've heard of but am less of a fan of, is to checkout the reuse repository to your user.lib. Then you can edit the reuse source and commit it back to SCC. This has advantages and disadvantages of course

Attached is 2013. I think I understand what you want but I'm just thinking. In some cases the number of rows might exceed the resolution on the monitor. One way to always keep the number of rows accessible is with a vertical scrollbar. Besides users understand how to resize a window, and if they only see 3 rows of 100, they know to resize the window to add more rows. Or if a column can't be fully viewed they may make the window wider. It is a design choice and will effect the user experience. You might also notice I set a minimum window size so you could just make that larger. It really depends on how much data you typically display. My solution is just one and you may know more about the users of your software and understand their needs better than I do. Still I think you could use my demo and programatically resize the window to show the set number of rows you want too. Hooovahh MCLB Test 2013.zip

Okay thanks for more details on what you are doing and trying to do. Attached is a demo of code that shows what I typically do in these situations. The UI has a splitter setting the upper half to a single pane that the Multicolumn Listbox (MCLB) is fit to. The pane also is set to scale objects while resizing. I then have an event triggered when the pane is resized which resizes the columns. At the moment it has 100 pixels for the 1st column, 90 for the 3rd, 60 for the 4th, and what ever is left is the second. I also setup panes for the buttons below so the right button sticks right, and the left sticks left. I also added a New Data button for generating new random data which stays in the center due to more panes. The thing to notice about this type of solution is that there is zero code handling resizing or moving of controls. This is all done by LabVIEW and even happens when the VI isn't running. This means there is not math or code figuring out how big or where a control should be making some parts of the development process easier. Working with panes can be a pain and some shy away from this solution but the improvements on performance and ease of use once you master working with panes is why I typically use this method. Hooovahh MCLB Test.zip

VIPM keeps a cache of all versions, of all packages installed, locally. So if you've ever installed the package, and then installed a new one, then from VIPM you should be able to right click the package and choose to install a different one. In 2017 both will show up as able to be installed, and in 2013 only the one compatible one will show up.

It isn't quote clear what you are asking for. Do you simply want a list box that fits to a pane? If so use splitters to split up the UI into sections which can be resized independently.

Years ago I showed how you could call the 7-zip command line EXE to have it perform functions that are hard of impossible with the native LabVIEW zip, or OpenG. I suspect that the 64 bit built EXE could perform the compression without any issue and can be called using the System Exec. Beyond that I'm guessing you already know about TDMS defragging, and how it can save on TDMS file sizes. After a defrag most of the data will be binary, and won't compress much anyway. I'd suggest defragging first, and then zipping. If your size doesn't go down in the zip it might not be worth the extra effort.

So I have the need for a stack light, Red, Green, Yellow and I'd prefer something that can be controlled over a wired network via TCP. I swear I remember seeing something but now that I'm looking for it I can't find much. I found this place which is fine but I'm curious if others have had success in using stack lights like these and have any that are recommended. Thanks.

It isn't just that these special controls need to be there, but they also need to be connected to the connector pane the right way. Making a new VI does this automatically. It is somewhat like a DLL call. To call functions dynamically, the interface needs to be known, like what kind of controls are found at what location. Removing these removes the ability to call the functions from the NI API. This is similar to calling any subVI where if the interface changes you need to relink the VI to call it properly and some times rewire the VI. If you are new to LabVIEW you might want to check out some of the free training links at the bottom of this page. There's lots to learn for sure.