Rolf Kalbermatter

The biggest problem is about trying to tackle this without having a fundamental understanding of C and memory handling in general. 1) yes 2) 16 times 7 times 2 bytes, plus some LabVIEW dataspace for management of the array but you do not want to pass the LabVIEW array to the C function but the C pointer to the array. Only specially written C code can directly handle native LabVIEW arrays and strings. 3) Code Interface node is an old legacy technology to incorporate external code in LabVIEW. It is only present in some of the LabVIEW platforms nowadays and completely missing on any 64 bit versions of LabVIEW and also all realtime targets. LabVIEW ceased to ship with any tools that were necessary to create CINs many versions ago. 4) You can return data from a function through its parameters and are not limited to the function return value. Also it is good courtesy to mention that you have crossposted this in the NI forums already. The LabVIEW community is not that big that nobody would notice, but it helps others to see if they should spend any time to provide an answer that was already given elsewhere to the same person.

From what I could see on the website they are mostly into high end hardware for space/defense/airplane industries and there USB doesn't really fit into very well in terms of reliability and harsh environment resistance. Haven't seen any prices but it would not surprise me if their price is in the same range or higher than NI.

Except that when you follow the link from Dave's post you get to a page which looks like the card he is talking about and in red letter New Product! afterwards. After about 8 years it would seem a little strange to still claim it's a new product. CPCI isn't as quick paced as general computer technology but that slow!!!!???

AVI is really only a container format and mostly meant by Microsoft to be used for real world video. What format the data is actually written in depends highly on the available codecs on your machine. Most likely it won't support U8 and/or greyscale without installing a very specific codec that supports such a format. And if you created such a formatted AVI you won't be able to replay it on machines that have not the same codec installed. The Windows AVI interface correctly changes the format to an available codec format that, at what it believes at its own discretion is the closest match to the incoming format. If you check the format of the resulting AVI file with some AVI file format checker you will see that it is already RGB when written on disc and the reading will simply read in what is on disc and has no way to magically know that it should convert it back to U8 greyscale.

The Blogs seem to have gone and I wonder if there is still any way to access their content other than trying to find them in the wayback machine.

BSD is a very permissive license and as such should not pose any problems. In fact the Open Source license usually only really matters for reuse libraries. This being a tool it is of less concern, even GPL (with a small exclusion clause that the SW may also be used within the closed source LabVIEW application) would work as all it disallows is to use the SW library for derivative works without releasing the entire source code of said derivative work. As a plugin for LabVIEW with aformentioned exclusion clause there is not really much you would take away from potential tinkerers with your tool/plugin. That said I usually use nowadays BSD for anything I want to make available as Open Source since it is the most simple license IMO. GPL and LGPL are about umtien pages of text now, that even lawyers disagree about what it all means

Most likely this is Excel itself that is doing this. While loading the data file, imagine what would happen if another application is at the same time writing to it. This could result in inconsistent data being read during the loading process so Excel simply disallows write access for other applications during loading (and probably fails the load if another application has already opened the file for write access). After the file is loaded and all data is safely in memory, Excel probably simply closes the file altogether or at least resets the DENY rights on the file. The read only settings when opening a file is not so much how Excel opens the file itself, but an internal setting of a workbook that disables editing of that workbook.

It shouldn't. But then without seeing what your working Java application does, or how your Android app does setup the communication, it is mostly poking in the mist as what might be required to make this work with LabVIEW.

Well, theoretically you could use TCP/IP, UDP or even some other low level protocol, so yes you should be more specific! "I want to go to New York" is usually not enough for someone to help you come there. It's quite helpful for that person to know if that should be by train, airplane, ship or maybe rocket and if you start in Paris/France or in Washington DC. If it is TCP/IP or UDP you can do it in LabVIEW but the principle does differ somewhat since one is a connection based protocol while the other is not. Assuming you use TCP/IP you would simply look in the Example finder for the "TCP Communictor - Passive" example, open it, configure the port to what you have and start it then run your Android app. Obviously you would have to tell your app which IP address your PC has. If it is UDP you rather want to look at "UDP Receiver" in the examples. And if it is something else than TCP or UDP you won't be able to do it in LabVIEW native but will have to interface to the OS socket library through Call Library Nodes to do it.

Are you using TCP, UDP or some other transport protocol? If you use TCP or UDP you will look into the respective function palette in the Data Communication->Protocols palette.

There is another problem about the question with clusters. It is not very specific as to what is wanted. Should it be a cluster where each element in the cluster is matched with a column in the database table? If so should it be matched based on cluster element name matching the column name or rather its ordinal value in the cluster match the row number? What about if the cluster doesn't match the rows in either case? Or is it about storing a cluster as binary blob in a single column? Questions, questions!!!!

