Rolf Kalbermatter

Don't worry, your language is quite fine. DLL functions are only executed in the single threaded UI Execution system, if you set them like that in the Call Library Configuration. Otherwise they are called in whatever thread is currently available for the execution system, the current VI is executing in. But unfortunately the "Call in single threaded UI context" is not so much to avoid race conditions in the call sequence itself. You can already avoid that by using proper data flow, making sure functions execute sequentially instead of parallel. The issue is much more complicated than that. So could a DLL for instance use thread local storage to store state between function calls. This is a nice way to avoid passing context values between function calls and works perfectly in C, since you typically call a DLL all from the same thread. In LabVIEW this fails miserably since each execution system has a number of associated threads and LabVIEW will pick one of them which is free to call your function in. So not only different functions in your DLL can get called from different (random) threads but also the same function when called multiple times. So it is not as easy when you deal with DLL function calls. Your DLL may be not thread safe because of using global resources such as variables or hardware , but if you know about that and take care about avoiding race conditions through semaphores or simply proper dataflow there is no real problem in executing the DLL functions from other execution systems than the LabVIEW UI one. Off course this is not an option for a library you are going to distribute simply because it is almost impossible to describe the necessary limitations to most of your potential users but the most advanced ones. On the other hand your DLL may be so called thread safe but use thread local storage and that makes it almost impossible to call your DLL functions safely from other execution systems than the UI one. And there are various other issues that are complicating the whole topic. For your case it means you REALLY need to understand what are the requirements of the used DLL in terms of multithreading. UI execution system is the safe one because it avoids all these potential snake pits, but at the cost of serializing any and all calls done in it and therefore quickly causing performance issues. LabVIEW multithreaded calling of DLL functions on the other hand has quite a few potential gotchas but gives you a way of avoiding serialization of functions.

Another case of someone not finding the forest because of all the trees . It's part of the LabVIEW online documentation for quite some time already. Based on that document too. Help->LabVIEW Help...->Fundamentals->How LabVIEW Stores Data. Opening the help and searching for flatten would have given you this in less time than it took to write your post.

LabVIEW scripting was an adhoc feature until 2010. Meaning it was developed and implemented as people inside NI came with some use cases for tools, either internal or for inclusion with LabVIEW. As such it's support of methods and object type is quite scattered. Adding method X to object Z didn't mean that this method was automatically added to all other objects. And adding new objects type such as - let's call it for now - the binary custom control, didn't mean that all the scripting methods from similar objects were implemented and depending where it was placed in the object hierarchy it only inherited limited scripting support from more generic object types. With scripting now being an official part of LabVIEW, this will probably slowly improve, but the play field created already so far is way to large to cover it in one or two LabVIEW upgrades alone. If it doesn't work in 8.5 then that is most likely just the way it is and there is no way around that but to upgrade (or not use that feature). Once you start working with scripting more you will quickly notice that you run into methods and properties that are there but either do nothing or return an error such as "Not implemented" until you upgrade to a newer version. And sometimes it simply crashes until you upgrade. Not much we can do. If LabVIEW would be open source we could take those fixes and backport them to earlier versions, but I will probably be retired when LabVIEW gets open source, if ever.

Have you read the actual document that describes the flatten format of LabVIEW data? For the fundamental datatypes like skalars and structs it can't get much more standard than the default C data format. The only LabVIEW specifics are the prepended string and array sizes, and the structure alignment of 1 bytes, as well as the default big endian byte order. It only gets LabVIEW specific when you talk about the aforementioned array sizes that get prepended, complex numbers and extended precision datatype, and other LabVIEW specific datatypes such as timestamps, refnums, etc. As to Open Source there exists an implementation although not in C but in LabVIEW. Checkout the OpenG lvdata Toolkit. Feel free to translate that to a C library or any other language of your choice .

I'm sure you are not working with Windows anymore, since Windows changes the way of working and data formats with every new version. Not sure you will find another solution though without at least some of that problem too . As to flattened dataformat changes, lets see, one incompatible change at version 4.0 since LabVIEW was introduced as multiplatform version in 1992. (Version 4.0 was around 1995.) Sounds at least to me like a VERY stable dataformat.

Looks almost like an implicit (and definitely not legal) I8 cast is done somewhere. This is something NI really will want to investigate, since such errors are a terror for any LabVIEW user.

