hooovahh

I am unaware of a time limit on editing your own posts. You are welcome to use the report to moderator to make fixes. I realize small things are just easier to ignore than making a report.

The newest version of LabVIEW I have installed is 2022 Q3. I had 2024, but my main project was a huge slow down in development so I rolled back. I think I have some circular library dependencies, that need to get resolved. But still same code, way slower. In 2022 Q3 I opened the example here and it locked up LabVIEW for about 60 seconds. But once opened creating a constant was also on the order of 1 or 2 seconds. QuickDrop on create controls on a node (CTRL+D) takes about 8 seconds, undo from this operation takes about 6. Basically any drop, wire, or delete operation is 1 to 2 seconds. Very painful. If you gave this to NI they'd likely say you should refactor the VI so it has smaller chunks instead of one big VI. But the point is I've seen this type of behavior to a lesser extent on lots of code.

It has gotten worst in later versions of LabVIEW. I certainly think the code influences this laggy, unresponsiveness, but the same code seems to be worst the later I go.

In the past I have used the IMAQ drivers for getting the image, which on its own does not require any additional runtime license. It is one of those lesser known secrets that acquiring and saving the image is free, but any of the useful tools have a development, and deployment license associated with it. I've also had mild success with leveraging VLC. Here is the library I used in the past, and here is another one I haven't used but looks promising. With these you can have a live stream of a camera as long as VLC can talk to it, and then pretty easily save snapshots. EDIT: The NI software for getting images through IMAQ for free is called "NI Vision Common Resources". This LAVA thread is where I first learned about it.

If you are in a Windows environment, and have many files to process, this is probably going to be faster. There probably are several factors in determining when doing this in .NET is the better solution.

That's how I'd do it. Then combine that with the Foreign Key Sort from my Array package, putting the Time Stamps into the Keys, then paths into the Arrays, and it will sort the paths from oldest to newest. Reverse the array and index at 0, or use Delete From Array to get the last element, which would be the newest file.

No but that is a great suggestion to think about for future improvements. At the moment I could do the reverse though. Given the Request/Reply type defs, generate the JSON strings describing the prototypes. Then replacing the Network Streams with HTTP, or TCP could mean other applications could more easily control these remote systems.

Yeah I tried making it as elegant as possible, but as you said there are limitations, especially with data type propagation. I was hoping to use XNodes, or VIMs to help with this, but in practice it just made things overly difficult. I do occasionally get variant to data conversion issues, if say the prototype of a request changes, but it didn't get updated on the remote system. But since I only work in LabVIEW, and since I control the release of all the builds, it is fairly manageable. Sometimes to avoid this I will make a new event entirely, to not break backwards compatibility with older systems, or I may write version mutation code, but this has performance hits that I'd rather not have. Like you said, not always elegant.

Yes. The transport mechanism could have been anything, and as I mentioned I probably should have gone with pure TCP but it was the quickest way to get it working.

Variants and type defs. There is a type def for the request, and a type def for the reply, along with the 3 VIs for performing the request, converting the request, and sending the response. All generated with scripting along with the case to handle it. Because all User Events are the same data type, they can be registered in an array at once, like a publisher/subscriber model. Very useful for debugging since a single location can register for all events and you can see what the traffic is. There is a state in a state machine for receiving each request for work to be done, and in there is the scripted VI for handling the conversion from variant back to the type def, and then type def back to variant for the reply. When you perform a remote request, instead of sending the user event to the Power Supply actor, it gets sent to the Network Streams actor. This will get the User Event, then send the data as a network stream, along with some other house keeping data to the remote system. The remote system has its Network Stream actor running and will get it, then it will pull out the data, and send the User Event, to its own Power Supply actor. That actor will do work, then send a user event back as the reply. The remote Network Stream actor gets this, then sends the data back to the host using a Network Stream. Now my local Network Stream actor gets it, and generates the user event as the reply. The reason for the complicated nature, is it makes using it very simple.

I have a network stream actor (not NI's actor but whatever) that sits and handles the back and forth. When you want work to happen like "Set PSU Output" you can state which instance you are asking it to (because the actor is reentrant), and which network location you want. The same VI is called, and can send the user event to the local instance, or will send a user event to the Network Stream loop, which will send the request for a user event to be ran on the remote system, and then reverse it to send the reply back if there is one. I like the flexibility of having the "Set PSU Output" being the same VI I call if I am running locally, or sending the request to be done remotely. So when I talked about running a sequence, it is the same VIs called, just having its destination settings set appropriately.

I work in a battery test lab and was the architect for the testing platform we use. Our main hardware is an embedded cDAQ, or cRIO running Linux RT. This is the hardware that runs the actual sequence, and talks to the various hardware. We use the RT platform more for reliability, and less for its determinism. Timing is of course important, but we don't have any timed loops. mS precision is really all we care about. The architecture is built around User Events with asynchronous loops dedicated to specific tasks. These events can be triggered from the RT application, or from a device on the network using Network Streams. A low level TCP would probably be better, but the main sequence itself isn't sent, step by step from Windows. Instead the sequence file is downloaded via WebDAV, then told to run it. The RT then reads the file and performs the step one at a time. Windows from this point is just for monitoring status, and processing logs. This is important to us since Windows PCs might restart, or update, or blue screen, or have any other number of weird situations, and we wanted our test to just keep going along. This design does mean that any external devices that use Windows DLLs for the communication can't be used. But network controlled power supplies, loads, cyclers, chambers, and chillers all are fine. Same with RS-232/485. Linux RT supports VISA, and we plugged in a single USB cable to a device that gives us 8 serial ports. If money were no object I suppose we would have gone with PXI but it is pretty over kill for us. On the Windows side we do also have a sequence editor. The main reason we didn't go with TestStand is because we want that sequence to run entirely on Linux RT. Because the software communicates over User Events, and Network Streams sending User Events, we can configure the software to run entirely on Windows if we want. This of course takes out many of the safety things I talked about, but to run a laptop to gather some data, control a chamber, battery, cycler, or chiller for a short test is very valuable for us. As for the design, we don't use classes everywhere. Mostly just for hardware abstraction. The main application is broken up into Libraries, but not Classes. If I were to start over maybe I would use classes just to have that private data for each parallel loop, but honestly is isn't important and a type def'd cluster works fine for the situation we use it in.

Thanks for still monitor these forums to help give answers. It sounds like the intent is to allow free use in any context, being the literal person I am, interprets accessing the block diagram as "discovering the source code" which would violate it. This is also a good exercise in reading the license agreements, for things you download.

I like this solution. It doesn't ban external links entirely, instead it asks a mod or admin to approve the post with external links. I got got an email to approve of a post, just like I would get an email for reported spam.

Your reporting of spam is helpful. And just like you are doing one report per user is enough since I ban the user and all their posts are deleted. If spam gets too frequent I notify Michael and he tweaks dials behind the scene to try to help. This might be by looking at and temporarily banning new accounts from IP blocks, countries, or banning key words in posts. He also will upgrade the forum's platform tools occasionally and it gets better at detecting and rejecting spam.