Rolf Kalbermatter

QUOTE (Jim Kring @ Apr 2 2008, 02:57 PM) I think your reasoning is way to general. There are functions that might benefit reasonably well from subroutine priority but many others that will see little benefit in typical applications. The first could be some of those little helper functions such as Valid Path. The latter would be for instance things like Delete Recursive and such. It's all about is it a function that takes always little time to execute and is likely to be called inside loops many many times. If not the advantage of a little faster execution is IMHO not at par with the disadvantage of causing possible problems that might be also hard to debug since debugging of subroutine VIs is not possible at all. In general speed of an application is not lost in the calling overhead of VIs at all but in the type of algorithme used and even if calling overhead of VIs can add some significant performance loss it is probably about much less than 5% of the VIs that can significantly add to the performance by reducing their calling overhead. Penalizing the other 95 to 99% of the VIs for that is not a good option for me. Rolf Kalbermatter

QUOTE (pallen @ Apr 2 2008, 10:39 AM) Yes if you run the application hours and hours they will eventually be called million of times but with very very often I meant millions of times in short time (seconds). Anything in the context of UI should not be optimized in terms of microseconds but rather in the way it is done (more optimal algorithme to prepare data, avoid huge memory copies, defer panel updates during bulk UI updates, etc). Rolf Kalbermatter

QUOTE (pallen @ Apr 2 2008, 08:25 AM) I don't think they qualify for the "very very often called" item. At least not as I design them. If there is an operation that would require that functional global being called millions of times inside a loop I usually create a new method that does that particular operation inside that functional global instead. That should take care of that. Rolf Kalbermatter

QUOTE (Jim Kring @ Apr 1 2008, 04:29 PM) Well it's all relative. Now with LabVIEW being always multithreading even inside a single execution system the negative effect of subroutine VIs is not as dramatic as it used to be in old single thread LabVIEW days. At that time subroutine priority was specifically reserved for small VIs that could be relatively quickly executed. LabVIEW optimized the calling context in such a way that there was very little overhead in calling a subVI similar to if the VIs diagram would have been directly embedded in the caller. This could lead to rather huge speed improvements because the calling overhead and the chance for memory copies could be greatly reduced. At the same time while a subroutine was busy NOTHING else in LabVIEW could be going on, since that subroutine exclusively blocked the one single thread LabVIEW had at that time. So if you did that to a lengthy function, LabVIEW could seemingly freeze entirely. With Post LabVIEW 5 multithreading this setting has both been less important as well as having a lesser bad inpact even for lengthy functions. Since there are many threads LabVIEW is using even a blocking subroutine will not block the entire program (unless you happen to run the subroutine in the UI system). At the same time LabVIEW has made many memory optimization improvements so that the advantage of a VI being sort of inlined does not likely yield a big effect there anymore. What remains is the reduced caller overhead for a subVI. So the thumb of rule would be: Use subroutine only for very small subVIs whose execution speed is rather short and that gets called very very often. Because for a VI that takes 1s to execute shaving of a microsecond in calling overhead is simply useless, but if that subVI itself only consists of a few LabVIEW primitives taking up anything in the order of 1 microsecond to execute, adding another microsecond for the calling overhead will be significant. But even then if you do not call that VI millions of times inside a loop it is not likely to buy you much. Rolf Kalbermatter

QUOTE (mattdl68 @ Apr 1 2008, 07:40 PM) This discription does not sound completely right. I don't remember having had to parse the string for VID and PID. Unfortunately my sources won't help you to much since they are for a specific device. There is however enough code to show you how it needs to be done. Search for usbhidioc on the net. I've used a Visual C 6 version as inspiration. Specifically http://www.lvr.com/hidpage.htm and there halfway down Visual C++ 6 section. You won't get around installing the WinDDK from MS I'm afraid, unless the newest PSDKs come with the necessary definitions too. In that example you find the actual code to search for a HID device in usbhidiocdlg.cpp/CUsbhidiocDlg::FindTheHID() The code in that function in itself is just standard C but the project is in C++. And no I will not even consider to look into the possibility to call these APIS directly from LabVIEW with the Call Lbrary Node. It's very very maybe possible but it will be such a pain that even if you have to install and configure an entire C environment and have to learn C too it will not be less painful and time consuming than getting you to the point where such a direct LabVIEW interface would work reliable. Rolf Kalbermatter

QUOTE (Götz Becker @ Apr 1 2008, 04:26 AM) That doesn't load as project. And just looking at the subVIs itself won't show any leaks for sure. Rolf Kalbermatter

