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

QUOTE (Darren @ Mar 19 2008, 07:48 PM) I never use the New... dialog for VI templates and very rarely for anything else. The way I open instantiated VI templates is simply by double clicking them in Explorer. I guess that is a remainder of pre LabVIEW project times where Explorer was part of my project management, together with a Top Level.vi that contained any and all main VIs and dynamically called VIs. Rolf Kalbermatter

QUOTE (Michael_Aivaliotis @ Mar 19 2008, 04:13 PM) Pease note that Compare VI Hierarchies, different than Compare VI is a Professional Development System feature and therefore not available in the Full Development System if I'm not mistaken. Rolf Kalbermatter

QUOTE (7J1L1M @ Mar 11 2008, 10:03 PM) In LabVIEW < 8.0 this function was indeed called Seek but very seldom used, since the Read and Write File functions had an offset input that defaulted to the current offset. Rolf Kalbermatter QUOTE (7J1L1M @ Mar 12 2008, 01:30 PM) Thanks for all the suggestions! I'll see what I can do with the "append to end of file" technique, although I'm afraid that will be extremely hectic and complicated for me . One of my main goals with this format was to attain the smallest size possible (even at gigantic sizes! :laugh: ) for easy transfer, but still with the speed of commercial databases. I may have found something that will do what I've been wanting to do: Windows Kernel32.dll has some functions called file mapping like "CreateFileMapping", "Memmove_a", and other similar functions. It looks like it may be possible to use these to actually "move" parts of the file to "nothing" and thereby erase it. I believe there is also an insert function. Does anybody have any experience with file mapping? If so, it may be possible to use this idea. Here's a link to a situation similar to mine that uses this method: If anyone has an idea for this, it would be most welcome! File mapping simply maps a view of the file into memory. It is meant to quickly modify files but there is no way to map a part of the file to "nothing" and make that part magically disappear. You still have to move the remainder of the file view to the new position before closing the file mapping to make that part be go away. Writing a VI that goes to the offset where the modification starts and then in a loop reads in junks of data writing them back to the new desired offset will be not that difficult. If the part to insert will be bigger than the part it resizes you obviously will have to start the file junk read and write back at the end of the file if you do not want to write the changes into a new temorary file first and then deleting the original one moving the temporary file to its name. Of course this too would be done with a loop reading in junks at a time to avoid having to read in a 100MB file into memory. For security reasons I would recommend to do the temporary file anyhow as this operation will take some time (seconds) and there is always a chance that a crash in the middle of the data copying might leave the file in a completely corrupted state. Rolf Kalbermatter

QUOTE (jlokanis @ Mar 13 2008, 08:33 PM) I'm using my own LabVIEW ODBC VI library to do database access. From a VI interface perspective it is closely related to the previous non ADO Databases Toolkit from NI, ex Ellipsis Medium SQL Toolkit. All these VIs do is calling into a DLL/shared library that interfaces to the actual ODBC API. While there have been claims that ODBC is slow this is not really my experience but the problem is similar to what you see in your ADO.NET access. The most simple ODBC access method is to query every row and column value independantly causing many server roundtrips. By using the right methods (multi row cursors the equivalent to rowsets in ActiveX ADO) you can avoid many server roundtrips and get quite impressive speeds. I implemented this in the DLL almost completely transparent to the calling LabVIEW application (almost because you can influence the rowset size by a parameter or disable it entirely). Doing the SQL datatype to LabVIEW datatype conversion in the DLL too, and making sure to use similar datatypes in LabVIEW that match closely to the SQL datatype instead of all strings will also help to speed up DB access. And before you ask, no I haven't made that VI library available to people outside of our company yet. I considered doing this but there are several reasons why this might be not such a good idea. One of them is that there are already many (albeit non ODBC) database access libraries out there for LabVIEW. Adding yet another one is not likely to help many people. Another one is that it was and is a lot of work to write and maintain such a library and even more to support it once it is public but there is no real market for VI libraries sold by someone else than NI. Rolf Kalbermatter