hooovahh

This is pretty accurate. I know one ex-coworker in particular had an RSS feed push to his Outlook every post on LAVA. When LAVA had a major crash his Outlook was used to restore as much content as was possible. As for the content moderation, we try to self police our selves, enough to not get on NI's bad side. I have very rarely ever needed to intervein. One time I had to ask one user, to tread carefully on the topic they were sharing, but I did not delete any content or post. Thanks for the additional history. Jim has mentioned this story to me in the past but I didn't remember the details. I believe there was a meeting with NI where they were insisting that the scripting code wouldn't be made public, and someone called their bluff basically stating the tools for scripting are already being made by the community, and that if these were good enough for NI to use, we should also have access to them.

You shouldn't need to delete and reinsert for the icon to be updated. Just close and reopen the builder if it is open to have it refresh.

That's because you didn't add it. The Palette does not show all VIs. It is a place where you can add your VIs, or directories that you want it to show. If you added a VI, and the package builder already has it open, then click File >> Close, then pick your project in the new window. Then go to Palette, then Right Click >> Insert >> Control or VI and pick your new VI. This video shows some of the process even if it is older.

Why would you repeat steps 1 and 2 every time? Just open the the VIPB you made from the last build you made, then click Build Package. The Palette you made previously will only have items removed if the file it references no longer exists. You may also want to update the Release Notes or Change Log with every release but realistically that's all you should have to do. Is your Source Directory and palette getting wiped away after each build?

VIPM has an package builder that is free, and has some really nice features. One of them is the ability to make a palette laying out items how you want. Then installing this package will give the user the API you want them to see. You don't need to create the MNU files your self manually, but if you do use the Palette API built into LabVIEW which lets you read and write MNU files.

Probably. Again NI-CAN drivers, which you need to use your 8473, only work on LabVIEW 32 bit. Do you have LabVIEW 32 bit installed? Do you have the NI-CAN drivers installed? Do you see the "CAN" palette under Measurement IO? If not then you need to resolve this. Sorry.

No you can't. This lets you use XNet hardware (which I don't think you have) but use the older NI-CAN drivers. This was intended to help developers transition to the newer XNet hardware but use their old software. You cannot use any XNet sessions on the 8473 hardware.

I can't open it at the moment it is new too of a version. But based on the name it looks like it is again using the XNet drivers not the NI-CAN. You need these drivers for the USB-8473.

I'd need to see some code. For NI-CAN I usually start with the example provided by NI. Get that working first.

Oh I'm sorry I did a quick google search and of course the first search result shows a picture of an XNet device but when you click on it it shows the correct one. Well in that case you need to use the NI-CAN drivers which also appear on the Measurement IO palette. Note that you can't do the Signal API in NI-CAN with that hardware and can only use Frame API. But that's okay my conversion library returns frames. Part 3 of the CAN blog also goes over NI-CAN hardware. And again there are examples in the Help >> Find Examples. NI-CAN hardware is old and not getting updates. It also is only 32 bit binaries so it only works in LabVIEW 32 bit, but can run on 64 bit OSs.

With the XNet drivers installed there will be a new palette under the Measurement I/O for XNet functions. Also in the Help >> Find Examples there are several thing showing how to read and write frames on the hardware. Additionally I have two CAN blogs that might help out with Part 3 talking about XNet code for doing basic frame functions, and Part 6 which talks about the different XNet session types. But also if you are just dealing with CAN signals, and not frames you don't need my conversion library to work with XNet hardware. You can create the signal sessions and do the writing as single point session types which the hardware will then retransmit at the rate defined in the database. My conversion library is primarily used for situations when you don't have a Signal API and just have the raw frames.

Glad you got it working. In the future you can get the packages from a computer that is online and copy them to the other. These are usually found in the folder here: C:\ProgramData\JKI\VIPM\cache Finding all dependencies from that can be a pain. Oh and VIPM has a Package Configuration feature that lets you pick a set of packages, then save it as a configuration, and even store the package files in a single file. This VIPC file can be copied over to the offline PC and installed through VIPM without the internet. This used to be a premium feature but I think it is include with the community edition now.

Yes this is the purpose of the Frame Signal conversion library. Development and discussion has primarily been taking place over on the dark side here. A more polished (but older) version can be found on my CAN blog here.

I wasn't suggesting you were whiners. If I ask for support from NI I don't think that makes me a whiner. I was suggesting the changes you are proposing are useful for everyone, and that if you have useful changes, all VIPM users can benefit from them by having JKI use what you've developed. Because you are a developer. I also asked that question because I wanted to know incite into why VIPM does what it does so I can be a better developer.

Has anyone talked to JKI about this? I'm sure they make VIPM do this during the build for a reason and they would probably be interested in the changes you are doing. Like what? Are you referring to the earlier discussion, where you may have "32" in the DLL name when it is a 64-bit binary? I handle that by only performing the rename if there exists the correctly named DLL for the other bitness, on disk. Otherwise it leaves it. User32.dll wouldn't be renamed for multiple reasons. But even if we installed "MyAgeIs32.DLL" it wouldn't rename it unless there exists a "MyAgeIs64.DLL" and we are in 64 bit LabVIEW. Not perfect but I'd prefer that over editing the VIPM build environment.