Weird reasoning. The LabVIEW variant is not the same as an ActiveX Variant. LabVIEW does wrap ActiveX variants in its own variant to make them compatible diagram wise, but the actual internal implementation of LabVIEW variants is NOT an OLE/ActiveX Variant. And the same applies to the flattened format which is just as proprietary as the other flatten formats, although fairly well documented, except for the Variant. NI usually does a good job in maintaining compatibility with documented behavior but reserves the right to change any non-documented detail at any time. In case of the flatten format they changed the typedef description internally with LabVIEW 8.0 and in the mean time even documented that new format but maintained a compatibility option to return the old flatten typedef. The actual flattened data format stayed the same, except of course was extended to support new datatypes (I/U64, Timestamps, etc.). The only real change in flattened data itself was in LabVIEW 4 when they changed the Boolean to be an 8 bit value instead of a 16 bit value (and boolean arrays changed to be arrays of 8 bit integers, whereas before they were packed). Other changes in the flatten data format were in various versions in how refnums got flattened but NI does not document most refnums internals and therefore it's internal implementation is private and can not be relied upon. But if you know where refnums are you can usually skip them in the datastream without version dependency (almost ). And claiming ActiveX Variants are a standard is also a bit far reaching. It's a Windows only implementation and many other platforms don't even have such a beast.

I left it open on purpose. It can be quite a decision

Any plans on moving to Europe?

Contratulations Daklu. The next 1000 posts will be a charm .

Congratulations François. Nice achievement.

you clearly missed some, mostly from february 2010 but also later. I reported them but not sure who gets those reports. I think I reported some of them already last year.

Just to confirm! There is no way you can create your own custom control for LabVIEW. While the image control is located in kind of an external resource, some sort of DLL, it uses a completely proprietary and undocumented interface to integrate into and interact with the LabVIEW user interface. And all the meaty functions which do the real image drawing and what else of that control, are implemented in the LabVIEW kernel itself. Since we can't extend that kernel - it is located inside LabVIEW.exe - there is no way for people outside NI to do something like that.

Well as you go on with this project you will soon find that it takes A LOT of time and effort to write such a thing, and therefore it is likely that your Open Source library is only ever going to support a fraction of the functionality of IVision and you will understand why they didn't make the entire OpenCV API fully accessible in LabVIEW. IVision as it is, is a really large task in itself to accomplish already and contains quite a bit of work to make the OpenCV API work with good performance from LabVIEW. Sure you could go and simply create LabVIEW wrapper VIs for the OpenCV functions directly without any intermediate DLL but you will soon find out that the VIs created in such a way are kind of hard to develop and maintain and the performance of such a solution is likely going to suffer. The LabVIEW ecoverse is kind of small, and while Open Source can and does work in some areas image acquisition is probably not the most likely one. It requires quite a bit of domain knowledge, a very good programming knowledge and a large amount of time to maintain, and all that for a very small user base. Small because the professionals will use IMAQ Vision anyhow, since it is backed up by NI support, semi professional might go for IVision because of the cost, and the poor students will take whatever is there if they can get it for free, but only really do the minimalistic stuff of accessing a webcam and storing an image to disk, with an occasional simple image analysis function if they even have the time and guts to dive into the theory of how to use that.

Besides that there are examples in LabVIEW that show you how to do simple TCP/IP communication as already mentioned by Tim, this request is so unclear and brutal at the same time that the only thing I can come up with is "Homework hustler".

There are some serious trouble and some minor nitpicks. First thing is your initialization of the string cnt value before you allocate the string handle with NumericArrayResize(). This can't work, since the cnt element is just another element inside the memory buffer of the handle. Therefore it does not yet exist. In fact the (*((*(CamArray))->CamInfo[deviceIndex].SerialNumber))->cnt = strlen(String); must crash since you dereference the (*(CamArray))->CamInfo[deviceIndex].SerialNumber value which is still a NULL handle from the previous DSSetHSzClr(). And if you hadn't used the function with Clr in it, the value would be not necessarily NULL but still as invalid a memory address as NULL is. So you can't initialize cnt before you allocated the string handle with NumericArrayResize() and in fact I make it a rule to always only initialize cnt AFTER I have filled in the data. The same potential error is done in the FillError function. Potential because the string may be not NULL if the VI that passed in the error cluster had put a non-empty string in there. Another issue although not fatal is that you do not need to account for the 4 bytes of the dim (for string its the cnt) integer when you use NumericArrayResize(). This function accounts for the dim integer already when allocating the necessary memory handle (but it doesn't fill in the dim/cnt value. You do need to account for the dim/cnt size when using the DSNewHandle(), DSNewHdlClr() and DSSetHandleSize() functions since this are low level memory manager functions that make no assumptions about the content of the handle. Last but not least strncpy() is a rather tricky function. It's semantics happen to work for this specific case, since a LabVIEW string does not need to be NULL terminated and strncpy() does not insist on adding that NULL character to the end if the count value happens to be equal or smaller than the actual characters in the source string. So while strncpy() actually works perfect for this use case with LabVIEW string handles I try to avoid this function at all costs since when used with normal C strings it often can result in unterminated strings in the memory buffer which can cause all kinds of buffer overrun errors. Call of MoveBlock() or memcpy() is much more clear in this respect since it does what one expects and nothing more or less.