Well yes but the CWD is a broken concept for multithreaded applications anhow. So why trying to risk anything aside from that changing this path might break some other broken implementation elsewhere in your application, like in a third party DLL. The best solution is to make sure that the DLLs are put in a place where Windows will find them, that would be most likely a directory in the PATH environment variable in the development system and the application directory in a built application. If you absolutely need to trick Windows, I would do it a bit different. Just call LoadLibraryA() with the library path where you now call SetCurrentDirectory(), That loads the library into the process and then Windows will hit that library name in my earlier list in step 1) already. Achieves the same, requires also just one Call Library Node but avoids potential race conditions and breaking other compoments that might rely somehow on CWD being set in a certain way. Just make sure to not call LoadLibrary() many times, and strictly speaking you should also FreeLibrary() but unless you work in a plugin situation where you might unload the plugin sooner than later, it really doesn't make a big difference if the DLL remains loaded in the process until the application is quit.

I would consider modifying the current path (CWD) to achieve this not only hacky but really a potential race condition in a multi-threading system like LabVIEW. There are various Windows APIs which will themselves modify the CWD internally with the File Dialog API being one of the more prominent ones and there is definitely a chance that something else in the application might call some functionality that changes that path between the time you call SetCurrentDirectory() and LabVIEW gets around to load the library. That's admittingly a small time window, if you program your VI right, but the sheer possibility of this makes me run away from this solution.

It's not LabVIEW which is searching the dependent DLL but Windows. LabVIEW only knows about the DLL that you reference in the Call Library Node and nothing else. It asks Windows to load the DLL and the Windows loader then finds in the DLL references to other DLLs and tries to load them. For that Windows uses a predefined search strategy and looks in following locations: 1) if the same DLL is already loaded in memory it uses that 2) in the application directory (that is the directory where LabVIEW exe resides for the development system and yourApp.exe for a compiled application) 3) in the Windows directory 4) in the system directory 5) in the current directory (typically the directory where your application was started from but also the last directory in which the File Dialog box was positively dismissed inside your application) 6) in any directory that is named in the PATH environment variable Put that DLL in one of these directories (and make sure to include it in any build of your application too) and things will work.

Already reported it

Just a small note: I was only marginally involved in this library. The main developers were Jim and to some degree Heiko. I had at some point made my own version and likely posted them on some forum but if anything it only served as some inspiration for this library. Looking through my archives I found this library which is already quite old and not very well tested if I remember correctly. But it did implement the HTTP1.1 protocol including the HOST field. The top level VI is meant to be HTTP Site Downloader but I never got around to implement the actual parsing of the HTML document and adding its contained links to the download queue. But it serves as a good idea how the HTTP Parse URL and HTTP Download Link are meant to be used. And yes it does not implement authentication either. I find basic authentication useless and the digest was a little bit complicated although I meant to get around to implement that eventually. It's LabVIEW 6.1 but should still be loadable by LabVIEW 2013. HTTP.zip

Your DLL depends on an SxS assemby that is not installed on your machine. Most likely it was compiled with Visual C++. You need to find out what version of Vsual C++ was used to compile your DLL and then download the Redistributable C Runtime Library for that version from Microsoft. More generally the manufacturer of your DLL should have provided you with an Installer for the DLL that takes care about installing the DLL on your computer and also install all the necessary dependencies it has.

I'm not sure I understand the entire problem here. You may have to consider different file types differently. As long as you do not have any VI open, even if your project is loaded, just changing the VI on disk shouldn't cause troubles with LabVIEW remembering any old VI code. This assumes that the VI names and/or path don't change. You should be able to simply do a revert or branch without any strange influences. When you then open the main or any other VI from the project you should be fine. If names and or paths change, things get more complicated. But assuming that the GIT repository state was consistent at the moment the reverted or branched situation was taken as far as LabVIEW is concerned, this would also mean that the lvproj file and lvlib files have changed, because these are were the actual paths are recorded for management reasons. So if your GIT operation changes any of these files then yes you will have to find a way to reload the project and/or libraries that are affected. So if you have a way to determine that such files have changed you could attempt to do a smart reloading. Otherwise it would seem the safest option to reload the entire project every time you do an action that could potentially change the project and/or library files under the nose of LabVIEW.

