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.

What you are witnessing is a race condition specific to the way the implicit write text file works.

I thought it was odd you get an empty string when it fails - the file should never be empty as you would expect to be overwriting the existing data. This VI works though.

My guess is internally the implicitly opened write to text file clears the existing contents first. What you are seeing is a race condition between the file being cleared and the new data being written. I also tried it without the close and that still works (but obviously leaks file handles)

So I don't think this is the root of your problems.

I would guess that switch tabs means that everything on that tab is now triggered to be redrawn (which would be inline with rolfk's comments). If you had some large graphs or something similar then reducing the data they are holding may help reduce the spike to an acceptable level.

That said the embedded UI is new and has a few... quirks... so if there is nothing big then talking to NI might be worthwhile as it could be a bug.

I agree with crossrulz given the errors involved (E-12 and E-13). I put a snippet on a blog post which lets you calculate the error for a particular range. https://devs.wiresmithtech.com/blog/floating-point-precision/ (Note these will be smaller since these are the representation errors which will increase through rounding errors in the maths)

I expect neither is better - since the dynamic range of both is the same then no option is more or less appropriate for floating point numbers. I would just pick your favourite, safe in the knowledge that your hardware will probably generate errors much higher that 1 pHz!

(p.s. I attached the code since I couldn't get the snippet in the post to work)

Double Precision Calculator.vi

Hi Ton,

I'm interested in getting an scrypt implementation in LabVIEW and so looking at using your library as a base. It requires the addition of PBKDF2. Are you interested in contributions to this library rather than forking it? If so it would be great to have a version with your test vectors as well and what version you would want to keep it in. Ideal would be a github repo.

If not we will crack on and just depend on what you have already.

Cheers,

James

I like OO - so bear that in mind with my answer!

Ideally you don't want your state machine to know how UI updates are done - it doesn't care, it just needs it done. So I would consider creating a UI class or multiple UI classes for the different parts of the UI with update methods which your state machine can call. Inside of their you can use any of the methods and chop and change between them.

Within there my temptation would be to queue them as messages or user events to a separate UI loop but once the separation is done it is easy to try different techniques.

There is a bug with variant attributes with this method on all targets I believe. I've had this issue where the attributes don't get flattened.

I've also had other unknown issues with these methods as well so I tend to avoid then and follow smithd's advice - using JSON or similar to have some more control over the process.

I don't have full examples but I did write a post on what I felt was the approach to learning OOP that helped me: https://devs.wiresmithtech.com/blog/learn-teach-labview-oop/

(More conceptual than technical)

Looks good, the performance stats look great.

I use the LAVA library in most projects. Normally just small config clusters but I have once had to write my own parser for a 1600 element object (that needed to be quite high performance).

Sometimes in config files I will use the key-value mode to read what items are in the object to help with defaults if missing or version migration which I guess isn't the intention of this API but that's the only case I have that this wouldn't work for.

Great performance - sometimes the simple methods are best!

I think this is a scan engine node that has lost it's reference to the IO point. That's what it reminds me of anyway.

The blue square means that it is actually connected to something.

I've worked with postgres with the NI toolkit in the past without any issues.

I can't remember specifics but I remember finding it to be more feature rich that MySQL (partitioned tables was definitely one we were using)

Hi Bhavin,

It depends on what you want to achieve. If you are new to OO I would suggest that you keep with the standard Producer Consumer pattern and just start changing some of your code to use classes. Anywhere you have libraries, custom clusters or FGVs are good indicators. This lets you get used to the basics without getting bogged down in more complicated design patterns.

What you have to remember is design patterns are all solutions to a single problem so if you don't have that problem then don't rush to use them as they can make your code more complicated.

If you really want to take a look at one though the most equivalent is the command pattern. This allows you to add actions to the consumer loop without having to change its code at all (the problem it solves). But as per my warning above, I use OO all the time and have still never used this in anger!

I thought the concept is that you would still own the copyright on your contributions anyway, if you happen to license it under open source (as you are obliged to if you have derived from most open source license) that doesn't have ownership implications so I wouldn't expect that to be necessary (although I'm not familiar with the in's and out's of R&D credits as I haven't found a project for them yet).

Either way I am happy for you to do this but I do think it would be a shame to split to 2 projects as it tends to cause more confusion (jenkins vs hudson for example!)

It still creates two different contexts in the projects so any libraries or classes that are in both (a.k.a all of them as it is the same VI!) are locked and you cannot edit type defs or add VIs.