JamesMc86

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.