Rolf Kalbermatter

No, I do not think so. First there are no such things like DAQ thread, etc in LabVIEW. There is a DAQ Execution System and some others too, and each of them exists of usually 2, 4, 8 or more threads allocated at startup of LabVIEW. In newer versions the number of threads is even dependant on the number of cores the machine has. LabVIEW simply allocates those threads at startup and the OS provides them but the OS has no idea what they are used for. There is possibly one exemption which would be the UI Execution System with always only one thread and this is the initial thread that was implicitedly created by the OS when the LabVIEW process started up. This thread is priviliged in Windows terms in many ways as it is for instance the thread that is used to dispatch any Windows events to the application and many technologies like DDE, ActiveX and such in Windows rely on this thread being responsive in order to work properly since the synchronization (for RPC for instance for Remote control of ActiveX) is going through the message dispatcher. It's a piece in Windows that is in fact amazing to work and keep working over all the different Windows versions. And I have not seen any methods in LabVIEW that would return more specific information about the different threads such as the Windows Thread ID, which could be used to identify the different threads. Windows itself with the exception of the UI thread and that also only by implication, has no idea about what thread would be assigned to what execution system. Rolf Kalbermatter

Of course you have it if you have a recent Windows machine. How to use it I wouldn't know myself. As to the OGIC supporting SSL: Forget it! Implementing SSL is a very serious project in itself, with many implications. Doing that in LabVIEW is a complete nogo, not because it would not be possible but because of a number of other reasons, two of the most prominent are: 1) It is a huge undertaking that would require man years of work. 2) Encryption software is a difficult business that can only work if there is peer review by a broad community or at least by a panel of real experts on this subject, and guess what those experts wor mostly for profit within specific companies. The only feasable option would be to use an existing software such as OpenSSL and link it into LabVIEW. However the OpenSSL API is not really meant to be linked into a system like LabVIEW, requiring things like callbacks and such which makes an interface to LabVIEW a lot more complicated than just implementing some Call Lbrary Nodes. The easiest thing I have found to do (still not trivial) is to actually use an external application like putty to implement the SSL connection and then connect to it through the OpenG Pipe library from within LabVIEW. Rolf Kalbermatter

It could be that the Cleanup Tool does not know the inplace structure. In this particular case the inplace structure is completely useless anyhow. A simple Replace Array Subset will do the same with no performance degradation of any kind I could think of. Rolf Kalbermatter

The Call Library Node does not directly support to pass complex datatypes, resp. it does using the Adapt to Type but this passes an array as a LabVIEW handle which is absolutely not the same as a C array pointer. So you will have to trick this a bit. First configure the parameter as an array of bytes (8-bit integers). Then allocate a byte array of enough length with the Initiliaze Array function and pass this to the Call Library Node. The returned byte array can then be typecasted to a LabVIEW array of clusters and should after that be routed through a Swap Bytes and Swap Words node when you are on Windows. Alternately in LabVIEW 8.2 an newer you can use the Unflatten from String function (convert the byte array first to a string) where you set the endianess input to little endian, or even better native, host order, and the "data includes array or string size? (T)" set to false. With this you replace the Typecast and Swap Bytes and Swap Words. You will have to create a cluster that is compatible. For the char name[32] and char pad[3] you can NOT use a LabVIEW string but must instead insert another cluster of 32 resp. 3 8-bit integers. The get the length of the entire byte array typecast this entire cluster to a string and get the string length and multiply it with the number of struct elements you want to pass to the DLL function and then pass this value to the length input of the Initiliaze Array node. Rolf Kalbermatter

