Mads Toppe

Just thought I should share this little trick I have successfully used for a number of multi-target projects now. LabVIEW does not allow you to copy build specs to another target, or change the target hardware for an existing one, and our build specs are often quite elaborate with a lot of different destination folders/llbs. Having to recreate them manually is a lot of tedious and error prone work. 🤢 So, until NI decides to support an automatic conversion (which based on the method below should be easy even if they need to take some extra considerations across the spectrum of targets...), I have found another way: Open the lvproj file in a text editor, preferably one that has some XLM-support (I use NotePad+). 1. Copy the/one of the existing target item sections to a temporary file. 2. edit/replace the target header to define the right target type and hardware, an example is highlighted in the image below: (If you do not know the correct DeviceCode (7740 in the case of 9063) and CCSymbol-values for the new target you can always figure it out by adding an empty target of that type to the project first...the device codes are also listed in your firmware folder and on the web.) 3. Then replace all instances of the reference to that target name with the new one in the rest of the spec, here the cRIO-9063 part would be replaced with cRIO-9030 if that is the name of the new target we need: 4. Now add the new item to the original project file and save. A possible next step would be to write a little VI that does this automatically for you, you could make it recreate the build spec of a given target for a whole bunch of targets automatically....I have not done that yet. So far I am happy saving lots of time this way already 😀 I have not discovered any pitfalls yet, but perhaps there are(?) The applications build and run fine on each target... In my case all the target build specs are/can be identical (in some cases I might need to change a conditional disable symbol here and there though), but if yours are not then you can still use this shortcut to do parts of the job.

Right now you just see the name and icon of the package, and a short description of what it does. I would like to see some small icons or text at the top next to the icon of each package for example. That list of compact of information should tell me things like the price / type of license, minimum required LabVIEW version, whether the package is part of a larger set (OpenG-tools for example are easier to download by grabbing the all-in-one package), when it was introduced and last updated, project link, category....(and let us filter the list based on these parameters as well). Much of this additional information is currently available if you click in the tool, but that is a huge waste of time when you are browsing hundreds of items. Pack the main screen tighter. The current design is far far away from information overload.

Never used it until now, and do not think I will use it again. With the VI Package Manager installed it feels more natural to use that. If the web interface offered more information about each package in a compact form it might have been useful though (until the same was available in VIPM...). To have packages visible and linkable on the web is good when you do not already have the more able alternative installed on your computer I guess. Now that VIPM even comes bundled with LabVIEW most people needing packages can fire up that to do the full job of finding and installing packages there anyway though.

Boring yes, but the best option when designing user interfaces is to make it work the way other sites already work. Then it meets the users' expectations, and will come off as intuitive to use. You can sprinkle it with smartness on top, but just have a look at the various app stores e.g. and copy that. For LabVIEW users VIPM and NIPM are established interfaces though - so making something similar to that is good, and then you can get an advantage over it by immediately incorporating the most requested, but not yet implemented GUI-features from their idea exchange...Showing and allowing people to filter based on the type of license is one of those for example. Personally I either know what I am looking for and search for the name or relevant terms so having a smart search function that will find stuff even though I am not using the correct or full name, or have written something that matches completely with a tag is a necessity. I also want to be able to see what the pricing model is and/or filter based on that. If I am just looking for anything useful, having easy access to lists of the most popular and/or highest rates ones is good. I will then typically want to see the price of the package in that list as well, not have to drill down several layers only to figure out that it costs more than I would be willing to pay.