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

It's considered friendly to mention cross posts to other boards even if they are on the "dark side". During a recent crash all of the content got lost and had to be restored from backups. This broke many links. The admins can fix them if they know where to look exactly but this is manual work so be kind and give them the exact information about what is broken and some time to fix it. VIPM is the flagship software from JKI. So they are not likely giving out the source code for that. But once the links are restored you should get the examples you need. But the principle is not so complicated. First you have a tiny little LabVIEW EXE file that gets assigned the file extension(s). It is always started with the filename as command line parameter and it takes those command line parameters, opens an interapplication communication channel (TCP/IP, DDE, etc) to your real application and passes it the command line parameters over that. After that it simply terminates to be launched again. Of course there is a little more to it since the command line intercepter has to check for the main application to be started and if that is not the case do so first. Unfortunately this is absolutely necessary in pre-8.2 scenearios since the LabVIEW DDE server functions never implemented receiving DDE Execute commands (the client functions support sending them though ) and that is how the Windows shell passes those requests to an already started application. I once tried to implement a new version of the DDE functionality in LabVIEW that would support receiving DDE commands too, but never got really far due to time constraints and lack of any need for that for myself. From 8.2 you have this private Open Document event in the event structure. It seems to be there since and not really changed but there are troubles with this, that it throws an unknown LabVIEW document error the first time after the application has been launched. Not sure if this problem still exists in the most recent LabVIEW versions. Rolf Kalbermatter

I have found that having a wire and getting its Terms[] property you can get directly to the object (node, terminal or whatever) that wire is connected to. For Control class (Control & Indicator terminals) the Term is directly the control (cast it using To more specific class) while for other objects you can use the Owner Property to get at the node, structure or whatever that owns the term. As to the first element in a Terms[] array always being a source, that is not entirely true. If the wire has no source at all (broken wire) the first element will be one of the sinks it is connected to. Rolf Kalbermatter

Why not turn the whole idea around? You do want callback support and ActiveX (long ago) and .Net (since version 8) interfaces in LabVIEW support it out of the box. So the real solution would be to write a thin ActiveX or .Net wrapper around your DLL code that translates the DLL callback in an according ActiveX or .Net event. Then your DLL invokes the callback funciton which in turn sends the ActiveX/.Net event to LabVIEW and LabVIEW invokes the according callback VI which then returns whatever data is required to the ActiveX/.Net event and that returns control to the callback. Yes it is not trivial and it would not work for tight low level kernel type callback drivers, but nothing will directly work with such callback drivers from a high level environment like LabVIEW. You could make it sort of work from a simple C program but certainly not a .Net application or such either. If you need to pass large amounts of data from the callback to LabVIEW or vice versa you would have to opt for an in-process ActiveX or .Net wrapper otherwise you can go with an out of process wrapper too. ActiveX/.Net will take care of marshaling the data for out of process servers between said server and LabVIEW (and .Net may do marshaling no matter what). Marshaling is ok for small amounts of data but if you plan to move large amounts of data it is going to create an additional bottleneck. Rolf Kalbermatter