Rolf Kalbermatter

Interesting, never had problems before with AlZip. And it is able to open its own archive! Well lets see: Here are the files compressed with the OpenG ZIP tools . Desica_Megasonic.zip Rolf Kalbermatter

What I do in this case, is wait in the caller until the subVI has opened its FP. The reason to this is that the VI is kept alive by either a VI refnum to it or its FP being open. So after the FP is open, closing the VI refnum used to spawn it is safe. You can do that with .vit too although I usually have those dynamic VIs rather in a "all VIs" top level VI that I have open when developing (and add to the build as explicitedly added VI). To put a VI Template on a diagram instead of its instantiated VI you need to drag the icon from an open VI Template (file->open) or or dragging it from the explorer into the diagram, rather than using the "Menu Palette->File Browser" method. You can also change the setting of the according VI in the build settings in your project but I admit that this is something that can easily be forgotten and the FP frontpanel property is a nice trick to make sure things work always as expected. Instantiation from a VIT is a lot more costly in terms of time needed to open it and most likely also same or worse in memory footprint than a reentrant VI. But the option to have a front panel for reentrant VIs was not there before LabVIEw 8.2 I think. Rolf Kalbermatter

This request is a little very much open ended. Should this be about a DLL that can be interface only by LabVIEW or should it also be possible to call it by other applications (VB, C, Delphi, etc)? If it is just about a LabVIEW compatible DLL, is it legitimate to have LabVIEW specific parameters (advantage: direct parameter passing, disadvantage: call to specific LabVIEW manager functions that the C programmer needs to learn about)? The Calling external Code in LabVIEW section in the online help has a very detailed chapter about how to do it from LabVIEW and with some good will can be used for the opposite too. If LabVIEW specific parameters are desirable then he would also have to read the LabVIEW External Code Reference section that describes the functions one can call from an external code to deal with LabVIEW data types. If the DLL should be generic instead, the same advices apply although to a lesser strict degree as what one would need to follow to allow calling that DLL from Visual Basic as FUNCTION. This means basically: - no C++ functions, they get decorated to an unrecognizable name - no C++ interfaces, LabVIEW can not access them in any way - You can pass C++ object pointers to and from functions but LabVIEW can only treat them as opaque pointer sized integers, there is no way it could access methods or variable members of such an object except using explicit standard C exports of the DLL that accept the object pointer as parameter. This is however dangerous since on the LabVIEW side these objects are simply pointer sized integers and it is rather easy to pass a pointer to object type x to a function expecting object type y, unless the LabVIEW programmer treats those pointers as a private refnum (which will not work for LabVIEW 64 byte since the refnums there seem still to be 32 bits, while a pointer there is 64bits) - no structures with embedded string or array pointers as parameters - all string and array pointers need to be passed as separate parameters and preferably with an extra length parameter telling the function how long the allocated buffer is (preferably in # of elements but bytes can work too with some extra effort by the LabVIEW developer). - in addition to above two parameters types only use scalars of standard ANSI C integer and floating point types as parameters - strings should be passed MBCS encoded and not as widechar or unicode8, simple ANSI is of course best whenever possible - they can be either zero terminated C string pointers or Pascal string pointers - no fancy calling conventions, it's either cdecl or stdcall for Windows and just cdecl for other platforms, if multi platform is needed do only use cdecl as it is the only calling convention supported on all LabVIEW platforms. - buffers to return data should be allocated by the caller, returning buffers allocated by the DLL is although possible not recommended if the contents needs to be accessed from LabVIEW somewhere and it will require an explicit export to deallocate that buffer later, since LabVIEW can not automatically deallocate memory not allocated by itself - alignment in LabVIEW clusters is always packed (1 byte), other alignments for C structures need to be explicitly declared to the LabVIEW developer so he can do it on the LabVIEW side by embedding extra filler bytes in the cluster but it is a better idea to actually declare these filler bytes explicitly in the C structure declaration, to avoid misunderstandings between the C programmer and the LabVIEW programmer. - no function return values other than scalars and string pointers - document if the function is threadsafe I guess that is it in a nutshell. Not sure what else you would want to tell a C programmer to make your life not to complicated to integrate his DLL into LabVIEW. Rolf Kalbermatter

I don't see any order of magnitude faster or anything. The "real" typecast method is simply a flat line independent of the size of the array. And that is not surprising since the work to be done is always the same. Also smart move to use the shift operator for the size adjustment. That way you avoid any possible rounding problems if the incoming array is of uneven length. Otherwise using the divider operator you could get x.5 which could get rounded up to the next number (not sure about the exact semantics of C in this case if both the divider and and dividend are integer, though there is a good chance that the 2 in (**arg2)->dimSize /= 2; might get expanded to a floating point number first anyhow. But why even bother about that if you can use the shift operator instead which will always do the safe thing. I guess someone at NI will soon go and add a special case code to the Flatten and Unflatten function that will do the smart thing when input and output are simply both flat arrays and the desired endianess matches the endianess of the current processor. Rolf Kalbermatter

I'm sure you guys know that already but there is a way under Windows to avoid that problem. It requires to use the Widechar Windows File API and format the path in something like "\\?\a:\path to very long filename". Not all APIs do support that and it would often fail for shell APIs but it is at least a way to circumvent that problem. Not sure about the usability of this on FAT volumes though. Rolf Kalbermatter

How did you download and/or open it? I just tried myself to download the file in Firefox 3.5 and open it with Alzip 7 and had not trouble to extract the files. Rolf Kalbermater

Transpose Array is under such circumstances usually almost a NOP. Thanks to LabVIEW having something like sub-arrays. Rolf Kalbermatter

Converted to DSC 7.1. I would expect this to be enough for DSC 8.6. Desica_Megasonic.zip Rolf Kalbermatter

It might be possible but I have some doubts. There are several reasons why it might not be possible to make a normal .Net assembly remotable. 1) Security! It is always an inherent risk to allow that with arbitrary components. If you create a component specifically to allow that you hopefully take measures to make it really secure but if you can do that with any component, chances are high that there will be some security holes in one way or the other. 2) Complexity! While it is possible to do that with most COM objects (ActiveX servers) there have very few people been able to make it work and even less to make it reliably work. The issue here is that you do need some form of security in place and getting that security configured just right is a very daring task. Even configuring Windows networking can be already an interesting task. In my experience, while I could see more or less any computer on the network in Windows 95 I have nowadays regularly problems to see computers that I have actually explicitedly setup with login and all to be accessible. And suddenly I can see them one day and suddenly they are gone. Rolf Kalbermatter

