Rolf Kalbermatter

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.

Well, LabVIEW has a LOT of error information and much of it has gotten fairly descriptive over time. So part of the problem may actually be the amount of error information that is already there and that makes identifying areas that can be improved a bit hard. Also maintenance of all that information has to be a real nightmare by now.

Just try to open a connection and possibly run a simple query on it. The failure that results when the server is not available should be evident.

Calling the SetCurrentDirectory() Windows API with a path you do not mind to be locked. The issue is that the Common File Dialog function in Windows sets this to the current path whenever it is dismissed with an OK click. So yes it is really a Windows issue. It happens with other applications too, that use the Common File Dialog but you rarely run into that issue there, at least I don't. The actual API seems to have a flag OFN_NOCHANGEDIR that prevents Windows from changing the current directory if the user browses to a different directory during the dialog, but it is not supported before Vista. So NI still would have to inmplement a workaround around the Common File Dialog call, which admittedly shouldn't be difficult, but it may have implications in areas nobody is thinking about at the moment. The other issue with files being locked by LabVIEW that another application opened I'm flabbergasted. Never saw that happen so far.

Please be more elaborate in what you are asking. Which memory is provided by the system when calling a DLL? The memory where the DLL resides in? The memory passed to the function as parameter? Some other memory? What do you want to count?

LabVIEW really does some custom stuff here as it is not Windows common behavior and not even supported by Windows out of the box. I believe what LabVIEW is doing here is simply detecting if another instance of the same LabVIEW version is running (how that is done is another question, possibly a shared global variable in shared memory or such) and on detecting that sending all its command line parameters to the other application instance through DDE. At least that is how it was done in LabVIEW 5 and 6. The LabVIEW DDE server supports passing commands to its system topic since that is the means File Manager used to pass file paths to an application and it is still the way Windows Explorer passes parameters to an already running application when you double click an application file.

No this was definitely something like LabVIEW 6 or even earlier. With ancient I did mean ancient! I haven't even started to do real project work in LabVIEW 2009 yet.

I believe that in order to start and stop a service you need to have administration privileges in Windows 2000 higher. Windows Vista and higher might even require specifically elevated privileges that an administrator account doesn't automatically grant to an executable, but requires an additional explicit User Authentification as administrator. It would be strange that CMD.EXE itself is requiring elevated privileges but it is the service manager start and stop command you try to execute in CMD.EXE that is barking on the to low privileges you have as normal user. .Net can't circumvent the privilege level control for the service control manager but it might have extra support to allow temporary privilege elevation for the current executable for execution of service control manager commands which would require at least the according admin login credentials somehow (and if they care about security it won't be a programmatic login but an interactive login).

I've seen that happening in the past with some application a few times. Not sure what was the fix as it is quite some time ago and involved an ancient LabVIEW version. I guess moving up to a newer LabVIEW version was the fix for that for me.

Yes the flattened data only contains the actual variant part of a control and not its invariant data type information at all. The Unflatten from String did not really take a type descriptor as it also needed to know the final data type at edit time. The Flattened String to Variant does take such an input but the entire type descriptor business got internally completely redesigned with LabVIEW 8 to avoid the problem of the 16 bit size limit for old style type descriptors and NI decided at that point that they are not going to expose the new 32 bit safe type descriptors to the LabVIEW diagram in any way. The old 16 bit type descriptors are still exposed since they are used in the OpenG Variant tools and many other projects but do crash on type descriptors exceeding the 16 Bit size limit.

Please post such questions in the future in the applicable section (External Code). The LabVIEW application Builder recognizes DLLs as dependant files and includes them into the build when creating an executable. The OpenG Builder might not do that. An additional feature of the LabVIEW application Builder is to also adjust the location of the VI Paths AND DLL Paths in the compiled version for the build application which the OpenG Builder might also not do for the DLL Paths. There is certainly a possibility to improve the OpenG Builder to also care about DLLs properly but that is not for the faint hearted. Once LabVIEW does not find a DLL where it expects it to be it tries once more in the directory where the project file is located (obviously not applicable for executables) and then simply passes the request with only the DLL name to Windows and then the standard search criteria of Windows apply: 1) already loaded into the application memory 2) the executables directory 3) the system directory 4) the windows directory 5) any directory mentioned in the PATH environment variable So your options would be several depending at which stage you want Windows to find your DLL. 1) Create a specific loader VI that locates the DLL and loads it into memory and also stays in memory and is run before your driver is loaded 2) - 4) copy the DLL in the according location 5) modify the PATH environment variable to point at the location where your DLL can be found

