Rolf Kalbermatter

Unfortunately this only returns NULL as serial number on my XP SP3 system, independent of the log in I use. And I have tinkered quite a bit with IOCTL_STORAGE_QUERY_PROPERTY myself but it just doesn't seem to work on my machine and with that harddrive, except when using directly SMART, but for that I need to open Physicaldrive0 with READ and WRITE access and that fails without admin rights. Rolf Kalbermatter

I haven't played with the BIOS serial numbers yet. I did some tests with my OpenG port IO functions to read directly the physical memory to get to the BIOS information. But this requires a kernel driver that you can only install with admin rights (and elevated admin rights in Vista and higher) and most likely loading that kernel driver is also a Windows privileged operation, just as opening the PhysicalDrive. I was able to read various BIOS information in that way and the BIOS serial number was also part of it, but I was of course logged in as admin. Rolf Kalbermatter

Not exactly sure what you mean, but it should be fairly easy to modify those VIs to actually download a binary stream after they get the initial html header. Rolf Kalbermatter

Well I once was fairly fluent in vi commands but if I sometimes happen to get in that mode nowadays, I look pretty silly. Talk about a non intuitive edit flow! Rolf Kalbermatter

Actually I was thinking the same, but in the case of loading a .Net assembly in the LabVEIW development environment 8.0 or higher, it should in fact use the project directory rather than the LabVIEW executable directory, according to some posts by Brian Tyler, the principal architect of the LabVIEW .Net interface and at that time THE NI .Net specialist, before he went to MS. But I have to admit I never tested that thoroughly. My only .Net exposure so far was really the development of a binary .Net interface module for LuaVIEW that had mainly to run under LuaVIEW and LabVIEW 7.1. Rolf Kalbermatter

You can actually do that with the Windows Message Queue example on the NI side. Since it normally hooks the VI window there are events that it never will see, but hooking the application window should be possible too, albeit a bit more troublesome. (and if you mess up that hook you can hose LabVIEW pretty badly , as I know from various projects where I went that path). Rolf Kalbermatter

Just a few remarks here, although I'm not a .Net Guru at all. I'm not sure if app domain is the right word here but LabVIEW indeed registers the project directory for private assemblies. .Net basically only allows two locations for .Net assemblies and that are the GAC and the private assembly directory, which MS might call app domain. Obviously there is no project directory in a LabVIEW executable and therefore the executable uses the default .Net private assembly directory which is the executable directory itself. One additional complication is that you can only add strongly named (fully versioned and all) assemblies to the GAC. Supposedly, all these restrictions are to avoid DLL hell. The problem here might be really that the .Net reference stores the relative path from the project to the assembly, which would explain the mess you get on different computers causing recompiles all the time. Rolf Kalbermatter

I'm probably missing the point in this. What do electrons on the pavement have to do with a proper bidirectional USB protocol? Rolf Kalbermatter

The problem of this setup as it seems to me is that the data resides on the RT system. This has a number of limitations: 1) How do you backup that? No IT provided backup scheme is going to plug into your RT system easily to have that data backed up automatically. 2) How do you access the data? The data may be stored by the RT system but usually the results are not interesting to the RT system anymore but instead to your test department, calibration services, production management, etc. Accessing the data on your RT system by them will require them to use custom made tools by you to retrieve that data and copy it into a more normal database so they can perform their queries, and data mining tasks on them. 3) Assuming you do not need this data external to the RT system, why would you need a relational database at all? That are the fundamental problems of this question. There are also technical ones and building the SQLLite into a shared library that can run on those systems is probably not the biggest of them. More interesting to me would be the stress on the system caused by such a DB engine continuously running in the background, how long the various storage media (some are still pretty simple flash media) will last with a DB engine continuously reading and writing to it, etc. Also assuming you want to do some really usefull stuff with that DB on the RT system, there is a lot more than just making the C code compile, link and run on the RT system. Making sure the resulting engine will really do the right thing independent of all the specialties and constrains of an RT system such as for instance endianess (yes the VxWorks RT targets are all PPC based and use big endian where as all the rest of LabVIEW nowadays uses x86 with little endian), will be likely a lot more work than to get the C code compile and run would be. You do not want to trust your vital data to a DB engine that will eventually crunch your data to an unrecognizable mess on some border condition. All these are things that would need to be investigated very thoroughly before you start to spend many days of working power to port the C sources to compile and run properly on an RT system. Can you explain to me your use case for an embedded relational database more clearly? I would like to understand that issue. For what I have used DBs so far, it was either data logging (historical DB) or managing test results (where a relational DB may come in handy) but those data are typically needed by people that have no direct access to the RT system and so storing it in a network database is a much more sane approach. So what I usually do for test data, is to store the data locally in a buffer and cache it regularly in a simple binary file format. This data then gets regularly transferred to the host application and from there stored in a network database using an ODBC connection. Rolf Kalbermatter

Walking the registry, while not necessarily to bad, is still a bit of work and doing that regularly to detect addition or removal of drives seems a bit expensive to me. And the registry unfortunately doesn't help in my case either. The serial number is not in there!!! Damn I know that feeling!! Rolf Kalbermatter

I would agree with the previous two post. Full Duplex support is important for industrial applications but with a little onchip buffer this should be doable. Also the termination debugging is a good feature. Are there internal termination resistors and are they possible to be disabled? What about bias resistors? The 5V power output on the port would be nice. Doesn't have to be high power, just a few mA in order to add some bias resistors to the setup on the other side. Rolf Kalbermatter

Good work. A very nice library. Rolf Kalbermatter

I see you are using the IOCTL_STORAGE_DISK ioctl codes now. Unfortunately that seems not to work for some (all?) SATA drives, at least on my computer the serial number field always remains empty using that method. This seems to be a known issue with the STORAGE class device driver API not returning the serial number for SATA drives. In short all my research has not brought any reliable method to return the serial number both without admin rights and for all types of built in drives. Don't even talk about USB connected drives, they return the model number devided up in vendor ID and ProductID, which have a meaningful meaning for USB sticks, but divide the ModelID into two parts for USB connected HDs and never return any serial number. Maybe they improved the storage device driver API in Win7 to also return the serial number but at least on XP it will not work for SATA drives. 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