Rolf Kalbermatter

Must have been an Info-LabVIEW post then and not as detailed and about all these things. Many things described in the previous answer were not even possible with LabVIEW 4 or so, which was the then most current version. Also at that time while I was busy trying to write the occasional CIN, I was also often flabbergasted at how to match C and LabVIEW well. Would it be a post explaining about the Windows SDK datatypes and how they relate to LabVIEW datatypes? That could be from around that time. Rolf Kalbermatter

I would quess that the codecs and the entire h323 setup on the Linux machine was probably all in C, with no LabVIEW involved in that part. Maybe it was compiled as shared library and accessed over the Call Library Node, or it could have been its own process and communicate over some TCP/IP protocol with the LabVIEW test application. I have been looking into the possibilities of supporting SIP based VOIP through LabVIEW and came across the sipXtapi libraries, but that went never into a stage where real programming work was done (and it would require some serious DLL wrapper written in C to interface it to LabVIEW). Rolf Kalbermatter

I had a Dell Latitude C 620 or so, then a VAIO and now a Dell Latitude D 830. They all worked well for a long time, with almost daily full time use, and with the Vaio having some issues with certain software drivers. The first Dell's display stopped working after almost 3 years, just a the end of our 3 year onsite support we got with it, and Dell responded promptly replacing first the display, which didn't help, and the next day the system board, which helped because apparently the power converter on there was bad. I did however specifically choose Latitudes eventhough they are more expensive than the other Dell series, because they did look and feel more robust and reliable. Still happy with my D 830 but I recently looked at the newer E Latitude series and it seems the user ratings are rather spread from very enthusiastic to simply abdominal quality. Rolf Kalbermatter

Because I hadn't looked closer at it at that point. Because my solution didn't work properly at that time. I had in the past tried to make modifications to get around the admins-right limitation and the whole thing was not compiling at all. And the older version I had running did not have the MACaddress and HD Serial option. I got it back running with the admins right limitation in the mean time, after looking at your DLL and recognizing the IOCTL operations, but circumventing the admins problem is tricky to solve for all HDs and supposedly going to fail in Vista/Windows 7 again, so not a very high priority for me to get this done. Yes I'm also not saying that a DLL needs to be miniscule. But I like to see what is possible and find it interesting to try to not get unneccessary stuff linked in my DLLs. One possibility for this is to still use VC 6. Not because it creates compacter code than VC 2008 (it most probably does a worse job than 2008) but because it's runtime is also much smaller and can without any trouble be selected to be dynamically linked. For Borland C, Delphi and VC 2008, you probably have to include the C runtime in the link to make sure that you do not need to distribute an additional runtime library installer. Rolf Kalbermatter

Yes, I know. Especially since most methods to get this information, including the one used here, are hampered with limitations about who can retrieve the information. You do need admin or elevated rights to run this IOCTL code. It is better but I get that in my own lvUtil DLL, which does a lot of other things too, such as printing of LabVIEW strings to any Windows printer, serial port enumeration, pipe implementation and a few other things like network MAC and CPUID retrieval in about 32kB . Are you running it with admin rights? In Vista it even most probably needs to run with elevated rights independent if you are logged in a administrator or not. The used IOCTL code seems to be not accessible without admin rights and in the case of Vista it seems to even require explicit elevation. Get Harddisk Volume Info, returns the serial number of the formatted volume which is a random (or not so random, because format allows to specify what volume serial number should be used) number assigned to the partition during formatting. Rolf Kalbermatter

Is this a .Net DLL or something? 508kB for these few functions seems a bit excessive to me. Or is that the price one has to pay nowadays for using VC 2008? Rolf Kalbermatter

Ahhh I see. That works of course for RGBA images but PNG also supports an alpha channel for 2, 4, and 8 bit color and gray scale images with palette (and a variant with a single mask value defining a specific color to be treated as fully transparent). Maybe that LV PNG translates any lower bit image into a 32 bit RGBA image, but I'm not sure about that. My tests with using the automatic transforms of the PNG library to turn everything into a 32 bit RGBA image did show some strange results with certain input images. So I simply read in any PNG image into the closest image depth that the LabVIEW picture control supports without trying to transform everything into RGBA. I was also surprised that the LVPNG.DLL seems to be around 565 kB. My complete PNG library does not even take 140kB but a short look into the DLL seems to indicate that they distribute the DEBUG version of that DLL . Rolf Kalbermatter

