ensegre

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.

Isn't it the same I wrote about?

Firewall. Surely needs to be opened for the 5 relevant services on system 1, maybe on 2 too, I'm never sure; it is always so tedious to do. I wish someone had conocted a handy script for doing that automatically on every new LV installation.

Not directly related to dlls generated specifically by labview, but I happen to have also been dealing a lot with matlab loadlibrary on third part shared libraries during the last days, so I allow me the liberty of adding some comments. If that is not clear enough, let me stress: for loadlibrary to work, the matlab build chain has to generate this _thunk_ file, and it will succeed at it only if all is in place. Looking up "cannot build" on the internet is bound to bring up irrelevant HELP ME HELP ME posts; my winning strategy for importing was to start tackling the compilation errors from the first onward. It should be clear that loadlibrary speaks only C, not C++. The perl parser does quite a good job on well written C headers, but does not handle everything (see, in matlab, help on "Limitations to Shared Library Support"); for one, it does not deal with unions and non typedef'd enums. The perl "deprecated unescaped left bracket" warning I got too, and for me it was merely a symptom, not the cause. When you've got .h files, check for anything which stinks of C++. If the .h file is really well written, it will have proper #defines which reduce the prototype syntax to something digestible by pure C. For example, defining EXPORT_EXTERN_C to be an empty string if not __cplusplus. If that is not, you may get through by pointing loadlibrary to your massaged version of the original header files. That is what I ended up doing in my current project, and fortunately involved only minor changes in them. Matlab should be perfectly able to use visual studio afaik, but alas, there is a certain third party library which I managed to import rather easily in linux with gcc, whereas the corresponding windows version of it - well, I haven't even started to bugger about what VS wants from my life there (I might have to, soon... 😒) Another strategy can be to interface with matlab by writing mex files. Mex files can be C++ (don't look at me I'm analphabet there).

From time to time, albeit sporadically, I have to build wrapper sets to .dll and .so, and I would love any improvement. Back in the days I was used to have to write my wrapper VIs one by one, and by now, especially for large libraries, the import wizard is a lifesaver to me. However, I end up still spending some amount of time, often significant, domesticating the .h files provided with the libraries so that the wizard sees better through them, writing LV translators between C structures and casted down byte arrays, creating ad hoc enum ring typedefs, hunting untranslated pointers, and similar chores. If that could be automated, I would enjoy it, though I agree that beyond some point that becomes project-specific. And at times (callbacks, message pumps i.e.) still no choice but having to write C containers. Have btw the import tool parsing capabilities got any better across versions? (I vaguely think yes but I don't have fair data for a comparison)