You are of course correct. I meant he could drop the pad string from the user friendly cluster, but of course it should be present in the low level cluster. And well about your latest remark, I do love to dabble in that low level stuff too, but yes it is always nice to return back to LabVIEW high level programming and concentrate on the real problem instead of making the memory ends meet everywhere and watch out about correct memory allocation and deallocation and never to access an invalid buffer . Rolf Kalbermatter

Congratulations and a success on your new endeavor! Rolf Kalbermatter

Actually I seldom can remember my dreams and if I do they are never about technical things. But I regularly get up the morning after a day of trial and error in getting something to work in either LabVIEW or a DLL and suddenly there is this idea in my head: "Hey why don't you try it in that way?" I'm pretty sure I have somehow worked on that at some point in my sleep and those ideas are often a bit unusual but most times they do work or at least get me a good way on to the real solution. Rolf Kalbermatter

If you can install them in LabVIEW 64bit and can open the VIs without getting a broken arrow then yes they have been obviously recompiled for Windows 64 bit. The LabVIEW Call Library Node can only access DLLs that are specifically compiled for the platform that LabVIEW is itself running on. It does not mean that that is a 100% warranty that there might not be still somewhere 32 bit limits in the IMAQ Visions software, but the DLL itself is certainly 64bit code. Rolf Kalbermatter