QUOTE (mattdl68 @ Mar 31 2008, 12:47 AM) For HID devices I do not think you can use MAX at all and it doesn't make to much sense either as you would have to implement the HID Class protocol again in LabVIEW using VISA Nodes. HID devices are well known to Windows and it will claim them and VISA won't really be able to hook them if I'm not mistaken. Instead you will need to go the Windows API route as you have started out but that is not for the faint at heart without some fair C programming knowledge. So what device is it you want to access? Because I do not think VISA USB Raw is gonna help and the Windows API is likely at least one league to complicated for you. Even if you manage to access the Windows API for the HID device this will not be your end of the troubles. HID itself is also very basic with just a bytestream for read and write. How this bytestream needs to be formatted (usually binary) will be another problem to tackle and without proper documentation from the manufacturer likely not possible. Doesn't the manufacturer have a DLL to communicate with that device already? That would reduce to problem to interface that DLL and get its documentation. Rolf Kalbermatter

QUOTE (neB @ Mar 31 2008, 08:45 AM) God am I lucky to have disabled that. I have one VPN adapter, several VMWare virtual networks, a Wireless network and a built in 10/100/1000 MB network on my computer. That would probably cause nilm.exe to go completely nuts :thumbdown: Rolf Kalbermatter

QUOTE (Michael_Aivaliotis @ Mar 30 2008, 05:49 AM) Ok I just checked. lmgrd.exe is the actual service that you have just disabled. nilm.exe is also part of the license manager but not exactly sure what it does. All I know is that LabVIEW has it's own copy of the FlexLM license manager integrated and apparently does all the license checking directly itself through that. Not sure why there would be an nilm.exe ever nor what the lmgrd.exe service would be good for other than for volume license situations. Also haven't found any official information from NI about that and as long as it works without I just won't start it up. Rolf Kalbermatter

QUOTE (orko @ Mar 29 2008, 07:54 PM) I'm not really sure but I think for a single dev workstation it is not needed at all. That is of course a different story if you use a volume license or distributed license. Here I would assume the license manager service is required to allow connecting to the license manager that would be running on some central system. But yes NILM does not really do anything on my system it seems. I have it on manual startup since LabVIEW 7.1 came with it and never had problems with activation or whatever. All I noticed is that it creates sometimes temporary license files in the license folder when LabVIEW starts up. But it seems to work and that is the only thing that counts for me. In your typical Windows system there are countless services that do virtually nothing. It would be nice to clean them all out but researching that matter is a work with no end and at the end of the day I need to do some work to justify my salary too. Rolf Kalbermatter

QUOTE (Michael_Aivaliotis @ Mar 29 2008, 04:30 PM) Control Panel->Adminstrative Tools->Services Then in there look for the NI License Manager Service, select it and in the dialog select Stop. And set it's startup type to Manual to prevent it from restarting at the next reboot. Rolf Kalbermatter

QUOTE (Michael_Aivaliotis @ Mar 29 2008, 04:12 AM) It's the NI License Manager process! Are you sure you have no illegal LabVIEW Vis on your computer and the license manager is phoning home?? :ninja: I've shut it completely down since LabVIEW 7.x already and never have noticed that my LabVIEW licenses wouldn't work. Apparently the built in LabVIEW license check has a fall back to read the license files directly from disk. But to know that about 1MB from the labview.exe file is actually this built in license manager kernel, feels a bit well... Rolf Kalbermatter

