Rolf Kalbermatter

Actually not exactly. NI set this compile define to make the shared library multi-threading safe, trusting the library developers to have done everything correctly to get this work like it should but somehow it doesn't. Still there is something seriously odd. I could understand that things get nasty if you had other code running in the background also accessing this library at the time you do this test but if this is the only code accessing this shared library something is definitely odd. There is still only one call to the shared library at the time your PQfinish() executes so the actual

What do you mean with "threadsafe CLN"? It is a rather bogus terminology in this context. What you have is "reentrant" which requires the library to be multithreading safe and "UI Thread", which will allow the library to do all kind of non multithreading safe things. That trying to call PGisthreadsafe() from any context is not crashing is to be expected. This function simply accesses a readonly information that was created at compile time and put in the library. There is absolutely nothing that could potentially cause threading issues in that function. That every other function simply cra

Is it? Then there would be indeed a discrepancy between when the front panel update is executed and when the debug mechanism considers the data to be finally going through the wire. Which could be considered a bug strictly speaking, however one in the fringes of "who cares". I guess working 25+ years in LabVIEW, such minor issues have long ago ceased to even bother me. My motto with such things is usually "get over it and live with it, anything else is bound to give you ulcers and high blood pressure for nothing".

Ahhh I see, that one had however no string input at that point. But now it's important to know on which platform this executes!! I don't think this VI is a good method to use in implementing a protocol driver, given LabVIEWs multiplatform nature. The appended EOL will depend on the platform this code runs, while your device you are talking with most likely does not care if it is contacted by a program running on Windows, Mac or Linux but simply expects a specific EOL. Any other EOL is bound to cause difficulties!

You either have a considerably corrupted LabVIEW installation or are executing some external code (through Call Library Node or possibly even as ActiveX or .Net component) that is not behaving properly and corrupts memory! At least for the Call Library Node it could be also an incorrect configuration of the Call Library Node that causes this. Good luck hunting for this. The best way if you have no suspicion about possible corrupting candidates is to "divide and conquer". Start to exclude part of your application from executing and then run it for some time and see if those errors disappea

You are trying to force your mental model onto LabVIEW data flow. But data flow does not mandate or promise any specific order of execution not strictly defined by data flow itself. A LabVIEW diagram typically always processes all input terminals (controls) and all constants on the top level diagram (outside any structure) first and then goes to the rest of the diagram. The last thing it does is processing all indicators on the top level diagram. There is no violation of any rule in doing so. Updating front panel controls before the entire VI is finished is only necessary if the according

What is that icon with the carriage return/line feed doing? Any local specific code in there? If your other side expects a carriage return, linefeed or both together specifically and just ignores other commands you could get similar behaviour.

The VI generates the error 32. What code does the ShellExecuteA() function return? That might be giving at least some idea what is going on. Most likely there is no print method registered for the PDF file type.

