JamesMc86

I've done something similar before but don't have all the answers. As you described I wrapped the LabVIEW code in a basic C function. The LabVIEW code was compiled to a DLL with the "Use embedded version of run-time engine" option selected. This removes the need for a UI. For shutdown I don't think I did anything special. I was perhaps less concerned as it was an embedded application - I do have a panel close? handler in the code but I can't remember if that fired when it was embedded. Error out is actually pretty simple. You can use the pipes API and write to id 1 for stdout or id 2 for stderr. Below is a screenshot from my error message handler.

Yeah I got a couple of things mixed up based on the whats new presentation now at https://www.youtube.com/watch?v=PcQd6YstpTo The decoupling is different from the gRPC of drivers (NI Remoteability as it was called in the presentation). The way I read the decoupling is that newer versions of LabVIEW will officially support older versions of drivers. i.e. 2023 DAQmx can be supported by LabVIEW 2024 as LabVIEW can generate the APIs it needs (and probably other use cases, but that seems like the significant one)

My understanding of the decoupling is that I think there is a gRPC server that runs in the background which the decoupled API talks to. So the decoupling is done through API versioning I guess. DAQmx 22 would be API v1 and as long as they don't have to increment the API number then the LabVIEW API will continue working. Unless there is also a discovery mechanism like the .rc files? At some level the API will need to understand newer functions but I guess they are betting they will be few and far between for something as mature as DAQmx. All a bit of a guess as I can't find any details from NI yet. Except this very familiar feeling article from last year! https://www.electronicspecifier.com/products/test-and-measurement/labview-2021-enhancements-unveiled-at-niconnect

I'm not sure if this helps but are you sure it takes timezone from the PI? On RT systems (but I've not worked with the Pi) front panel timestamps display as the timezone of the host system which can cause confusion in things like this. I don't think that explains everything your seeing but might help.

As yet it doesn't really support code add-ons is my understanding (at least not well). For example I think it still lacks any support for palette editing.

Yeah that would be cool but it is a front for different package technologies i.e. npm, nuget It would involve persuading GitHub to run a LabVIEW package server - maybe not impossible - but probably not high up there list. Many package managers can just read GitHub repos as a package though - so rather than just entering a name you enter a path to GitHub - that seems more achievable if GPM takes off

I have a few things that might fit a user story - but also some more freeform feedback too - I'm excited to see some effort and thought going into this area - although early discussions sounds like a lot of technology work where I think there is a solid base already. To backup Joergs point as well - I want to use github/gitlab etc. for my open source projects - leveraging what is already there makes it easier to find resources, help and allows me to translate my experience between languages. There should really only be LabVIEW specific elements where that is absolutely necessary IMHO. Discoverability is kind of interesting - but when all the other package managers already have sites for this, it doesn't feel like very low hanging fruit. Pushing collaboration feels like a great approach. Getting more people owning code and publishing it in a way that people can collaborate feels like something that is lacking. There are so many projects that appear as forum posts or packages on the tools network that lack a public issue tracker, code repo and other things that can impact collaboration. Better still this is mostly an education play requiring less investment and can leverage loads of great existing resources like opensource.guide. Having a non-gated repo would be of interest though - even if you can just link to a package to simplify the infrastructure that would be a great start.

Not through the FPGA interface I'm afraid. You can if your using scan engine/ethercat (though I would have to look up the calls again)

Could you use an adaptor around the DVM that inherits from the desired abstract classes? That has been my solution to this problem in the past.

I would definitely recommend a thin client. It should be easier to secure (you just don't build in the ability to do anything you don't want it to) and HTTP is going to be much more firewall friendly. It does require building that thin client though! If the load is low this could be LabVIEW web services though (but if you have experience with a more suitable technology I would consider that).

Hi James, I've seen you show off some cool demos with the JSON extensions. Is there any instruction on how to include that in this library? Cheers, James

ditto - in 2015 I have been able to modify this and save my changes.