Leaderboard

Yes but you'd need to define "reliably". I think there would be few milliseconds of jitter and probably a minimum of about 4ms.

I don't know exactly how your collection looks like and in what the NI Web Server as it is fills in, but as for linux and serving http I have been positively impressed by this: https://github.com/illuminated-g/lv-http-server In fact I did some preliminary evaluation of it some time ago, and I was planning to build on it for a project which has been delayed. If you look into, I'd be interested in hearing your opinion as well.

Oh! I got it, thanks a lot. Actually I know about I/O node, but I didnt realise that I should manually add these triggers to the IO(thinking about FIFOs ,registers),now I can receive these triggers and try synchronizing my cards.

they're called hash marks and indicate where LabVIEW compiler will optimize and fold it into constant code. you hide these by changing your LabVIEW settings in the 'block diagram' page see online help : https://www.ni.com/docs/en-US/bundle/labview/page/block-diagram-objects.html bonus link : https://forums.ni.com/t5/The-Daily-CLAD/LabVIEW-Compiler-Optimizations/ba-p/3482600

As far as I know, a .NET dll in LV is loaded on the 1st call to one of its functions, usually a constructor.

for what it is worth, we do this... I have a shallow-ish hierachacy somthing like ths: actor <-- device <-- type_of_device <-- concrete_implementation We have some scipting code to help us make a new instance of type_of_device <-- concrete_implementation I have a template with the last two in a .lvlib, and we clone them as needed to two brand new classes. To further complicate, our stuff is in PPLs.

Hi Richard, I was referring to the Save a Copy on a LVLIB that contains classes A and A1, instead of saving individual classes sequentially. You'd start with Template.lvlib:A.lvclass * Template.lvlib:A1.lvclass, and end up with Clone.lvlib:A.lvclass & Clone.lvlib:A1.lvclass Your new clone lvlib will maintain the linkage within its own namespace. It then becomes a renaming operation for the Clone.lvlib:AX.lvclass to Clone.lvlib:BX.lvclass This only work if your template has all dependent classes in the same lvlib, hence why I called that a "special case". Your solution is more generic. Even when I don't want the classes to end up in the same lvlib, I prefer to extract them after they have been cloned...

The variant attribute cannot have duplicates. If you set it, it overwrites the previous values. With the "array with tag" you can have duplicates.

For your own long-term sanity, I do not recommend replacing any existing wires you have with a variant+attributes. Maybe I am misunderstanding your use case though...

You can NOT install LabVIEW RT on non-NI hardware without a license from NI! And they have so far hesitated or stalled to say if they ever plan to sell such a license. What you can do is install NI Linux RT on whatever hardware you care since the Linux kernel is GPL software. And that is also what the NI Github repository is about. To provide a means to fulfill the GPL requirement to have the source code to the GPL covered software accessible to any user. What the NI Linux RT Github repository does NOT contain are the LabVIEW RT runtime kernel , NI-VISA, NI-DAQmx, NI-this and NI-that since they are closed source software and the Linux kernel comes with a special GPL clause that allows people to build and distribute closed source software that runs on it. Quite some kernel folks would love to get rid of that clause and force everybody to open source everything everywhere, but that didn't even fully work for kernel drivers, where they did a lot of effort to prevent closed source drivers from being able to do high performance operations. The big point here is that NI Linux RT is NOT LabVIEW RT. The whole LabVIEW RT runtime and NI driver stack are closed source and you can not install it on random hardware without an according agreement from NI. If you install NI Linux RT on your Jetson hardware, what you basically get is a somewhat expensive Raspberry Pi or Beaglebone Black board with additional soft RT capabilities but no LabVIEW target support at all! And no, the LabVIEW Hobbyist Toolkit can't be easily repurposed to run with such a hardware either. It's support is limited to ARM Cortex A hardware platforms and you may be able to get the according schroot image installed and running on the Jetson, but that is an entirely different thing than getting NI Linux RT installed on the Jetson. It is legally questionable but maybe you could get away with it, but it is technically quite a suboptimal solution as the schroot environment in which the LabVIEW RT kernel is running is a limited non-RT capable virtual machine running on the normal Linux host on your Jetson.

AFAIK, documentation about this part of LabVIEW is only available as part of the cRIO C module development toolkit. And you had to sign a special agreement to get that. The part number is 779020-03 and it costs currently € 6200 and has a delivery time of 85 days according to the NI order system, but it has no product page anymore and it is questionable that you can find anyone at NI who even knows what an MDK agreement is. AFAIK it included also an NDA section. The whole Elemental IO was developed for cRIO module drivers but its functionality was never really finished.

That vipm package seems to have gotten corrupted somehow. I'll contact NI about it. In the meantime, try getting it from here: https://forums.ni.com/t5/JDP-Science-Tools/Out-of-Memory-Error/m-p/4335019/highlight/true#M156

Hello Benoit. Thank you for your library ! But I have done few modifications to be able to use it : I2C Device Read.vi : - cluster "options" changed ("Acknowledge bit" renamed "Not Acknowledge bit", "Not Acknowledge bit" and "Reserved bit" inverted) - conversion from and to string for "Data" deleted => Be able to receive also bytes with a value of 0. MPSSE I2C.zip

Ok, this is really weird. Yes it is. And I never set that. But what is really strange is it is grayed out and I cannot figure out why or how to unselect it. ------------------------------------- Ok, sorted it out. If you accidentally select "Top level application window" and then customize it, you will get the the "Show front panel when loaded" checked and grayed out. If you instead select "Dialog" or "Default" first and then customize, you will get the "Show front panel when loaded" unchecked but still grayed out. Seems like there is no option that lets you control this manually. That could be a bug. I don't recall this being always grayed out in the past. As for the 66 VI that always want to be saved, that looks like an unrelated problem with this project.