There is no way to fix that really as far as Windows goes. The reason is the limited file association based on file endings instead of Meta data as was used in the old Mac OS Classic Desktop interface. I think Mac OS X still supports that but they also went the path of basing most of the launching on file endings instead. The registry defines which program should be started for a specific file ending and obviously you can not really register more than one primary application for a single ending. The specific problem you see is that the actual launching of a file in an already launched application is done through DDE. The registry defines for the file type a DDE server name and an application topic and the Windows shell (the part that basically sits above the actual Win32 API and where the File Explorer is the UI of) attempts to contact the registered application through DDE and if that succeeds it passes it the file path to open. On failure it launches the registered executable passing it the file path as argument instead. LabVIEW uses the same DDE server name in all versions. You could say that this is a bug but unfortunately since the whole file association in Windows is based on file endings only and therefore a file traditionally only has one association there was very little use in trying to be smart and use versioned DDE server names. Recent Windows versions added a possibility to register multiple applications for the same file type but this is in fact at best a hack IMO. Microsoft itself does discourage to use DDE since about Windows NT4 for anything, although it is still the standard way of launching files into a running application. NI probably never has looked much into that anymore since it is both unsupported technology as far as MS is concerned and the registration of different LabVIEW versions for the same files would be mostly a hack anyhow as it is only a UI feature of the Explorer where you get multiple sub menu items under the Open right click menu. There is really no way to version automatic file launching for the same file type, simply because you can not do a 1 to n selection automatically. The Datact version chooser in my opinion would have a chance to do the right thing although it is by far not trivial. The solution would be, and I was under the impression that was what it did, to use VI server to launch the file in a specific LabVIEW version. There are a few difficulties with this. The first is that someone would have to configure the actually installed LabVIEW versions somewhere although I think VIPM is currently able to do that automatically for most standard installations. The second is that the VI server protocol did have a version chance between 6.x and 7.0 and there was a limitiation that only an old client could connect to a new server or vice versa (I'm not sure anymore which direction it went). The principle would be simple. When the user selects a specific version do launch a file in the Version Chooser it would try to contact that LabVIEW version over VI server (each installed LabVIEW version would need a different VI server TCP/IP port) and if that fails it would launch the executable and connect to it again. After that it would send the open command over the VI Server interface. Rolf Kalbermatter

In my case I have a big hole in the third from the bottom. Does that mean I never can make it better than "How can I pass-by-reference?" I think we could also have something like "Go with the (Data)Flow", "Looping forever", or maybe "Globals are Evil", "Modular Hierarchy", or "LabVIEW The Force". Rolf Kalbermatter

QUOTE (empstar @ Jun 9 2009, 06:45 PM) Sorry I'm not a magician and my crystal ball does currently not work . Translation: I have no idea! You could have not initiliased the camera correctly, your camera is defect, your driver not installed right, your computer flaky, the moon phase not in the right place, etc. etc. I can really not tell you more with the information I have. Correction: Looking at the original function prototype I see the parameter is actually a pointer to a pointer to a pointer!!!!!!!!!!!!!!!!!!!!!!!!!!! This can not be done in LabVIEW. A wrapper DLL written in C is the only solution here. Rolf Kalbermatter

QUOTE (empstar @ Jun 9 2009, 10:20 AM) Why use MoveBlock?? The data is there in the byte array already so no need to move that to someplace else. You just have to decode the array data correctly :-) Basically you want to Typecast that array in an array of 16 bit unsigned integers pass it through an Swap Bytes function to correct the endianess correction the Typecast does and resize it to a two dimensional array of 1000 by 1000 Then you also grab the subset from offset 2000000 (not 0x2000000) in the original array to the end and get there the additional array. Not pretty and certainly destroying some performance with it, but the alternative is to write a DLL wrapper in C which separates out those data parts into more LabVIEW friendly data types. Rolf Kalbermatter

