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

QUOTE (neB @ Mar 17 2008, 01:59 PM) No I haven't done that yet. I have a fairly complete ODBC LabVIEW library here but that interfaces to the ODBC API and to my knowledge the ODBC API is not available on the RT OS. There is a little chance that you could get the Windows ODBC Manager running under the older Pharlap based RT OSes and that some ODBC drivers might work too. But it is a big if and that would definitely fail for the newer vxWorks RT Targets as that requires different object format libraries, so that there is absolutely no chance to get the Windows ODBC Manager working on them. To get that done one would have to port unixODBC (or libiODBC) to the RT target. However that still would leave the problem of the according ODBC driver open. So in principle this approoach is a dead end. Another approach would be to implement the actual database network protocol directly on the RT system. But that is really non trivial even when using existing open source libraries to create a shared library module for the RT OS. First porting those libraries to RT OS is tricky at least as RT OSes have simply a more limited OS API set than normal desktop systems. Second depending on the database used those libraries are fully fledged (Open Source databases like mySQL) or more or less limited or even antiquated (like for SQL Server). Reimplementing the protocol in LabVIEW while in principle possible is simply such a big project in itself that it is just not gonna happen. What I would do is creating some LabVIEW ODBC proxy running on a generic ODBC enabled plattform (Windows, MacOS, Linux) and then using VI Server or just a simple TCP/IP protocol, call it's methods from the RT application. This also would make sure that the actual ODBC execution is entirely isolated from the RT system itself. There are also commercial ODBC proxy applications that allow to be interfaced with more or less simple network protocols and/or easy to port API libraries. However putting the entire DB on the RT OS is a sure way to kill its RT capabilities. Rolf Kalbermatter

QUOTE(Klaus Petersen @ Mar 4 2008, 04:06 PM) If you install MDAC (already installed on recent Windows OSes like XP) you should be able to read Acess database files *.mdb) using a properly formatted DSN/UDN. Rolf Kalbermatter

QUOTE(vugie @ Feb 15 2008, 09:48 AM) Very nice tool. Looks really good, and I'm sure NI is looking with big interest at this . Rolf Kalbermatter

QUOTE(Justin Goeres @ Feb 25 2008, 03:44 PM) I take LabVIEW's string handling at anytime instead of things like Perl's obscure and very compressed string manipulation operators. I do always get headaches trying to figure out what the result of such expressions would be whereas in LabVIEW I can fairly easily tell what the operators do. It's using real estate, but hey as you say we have subVIs and they should be used for sure. Rolf Kalbermatter