RTFM or in this case the online documentation. It is written in there for the table control.

Another problem I have seen repeatedly with people complaining that the constructor is not available in LabVIEW is when they try to use static objects. That are objects that do not need nor can't be instantiated to work since they do not hold onto any local data for their operation. For instance mathematical function libraries that always take all their data as method parameters. LabVIEW simply allows to call static objects by selecting them into a refnum and then selecting the methods for those objects in a method node.

You could help potentially others who might use the search function before posting, by posting an explanation of what caused your problem and how you resolved it, rather than just posting that you solved the problem. This last information is more or less meaningless to everyone here as it is not our problem so if you solved it or not has little importance to us, but how you solved it may be very interesting and helpful to others.

Knowing a bit about production quality insurance I think you are right that he did the work mostly on his own time, but that committing it to be part of an upcoming release, takes usually a multiple of the time, the actual development took. I can add most features to software in a very short time, but having them tested, documented and tested again, takes usually up a multiple of the time that was needed for the actual development of the feature.

While there is no consistent implementation of refnums in LabVIEW there is one specific thing an LVRefNum has always been, and most likely stays in 64Bit too, and that is its implementation as a MagicCookie as shown in the LabVIEW CINtools headers. Here you can see in extcode.h typedef uInt32 MagicCookie; completely independant of the bitness of LabVIEW so it seems to be a safe assumption for now that the data part of refnums correspond always to a 32Bit value. There is of course a wrench with this, since the so called Tag based refnums, like VISA, DAQmx, etc refnums also consist of a string part identifying the actual resource a refnum refers too, but even those refnums use internally a MagicCookie too.

LabVIEW doesn't tinker with TCP/IP options a lot. It sets everything that is needed to make asynchronous sockets work reliable and leaves the rest at whatever the OS chooses to create a socket with.

I wonder if the LabVIEW General board should be locked for newbies to create new threads in. Almost everybody seems to post nowadays only there creating a long stream of completely unrelated topics in it, while most of the topics clearly belong into one of the sub threads in LabVIEW (By Category).

Why is everybody posting into LabVIEW general nowadays. This and most other topics here are clearly posts that should have been placed in the relevant thread under LabVIEW (By Category)! Just because it doesn't crash during debug run does not mean everything is right. The symptoms you describe clearly point into one of these directions. 1) You have setup an output parameter (a buffer parameter where the DLL function is supposed to write data into, such as an array or string) but forgotten to allocate memory for it before passing it to the function. While LabVIEW's automatic memory management takes care of everything as long as you stay in LabVIEW, there is no way for LabVIEW to know how big a buffer it should preallocate when calling a C function. Therefore it doesn't and relies on you to do so. You have two options here, in LabVIEW 8.5 and higher you can define the minimum size of elements LabVIEW should allocate for such a parameter in the CLN or you can do it explicitedly by using the Initialize Array function. The reason it doesn't always crash is that by not allocating (enough) memory for the buffer, the DLL function will write into some memory area anyhow. This can overwrite information that is vital to LabVIEW but sometimes also information that does not immediately lead to a crash. In an executable most diagram and other information removed and only the runtime data remaining, chances are higher that it will touch vital data so a crash is more likely but that is not a rule. It can also be opposite, or depend on the moon phase or anything else rather esoteric . 2) You configured the parameters not quite right. 3) You pass data to the DLL that trigger a bug.

Calling C++ functions gets nasty if you have several variants of the same function with different parameters since you have to figure out which decorated function name you want to access for a particular parameter version. And the decoration while logically corresponding to the parameter list, is anything but easy to decipher (and varies between C compilers too). Accessing methods and member elements of objects will only be doable with C wrapper interfaces though.