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

SystemLink is an (expensive) solution to this as well. Though it doesn't give you project or shell access. Another, cheaper, alternative is to utilize a modem/router based VPN so that you can see the devices. Cradlepoint and Peplink are two that we have used.

Here's one for you. The AXS Port is a modbus device that monitors power inverters. It would be great to feed Nigel the attached document and have it generate drivers/API for communication with the device. https://www.outbackpower.com/products/system-management/axs-port Another one for you, in a similar vein, but a little less straightforward. This is a Banner IO-Link Master that can communicate via ethernet/IP or modbus. An ethernet/IP driver would be great that could configure the device as well as the IFM DTI434 IO-Link RFID read head also linked below with attached documents. https://www.bannerengineering.com/us/en/products/industrial-networking---smart-i-o/io-link-masters/dxmr90-ethernet-io-link-master.html?sort=4#all https://www.ifm.com/us/en/product/DTI434 ifm-DTI410-20190125-IODD11-en (2).pdf dxmr904k.pdf axs_app_note.pdf 229732.pdf

The demo made me wonder if it could theoretically create drivers from spec sheets automatically. It seems like it would be a well bounded problem, create labview wrappers for the commands listed in the manual.

Is anyone headed to Austin for NI Connect in a couple weeks? Since I haven't seen any LAVA BBQ news I assume that's not happening, but perhaps we have some fellow LAVA-ers(?) interested in gathering somewhere?

What sample rates and what frequencies are you using?

This may be of help:

I couldn't find the code repository entry for this library, but I am getting an error: PQ Connection.lvclass:Connect.vitsdb CONNECTION_BAD: authentication method 10 not supported with postgres versions 14.7 on linux, and 15.2 on pc, running the toolkit in LV2021 on windows. Is there an issue with the authentication and SHA-256 on the newer versions of postgres?

*ahem* Not that I'm suggesting that you do bother haha.

I have had a passing interest. I think you were extoling its virtues some time ago. But when I saw I'd be needing to build the LV implementation of the protocol from scratch I lost interest. I also didn't see a lot of wide adoption at the time in areas where I was working, but that is probably worth a fresh look.

I am intrigued by a separate "NI Create" event for developers.