So you have found a solution but find it to complicated? Or what is the problem you still have?

Then let it send you a confirmation email. In there all activation codes are listed and can be copy-pasted enblock into the activation wizard. Had to do that here because the wizard seemed not able to connect to the activation server, while it could actually have me send the email, so go figure .

And it's a long way to be anything but Windows only. I know of Moonlight but sorry guys that is not cutting it yet for use in an application like LabVIEW on non-windows platforms. Even Mono is still lacking quite a few things to be a true .Net replacement.

It's your application, at least I would hope that, so the answer to both questions can only be given by you. The only thing we can tell you are generic advices or in other words: 1) It's time to close your VI FP when you don't have to show anything to the user or don't have to get information from them anymore. 2) Invert number 1) and you have the answer to that as well.

Well you can access the data and therefore export it to some other place but ODBC indeed is not meant as a management interface to a database. Each database implementation has very different ideas about how its data needs to be managed and that would be almost impossible to put in a generic API that fits all. So this is really mostly left out of ODBC (and ADO and DAO and JDBC and what else generic database APIs you have). A database usually comes with it's own management application that is meant to be used for this task. For MySQL there are also PHP based management tools since MySQL is often used as backend for web servers. Trying to do real management of a MySQL database from within LabVIEW would require a specific VI library to access the MySQL management API. Certainly doable but not something that could be done in a weekend or so. And that is why it most likely hasn't been done by anyone so far.

Well that the DLL call is done in the UI thread may be just a byproduct. What I was meaning to say is that the execution of the entire XNode may be forced into the UI thread. I have never bothered to look into XNodes and how they work, but it wouldn't surprise me if they are more of a quick and dirty hack added to LabVIEW than a properly designed feature, which might be one of the reasons that it never made it into a public feature. And taking the shortcut of executing XNodes in the UI thread would make creating such a feature much easier. Of course it's not ideal to do it that way but hey I have no idea what the intended use cases were so it may have made perfect sense.

The logical and real "fix" would have been to use user refnums, which are available since at least LabVIEW 7 or so. And allow us mere mortals to use them too, without having to revert to reverse engineering them!

My point is that the password does disallow looking at the code, but does not encrypt it in any way. And why should it, if it did this would serve almost no purpose at all, since it would be functionally almost equivalent than removing the diagram altogether. The only difference with that would be that if you remove the diagram and loose the original then you lost all your work, with the password protection as long as you remember the password you still can get at it, even if you loose the unprotected original. But that is a minor difference that would not justify spending much resources at all to be put in LabVIEW, since loosing a password is actually easier than loosing original VIs, if you do some kind of useful backup, and we all do that, don't we? As far as LabVIEW is concerned the password protection still allows LabVIEW to load the diagram and compile it, that is a given and not just an assumption. As such NI can create an internal LabVIEW prototype that would allow opening password protected diagrams. Of course they don't just as there is nobody out there who admits openly to have broken the password protection yet. Bottomline: If the security of your diagram is life threatening to you, don't distribute it, password protected or not. LabVIEW can get at the diagram and so could a sufficiently determined hacker. It's not easy but certainly not impossible. Is it safe enough to prevent usual theft? Yes I believe so! But then I have not used the password feature at all so far and don't feel it useful for the work I do, and I have even released quite a bit of code as open source, so maybe I'm just not paranoid enough to care about the password protection of LabVIEW diagrams .

It's no help I know but this has been an issue as long as LabVIEW has had the Run method (and even before VI server when there was a CIN based VI library to do some simple VI Server like things, around LabVIEW 4).