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

QUOTE(TobyD @ Feb 25 2008, 02:31 PM) Hmm, it doesn't really tell her the exact IP adress, but then that is also something the user of the application (meaning her) should know. She probably never had to configure her email account either in her email application, otherwise if she did she would know the adress of her SMTP server. Rolf Kalbermatter

QUOTE(ned @ Feb 25 2008, 03:12 PM) Lol! It's not all exactly the same but they are fairly related. ActiveX is based on OLE as it's component object model, but adds extra things such as persistent object registration and activation interfaces, standardized object embedding and such. Before ActiveX it was not really possible to embed other applications easily in a generic way. Rolf Kalbermatter

QUOTE(crelf @ Feb 25 2008, 06:53 PM) But they didn't say they did it because they can. They said they did not think it was a bad thing since in nowadays days you do not use the same means to distribute applications as you did back in 1991. I'm sure the LabVIEW developers do not add software components to the runtime system just to bloat the whole thing. They do that because it adds some functionality somwhere and since modern distribution systems allow such sizes more easily they go rather for the added functionality than spending months and months to try to squezze another few MBs out of it or create a complicated and cumbersome user configurable component based runtime installer. Yes the components are actually there but the user interface to configure them would be a bit complicated for sure and many of the components not even we could decide if they are needed or not, until you happen to run the application on the target system in question and notice strange artefacts or errors somewhere. There were at least for 8.2 already two different runtime installers. One containing everything and wheigting in at around 89MB and the other containing only the actual runtime and weighting in at 24MB. And many users wondered why they can't run their application when using the smaller one only to find out that the bigger one worked. That little Mean function in there unfortunately wanted to see the MKL installed and that was one part among many others that was not installed by the smaller installer. NI specifically said the small one was for Web Browser use only (Front Panel inside a web browser) and that means anything the Front Panel needs is there but all the rest that a diagram function could use is not there if it isn't contained in the runtime engine DLL itself since the diagram is executed on the server anyhow. And many users got upset that there was a smaller installer. So I think we can ask for more fine grained selection of runtime engine components but it won't make things really easier and therefore won't be used much. Also as you can see from the 8.2 installer, much smaller than 20 MB won't be possible anyhow (you could still shave of the non-English or whatever you want language resources) and that is still not a size that you normally want to email. Even the most minimalistic LabVIEW 7.1 runtime engine that I sometimes copy together with my executable into the same directory was at least 10MB in size and then you couldn't do 3D controls, or Advanced Analysis Library or many more things. Good enough for a small Autostart executable on a CD but not really useful for a normal LabVIEW application. Rolf Kalbermatter

QUOTE(Aristos Queue @ Feb 25 2008, 10:40 AM) Hmm, RTE can also be run-time engine. And there I would expect to have OO runtime support, otherwise you couldn't run executables that use OO. But I agree the runtime support for that won't be extereme in size. A lot of what the run-time engine adds to the system are in fact secondary things such as multi language support for it's dialogs and runtime texts, Intel Math Kernal Library, Service Locator, Logos Sybsystem, etc. etc. Most of them not strictly necessary but using some seemingly harmless functionality could already depend on one or more of these. Rolf Kalbermatter

QUOTE(crelf @ Feb 24 2008, 06:47 PM) Not sure I can agree to that? When were you last able to put a Windows service pack or KB patch onto a Floppy disk? Or a Macintosh OS bugfix? Or Linux for that matter! Without a fast broadband access keeping up with the state of security fixes on all these systems is simply an impossible thing. Ok you could also say without broadband access those security fixes aren't that important. But then maybe going with let's say LabVIEW 6.1 instead of 8.5 wouldn't be either. Rolf Kalbermatter

QUOTE(tcplomp @ Feb 24 2008, 02:54 AM) Well, I guess managing IT infrastructure is a rather thankless job. If you do it right nobody notices, but every hickup is made into a big issue immediately. Add to that the extra difficulties that software manufactureres throw into the picture to protect their interests and it gets really difficult. As far as acessing the company database is concerned. Imagine someone doing something that shuts down the system somehow. That can be fatal for nowadays interconnected workflow processes so there are of course concerns. My experience in that is that often lower management has this nice idea about how to automate testing or production and asks the programmer if it is possible to connect to the database. Our first technical reaction is what for a system and then, oh well yes of course we just use ODBC, ADO or whatever. Now IT is as the dead about such things. It could potentionally disrupt the whole system and if it does they are the ones that get beaten first. So the solution is to get lower management to talk with higher management and convince them that this is a good thing and once they are convinced they will tell IT to make it happen and everything suddenly works smooth. It's politics yes, and we all are technical people for some reason among one of them probably that we don't like politics to much. But you can't beat the system you have to play along with it. Rolf Kalbermatter

QUOTE(blueguard @ Feb 4 2008, 10:26 AM) Since you are doing vibration diagnostics one problem of sound cards is probably not that much of a problem for you. Sound card inputs are bascially always DC decoupled meaning they can't measure DC voltages and have a lower bandwith frequency of around 20 HZ. Multi channel is often not possible unless you get some more high end type card that sometimes happens to have two IO channels. But still you should be aware of that sound cards are using chips that are selected to produce fair results for audio applications. The human ear is all but an exact measurement device and therefore you can get away with rather bad hardware components without most people noticing to much of a quality degradation. In the PC component industry where every dollar not spent for a product is both a marketing advantage as well as a possibility to make a few cent more profit, this results normally in the cheapest components selected that will just about do for the task at hand (and for some products the quality degradation is definitely noticable even for the human ear). So using that hardware for measurements is not likely to produce accurate results. It will be more like guessing than actual measurement. If that is acceptable for your purpose will be something you have to decide for yourself. Rolf Kalbermatter

QUOTE(aoshi @ Feb 22 2008, 04:46 PM) By using the VISA nodes to communicate over RS-232. Your problem will be probably twofold. First find the documentation for the command set of your device. I have no idea if you got a programmers Manual with your device. This information is usually in such a manual but for end user devices this is either not automatically shipped and sometimes not really available at all up to the point where the manufacturer treats that information as trade secret. Next step will be to get acquinted with VISA programming and possibly LabVIEW programming too. Rolf Kalbermatter