QUOTE (empstar @ Jun 8 2009, 01:27 PM) You should learn a bit about C datatypes and how the C compiler allocates them. The two arrays in your structure are fixed size and therefore are not added as pointers to the structure but instead inlined. This means the structure is as long as the two arrays put together into memory. Also a LabVIEW cluster with two arrays in it is not the same as a C structure with two array pointers in it since LabVIEW arrays are not C pointers but special LabVIEW data types. But this does not apply here anyhow. What you will want to do is create an array of bytes with the length of 1000 (width) * 1000 (height) * 2 (sizeof(UINT16)) + VIVAGRAB_FRAME_METADAT which according to my calculations would be all together 0x2000000. Then pass that as C array pointer to the function. And now comes the intersting part to extract the info from the array. This will be an interesting exercise for you to do. :-) Rolf Kalbermatter

QUOTE (Michele @ May 29 2009, 10:36 AM) Not sure about MySQL but for SQL Server I have been able to insert binary data into a BLOB field by using the binary data syntax. Basically it is a conversion from the binary data into its HEX codes such that the binary data 0x12 0x34 0x56 is formatted into the string '0x123456' and added to the SQL INSERT statement. I'm pretty sure MySQL supports a similar syntax. Rolf Kalbermatter

QUOTE (Fakir @ Nov 8 2006, 02:30 AM) You do not add extra states to the push button. This is impossible as it would require you to change the logic of the C coded button implementation in LabVIEW. What you can do is changing the appearance of the system button to look like a push button. Rolf Kalbermatter

QUOTE (george seifert @ May 20 2009, 09:00 AM) I solved such a problem by writing a wrapper around my Configuration File Close function. Basically what it does is to calculate an SHA128 hash over all the keys and key values in an INI file topic whenever the ini file is (rightfully updated) and adds this value as an extra key to that section. On opening the INI file I recalculate the hash and verify it to be still valid and otherwise post an according message and refuse to start the application in any other mode than the administrator mode which has its own password protected login and the adminstrator then has to go into the application configuration and verify all settings and save them back to the INI file which will update the hashes. Of course not absolutely safe but for any practical means more than safe enough. With some extra documentation of the operation it would probably even pass most FDA requirements. Rolf Kalbermatter

QUOTE (Gavin Burnell @ May 17 2009, 12:29 PM) Someone probably feels very hurt at being so badly misunderstood in her intentions that were anything but self centered. Well I did learn a new word "purdy" Rolf Kalbermatter

QUOTE (hooovahh @ May 27 2009, 09:50 AM) Your list is certainly extensive and not really required by many applications. For LabVIEW 7.1 what I have found absolutely necessary in order to get a simple executable running are following files: lvapp.rsc vidialogs.rsc lvrt.dll if you use any of the 3D controls you also will need mesa.dll and some or all of the models subdirectory. If you only use simple 3D controls such as buttons you can get away with only including one or two ptc files in the models directory. Other DLLs may be required from the runtime directory depending on what functionality you are using in an executable. If you use various dialogs, lvdialog.rsc and lvstring.rsc may be quite necessary. The scripts directory is only necessary if you use one of the script nodes and then only the one dll in there you use the script interface for. visarc will be for the VISA interface object hierarchy descrptions and is only requiring startup time to build up the internal object tree if you are not using VISA at all.

Typically this is a problem with your DLL and/or how you call it. You do not say how you created the DLL (LabVIEW or C) nor how you try to call it. But a common problem is that people calling a DLL from LabVIEW using the Call Library Node do forget that in this case normal C rules apply and the automatic memory allocation management they have gotten so used to in LabVIEW does and can not work here. So they call a function to sum array a and b and hope that the DLL magically allocates array c to write the result in. Well the DLL can't do so and LabVIEW can't do so for you either as the development of the LabVIEW mind reader interface to read the programmers intentions is still in the early stages of prototyping . So what happens is that the DLL writes its results in the invalid (or to small) memory pointer that is passed to the DLL and sometimes that overwrites only non-vital data, sometimes it overwrites very vital data that will make LabVIEW crash after the fucntion returns (or destroy the VIs that you have in memory) and sometimes it happens to write to memory locations the OS knows are not valid for the current process, which will throw the exception during the fucntion call already. Review your DLL for possible out of bounds array references, make sure you call it with preallocated arrays that are long enough for all array and string output parameters and then come back with more info such as the DLL source code and test harness itself if it still fails. Rolf Kalbermatter