QUOTE (Tomi Maila @ Mar 28 2008, 07:56 AM) Ok I'm assuming that you use the Call Library Node and call a DLL with exported standard C functions here. ActiveX and .Net DLLs are an entirely different beast and not my real speciality. Although there are two ways to locate a function in a DLL (static linked import library vs. dynamic linking through LoadLibrary/GetProcAddress) the rest of this story is all the same for both, except that dynamic linking allows the linking application (or DLL) to specify an absolute path for loading a DLL and that will fail the load if the DLL is not located there even if it could be found in other default search locations (except I believe if a DLL with the same name is already loaded into the current process image). So when Windows gets a request to load a library (either through LoadLibrary() without absolute path or implicitedly through the import table of a statically linked import table inside an executable or DLL) it will look for that DLL in following places and search order: 1) DLL already mapped into current process with same name 2) The directory where the current process was started from (aka where LabVIEW.EXE or YourApp.exe is located) 3) System Directory (often called System32) 4) Windows Directory (sometimes also called WinNT) 5) Any directory present in the PATH Environment variable for the current user Now LabVIEW does do a little more than just passing the DLL name itself and remembers the actual (relative) path of a DLL inside a VI and first tries to load that DLL with the resulting absolute path. If that fails because the DLL is not there it tries it again with only the DLL name. That is why it can work for the application builder to put support files including directly called DLLs into a data subdirectory inside your application directory. LabVIEW does remember that relative location and will try to load the DLL explicitedly from there first. However there is no way short from scanning the import table of a DLL to find out if it has other dependencies and I'm not aware of any application or programming environment that would go to these lengths ever. So while you could put your directly dependant DLL into a data subfolder inside your application you can not really put dependancies this DLL has into the same folder since here only the Windows standard search order will be used and that would mean it can't find the DLL at all. However by putting all those DLLs (and most probably your directly called DLLs too for the simplicity and clearness of it) into the same folder as your executable you can quite simply ensure that your application will always use the DLLs it was designed for without clashing with other versions of the same DLL. You could try to trick LabVIEW into explicitedly loading those DLLs too from a subdirectory directly by adding a dummy VI to your startup VI that references those DLLs directly without ever really calling them. That way when your own DLL that depends on these DLLs is loaded, Windows will find them already mapped into memory and not look any further. But that can be a bit tricky because you do need to know the exact dependancy tree and start to load the VIs referencing those DLLs in the reverse order of the DLLs in order of their dependancies. Not a big problem if the dependency is as you draw it but it can get tricky if those subDLLs also have dependancies on each other. Personally I have never felt the need to do such tricky stuff but instead just throw all the DLLs into the same directory as the executable. Yes it clutters that directory a little but hey it's quite common to have a few DLLs in the executable directory of nowadays applications. Of course for your development machine or when you would want to distribute the VI library for development to others, things could get a bit more tricky. Since you do have a custom DLL already you could try to make those sub DLLs loaded explicitedly from the same location as your DLL itself is loaded but that would mean that you would have to reference your A.DLL from inside LV_A.DLL completely dynamically and also wrap every direct A.DLL import into your VI library through LV_A.DLL making it call A.DLL dynamically too to ensure that the DLLs are loaded properly already before A.DLL gets loaded and Windows tries to satisfy it's direct imports. Quite a hassle indeed. So here again the most simple approach would be to just drop everything into the LabVIEW root folder (since your LabVIEW.EXE that is starting your LabVIEW development process is located here). Alternatively you could consider telling people to put it in system32 if they want to develop in LabVIEw with yout library but you will have to make sure to document to them how they need to adjust the built process to make sure those DLLs get added as support files to the built and to make sure to put them into the same directory as the executable itself. PS: you are not by any way incorerating something that is using the Apache Runtime Library Support? Although I didn't think that was LGPL. PPS: And no there can't be only one DLL of the same name in memory at once at least technically spoken. The limitation is that only one DLL with the same name can be mapped into a specific process space. A differnt executable and therefore different process space does reference it's own DLL version and if the paths do not match it will be two different DLLs loaded into memory, one for each process. Rolf Kalbermatter

QUOTE (Phil Duncan @ Mar 28 2008, 01:21 AM) I think the distributed architecture is fairly easily sovable with things like VI server or your own little TCP/IP protocol. What will be a challenge is to make your calculation algortihme distributable and decide on a manager component architecture that can handle this properly, and here everything will be very specific to the problem you are trying to solve. So even if someone has done this already it's not likley that you would gain much by looking at it. The main work will be in the part that decides how to distribute the subsets to possible clients and how to integrate the actual results back together. The actual data transfer to and from the clients could be as simple as one or two VI Server calls and the client itself won't be much more work. And a little TCP/IP server in the manager for the clients to connect to and advertise their availibity can be easily adapted from one of the TCP/IP examples that come with LabVIEW or if you want to do robust TCP/IP go with the template that you can get from www.labuseful.com. Rolf Kalbermatter

QUOTE (jcabrer @ Mar 27 2008, 10:53 AM) There is something fishy about this, and considering that I use LabVIEW quite a lot in such scenarios without seeing this I would have a hunch that it is something you are doing that causes this, and not a bug in LabVIEW. Show your code and we can look at it. Rolf Kalbermatter

QUOTE (Tomi Maila @ Mar 27 2008, 11:02 AM) It's not a very good idea to install Open Source DLLs globally exactly because of the version problem and the fact that many Open Source projects reserve the right to make binary incompatible changes to the API even between minor versions. So someone else installing a newer version might break your app too. Instead copy the DLLs in question into the main directory of your application. That will always make your application use the version of the DLL it was built for and avoid any conflicts with other applications that might use a different version of your application, even if some other application had the great idea to install a newer and possibly binary incompatible version in system32. For .Net DLLs the GAC and the main application directory are really the only valid directories although LabVIEW allows to link to .Net DLLs by path name, but that will usually bring you into problem when distributing your app or otherwise when upgrading between LabVIEW versions, since they still try to figure out the best way to deal with that issue. It may sound a bad advice because DLLs were meant to avoid code duplication on the disk. But it is the way Microsoft also deals with DLL hell in .Net and considering nowadays harddisk sizes saving a few MB of HD space is a very bad excuse to turn yourself into dealing with DLL hell. And are you really saying that you are linking Open Source DLLs statically in your app? I find that a very bad idea unless you have some strong interest to hide that you use such DLLs. But even that usually won't work since the most popular license that would allow that (BSD) does require you to credit the use of such software in the doc and application such as in a splash or about screen. Rolf Kalbermatter