It's more complicated than that. When you only have the project open, no VIs are actually loaded in memory. But the project remembers all the linkage and you get into conflict hell when the location of any of the VIs changed. LabVIEW is in that respect very special as each VI is in fact its own dynamic loadable library module. You get the same DLL hell issue when you deal with multiple DLLs but this is a problem that happens at deployment of the traditional application only, not during development. Basically in conventional programming environments you do not have any dynamically linked modules like in LabVIEW. Each source code file is its own entity only loosely coupled by the name of the symbols and also only at the linker stage. The compiler does not care about if module x uses function z from module y or if that function is rather located in module xyz. Only the linker tries to fit everything together and complains if it can't match a required import to any other export symbol in the combined object files. All source code control is build around this typical scenario, not about a strongly linked system like LabVIEW is using even at development time already. Should LabVIEW adopt a loosely linked scheme like C does? Most likely not. They used to have a much less strict system before projects got introduced. LabVIEW simply matched a VI reference to the very first VI it could find on disk with the required name. That was in several ways easier to deal with than the current project approach that remembers also the exact location of each VI as it was last used and gives you conflicting items if something has changed. Quite a hassle to resolve when you know you moved a VI library on disk for some reasons. However the situation with the less strict system before projects existed caused many headaches and undesired cross linking by not so experienced LabVIEW programmers, and even many experienced LabVIEW progammers run into a mess at some point sooner or later. So the problem here is that LabVIEW has several reasons to do as it does but that all the source code control systems were never really designed to deal with these specific requirements that LabVIEW poses. You could just as much claim that it is the SCC's fault than LabVIEW's but in reality it is neither's fault. LabVIEW has certain requirements born out of of certain expectation in how it was designed to work, at a time SCC was itself in its infancy and CVS was about the highest of the feelings you could get in that area. Requiring LabVIEW to change its paradigmas to work better with modern SCC systems is not really a realistic expectations. At the same time NI is not likely going to develop its own SCC system that is specifically adopted for LabVIEW's quite unique requirements. Bigger fish than NI have failed catastrophally in that area, or is still anyone on this site forced to suffer under Visual Source Safe??

Imaq USB Init.vi sounds a lot like a VI from the unsupported IMAQ for USB Webcam addon that NI has made available many years ago. This functionality has been fully integrated in the IMAQdx Image Acquisition interface in modern LabVIEW versions. Integrated meaning that the DirectX interface that most USB cameras support is now available in the standard IMAQdx Acquisition VIs, not that it provides you the exactly same VI names. Simply use the IMAQdx Open Camera function to open a connection to the camera. IMAQdx is however a licensed software which requires activation. If you want to keep using the older IMAQ interface you will have to find the IMAQ for USB camera drivers on the NI site and install it in your LabVIEW yourself. It's unsupported and there is no guarantee that it will keep working in never LabVIEW versions.

Well, one big advice: Try to avoid merging as much as possible. Unlike with text sources where there is often automatic merging possible and you only have to glance over it to make sure nothing stupid has been done, graphical merging is still a fully manual job. The merging tool shows you the differences and lets you decide which changes should be copied into the master but it will not do any automatic merging. That alone is a big incentive to only really merge if there is absolutely no other way around it. We have found that it is easier to ensure that no two people are ever working on the same VI to avoid the merging hassles afterwards. Graphical merging is still in its infancy and I'm not even sure there is an easy way to reach the same level of automatic merging than with text sources. Text is fairly one dimensional in structure, while graphics are at least two dimensional and in the case of LabVIEW in fact more like 2 1/2 dimensional. Automatic text merging can still suck too, if two developers happen to make changes to the same text lines, but for LabVIEW merging the smallest unit of measure for automatic merging is still a VI.

There is very little you can not do in LabVIEW. But the architecture you describe is not something that will be trivial to build. Are you planning to write your PHD about distributed cloud computing or rather the imaging aspect you described? The system you describe could easily be a whole PHD on its own and then some more. As long as you keep everything in LabVIEW, what you want to do is somewhat manageable but still a big task.Obviously because of your idea about distributed computing you will need to keep its communication network based. A fairly quick and maybe a little dirty approach would be to directly use the VI Server interface, with which you can control local VIs as well as VIs on any other computer that has LabVIEW installed and is accessible through a TCP/IP network connection.

Well, I can't make any promises. The function is in the sourceforge repository and as such available for download if you use SVN directly. Building packages is an entirely different beast, which I haven't done so far and also don't really know how to put it up on the VIPM accessible download locations. It's also not very efficient to release a new package with every little change. There are other bug reports with other OpenG packages and also improvement requests, where there hasn't always been reached a broad agreement on how to solve it. Those likely would need to be consolidated and cleaned up as well, so there could be one single combined release of new OpenG packages.

crosspost here http://forums.ni.com/t5/LabVIEW/kml-file-on-google-map-on-labview/td-p/2861286

The second is not really a bug. The End of Line constant on Windows is rn while when entering multiple lines in a LabVIEW string LabVIEW uses a single n only, except one explicitly enters the rn sequence. So the rn does not occur and therefore won't cause the string to be split in multiple elements. Enclosed is a first attempt at fixing the "ignore duplicate delimiters?=TRUE" case. String to 1D Array.vi