Rolf Kalbermatter

The Open VI Reference function is a very bad function to call in a tight loop. Don't do that ever as it needs to execute in the UI thread and will slow down your loop tremendously.

Are you using the LabVIEW DOM library from the Internet Toolkit or simply accessing an XML ActiveX interface? In both cases you may be running into LabVIEWs automatic garbage collection for refnums. Once the top level VI in whose hierarchy a refnum was created goes idle (stops executing) LabVIEW will automatically dispose of that refnum (and the objects they reference). I'm not familiar with X controls nor how they work but if your XControl creates the refnum in some initialization state that goes idle afterwards the object goes invalid at the moment your initialization stops. How to solve that? Initilize the object in a context that will stay running for the desired lifetime of your object.

You should be able to do that with some FPGA logic and last time I searched on the NI board they did actually already have a sample project or two which implemented I2C on FPGA and in RT software and I believe even based on a DAQmx interface. So many options to pick from without needing to reinvent the wheel.

Yes, and your PCMCIA-USB comes with drivers that install a raw USB driver in the system (because Windows 95 certainly didn't have USB support on board, it was an addition to the Win95 OEM SR2 that was rather unstandardized). Raw USB is just that, raw. many different USB devices have many different requirements and therefore there exist many different USB device classes, such as mass storage devices, human interface devices, still image capture, printers, serial communication devices etc. Each of them has a different protocol on top of the USB bus and therefore needs different drivers to allow Windows or any OS to do something with them. Your PCMCIA driver CD likely will install a USB mass storage device driver that makes such devices available to Windows as volumes. It most likely also comes with a human interface device driver, that allows mice and keyboards to be recognized by Windows. It may not come with an USB communication device driver, which would be needed to make a USB COMM class device appear as an additional RS-232 port in your computer. And it will most likely not come with more specialized drivers such as still image class devices or printers or network devices. All that said it will be very difficult nowadays to find a PCMCIA-USB interface and even more difficult to find one that still supports Windows 98 or even worse Windows 95 since Windows 95 had no USB support in any of its standard releases.

As mentioned earlier you can adapt LabVIEW Embedded SDK to just about any 32 Bit platform but it will in most cases not just be an install and run experience. New supported targets are of course always nice but someone has to do them, and NI can't do them all nor will they do any if they do not see some potential market. But there is a catch 22 problem here. The cheap targets are usually used for mass production and there hardware components matter down to the penny. LabVIEW generated code is not exactly lightweight so you do need some minimal amount of memory to even be able to download a simple solution. Those targets supporting more memory are usually not the low cost hardware systems. Also low cost is used for high volume hardware usually and those developing for such a market may often exchange the ease of development with LabVIEW with the memory efficiency of a native C program to save a few more pennies in hardware costs. If they go for an expensive development system they usually go for one of the specific commercial embedded development systems and the hobbiest will go with a gcc based toolchain anyhow.

That is really not so easy. An icon consists in fact of up to four resources namely an icongroup resource, and an icon resource for each of the 3 possible bit depths 1, 4, and 8 bits. For the principle you best check an old Inside Macintosh Volume since LabVIEW binary files are more or less Macintosh OS 9 type resource files, with some minor modifications and of course many non Macintosh type resources in them. But since LabVIEW version 8.2 there is a private application method to extract the icon of a VI without loading it. Get VI Icon.vi

If you already have an analogue output you could simply do the entire function generator in LabVIEW software and output the desired signal through that output.

Because with the USB interface in your computer you are possibly not even halfway done. You need the driver too. Maybe the device installs itself as USB-COMM device which modern computers will install as virtual RS-232. But I'm really not sure USB was that major and far along when Windows 98 was released so even if the device is a USB-COMM class device the Windows 98 computer may not recognize and install it as Windows serial port device. If it is not an USB-COMM class device then you would need the according system drivers for Windows 98 (.vxd which are different than the drivers needed for NT based Windows systems such as 2000, XP and newer) and then also create a Modula2 module to access that driver. But manufacturing a device that is produced in 200 pieces a year at 40 $ each does not sound like a good business to me either.

Are you asking us to develop this all for you???? We are not a free consulting service here. I'm sure what you want can be done in LabVIEW though not everything in a very easy way. Expect to spend a few months of programming to get everything as you show in your screen shots. And if you have no LabVIEW experience triple that amount of time. Or you can hire a LabVIEW alliance member in your area to do the work for you.

I've done this in the past with customer specific fonts (containing their company logo etc) by simply adding the font in the distribution and setting its target to <windows directory>/Fonts. I guess there might be an issue about localization sometimes but it worked so far for the systems that was used on.

Yes you can't delete sub parts from a control nor adding any. The actual internal structure of a control is very static and specific to each control class.

Have you done some benchmarks first to make sure 1500 variables is going to fly? I have no idea about the latest LabVIEW DSC versions, but from what I know they are based mostly on the shared variable engine technology and I have in fact some doubts that technology scales well. So before going through all that hassle I would make sure I can operate with a reasonable amount of variables first. As to automating the binding to front panel controls you might be able to get at that information through the scripting API. In that case you could fairly easily create a little tool yourself that does whatever automation you feel is right.

Refere to this and this communication on the NI boards to get more information about that. There is currently no standard support for DICOM in LabVIEW. I would suggest next time to first use the powers of Internet such as Google before posting here such a request. That is how I came up with these links and in fact many more that might be maybe interesting.

Quite some time ago I played with HelpMaker from Vizacc software. The interesting things about this package were the ability to use the LabVIEW generated RTF as starting input, the possibility to create both help files and documentation from the same sources and it's being free. Haven't followed up on that completely since there had been other projects that were more pressing or tempting since. Seems Vizacc got into some serious disagreements with the original developers and they are redesigning the software currently from ground up in C++, while the original software was written in Delphi. And they seem to not want to give it away for free anymore once the new C++ version is released (when?). So using that software may be now a bit of a timebomb it seems.

I always wished there would be a Search 1D Array that uses bisection algorithme when you know that the incoming array is actually sorted. Not sure if an optional input would be good, since someone might enable that on unsorted arrays and get of course strange results I wrote long ago my own for the most common data types but of course it doesn't adapt to the any datatype like a native function would. EDIT: Thinking about it this is not so much the Search 1D Array function but the Threshold 1D Array. Haven't checked that lately but it may use bi-sectional search now. At the time I did a lot with that function (LabVIEW 6 or so) benchmark showed that the algorithm had to be linear since the time grew linear with the index in the array where the searched threshold was.

Yes likely! The LAVA search suffers from the problem earlier search engines had. If you entered multiple words there it gave you all the pages that contained one of them. You had to prepended an explicit + sign to every term to indicate to the search engine that you intended this to be a logical AND. Google was one of those who found that this kind of search syntax wasn't exactly intuitive to anyone but shell script hackers and put in an algorithme that first ranks all the results that contain as many search terms as possible and then lists those that have only one or a few of them. Haven't much tried to play with the LAVA search yet but it may still use this somewhat ancient syntax.

The LAVA search too!!!

Good observation. If it is not LabVIEW the arrays will throw a wrench into the wheels. LabVIEW expects for any array in a bytestream an int32 telling it how many elements will follow. For creating a fixed size array you have to resort to a cluster of that type with as many cluster elements as you want to have fixed size array elements.

Sorry for that! It has been some time that I had to play with that. The {MySQL ODBC 3.51 Driver} is in fact an alias to another section in the registry that eventually points the ODBC manager to the original DLL as you have tried it out first. I was under the assumption that a direct driver path should work too, but have to admit that I can't say for sure. Maybe it is also a Windows version thingie too.

Bascially what you should do to get the right direct connection string is to configure a database with the Windows ODBC Configuration and then go and look in the registry what that results into. "HKEY_CURRENT_USER\Software\ODBC\ODBC.INI\ODBC Data Sources" lists the installed user DSNs, while "HKEY_LOCAL_MACHINE\Software\ODBC\ODBC.INI\ODBC Data Sources" lists the installed system DSNs. Under the "HKEY_<user or system>\Software\ODBC\ODBC.INI\<DSN name> you will see a list if keynames and values that you want to put into your direct connection string, separated by semicolons, to get the same effect as when you would specify an according configured DSN name.

For most cameras you can more or less forget that. First the protocol is not documented for most cameras. The actual USB control messages are only a few and you could get for some of the chips used quite a good idea about how to access them from looking at the Linux driver source for that cam. But some chips use proprietary compression schemes that are protected by very heavy NDAs. But even if the compression scheme is documented and available as algorithme, implementing it in LabVIEW is usually not a useful option.

Didn't know that either but it makes sense, as it is in fact almost the same with ring controls and enums.

But you should be still able to do what you want by using the DB Tools List Columns.vi to get the column name and datatypes of the query result and according to that info put everything properly into your cluster.

Why shouldn't it work under Linux? It does AFAIK not use DLLs or other external code solutions but is all written in LabVIEW so that should be easy to use on Linux too. I would expect the original poster of this library to have moved on and/or likely being busy with other projects, so whatever you need to do with this you should prepare to spend some time to actually learn EIP and get your hands a bit dirty, if you want to use it for your specific application.

I'm afraid the OLE Variants, which the Database Variants really are, do not map 1:1 to the LabVIEW type descriptor definitions so it is very likely that this is not possible. On the other hand the Database toolkit used to have support for parametrized updates and queries so there should be some way, but maybe that got discontinued in the later LabVIEW versions as it was a seldom used feature and likely a pain to support too.