QUOTE (Yuri33 @ Mar 27 2008, 10:44 AM) The simple Numeric has not a separate housing and text area. That makes it impossible to replace the housing with the system style frame since it isn't there. Taking a normal numeric instead and replacing its housing should work although there you have additional troubles with the increment and decrement buttons and making the housing and numeric text box area match nicely in size is a bit of a hassle too. Rolf Kalbermatter

QUOTE (jccorreu @ Mar 27 2008, 06:04 PM) LabVIEW 8.x definitly has some improvements for this. Not sure about the Compare tool itself, but with the new projects you can have two different projects loading different VIs with the same name at the same time. The global address name space is now not LabVIEW global anymore but only project global. Quite some of your problems will go away with 8.x and specially 8.5. Not sure however if you can compare two different projects completely. Rolf Kalbermatter

QUOTE (reemon @ Mar 24 2008, 04:25 AM) I can be very short with this: Of course can you access this from LabVIEW. It has an RS-232 connection so using VISA functions will just work. However: LabVIEW does not come with a ready made GSM protocol driver. And it wouldn't be feasible to do so since each GSM modem comes with its own flavor of AT command set. To get up and running quickly it might be interesting to look at a GSM driver toolkit such as http://www.citengineering.com/pagesEN/products/sms.aspx or the one from VITech. I know that our toolkit was developed for the previous model from Wavecom so it should probably work without hassles with this one too. For the rest I can only echo the recommendations you got from Tomi. Your post does not make itself very attractive to be answered. Rolf Kalbermatter

QUOTE (Yuri33 @ Mar 25 2008, 11:26 AM) I'm not 100% sure if subarrays are passed through subVI boundaries but there is no reason why this couldn't be done. The information if it is a subarray or a normal array is in the wire typedescription and a subVI has access to that. The only case where this needs to be converted into a normal array at all times for now, is when it is passed to external code (shared library or CIN) since there is no documented way to deal with sub arrays. In fact CINs do have access to the typeddescriptor too for all parameters (SetCINArraySize() and GetTDPtr() which is internally used in SetCINArraySize() is proof of that) so in theory it could be already done but since subarrays are not documented, there is no way to do that for non-NI programmers and therefore NI has to pass this always as normal array (except they could add an additional CINProperties() attribute telling LabVIEW if the CIN is subarray aware). But since CIN is a legacy technology for a long time which NI tries to completely move away from I do not think they even considered that possibility. Rolf Kalbermatter

QUOTE (Tomi Maila @ Mar 24 2008, 12:30 PM) Well, option 1 I assume is not yet possible since there is no way to pass type descriptor information along with the handle itself. Option 2 would require a new datatype that contains all that information including the pointer to the original handle and data pointer even for arrays that are not really subarrays. Lot's of work for little benefit I would think. Rolf Kalbermatter

QUOTE (GorionQuest @ Mar 23 2008, 06:11 AM) Make that 10 bytes: float: 4 byte, float: 4 byte, short: 2 byte, together: 10 bytes. Otherwise you are corrupting memory during the MoveBlock call. Rolf Kalbermatter

QUOTE (Aristos Queue @ Mar 22 2008, 10:06 PM) And if you think about it this can't be any other way. There would need to be a way to detect in the external code that it is a subarray instead of a real array and some documented memory layout or access functions to deal with that array. both do not exist until now since the information if it is a subarray or not is in the diagram wire typedef, not in the data pointer. Rolf Kalbermatter

QUOTE (Yen @ Mar 1 2008, 02:32 PM) If you integrate something covered by the GPL into a project it usually makes the whole project being covered by the GPL. Specific provisions such as an amendment to the GPL for the Linux kernel being excluded. To be able to integrate libraries or subcomponents that are desired to be GPL like licensed without making the rest of a program being GPL too there has been specifically the LGPL license created for. This allows including LGPL licensed components in a dynamic way into another application which can be of any other license including fully closed source. Purists claim that even calling a GPL based application over the command line explicitedly from inside another application is forcing this application to be GPL too, but I think that is a completely useless restriction and most likely not enforceable at all. Rolf Kalbermatter

QUOTE (sara @ Mar 22 2008, 06:15 AM) Don't use two single channel timed acquisition operations. Either use untimed ones (single read) or multi channel timed acquisitions. Rolf Kalbermatter