hooovahh

How much time do you have? Packages are version specific at the moment (so a String package needs a new release for every version of LabVIEW supported, String 2017 1.0.0, String 2018 1.0.0, etc). There is no palette editing so you'll need to edit your own palette, make your own MNU files and include them. There are no Pre/Post Build actions, and in fact all Post/Pre actions are EXEs with no option for calling VIs. Only Post-Install and Pre-Uninstall actions are allowed. Package dependencies seem to only be checked between the current feed. So unless I'm mistaken all external dependencies need to be copied to the new feed with all the dependencies brought over. No dependency scanning. No package of packages. No offline single file with everything included (but an installer might make that possible in the future). Packages can't be loose VIs, they must be in something like an EXE, or source distribution first. Basically NI has been saying that NIPM at the moment should be thought of as an installer alternative, and using it for reuse distribution is going to be very difficult. That can change in the future but for now if you want to deploy an application to multiple machines, Skyline can do that because NI Packages are like little installers. Until NI makes NIPM act more like VIPM, reuse and toolkit distribution using NIPM will be much more difficult.

In addition to this being a useful tool for development, I also this this helps demonstrate how to do some commonly requested things in XNodes. This can be seen as a template on how to handle updating the icon based on other objects, filling in the help from other sources, handling single clicking, right clicking, and replacing with non-XNode code via a right click. If anyone is looking to make a well done XNode I'd suggest looking at how some of these things are done with this one.

I've seen in the past that when updates were made to OpenG (years and years ago), they weren't to the newest version of LabVIEW and would support a couple versions back. Since VIMs are officially only in 2017 and newer that would limit those wanting OpenG's new refresh to that version. BTW I think these are the links that were intended for the XNode and VIM versions of the OpenG array tools. Both aren't just direct replacements but have a few other new functions, or new features to existing ones. Other improvements like inlining removing debugging, and automatic error handleing can also improve performance over the ones from 2009 or so. And yes I forgot about the zip utilities which work so much better than the native NI ones.

Yes many OpenG functions have native equivalents, but usually lacking in some way or another when it comes to what it can do. I made several idea exchange requests for Array, File IO, and Clear Errors to act more like OpenG. I heard rumors about a few things that might make their way into new versions of LabVIEW since VIMs are not a thing. Having my customer be my boss means I can get away with using any 3rd party tools I feel comfortable with (license permitting) and OpenG is one of those things I've just always installed on all development machines. I have a single VIPC that has all the OpenG, MGI, internal packages, and various LAVA things. As for OpenG being dead, looking at the last date of package releases makes it pretty clear development has basically stopped.

Yeah there are several reasons why NI's mistake here isn't as bad as Microsoft's. LabVIEW 2018 SP1 wasn't automatically pushed. An uninstall and reinstall fixed the issue, doing something like that in Windows is a lot more difficult. And NI's issue isn't deleting data (that I know of). Still crappy and NI is clearly looking into it. That being said I have 2018 SP1 running on a couple machines already just fine. But yeah having the 2017 SP1 example doesn't instill much confidence. Fool me once kind of situation here. That being said I don't mind being a test subject when it comes to these things. I updated as soon as I could and took the risk on a machine I didn't care too much about.

We use a PreBuild action, which can set the build number of an EXE to the SVN commit version. This means that we'll have software 1.3.1.384 where commit 384 is the source that made that EXE. Having it in the EXE means Windows can tell me what version it is even if I can't run my application and get to an About Screen. It isn't seamless but it works well enough.

Can you describe the issue you had after your upgraded? Maybe we can help NI in finding the issue.

Thanks for reminding me. I just tested it and yes the TDM Importer Version 18.0.1.7167 (as reported in Excel) now imports my TDMS files without crashing. That was a major pain because I'd uninstall TDM 18.0.0, reinstall TDM 17.x, but in the uninstall some other dependencies were removed which then needed to be reinstalled...which by default installed 18.0.0 again. Oh and it looks like the download page to this add-on was updated yesterday to the new version too. Other fixes in SP1 I've heard are related to VIMs but am unaware of the details.

I still have some legacy stuff that uses INI keys. The users I trust, know how to edit them pretty easily. Not saying they can't do the same for JSON but it is a more familiar looking format. It's good and bad, but every operating system has a text editor.

Those are all great suggestions. The read/write panel could have other improvements too a list of controls to exclude, or an option to exclude indicators. Do we really need to read and write the Error In/Out? Most likely no. The core of the code is using NI's configuration functions, which are fine for small files but for arrays of clusters of arrays it struggles. OpenG Read/Write takes a long time for large data types that are heavily nested, or array based. The MGI Read/Write Anything work much better when it comes to this.

I had a hard time downloading this, but it could be an IT issue on my side. The download would stall, and I'd pause, then resume to get it going again. After installing with default settings, I launched it and got an error "error unable to open resource files". I'll be performing a full uninstall and reinstall. It could be an issue on my end or an issue with the release. I probably should have tested this in a VM first... EDIT: Uninstall and Reinstall fixed it, not sure if that means there is an issue with upgrade or just me.