Something is surely off here: You say that the checksum is in the 7th byte and the count in the 8th. But aside that it is pretty stupid to add the count of the message at the end (very hard to parse a binary message if you don't know the length, but you only know that length if you read exactly the right amount of data), those 70 71, 73 and so on bytes definitely have nothing to do with the count of bytes in your message. Besides what checksum are you really dealing with? A typical CAN frame uses a 15 bit CRC checksum. This is what the SAE_J1850 fills in on its own and you can't even modi

Is that other application a normal Windows app or a LabVIEW executable? In most normal Windows apps each control (button, numeric etc) is really another window that is a child window of the main window. LabVIEW applications manage their controls entirely themselves and don't use a window for each of them. They only use a window for the main window of each front panel and for ActiveX/.Net controls.

LabVIEW doesn't handle name mangling at all. It would be an exercise in vain to try since GCC does it differently than MSVC, just to name two. There is no standard in how names should be mangled and each compiler uses its own standard. There is some code in LabVIEW that tries to work around some common decorations to functions names such as a prepended underscore. If the Call Library Node can't find a function in the library it tries to prepend an underscore to the name and tries again. Stdcall compiled functions also have by default a decoration at the end of the functions name. It is an

There are about 500+ ways to tackle this. You could use a Scan from String with the format string AOM=%d. Or with the format string %d and the offset with 4 wired. Or a little more flexible and error proof, first check for where the = sign is and use the position past that sign as input to the Scan from String above.

It does for me.

There are various packages around that do different things to different degree. Most of them are actually APIs that existed in the early days of Windows already. Things that come to mind would be querying the current computer name, user name or allowing to actually authenticate with the standard Windows credentials. Others are dealing with disk functionality although the current LabVIEW File Nodes offer many of those functionalities since they were reworked in LabVIEW 8.0. then there are the ubiquitous window APIs that allow to control LabVIEW and other application windows. As far as LabVIEW i

That was very lame of Indy! 😆

While I prefer non-violence, I definitely feel more for a sword than a gun. It has some style. 😎

The potential is there and if done well (which always remains the question) might be indeed a possibility to integrate into the import library wizard. But it would be a lot of work in an area that very few people really use. The Win32API is powerful but not the complete answer to God, the universe and everything. Also there are areas in Windows you can not really access through that API anymore. In addition I wonder what the motivation at Microsoft is for this, considering their push to go more and more towards UWP, which is an expensive abbreviation for a .Net only Windows kernel API without

My experience comes from the other side. We have started with SVN some 15 years ago or so and while it has limits it worked quite well for us. There are additional limitations because of the binary character of LabVIEW files, but GIT doesn't add anything to the game there really. I have been exposed to GIT in recent years because of customers using it and also from dabbling in some Open Source projects that use GIT and I have to say the experience is overwhelming at first. SVN certainly has its limits but it's working model is pretty simple and straightforward to understand. And it has always

I would agree with Shaun. Looking at the link you provide, the podcasts on that page are typical marketing speak. Many nice words about a lot of hot air. Now, I'm not going to say it is unimportant in nowadays time. Much of our overhyped and overheated economy is about expensive sounding words and lots and lots of people wanting to believe them. In so far it certainly has influence and importance, no matter how artificial it may be. The problem I see with that is that there is little substantial content in the form of real assets that back the monetary value of the whole. It's mostly about abs

What would the named pipe achieve? How do you intend to get the image into the named pipe in the first place? If you need to write C code to access the image from the SDK and put it into a named pipe in order to receive it in LabVIEW through the Pipe VIs, you could just as well write it to disk instead and read it through the LabVIEW File IO functions. Functionally it is not different at all, while the File IO is million times proven to work and the Pipe interface has a lot more potential problems. If your SDK driver has a way to simply put everything automatically into a pipe then it may

Most likely a cerebral shortcut with his more involved SQLLite library he has worked on so relentlessly over the years. 😀 There is a good chance that the Windows version of the PostgreSQL library is compiled in a way that supports multithreading calls while the Linux version may not. With the CLN set to UI thread, LabVIEW will always switch to the UI thread before invoking the library call, resulting that all such CLNs are always called in the same thread. With "Call in any thread" enabled, LabVIEW will call the shared library function in whatever thread the VI is executing itself. A VI i

Data buffer handling and especially callback functions really requires you to write an intermediate shared library in C(++) to translate between LabVIEW and your driver API. Memory management in LabVIEW has some specific requirements that you need to satisfy and usually goes against what such drivers expect to use. They are written with C programming techniques in mind, which is to say the caller has to adhere to whatever the library developer choose to use. LabVIEW on the other hand is a managed environment with a very specific memory management that supports its dataflow paradigma. Ther

The fact that VIPM does require a restart of LabVIEW is probably a good indication as to what it does. 1) enumerate all installed LabVIEW versions 2) read the labview.ini in that location and extract the VI server settings 3) if user changes the settings for a LabVIEW version, update the LabVIEW.ini file and require a restart On restart LabVIEW reads the LabVIEW.ini file and all is according to what VIPM wanted it. Simple and no hidden vodoo magic at all.

https://www.theregister.com/2021/01/05/qt_lts_goes_commercial_only/ One more issue about using QT unless you are fully commercial already anyhow.

Yes, except that without WinSxS you had one problem, with WinSxS you end up having several more problems! 😀 While maintaining binary compatibility across library versions requires some real discipline, abandoning that and trying to solve it with something like WinSxS is simply getting you further down the rabbit hole.