Wonder if it is an intricacy of the occurrences? At least in the beginnings all LabVIEW synchronization tools (queues, sempahores, etc) were based on occurrences and they do have a certain special behavior that they can initially trigger once, for occurrences that have been triggered by a previous execution of the code but not polled with a Wait on Occurrence. Rolf Kalbermatter

That would be a new feature then! Implementing a usable IP socket in hardware is anything but trivial and would easily eat up all your resources so there would be nothing left to do anything useful. The real time controller in the cRIO controller however implements a TCP/IP socket (obviously) so you could connect with that and have it pass the data by other means to the FPGA core. Rolf Kalbermatter

Most likely things are a little trickier than that. The Create Listener function has an optional net address input that allows to bind the according listen socket only to a specific network adapter. But leaving that open will bind the listen socket to all network adapters. And this is most likely what the VI server does too. It can't really know which interface you want to use and making that configurable adds yet another setting and makes the VI server configuration more complex. So binding to all interfaces is the most simple approach here. Rolf Kalbermatter

Not really . I think you managed to come up with a few possible obstacles and problems that if they surface, might kill this idea too. But I have no other good alternative at the moment for you. Rolf Kalbermatter

Adams suggestion is correct and should work. He only omitted that the string name you will get will always be 32 characters long with zero characters after the end of the string. So after converting the name cluster into a byte array with Cluster to Byte Array, you should do a search for the first 0 byte and cut the array there and only after that convert it into a string. Also the pad cluster you can simply drop. It will most likely not contain any useful information but is just there to make sure the array elements align properly in memory. Rolf Kalbermatter

Actually they can. LabVIEW knows internally a data type called subarray. It is just a structure containing a reference to the original array handle and some bookkeep information such as offset, stride, and whatever. Most array functions know how to deal with subarrays and if they don't for a particular subarray configuration they will invoke a subarray to normal array conversion, which will of course incur a new buffer allocation. Well I would be pretty sure LabVIEW does handle these things in an object oriented manner, so it is not such a complicated thing but more a well structured object method table to handle various variations of arrays and subarrays. The reason why they do it is performance optimization. Memory allocations and copies are very expensive so spending some time to try to avoid them can pay off big time. Rolf Kalbermatter

Stock Wine has not very well support for building under Solaris. The problem here is not that it can't be done but Wine is a moving target and its main development is obviously Linux based. There are only very few and sparse developers working on Wine for Solaris and the patches for that coming to Wine are very few. LabVIEW 7.x most likely would run nowadays on Wine, since the tests you mention are very old and at a time when Wine was still considered in its infancy despite its age of more than 10 years back then . Running Linux Apps under Solaris seems to me like an exercise in vain. Rolf Kalbermatter

LabVIEW's typecast is more complex than that. It is in essence a typecast like what you see in C but with the extra twist of byte swapping any multi-byte integer to be in Big Endian format on the byte stream side. I think the problem here is that Unflatten does other things like checking the input string length to be valid and whatever. The implementation of Unflatten is certainly a lot more complex since it has to work with any data type including highly complicated variable sized types of clusters containing variable sized data, containing ...... Typecast on the other hand only works on flat data which excludes any form of clusters containing variable sized data. Possibly Flatten/Unflatten could be improved since little endian conversion on a little endian machine should certainly not take longer than the Typecast and additional byte swap, but the priority for such a performance boost might be rather low, since it would certainly make the implementation of Flatten/Unflatten even more complex and hence more prone to bugs in the implementation. But thanks for showing me that the good old Typecast/Swapping still seems to be the better way than using Flatten/Unflatten with the desired endian setting . The reason for this is that LabVIEW originates from the Mac with its 68000 CPU which was always a big endian CPU. While the later PPCs in the PPC Macs had the option to either use big or little endian as preferred format, Apple choose to use the same big endian format that came from the 68k. When NI ported LabVIEW to Windows (and other architectures like Sparc and PA Risc later) they had to tackle a problem. In order to send binary data to a GPIB device or over the network, one had always used the Typecast or Flatten operator to convert it into the binary string and it would have been very nice if the data sent over the network or written into a binary file by a LabVIEW program on the Mac, could be easily read by a LabVIEW program on Windows. This required the same byte order for flattened data, so the flattened format was specified to be big always endian, independent of the platform LabVIEW is running on. A C typecast will be difficult to do in LabVIEW. Trying to do that with a small external code could be an option but it is quite tricky. It's not enough to simply swap the handles but you also need to adjust the array length in the handle accordingly so a different function for each different integer sizes would be required. Rolf Kalbermatter