Sorry if I wasn't clear. NI's ADCS has more or less been replaced by the ISO 15765 I posted online. It doesn't do hardware abstraction with classes (it should) but I was just in a hurry to post it online and thought most people would just be interested in the G state machine. Turns out most people are interested in a different things. The ECU toolkit is the one I've started to replace but may never be able to post online. This is the one that uses an A2L for XCP/CCP. If I had time to work on it I would probably update the ISO 15765 toolkit I posted online first to add hardware abstraction, and then make a post on how to flash an ECU using it. That is a lot less effort than re-writing the ECU toolkit. That documentation link isn't broken, it is just realllllly slow. I downloaded it and attached it here. XCP -Part 2- Protocol Layer Specification -1.0.pdf

Vector isn't the only one, Intrepid has hardware for doing it, and ETAS does too. But as far as software capabilities go none of these hardware options provide drivers which are capable of doing this in LabVIEW. They may have LabVIEW drivers for reading and writing raw frames but no software layer on top of that other than NI's, or writing your own. I've avoided the .NET capability due to the high price tag of having that software and hardware on the system. Vector hardware is licensed for software so installing CANoe, and then calling it via .NET only works if you buy Vector hardware, then pay for it to have CANoe enabled.

I've been in the process of re-writing the XCP/CCP drivers to work with other hardware. A while ago I re-wrote the ISO-15765 drivers (KWP2000, OBD, UDS) into pure G so that any CAN hardware can use it. This basically replaces the NI Automotive Diagnostic Toolkit from NI. The code was simple enough and all I needed to do was re-write the core state machine and the rest was more or less the same NI subVIs. XCP/CCP is more complicated as there isn't just a single core used by NI's toolkit to replace. I do have an internal toolkit for doing XCP, but parsing and processing the A2L file still leverages NI's DLLs and if I ever wanted to release it I would want to rewrite this file parsing stuff too. My toolkit does support a Raw mode which doesn't rely on an A2L (and doesn't need NI's parsing) but in this case doing things like reading a characteristic you'll need to provide the Address, Extension, Byte Order, Number of Elements to Read, and Number of Elements in an Item. Returned would be an array of bytes. Where when using the A2L you can call a function to list all the Characteristics by name, and then read the engineering unit based on the name, with all that other stuff pulled from the A2L. I was able to accomplish this just by sniffing the CAN bus while using NI's toolkit and seeing the commands performed to do things like Connect, Unlock, Get Processor Info, Get DAQ Resolution, get PGM Info, etc. NI's toolkit has an ECU simulator, and I have a couple actual ECUs to test with. Combined with sniffing I found some documentation here that helped understand the protocol more. At the moment I can't post what I have, way too coupled with NI, and not robust, and cleaned up. But I can point you in the direction of what I learned if you have any questions about the order of commands needed for an operation, or the type of things needed. If your scope is small enough I'd attempt to just use NI's toolkit on your ECU, sniff the bus, and figure out what the commands are to get what you need. But honestly for the money the NI toolkit is worth it. I'd argue the ADCS toolkit might not be worth it (since it is available on my website and open), but the ECU one is and if you can get away with using NI hardware I'd recommend using that toolkit.

Not that I can think of. I mean maybe the image only technique would work but I haven't tried it and wouldn't be surprised if it didn't. Beyond that maybe something frames would work, where a VI creates a webpage, that is then inserted into another webpage. No idea if this would actually work or the issues related. It would probably be a lot of work but if you get anything working be sure and post your results here.

The trial gets extended to 45 days if you login with your NI credentials which is free to sign up for. Also there are are VMs with snapshot features. Beyond that a home edition of LabVIEW is pretty cheap but I think that is still stuck on LabVIEW 2014. There were experiments in getting and viewing VIs as a series of PNGs, or flash which meant changing case structures to see other states. If the developer is aware of it, snippets are useful and can mean posting an image, with the VI embedded in it. You wouldn't want to do this on a whole project of course. But in general Shaun is right. Keep your code base in the oldest version of LabVIEW you want to support, and make decisions about upgrading as needed for newer hardware support, or feature sets.

None. There is no guarantee that the Add function doesn't start acting like the subtract if there is a full moon out. It is just in NI's best interest to keep users of their software and hardware happy and that generally means consistent behavior, but bugs happen. I missed you Michael.

No there is not. Only the Switch method is possible because of how VI Server works. Basically the latch only works if you can only change the button value from the UI. If you ever want to change the button value from anything else like loading the value from a file, or setting it programatically at runtime, then you need it to be switch. That being said the easy solution is to just create a local variable in the event case where the value change is being handled and write the boolean back to a False and you get basically the same functionality. The only way this technique doesn't work is if you are polling the control value, at which point you'd need to look for some boolean crossing and handle it differently.