QUOTE (Rob Calhoun @ May 14 2009, 10:29 AM) Your assumption is mostly right. The reason it is a 64 Bit integer is not exactly because the wire needs to be a known data size at compile time since a 64 bit platform is considered a different platform and a recompile would be necessary anyhow if you go from 32 Bit to 64 Bit or vice versa. But imagine you passing this pointer to a subVI. To make this work LabVIEW would either have to create a new pointer size datatype or as it does now, always use a 64 Bit (unsigned) integer. The pointer size datatype would be cool as LabVIEW could treat it as separate type incompatible to anything else and you could in such a way avoid a user wiring pointers to integers and vice versa. But it is also a very strict notion and primitives such as add or minus would either need to be updated to accept such a datatype or you could not do pointer arithmetics (offsets) on them. And you would need to find a new wire colour, and change many other functions to support this type too, and, and, and..... Since any sane VI library developer will avoid bothering his/her library user to bother about such things by having such pointers on the top level API, the fact that the pointer sized parameter can be wired with integers is not such a big deal. The person doing the Call Library Node VIs hopefully knows what she is doing and the rest don't have to worry about that . As it is now the Call Library Node will pick for such parameters the correct 32 Bit part or the entire 64 bit part of the integer based on which platform it is running. There is no ambuguity that makes this not foolproof, since you either work with 32 Bit LabVIEW and a 32 bit DLL or 64 Bit LabVIEW and a 64 Bit DLL. Mix and match between these two is not possible and a 64 Bit DLL will always use 64 Bit pointers and the same applies of course for 32 Bit DLLs. Of course if your DLL does some nasty tricks with WOW64 and passes those none-native pointers to the caller you would need to adapt for that by NOT using the pointer sized parameter types but explicitedly selected integer sizes. But anything that is declared as pointer in the prototype, and looks, smells and sounds like a pointer will use the platform pointer size that LabVIEW is also using when you select pointer sized integer. Rolf Kalbermatter QUOTE (stevea1973 @ Apr 26 2009, 08:01 PM) There are a couple of issues really. The statement char **ch declares a pointer to a pointer, so it is wanting to manipulate the reference you have to the string, I expect labview would have a few issues with that as it may cause loss of data because you are losing a reference to whatever that wire held. I really don't know how it would interact with labview, but I'd guess it might not be nice. You actually can do that by defining it as an (pointer sized) integer passed by reference. BUT!!!!!! You need to be very careful about what you do then. First you can not access the data in that pointer directly from within LabVIEW. You either need specific functions in the DLL to return information from that pointer or need to us the unofficially well documented MoveBlock() calls to copy the information out of the pointer into LabVIEW data buffers. Second and this is important: You need in most cases to call the according function to deallocate this pointer after you are finished with it. Otherwise you create a memory leak. I say in most cases since it depends what the function really returns. If it is just the pointer to some statically allocated buffer you better don't try to deallocate it. The same applies if it returns just a copy of the pointer that was passed in as parameter and therefore got in fact allocated by the caller, here your LabVIEW diagram. In all other cases however the library will either have to export a deallocation function (most cases) or document exactly which platform API has to be used to deallocate the resource. A free() will not cut it here since that can depend on the C runtime the application or DLL was compiled with so that the application and DLL can in fact use different memory manager libraries, and pointers from either part have no meaning for the C runtime memory manager calls of the other. (Obviously they are allocated in the same process space so can be accessed from both parts but functions like realloc() and free() might crash badly if applied to pointers coming from another subsytem/DLL). Rolf Kalbermatter