Well, I just checked it again. It has been a long time that I have worked with this but DDE Server is unfortunately not an option here using the LabVIEW DDE VIs. The LabVIEW internal DDE callback specifically refuses to receive DDE Execute commands and that is exactly the method used by the Windows shell to pass such requests to an application. You would have to implement your own DDE server in C and integrate it as DLL which I think is not a useful exercise in terms of effort required and the benefit you get. As to the solution to your problem I'm sure it has been talked about in the threads linked to from this one as well as in a previous post by me and others in this thread before. With any respect but I find this remark rather amusing. DDE is an old legacy technology. If it is any more secure than TCP/IP then only by its obscurity but certainly not by its way of implementation. DDE is a technology that origins from Windows 3.x days when applications had no seperate virtual memory and could write in each others memory anyway they wanted. Great for implementing interapplication communication schemes like DDE since you had almost nothing to do to allow that. Absolutely not so great for security. In order to make DDE work in Win32, they had to jump through many hoops and add a lot of code that does some obscure things deep in the windows event management to allow for proper operation of it. As such I would never trust it to be really secure, other than the obscurity fact, since very few people know nowadays about DDE and how to use it. The use of TCP/IP (either explicitedly or through VI server) has the advantage that everything will keep working exactly the same if you happen to use this on a non Bill Gates sanctioned OS . There is AFAIK no ActiveX server method to assign file extensions. Even if there would be an alternative that allows to invoke an application based on file extension, the LabVIEW ActiveX server would not be compatible since it only exports its own ActiveX Class Interface and not any other ones. Microsoft would for sure have designed a specifc COM interface for this, that such applications would have to expose, but as said I'm not aware of an alternative ActiveX activation based on file extensions. How things currently happen: If a file extension has a DDE Server registry entry the Windows shell simply tries to contact that server. Failing that it will launch the executable and optionally pass it the file as command line parameter (command/open verb contains the %1 parameter). If that parameter is missing it will try again to contact the application through DDE and pass it the open verb with the file path. Rolf Kalbermatter

There are many ways and what is the best will depend on you. But the only one that does not involve tackling not properly working private LabVIEW methods, properties and events, or writing some bunch of C code to do the "right" © thing in a DLL and integrate that into your app, is to go about it like it is explained in the wiki. The advantage of this is also that it will basically work in all versions and platforms of LabVIEW that support the pass command line parameters feature. This is every desktop LabVIEW version since at least LabVIEW 7.0. And I think you have all the information necessary to come up with a working solution in a day or so. So get started and show us the code, when you do not get any further. Rolf Kalbermatter

Battler, adding a comment to that idea is nice but supporting it by voting for it and click on the Kudos button would probably help more. These ideas are all weighted and the decision to implement them is based on various criteria such as: - The necessary work to do it (not terribly much but it is a tricky thing to get right for all LabVIEW platforms and will require quite some testing) - The availability of resources (developers and their time) - and last but not least the number of votes an idea gets Rolf Kalbermatter

It adds properties and methods to the LabVIEW VI server hierarchy, mostly application related and presumably project and other such stuff, that NI considers to dangerous, untested, or giving to deep insight into LabVIEW. It is related to scripting but not the same thing. Rolf Kalbermatter