You will not be able to create a VIM that operates the same way my XNode does. This is because the technique I used was to use the Array to Cluster function, and setting the number of elements using scripting. However using the OpenG method you can do this another way. It is likely less efficient and takes longer but if you want a VIM that does it this should do the trick. Array Of Variants to Cluster.vim

There is some kind of short timeout for posting. I can't remember the reasoning, and I don't have control over adjusting it but I too see it. Basically if you are on a LAVAG page for a couple minutes, and then try to post something it won't work and you'll have to do as you described, copying and refreshing. At least clicking submit doesn't clear out the text you wrote. That would really suck.

In the LabVIEW community a phrase that has been used to describe undocumented, or incomplete features of LabVIEW has at times been called Rusty Nails. In searching LAVA it appear this is never explained and so this post is intended to give a brief history with as many details as I know having not been active when this all took place. The earliest reference to "Rusty Nails" found online (thanks to AQ) is by Greg McKaskle of NI in 1999. Someone was asking about all the undocumented INI settings that could be found, and how some weren't exposed to the Tools >> Options dialog. Greg's reply was this: Back in the LabVIEW 5.x and 6.x era there was a new emerging technology that was LabVIEW Scripting. NI had created scripting for their own purposes but the community saw it and wanted to be able to automate editing, or creating LabVIEW code. With the help from Jim Kring and others, the basic tools for enabling scripting in LabVIEW were available. The story of how this came about is worth a post of its own, but the summary is that NI shipped a VI that didn't have a password on the block diagram, which allowed for the creation of any object, given an ID. Using a for loop, you could easily create every object in LabVIEW, including objects which facilitate in creating and manipulating code. Discussing scripting often leads into discussing other INI keys which enable private functions like the well known SuperSecretPrivateSpecialStuff. It is possible this is one of the keys Greg was referring to. Other INI keys from 5.x can be found here. After these discoveries the NI forums started getting users asking about scripting, and private functions. Users were looking for help, and documentation but NI wasn't ready for this knowledge to be public and so they started deleting all posts related to private, and scripting functionality. Some of the motivation for the creation of LAVAG came about by a desire to have an independent place to discuss the LabVIEW topics that NI didn't want to have on the public forums, potentially adding to the number of support calls, and confusing new users with advanced topics that were undocumented or incomplete. After LAVA's creation a subforum section was labeled Rusty Nails, and intended to be a place to discuss Scripting, ExternalNodes, XNodes, Private methods, and general LabVIEW hackery. Over the years several private functions have been made public, and scripting has become an official feature shipping with LabVIEW. Because of this the Rusty Nails and XNodes subforums were combined into what is now the VI Scripting section. Even over on the official NI forums, discussions about private functionality and XNodes has been relaxed since those early days. Asking for private methods and getting unofficial help is something users, and sometimes NI employees will participate in, without the heavy censorship seen earlier. And topics of scripting are encouraged now that the feature has been official since LabVIEW 8.6. If you have anything you'd like me to add regarding scripting's history feel free to reply and I can add it. And if I got any of the details wrong let me know. Again I wasn't around when this all took place and I've just tried putting down the details I've heard from other developers.

There are private events on the tree for Item Close? and Item Open? which is a filtering event and allows you to discard the open and close. You need the super special private special stuff INI to access these. Then I'd recommend turning that INI off after.

Oh I like this. Have a single place where all packages, and versions of packages get installed (extracted), and then switch in the package and version "Installed" by setting up the symlinks. I could see arguments that these links should link to under vi.lib, or user.lib or wherever, or I could see arguments for them being in folders relative to the project. I think having to uninstall and reinstall packages (delete and recreate links) between projects isn't too big of a deal and would reduce the likelihood of cross linking issues where one developer opens it and if finds the reuse library in a different place than expected from another developer.

You didn't specify the operating system on your PXI but I assume it is RT, it can be Windows as well at which point developing on the system should be pretty easy. If you're already familiar with RT on cRIO and cDAQ, then PXI should be no problem. You configure the devices in MAX just like any other remote device, and can setup virtual channels or other basic things there. Then in the project you add your target, write your VIs and run them there which get deployed. There really isn't any other considerations between a cRIO and PXI. If anything I'd say the cRIO can be more complicated due to the FPGA in the mix. Afterwards you create a build of your application and deploy it. EDIT: Oh and if you really want to test deploying to RT devices you can load up a virtual machine and deploy to it as if it were a PXI with no hardware.

I think it would be hard to install DAQmx without MAX. It is likely in your start menu as "NI MAX" if it isn't then that is probably needed to setup DAQ Assistant. If it is missing, install MAX and you may need to reinstall DAQmx. When DAQmx installs it looks at what things you have on your system and installs DAQmx support for those things. If a thing is missing when DAQmx gets installed, it won't install support for it and you'll need to reinstall. For instance if you have LabVIEW 2017 installed, and you then install DAQmx it only installs support for LabVIEW 2017. If later you then install LabVIEW 2016 you won't have DAQmx support, until you run the installer again and it adds support for 2016. During the second install it should see that 2017 support is already there and do nothing.