ensegre

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)

I'm not really sure about what is going on. I left the thread dangling because at the time I wrote I ultimately got away with a minimal size which was about right for my application, but there are certainly some limitations. This is the code I ended up using; and just checking it blindly today (linux, LV2017), I see that for the particular VI I try to resize, the minimal size is 50x20, otherwise Error 1 (the VI has all window decorations turned off). I haven't found a correlation between these numbers and what is shown on that FP (controls, menubars, title), maybe there is. I might try to investigate further someday.

Shootballing. It may very well be that the codec used for that video is incremental, so that only certain differences from the preceding image are encoded in the next. That at least is one of the tenets of mpeg. If that is the case, I wouldn't be surprised that reconstructing what looks as an innocent predecessor requires in fact to read much more information from disk, and perhaps more computation, than a successor. If so, that seem a characteristics of the codec used rather than a limitation of LV. For reversibility, perhaps a different codec should be considered.

No crash for me past the 2000th folder in 2017/32, 2017/64, 2018/64 on ubuntu18. 2018/64 btw is much faster in that than the preceding.

Yeah, this is what I would do too. I'm assuming the goal is to make sure that if the program aborts the file isn't corrupt, but you can do that with flush file. If you're taking data every second the continuous open/seek/write/close/open... is going to take a toll.  I normally use the open once - {carry on ref - flush file} - close at the end pattern as a rule too, but there could be an argument for the crooked way: the file is not locked for write by the OS in between writes. You never know what an end user might pretend to want to do, like editing the file externally during the test.

smithd just wrote it all, I myself would do pretty much like he says.

ok, nothing weird. I would perhaps have written the VI somewhat differently, but I don't spot a problem either.

Anything weird could happen in the init case, for i~=1 of the inner while, by chance? You don't show us what's in the other cases of the innermost frame.

Another thought - where is the black ear on the cluster icon? I mean, are you sure that this cluster on the BD is really the one you typedef'd? And if it is, and if I look at your FP image, which controls are flag_Z and flag_E? Are "Auto zero-enabled" and "same kind" captions instead of labels?

If you attach your .ctl, maybe someone could look into it. Anyway, have you tried to autosize to fit the cluster? My guess are that the extra controls are in there, just far out of your current border. Reorder controls in cluster might also give you some hint. Just open your typedef, create a new cluster (this will temporarily break the typedef), and drag into it the elements you want to keep. When you are done delete the original cluster and apply changes. That saves you from replacing every single instance of it in your codebase.

Update just for the record - a number of phone calls to the representatives, "so explain me again what error do you get" "Did you read my email?? When do I get an updated firmware?" I got this new firmware, whose release note spells Fixed Problems -------------- - some improvements in Ethernet communication and the problem disappeared...

Is anyone aware of a limitation on what the smallest possible FP size is? On LV 2017, I am under the impression that this is 116x41 on one windows machine, and 1x1 on a linux. Known issue, WM, or deserves a CAR? The reason I'm asking: I'm fiddling with the cosmetics of an Xcontrol. I would have nothing against a larger transparent border, but when I webpublish the big FP using it, the large transparent border turns grey on the snap png. ETA:, ah, https://forums.ni.com/t5/LabVIEW/How-to-set-front-panel-size-to-be-same-as-one-led/td-p/1565524 ETA2: ok, tried the snippet of that thread and get either no reduction or eloquent "Error 1 occurred at Property Node (arg 1) - Command requires GPIB Controller to be Controller-In-Charge" for tighter sizes.