First question: True Second: , with y = 1 It always amazes me to see such code snippets in someone elses program. I once had an application that was using the Select function exclusively to do just about every possible Boolean operation you can think of including AND, OR, NOT. I just can't imagine this to be easier to do than using the proper primitive instead. But maybe that is because I did actually learn Boolean Algebra in my electronics education. Rolf Kalbermatter

QUOTE (ShaunR @ May 11 2009, 05:41 PM) Which makes it probably more like XP Embedded anyhow Rolf Kalbermatter

QUOTE (zythum @ May 11 2009, 06:10 AM) Well the documentation link you provide says it all. If you want to access the VI from the same executable where it is embedded into, just change the path input to the Open VI Reference to a string only, containing only the VI name of the VI. This requires you to know the VI you want to execute of course. In LabVIEW >= 8 you can however not peek into an EXE or DLL anymore through VI server. So if you have some situation where you want to call a VI that is contained in an EXE or DLL that is different than the application runtime that is currently executing this will always fail. Rolf Kalbermatter

QUOTE (ShaunR @ May 10 2009, 09:19 AM) I haven't! I use a small VI that has as input the file size, the desired chunk size and the current file offset and returns the number of chars to read and the new offset. Very simple indeed. On the other hand, you can also just read until you find an error and then filter the EOF error after the loop. This is actually how you do it in C and many other applications also. You do need some indication that the file read loop needs to be terminated either by checking the current file offset to the known file length or by another mean. Since you should have an abortion on any errors in the loop anyhow, this makes the VI actually simpler as you simply abort the loop on error and then filter the EOF error out. Rolf Kalbermatter

QUOTE (ShaunR @ May 6 2009, 03:01 PM) Well, you do not get that error before you try to read PAST the end of the file. As such it is not really a pain in the ######. Reading up to and including the last Byte does not give this error at least here for me. Rolf Kalbermatter

QUOTE (angel_22 @ May 8 2009, 08:09 PM) Your requests so far are unclear at best and maybe even ambiguous. Please make an effort to explain what you want to do and how we can help you. But sending you software is certainly not an option here. NI has evaluation software to download and if you buy the LabVIEW 8.6 software you get just about every Toolkit currently available as Evaluation software on the DVD. If these options are not working for you you need to take this up with your local NI sales representative. They can and will arrange special solutions for legitimate customers. Rolf Kalbermatter

QUOTE (asbo @ May 8 2009, 09:28 AM) Well C hasn't either. NULL is simply a preprocessor define that is numerically not distinguishable to 0. Modern C compilers allow some type definition with pointer constants that allows at least a compiler warning if you try to assign NULL to an integer or 0 to a pointer but that is really all. Rolf Kalbermatter

QUOTE (turbo @ May 8 2009, 10:23 AM) Not officially. There is something called Xnodes that supposedly can do that. It is undocumented except some info in the Rusty Nails subforum here on LAVA and as I have understood quite a bumpy experience to create them. If you really are VERY VERY much inclined you can try that but it is likely yu loose interest long before you get something really nice and shiny . I haven't tried but it seems like a frustrating exercise to me. Rolf Kalbermatter

QUOTE (Antoine Châlons @ May 8 2009, 05:44 AM) I just had a short look at it. Seems it stores the information in hidden files in the system directory and there seems to be some encryption used. Since the functionality is VI based there is some possibility by a LabVIEW freak to actually replace the two or three main VIs provided by this tool and put inside the executable. Name Mangling at build time of your executable would be one possibility to complicate this to the point where it is unfeasible to work for anyone but the most determined hacker. Is it a good idea? Well I'm not a fan of software activation at all. Does it work? Most likely for almost all average users of your software. Is it worth it? The cost of the tool is certainly not a problem. The cost for maintenance however will be not negligible. You will have to build it in your app, make sure to maintain the correct keys and provide a prompt and fast service to your customers to provide them with the keys to unlock your software. Don't underestimate this last one. Rolf Kalbermatter