ensegre

as dadreamer says. One place where I remember I have used it is https://gitlab.com/enricosegre/LVVideo4Linux . Look in LV-libv4l2/Ancillary/libv4l2_path.vi and all its callers for an example.

I found this one dated 2016: http://download.ni.com/cert/doc/NI PCIe-5140.pdf

If you'd like to give me a review on this... I actually never used it for anything serious, but it was working for me.

Right, if I put it there I get all the brown and light blue bonanza. I was mislead by http://zone.ni.com/reference/en-XX/help/371361B-01/lvconcepts/customizing_your_work_environment/#How_LabVIEW_Stores_Options which is pointed at https://labviewwiki.org/wiki/LabVIEW_configuration_file. But uh, that is the help page for 8.2. Still, it is at odd with https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000PA7rSAG&l=en-IL

I see, thx. Still don't think my LV19 can toggle it with Ctrl-shift-DH, nor I seem to be able to create the brown nodes (it's ~/.labviewrc), but whatever. i was just curious.... thx for the conversion.

I'm curious to see if that exists in linux too. LVdebugKeys=True + Ctrl-shift-D-H don't seem to apply. Could someone attach the snippet saved as VI for LV<=2019??

Like Shaun's? https://lvs-tools.co.uk/software/mdi-toolkit-labview-library/

spitballing, having never worked on cRIO: standard linux ways like just parsing the output of free wouldn't help? Or reading /proc/meminfo?

Do you really need the whole power of telnet? Because if no commands are involved you can just tcp read/write, which I assume works multithreaded. At least that was the case the last time I had "telnet" devices to communicate with. ...Have you seen this thread?

So what (however the data is collected). Did I say my community was using it because it aimed at being popular?

I have been using Fortran for scientific computing till the mid 2000s, and that was no way odd in the numerical analysis community. Only, I stuck to FORTRAN 77 when everyone already transitioned to FORTRAN 90. You do still find reputable numerical physics codes around in Fortran.

If you grew up on Fortran you'd know that I default declares to INTEGER and A to REAL.

The DSC module has a few of them, but alas, you can easily create better custom boolean controls yourself Here is an example of mine. The pipes, the pump PP1 and and all the valves come from DSC, almost all the rest are customized controls.

I said xControl first... 😏 The solution of the Program Drafts above is for sure a lot more developed - all the decoding of gif in G, honouring the time lags between frames, etc. etc.

IIUC the OP, he wants to click on a particular area of the plot (needs a mouse Event on the graph control, and identifying the coordinates) and then popup something (Show FP of another vi). My guess at least.

Have you seen this thread?

would seem VI properties/protection "Locked (no password)". Couldn't you just resave those VIs as "Not locked" before analysing? This is a snippet I used sometimes to set/unset passwords programmatically for all VIs in a directory, if it helps.

LV2018_64, 6 true cores linux, debugging disabled in main and all subvis. A typical run of a few seconds: Notifier 5.18M, Lossy queue 4.27M, Unbound queue 3.81M, High speed channel 3.2M, whereas Lossy channel 26k, Tag channel 19k, Stream channel 18k, Indicator reference 10k, and the remaining three 8.6k. Usere event is the second last, 8655, better only than channel messenger (8612). Quite different than @shoneill's. What can be the affecting factors? ETA: Inconclusive. I've been getting quite different results running a few times run Main.vi at time critical priority, then at other priorities, closed/reopened labview, then again at normal. Some system effect (not load) might affect all this?

This is also an informative post by Rolf about older versions.

You can quite get there customizing the control. this for instance is a q&d expansion of the button (on windows it might actually look better), you can always replace the pulldown button image with anything nicer. BigCombo.ctl Btw, perhaps the thread belongs to the UI subforum rather.

It is possible. You have to write VIs.

If you are reading single register values at 1Hz, sample rate doesn't look to me a limiting factor. The modbus packet size might be some 20bytes [Mike correct me], at 230kbaud they are moved through in a ms. The jitter in the synchronization, rather, might be, but that depends on what you can afford or tolerate. You have to keep in mind that both DAQ and Modbus are in principle asynchronous measurements. You can write a program which pushes a modbus command into the computer UART and a start acquisition command to the DAQ. Depending on how you write the program and on the realtiming of the target you run onto, you can approach a simultaneous firing of the commands, but still you don't know the latency of execution of them. The bottom line is normally that if you want sampling to be tightly synchronized, you have to do that by hardware triggering. In reading the results, you may afford delays.

Confirm. But I have seen such things happen with corrupted controls once or twice across the years. My wild speculation was that there is an underlying event loop which goes foul for some reason.