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

A very nice and helpful bit of information. Thanks a lot Although I never thought of those as copy dots I have to admit that while I fully well know the concept of subarrays I didn't always think of them being used in those cases. Rolf Kalbermatter

QUOTE (jlokanis @ Mar 21 2008, 08:29 PM) Actually if you talk about VIPM that is another story. It is not a VI library but quite a useful tool. There is probably some market for this but it will be very difficult to generate enough sales for that to even pay for the maintenance of that product. QUOTE Actually, I am looking at taking the same path. As you mention above, this wheel is been reinvented many times... Ouch! I started this back in around 1996 for a customer project where the NI SQL Toolkit couldn't interface to their own proprietary ODBC driver for some strange reasons and improved since on it. It was then an absolute requirement for that project to access their database control system so there was no way around this, but over the years I can't actually count the hours I invested to get it to the state it is now. It must be many 100 hours for sure. Even implementing it from scratch again with all the knowledge I have now, I would estimate it to be at least 150 to 200 hours of work to get it where it is now. That is a lot of time. While I'm not ready to release the C source code for the shared library to the public I would consider making the VI library available to people under some still to be defined conditions (not necessarely money related) for the added benefit of more thorough testing and usefullness to other people. It wouldn't be an OpenG library though because I believe that every part of an OpenG library including the underlying shared library if any should be Open Source in one or the other form. Rolf Kalbermatter

QUOTE (TobyD @ Mar 21 2008, 11:06 AM) And it isn't in LabVIEW either until you make it not maximized. But maximized or not is not the same as resizable or not. And movable is an implicit attribute of non-maximized overlapped windows with title bar unless you customize the windows message handler. Rolf Kalbermatter

QUOTE (gosor @ Mar 21 2008, 05:20 AM) I can't say more than that you should maybe apply for the LabVIEW Beta program at www.ni.com/beta Rolf Kalbermatter

QUOTE (No.1 @ Mar 20 2008, 08:49 PM) That is not likely possible without intercepting the window message handling function itself. In Windows a window with title bar is in principle always movable. A change in that would require a custom windows message handling function that intercepts the move messages and refuses to operate on them. Doing that in LabVIEW is quite low level programming and not really possible without an extra DLL that hooks the LabVIEW window message handling function and would intercept the appropriate messages before passing control back to the original LabVIEW window message handling function. All in all a lot of work and complexity to deal with and I would put every possible effort to avoid having to do that in your place. Rolf Kalbermatter

QUOTE (GorionQuest @ Mar 21 2008, 12:02 AM) The only way to deal with that in LabVIEW besides writing a wrapper DLL, is to treat it as a uInt32 as far as the Call Library Node is concerned. Then using the MoveBlock() internal call in LabVIEW (search for that name here or on the NI forums) or some other OS API memory copy function, copying the contents from the uInt32 which is now treated as the pointer into a LabVIEW Cluster of compatible layout. Rolf Kalbermatter

QUOTE (Jim Kring @ Mar 16 2008, 03:28 PM) After 8.0 they are probably going to skip 9.0 altogether. And while I started to use 8.2(.1) for many projects I have still many projects in 7.1 and some customers insisting to keep using 7.1 even for new projects because they do not want to keep upgrading every year again their licenses. Rolf Kalbermatter

QUOTE (Norm Kirchner @ Mar 20 2008, 01:22 AM) Jeez, this guy must have used a 30 inch screen. Rolf Kalbermatter

QUOTE (tcplomp @ Mar 20 2008, 04:21 PM) That must have been a Belgian (AZERTY) keyboard instead. German is QWERTZ And are you saying you use the Caps Lock at all? For me that is the most useless key on every keyboard and since I use LabVIEW (and have not adapted to auto tool selection) the one that causes probably the single most sh.. exclamations by far. Rolf Kalbermatter