Jordan Kuehn

You can build an installer after you create your executable build spec. In that you can specify additional installers for drivers and such. I would recommend setting up a quick fresh VM in virtualbox or something to test with. Once you get all the drivers packaged up so that from a fresh VM your application runs via the installer then you can take it around your other computers and deal with IT just once. So often it's hard to catch every single driver or the machine you are checking it on already has some installed and you don't discover you missed one until you go to a brand new machine.

We've done a couple one-off IO-Link implementations, but it was by no means an all-encompassing tool that would work with the general standard. We would pay for a development license, but the deployment license costs from the one LV IOLink toolkit vendor were untenable as we have hundreds of systems. We'd be very interested in something like what you described. Please post updates! Is your intention to open source it or to commercialize it?

Thanks for the reminder! Since that comment I've had increased need to run this on Windows in a similar use case, but the linux command doesn't port over well. I'll give your tool another look!

Not to derail the above conversation, but can this ping function reliably time out in Windows sub 1s?

I've found the newest files edited in this directory provide some insight when you have crashes or issues with your app starting. It's not always intuitive as to what all is there, but I have been able to identify problem components from the legible portions. /var/local/natinst/log I don't share the same experience as Mads regarding reduced reliability or increased bugs, save for the compilation issue I commented on in another thread which was actually a software bug I introduced and discovered via that log directory. We utilize hundreds of cRIOs across the country running for weeks or months at a time in mission critical applications. In fact the reliability of Linux RT is a pretty big factor in keeping with the platform instead of utilizing expansion chassis and a central computer approach. Obviously built-in FPGA is another huge asset when needed.

I have many systems that utilize NSVs with programmatic access. They are reliable and work well in these applications. That said, we've transitioned away in newer applications and utilize MQTT for communication. There are several flavors of tcp communication wrappers/messaging libraries around as well.

Are you able to see the shared variables listed under the target using the Distributed System Manager? Depending on the type you may or may not be able to see the current value, but its presence alone will help tell you if it was properly deployed or not. Further, are you capturing errors when writing or reading from them? While the error codes aren't always super helpful they can lend some insight. Lastly, are you dropping the variables on the BD from the project to r/w or are you programmatically addressing them and utilizing the shared variable vis to communicate with them? The latter option, while not as convenient, seems to be more robust, scalable, and gives you the most insight into the activity or errors there.

Well this is timely. We upgraded to 2023 Q3 64-bit a couple months back. No major issues at the time, even transitioning to 64-bit and programming RT. However for the last several days I have RT builds that proceed successfully but simply will not execute on the target. These were already built and deployed after the transition just fine, but now after minor changes it refuses to build something that will run. It's certainly possible I have a problem in the code or whatnot, but your post popped up on day 3 of me fighting this so I figured I'd chime in.

Google can be easier at times. If you include site:lavag.org at the end it will filter it. That said, I could not find that thread with Google either. Even searching the title itself. So, my suggestion isn't super helpful in this case, but I use that google feature often with LAVA or NI.

Implementing the State Pattern in Actor Framework.pdf This PDF is in the project template. I'm literally in the middle of a new State Pattern implementation and am using this template for the first time myself. If anything it could use a refresh with the new launch nested actor vis, but aside from that the information is available in this example project.

Excellent points. All of them. I have echoed your frustrations with the ability to put Linux RT on arbitrary hardware, with lack of low/middle cost I/O boards, lack of low cost FPGA, etc.

Included in the project is documentation that directly addresses your question about overriding the Substitute Actor.vi including some caveats and considerations to make while doing it. The project itself is a simple functional example as well, as originally requested.

Stagg54's suggestion was a good one. Take a look at the State Pattern Actor example project that heavily utilizes this override. https://www.vipm.io/package/ni_lib_state_pattern_actor/

Thank you for sharing! I would have never seen it since I'm rarely on those forums. The link is broken, but here is the darkside link: https://forums.ni.com/t5/LabVIEW/Darren-s-Occasional-Nugget-08-07-2023/td-p/4321488

If you have a current service agreement I would suggest taking this to NI directly if you haven't yet. https://sine.ni.com/srm/app/myServiceRequests