Leaderboard

Ok, so this is a strange application, but I need to build a little exe that can be called from any scripting language (in this case Python) and can accept command line arguments and write its output to StdOut. So far, I have accomplished all this using the standard LV properties for getting the command line args and using some kernel32.dll calls to write to the StdOut of the cmd.exe console window. Where this breaks down is when calling a LabVIEW exe from the console, the console thread is not blocked while the exe runs. So, the result is the console returns back the command prompt and then a little while later my exe sends the data to the console and it just appears where ever the cursor is currently at. So, I need to figure out a way for my exe to steal the thread of the console and block it until it is done writting its output. Any gurus out there have a idea even where to start figuring this one out? It has me baffled. BTW: if you also have a .NET solution for writing to the stdout instead of the old school kernel32.dll solution, I would love to see it. thanks for the help and/or sympathy. -John PS. If you are wondering why the *$@#$! anyone would want to do this, basically it comes down to the need for some non-LabVIEW DEVs to control some cFP hardware over Ethernet and the only way I know how to do this is using LOGOS via DataSockets and that only works in LabVIEW!

Operator Error

It is very important to realize the cast or flatten primitives do not provide you with the binary form of the data as represented in memory. They do provide you with a serial form of the data which can be used to rebuild the data. It's an important distinction. When passing variable length data into DLLs, break them out of any struct/clusters. Fixed length clusters are fine, so long as you're mindful of byte boundaries/padding (#pragma pack(), etc). For arrays and such, pass in two items, an integer specifying the length, then the actual array as an array data pointer. For example: This code calls a DLL to generate 3 arrays of data all of equal size. It first initializes three dummy arrays at a known maximum size, then passes the arrays, along with their size to the DLL, which populates the arrays with data. The DLL knows not to exceed the given size, and returns the actual number of elements used, so LabVIEW then trims the arrays if needed after the DLL call. The other way of doing it is to make two serial calls to a DLL, one to determine the size of the arrays you'll need, LabVIEW then initializes the arrays, then call the DLL again by supplying the appropriate sized array. Which to use really depends on where your bottleneck is.

Is that a euphemism?

This is not really a question of the LabVIEW ActiveX interface but really a feature of the language used to call the open reference. In LabVIEW, references are closed when the top level VI stops running (in most cases). Even if you used the LabVIEW ActiveX interface to open a VI reference, that reference would be closed when the VI stops running. This is not because it is a VI reference, but because LabVIEW closes the ActiveX reference. In C or C++, references are only closed by the user explicitly closing. TestStand is written in C++ so this is the case they are in. C# uses garbage collection so a reference would stay open as long as something still remembers the reference. This could be equal to a thread being running if the reference is stored on that thread's stack but more frequently it is independent of threads. It is usually about a method returning which allows its locals to be collected or a static data structure whose value contains the reference.