I wanted to create a possibility to create a VI snippet in LabVIEW versions prior to 2009 and in fact I can go as far back as to 7.1, although I haven't really tackled the entire problem to turn a diagram selection into a VI Snippet, only for an entire existing VI so far. The main motivation would be to add this to the CCT as an extra possibility. Turning an existing VI Snippet from LabVIEW 2009 into a VI before 2009 is not an option as I have no way to back-convert VIs. For VI Snippets created with that tool turning them back into a VI of the same or newer LabVIEW version is of course not difficult either, but the direct dropping into a diagram is no option due to the lack of suitable drag and drop hooks into the diagram. And I'm not sure how you do get at the alpha channel data in the normal LabVIEW PNG File functions. As far as I could see you only have a threshold to apply to the alpha channel and the VI returns simply a on off mask only. Rolf Kalbermatter

Thanks I will probably do some tests with this, eventhough I do not know much about XControls yet. But it's a good way to get acquinted with them. I know . In any case it has given me already a nice VI library that can read and write PNG files both from disk as directly into a memory stream. Something the built in LabVIEW solution can't do. And it even supports alpha channels although the picture control doesn't support this yet. Rolf Kalbermatter

Selling and especially supporting XP embedded on hardware for development is not easy. In fact I think it is almost impossible or you would need a well paid support program from the hardware supplier. XP embedded is not a plug in the CD-ROM, launch setup.exe and voila thing. It is in fact very far from that. If you look for such an experience you are much better of with a standard XP installation. Using XP embedded means knowing and understanding in detail how you configure a build (yes you configure the components you want to have deployed to your hardware). So it is not like purchasing hardware with a preinstalled XP embedded. XP embedded will be always installed by you, the final assembler of the system) according to the configuration you made in the XP embedded Tools. And what components you will want to install will partly depend on the hardware (where NI would probably get in with a detailed list of what modules are required) but also on your intended use of the system. So NI can not really make that installation for you as they would have to decide between installing anything, basically creating a somewhat leaner XP install, or install whatever they find necessary which would likely leave you with some lack of support for some functions. Also in XP embedded your final application is usually also part of the image that you deploy to the system. Rolf Kalbermatter

It could worsen the problem on some machines where the temp location has been configured by system admins to be deeply nested. In fact the default temp location in Windows at least under XP is something like "C:\Documents and Settings\<long or not so long user name>\Local Settings\Temp" already, which doesn't look very much like a short path to me. Rolf Kalbermatter

I've been playing around with the possibility to create VI snippets even in older versions than 2009 and during that work I was suddenly wondering about the security for this. I'm pretty sure NI has thought about this, (it's probably another reason why a VI snippet only includes the top level diagram and no subVIs) and has implemented the dropping of a VI snippet in such a way that there can not be any automatic execution of code. However trying to implement that with the available LabVIEW API methods in LabVIEW < 2009 might be more tricky. I have not yet tackled the problem of turning a diagram selection into a new VI, to create a VI snippet from and also not the problem of dropping the VI contained in a snippet into a diagram, but the latter could supposedly reuse a lot of the techniques used in the inlining tool posted elsewhere here. But in order to do any of these one has first to instantiate the VI code from a snippet in memory and that is where I started to wonder if there is any kind of VI type, XNode, XControl, X anything, that does do code execution as soon as it is opened in the LabVIEW editor. I know that some of them will execute code when they are dropped to a diagram but do any of you know of cases where even opening such VIs (through VI server, not interactively) would execute something automatically? The reason I ask this, is that if the chance for something like this exists, I will abandon this idea. Rolf Kalbermatter

Probably you were not missing anything. The applications where I used that never required to be build into an executable so I never came across that limit and therefore never tried to tackle that problem. Although I did intend to leave the VITs and their subVis external to the exe for the case we ever would attempt to do the build. But not sure if that would make a difference. Rolf Kalbermatter

It could be also a hardware error on the build in port. Doesn't happen to often but it does occur. Maybe your port got soft damage from some EMC or lightning. Rolf Kalbermatter

You happen to have a slow internet connection or maybe a slow DNS server? Rolf Kalbermatter

Well LabVIEW can do that sort of but it requires the DLL developer to dig into LabVIEW memory management functions and use them strictly! Of course this is to much asked for most of them. What I would say is that such an interface is sort of ok to be used from C code only but absolutely unsuitable to be called from anything else, be it Visual Basic, Delphi, and yes even TestStand. TestStand is not a C compiler so it should not be expected to behave like one . Rolf Kalbermatter

It's all there and you have my blessings to put it in the wiki Rolf Kalbermatter

Aaaaa! LabVIEW 7.1.1 can get very slow too to start up. Especially on machines that had all sorts of other NI software loaded such as the newest DAQ drivers, newer LabVIEW versions, etc. But go back to 6.1, (just to try out ) and that is a quick start on nowadays Dual core machines! 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