Rolf Kalbermatter

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!

Well Siemens usually have its specific way to do things and that often looks a little different than the rest does it. :-) I've interface with various Siemens PLCs in the past and have used various interfaces to do that. With older S5 we usually went with a direct connection through a serial port which could be either the programmer port or a specific communication processor port. Protocols used there were all Siemens specific and usually developed inhouse on the LabVIEW side, such as AS511, R3964, etc. With the S7 series we did go a few times with Profibus and the actual card used depended mostly on the customer for which it was, as some of them have already a certain standard in house, so that it is not very useful to force them into something else. Cards that we have used where the Profibus card from Comsoft, which is actually what NI is selling as their Profibus hardware, but also interfaces from Hilscher. They all worked but we had of course to develop a VI driver for the Hilscher card first, whereas the Comsoft card came with ready made VIs. As to accessing the process image of the Siemens hardware, we did not chose to try to do that at all, but instead configured specific datablocks that were used to interchange information between LabVIEW and the Siemens software. It may seem more cumbersome in the beginning, but it is a big advantage if you have a clearly defined interface between the two systems and simply disallow any other interference between the two. It makes debugging so much easier and fingerpointing between the LabVIEW and PLC programmer about who is secretly changing that flag at some point is not an issue.

Yes somewhere around 8.0 or 8.2 they changed the behavior for refnums pointing to the same object. Before that, equality of refnums was merely based on the refnum itself. After that equality of refnums is based on the object the refnum refers to. Since all refnums refer in fact to the same VI (eventhough its instance is in fact different because of the 0x8 option) all of those refnums are considered equal. One could argue that at least for reentrant VIs this should not be true.

Not sure about LV2009 but until 8.6 they clearly went straight to the ni488.dll It wouldn't make much sense anyhow since the VISA interface eventually calls into the ni488.dll anyhow for GPIB devices. But learning VISA is definitely easier than the GPIB primitives and also more useful as you can use it for all other instrument communication too, if you ever happen to need it. The special GPIB features mentioned earlier are almost all also available through VISA and really only used for either very old or somehow non-compliant GPIB devices.

I'm on Win XP SP3 but don't have 2009 installed yet on my main machine which I use to work mostly. And I may not really use the applications where you see that. However I have frequently many applications open and also work regularly in Explorer to move files around, but if I had problems with files appearing locked they were either executables running (Windows allows renaming them though, so you can rename it and place a different executable under the old name although that could crash badly if the paging kicks in), directories locked by the SetCurrentDirectory() issue in the Common File Dialog or DLLs that are still opened in LabVIEW despite me having closed the VI that called them. Sigh!

I know and agree. But I have been guilty myself sometimes to not create to meaningful error messages when developing a new component, but instead use a catch everything single message, of course with the sincere intention to go back and make it all nice and clear, once I have a grasp about what sort of errors can happen in that component. And then when the release data approaches those intentions are just that, intentions. And once inside a product only bug reports or improvement requests (through the proper channels though) will really be effective.

It's not very surprising. Different people have often very different ideas about what is good and bad. We all grow up with this fuzzy idea that good and bad are some absolute state of everything, and fully believe in it. But you can't measure good and bad effectively. The only thing you can measure is if something adheres to some standard who everyone of course assumes to be good. It leaves a shallow feeling about ISO quality certification and all that hype among common people and I think not without reason. It's abstract because it does not match our perception of good and bad, but it's the only way you can measure something objectively. As soon as you start to use good and bad you are in a subjective perception, no matter how hard you try.

They do matter and get managed very effectively in our modern communication environment. To whatever effect the ones who have the interest and powers do want. I think this list shows one thing mainly. Once you are up in the list of the major players there is no way to avoid being called bad by some. As to the original topic which started this thread: NI did word that part about the SP1 release not being for free quite badly. To me it does show that NI is still not a company only driven by marketing alone. As to the question if SPs should be for free or should be only part of an upgrade or paid maintenance plan I do not have a strong opinion. Of course freebes are always nice, but I can also understand that they decided to consider this as a new minor version that requires some form of compensation. It will cost them some legitimate users for sure but I'm sure someone made up the calculation and decided that a new user paying for a license once and then never again has a lower return of investment than one who maintains a support service contract. That is not bad, just business. If you want to change that you have to change the way business is done everywhere nowadays Also this business model gives more room for a competitor to actually come up with a product that could compete with LabVIEW.

We sell mostly services. Not a product or some hot air. And as crelf said the Toyota issue, while showing a problem in the way they handled it, is also for a big part propaganda. Its publicity is a lot about fingerpointing and saying look how bad they are, completely forgetting that each of them had also major issues in the past whose costs went in the billions too. The difference is that Toyota might have a chance to survive this, while many others would have been dead by now.

You can't possibly support an application for indefinite time without some charge. Even if it is a big fix. We do have a warranty period on our software but if a bug hasn't been uncovered in that period then it wouldn't seem a critical bug. Also where do you consider the limit between a bug and a new feature? What if your application suddenly misbehaves because of some changes to the system you could have foreseen logically? Is this still a bug or is this some other thing that warrants some charges? Generally if you work for some production environment those people understand that maintenance has its costs. Computers do get older, system parameters do change, once perfectly running code can get affected by all this. If you do this all for no cost for many years after having delivered a system, you do get into problems with your business plan for sure and you might have actual issues defending your rights towards your customers. Maybe your car gets serviced for free every year where you live and any repairs are for free because the car manufacturer believes that his prodcut should run 10 years without any failure but it is not how things work here. That RPM sensor that failed two times causing system check errors? Well normally charged both times! Does it sound like a possible systematic error? One could argue that way as two times the same error in just 4 years is a bit strange. But it is how business works today.

Wrong! It will be never released! Because there is no way to test every possible permutation until it is actually used. And it gets only really used when it is released! And I'm sure even the famous stable versions like 7.1.1 do still contain lots of potential bugs by the criterion that requests 100% bug free LabVIEW versions.

You want an implementation of the Hayes AT command set as VI library. I have written various code for such things but it all has issues. One is that a lot of that code is copyrighted and I can't just post it here. Other issues are that there is not ONE single AT commands standard. Hayes invented it and various modem manufacturers extended, varied and experimented on it, which means there is not one single way to communicate with a modem but many similar ways. The principle is simple. You issue a command line and receive some answer that contains 0, 1 or more data lines and is always terminate by an OK or ERROR response line. There are various VI examples floating around (Info-LabVIEW, NI LabVIEW discussion forum, probably here too) how to communicate with modems and all of them do work under certain circumstances and with certain modem types but none I would consider a really robust implementation. But they can serve as a starting point for your work. I have considered at some point to write such a library for broader distribution but the issues about non-standardization with various modems, the resulting support issues and the fact that LabVIEW libraries are rather hard to be sold in any way, have prevented me to invest any real time in this.

I really don't think there is. The called VI has conceptually no way of knowing that it is called remotely or not and consequently also no way to retrieve information about its remote caller from anywhere. And the issue is rather arcane as you can very easily design your VI API to include any information you want to pass to the called VI.