hooovahh

Anyone else getting their popcorn? I cannot predict the future. And worrying about things I can't control gives me anxiety. So I'm just going to chug along as best as I can. My boss likes the work I do, and I like my job. I'll be mindful of industry changes. But at the moment I am not pivoting away from LabVIEW or NI if I can't help it.

I only worked with an FPGA CAN device once, and it was a long time ago. For me there was an example that showed how to create a DMA on the FPGA to send raw data back on. Then on the host you could read or write the raw CAN frames. From there you could use my frame signal conversion library. But I've never used them on the sbRIO so I'm unsure how that process is different. I'd be surprised if there wasn't some kind of CAN example installed with the software. From LabVIEW go to Help >> Find Examples and then search. I suspect the CAN port won't show up in MAX. To use it you need to write code, or open an example.

This looks interesting. What are the licensing used? What are the restrictions? Is there a manual that is in English? Is the source code available?

So I use Inno Setup for making most of my LabVIEW installers. It is pretty easy to setup file association with the registry like the LabVIEW Wiki mentioned. Here is a post explaining some of the settings. Once I'm on the LabVIEW side I've always used the property node Application >> Command Line Arguments. Maybe I've just used that because the event didn't always exist? I'd like to think the property node gives you more control since I can send other command line arguments not just a file. But the majority of the time I do just want the file path.

Yeah I get this. We also have Intrepid, and ETAS in the mix along with other random serial to CAN converters. It can be a bit of a hardware mess. I have written class wrappers around different CAN hardware, and then made a single API for doing things that use most of these hardware types. But I haven't got permission to share it, and specifically the XCP and A2L side of things, leverages NI's toolkits in ways that I can't share it openly in the state it currently is. Sorry. If I had more time, resources, and didn't develop it on company time things would be different. The large majority of the stuff on my blog was developed over a week at home during a staycation.

I would not count on purchasing a license, causing the passwords to be removed. Sorry. Additionally the NI toolkits are often just wrappers around a DLL or some binary. This means for it to work it must hook into NI specific function calls to NI specific hardware. The ADCS toolkit works this way and that's why I had to rewrite it to allow using different hardware. The ISO 15765, XCP, CCP, KWP2000, UDS, J1939, and other CAN protocols are really just software layers on top of some frame level API. They can all be written in a way that is hardware agnostic. But NI's toolkits are not written this way. NI wrote their ECU toolkit to work with NI hardware, and they want to keep it that way. The hardware helps sell software, and the software helps sell hardware. They don't have an incentive to have it work with other hardware. But honestly their hardware is quite good. I really like the NI USB 8502.

Yeah multiple targets is the main issue I've had over the years. I have a great reuse library that is written well to work on RT or Windows. But making a single PPL for both targets is impossible. And having the palettes, and builds, and projects pull from the right PPL, and pull the other dependent PPLs, is such a major pain that I abandoned it.

Several things can be done to optimize TDMS writing. TDMS has to occasionally write header data to the file to keep track of the data being written. Because of this you can add one TDMS file to the end of another and it will make a valid file. You can't for instance append an Excel file (XLSX) to the end of another and get a valid file. So you want to minimize the amount of times the header data needs to be written to disk. The easiest way to do this is to write multiple samples at once, or writing multiple channels at once. You want to avoid writing single samples. So build up N samples for your N channels and write them once the buffer is full. The buffer doesn't need to be your whole 12-18 hours. You can start small with say 10 samples and see how it performs.

Use the File Dialog express VI on the File IO >> Advanced palette. You can configure this to prompt the user for a file path then wire that into the open.

I went to dig up my fast ping utility for Windows, but I see you were already in that thread. As for this thread. I rarely use the parallel for loop but when I do it is a more simple set of code. It has those caveats Shaun mentioned and I typically use it is very small cases, and where the number of iterations typically are small. In the past I did use it for accessing N serial ports in parallel to talk to N different devices sending the same series of commands and waiting for all of them to give the responses. And I have used it for cases when I want to spin up N of the same actor. Here there is other communications protocols to handle talking between processes. And again these are usually limited to some hardware resource like two DMMs that are independent. If it needs to be very scalable, and have large numbers of instances a parallel for loop probably isn't what you want.

This is very true. But LabVIEW does a decent job with resizing panes with splitters. It isn't always an ideal solution but if you can known the supported UI layouts you can have subpanels, in subpanels to support what you want. Here is a demo I made. Just run the VI and resize the window. The youtube video isn't nearly as smooth. But this design only supports 20 images high, and 20 images wide. I should have probably implemented some kind of minimum size, and then have a scrollbar appear.

I emailed the site admin to see if there is something broken. Welcome back.

I use User Events as the transport mechanism between asynchronous processes. As a result I wish there were a feature where there was an event generated when a reference goes invalid. I made an Idea on the Idea Exchange here. Similarly the work around is to have a timeout where the reference is checked to be invalid. A better solution is to send a stop command as some kind of global user event, or in your case enqueue. But as you've seen there can be edge cases where things stop unexpectedly and I just want all the running children to go through their cleanup process. Stopping on the error, or invalid user event reference, is a fairly simple way to do that.

Is there a reason you are doing this, instead of having a type def'd cluster? Then you can use the Bundle/Unbundle by name to get and set values within a single wire? Then probing is easier, and adding or updating data types can be done by updating that one cluster. Typically Variant Attributes are used in places where an architecture wants to abstract away some transport layer that can't be known at runtime. In your case we know the data type of all the individual elements. If you were doing some kind of flatten to a Variant, then sending over TCP, you'd want some standard way to unwrap everything once it got back. I've also seen it used where a single User Event handles many different events, by using the Variant as the data type. Then each specific User Event will have a Variant to Data to convert back to whatever that specific event wants. There isn't anything wrong with what you are doing, I'm just unsure if it is necessary.

Have you tried uninstalling, then reinstalling the toolkit? Are the VIs in the vi.lib and just not on the palette?