Rolf Kalbermatter

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.

I'm pretty sure the mySQL protocol also supports transmission of binary data, which quite likely would speed up transmission and possible also conversion to Variants consideralbly but make the query interpretation a whole lot more complicated to program.

What sample demo did you run? A LabVIEW one? Without already owning the Microprocessor SDK Module? With the LabVIEW Microprocessor SDK Module it is not impossible, but it may be a lot of work if the hardware target you are using is not one of the supported ones. That is because you would have to create the interface logic between the Microprocessor SDK Module and your specific C toolchain and most likely also write some elemental IO blocks.

The difference is that the VT_I4 type is an OLE Variant type while the other is a LabVIEW Variant. The Variant to Data used to be able to convert both types but chocked on the VT_NULL Variant that could be returned. For that there was a Database Variant to Data function. It's possible that LabVIEW 8.6 or something changed this behavior so that you do need to explicitly use the Database Variant to Data function from the Database Toolkit palette for all Database Toolkit variants.

.Net Pinvoke may spare you a few mistakes, but I'm sure that if you do not know what you are doing you are still into a lot of trouble. Likely you will get an .Net Exception dialog instead of the Win32 Exception dialog if you mess up pointers but that are minor details.

I used to use the Not A Refnum constant for this. Yes is it not of a specific refnum type but that is seldom a problem since it coerces easily into any other LabVIEW refnum. Since about LabVIEW 8 you can also right click on a tunnel or terminal and select Create a Constant and it will actually create an according, typed refnum constant that has the canonical value of Not A Refnum.

For all LabVIEW built in LabVIEW refnums you can simply use the Not A Refnum primitive in the Comparison palette. This will not just check if the refnum is a NULL refnum but actually verify that the refnum refers to an actually still opened object. I'm not sure if your shared variable refnum is a built in refnum or some pseudo refnum but you can easily try that out. This function has the additional advantage that it does not depend on some strange features in newer LabVIEW versions. If you compare certain refnums (VI server refnums) with the (Not)Equal function since LabVIEW 8.0 you do get for instance equality eventhough the refnum is technically not the same, but it does point to the same object (VI refnums work for instance like that).

Take the link and convert it to the new location: http://messages.info-labview.org/2003/06/20/37.html gets: http://sthmac.magnet...iew/ILVDigests/2003/06/20/Info-LabVIEW_Digest_2003-06-20_037.html You can also go to http://hannahsmac.magnet.fsu.edu/infolabview/adv_search.html and do an Info-Labview search there.

So true. I canceled my subscription to those threads as I don't want to hear about new updates to them.

Well the CLSID isn't the primary mechanisme really to determine what application to open for a file type. It can come into play but the normal path is that the key in the registry matching the file extension is queried and that is usually an alias to another key that contains the actual information how to launch the according application. The primary key can also contain optional information such as the list of program IDs that can cope with that file and also CLSIDs for applications that should be used to handle the file but this last one is not the normal operation for most file types. A agree that the avi and vi extension have some similarity but this would mean that explorer has gone bad when parsing the file extension AND that LabVIEW somehow holds on to filehandles for files it was not able to handle and simply refused them. Quite a combination of unlikely coincidences.

The bit jamming indeed indicates a problem with the serial port settings. Parity, number of bits, and start and stop bits must match exactly. The data formatting is just that, a formatting. If you display a byte stream with a series of two hex code numbers or four hex code number is simply a choice about presenting data. That does not mean that LabVIEW makes of the stream of bytes a stream of 16 bit integers. It simply chooses to display the binary stream as 16bit hex numbers, that is all.

But to get your 30 V (actually you should go for some margin) you will need more than a dozen of them in series. Seems very costly to me and it will also reduce the total capacitance accordingly. Ctot = 1 / (1/C1 + 1/C2 + ..... 1/Cn)

Feeling the age. But quite impressive to do that sort of thing in 3rd grade.

The order of the diodes should have no influence whatsover, assuming no other environmental influences (PCB leakage currents, dirt, etc) would influence them in one way or the other.

I know you didn't want to say that, but it sounds like cars didn't produce CO2 when they were still polluting the environment in heavy ways with sulfur, and many other things. And I agree that any alternative will also come with its own problems. For me the real problem is not the particular energy we use to do what we do, but the sheer amount we use for that. No matter how you will get at that energy it will have sooner or later some impact on our environment. There can be variations in how dangerous or polluting that energy is, but I do not believe that there is any energy source that will not have some negative impacts on us if consumed in the amounts we currently do. And then to think that almost 1/2 of the human population is in fact in so called upcoming economies that strive seem to go to have the same energy consumption that we have!