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

QUOTE(tcplomp @ Feb 23 2008, 04:38 AM) Yes! If I send an executable to a client I add everything that the executable needs to run, except the runtime engine. I just add a link to the appropriate NI download page for the RTE and tell the client to install that. That gives me usually ZIP archives of about 1MB up to 10MB depending on the project size. Rolf Kalbermatter

QUOTE(brent99 @ Feb 22 2008, 05:06 PM) The project management is specifically not part of the RTE. Almost anything editor related is NOT part of the RTE. The LabVIEW RTE got big because of many new features and also support libraries which could or could not be important for a specific application. The problem is to chose between easo of use: you just create an installer and everything will work normally or requiring the user to have a very detailed knowledge of what he really needs to select as subparts in a build. Many users are already overwhelmed by the choices of extra components to add to an installation in the 8.x Builder. Subdividing the RTE in one dozen or more sub packages wouldn't make that simpler for sure. Whoever has created Windows Embedded projects knows probably what I'm talking about. There you have to decide what components you want to put in an installer and if you got it wrong the target system simply won't start, sometimes issuing a useful error message but quite often not. QUOTE Although, speaking of large RTE, uhmm, isn't Labview compiled to machine language? Its NOT Java running byte code. Is it? Well, the actual diagram (such as all the structures like loops, cases, etc as well as the actual wiring of data between nodes) is compiled into machine code of course but not every node is compiled into machine code on the fly and added into the VI itself. Most little yellow nodes are in fact function calls into the LabVIEW kernel or RTE. Also there is a lot of code necessary to draw the front panel, schedule execution of all the VIs and many more things like support for interfacing to VISA, Bluetooth, TCP/IP, etc. These things do not get added into the executable itself as that would be both a huge task to prepare a linker system that could link these together properly for the specific target system into an executable as well as a waste of storage space since each executable would contain the same code over and over again. Rolf Kalbermatter

QUOTE(brent99 @ Feb 22 2008, 05:08 PM) No definitely not! The entire UI widgets have been written for LabVIEW 3.0 from scratch based on the drect windowing API of the spcific platform (X11,Windows GDI and Mac OS QD) and that hasn't changed at all until now. The only real modification was with the adding of the 3D types of controls in LabVIEW 6, but they are based on the same proprietary object model that is used for the other built in LabVIEW widgets. QT appearently only is used for the Multiple Variable Editor that is part of the LabVIEW Data Logging and Supervisory Toolkit, but since the LabVIEW installations contains that anyhow (but the according license is necessary to enable that functionality) it comes with every standard LabVIEW installation and since it is in the executable directory, Windows will always prefer to load those libraries if some component such as the SCC API provider for said system needs to load those libraries with that specific same name. Rolf Kalbermatter

QUOTE(orko @ Feb 21 2008, 01:00 PM) No! This really works for any program that uses VISA to communicate with the port (serial, GPIB, and whatever). NI Spy in fact simply intercepts all VISA API calls and monitors them. Of course standard Windows applciations using directly the Windows Comm API can't be monitored in that way. Rolf KAlbermatter

QUOTE(Khodarev @ Feb 7 2008, 07:35 PM) Xmit is sometimes the name of the transmit line on the serial port. Rolf Kalbermatter

QUOTE(orko @ Feb 21 2008, 09:34 PM) Cool down orko And yes if she doesn't know, who would. She created the whole IVision Toolkit after all! Rolf Kalbermatter

QUOTE(psufleish23 @ Feb 21 2008, 03:40 PM) File mapping should work for use as shared mamory in theory and did so in the past for me but: no, if you update the file instead of a mapped pointer to the file I don't think this is gonna work. Also you should not try to copy the name string for the MapFile but instead the returned pointer from MapViewToFile. Another suggestion would be to use UnmapViewFromFile and CloseHandle afterwards to properly close of all resources. Also as has been explained on the page you linked to access to mappedFiles can generate exceptions. LabVIEW has an exception handler around Call Library Nodes but that will popup an user error dialog. To handle those exceptions yourself you will have to create an external DLL as custom exception handling is not supported by LabVIEW. I would say go for UDP/TCP instead. Much more robust, remote capability built in and easy to do in LabVIEW. Rolf Kalbermatter

QUOTE(mballa @ Feb 21 2008, 11:43 PM) No! 8.5.1 is due sometimes soon. It's a bug fix release! But now please don't call those poor customer sales representatives for an update shipped to you. Because if you have an MSP you will get it anyhow and otherwise.... well we'll see if they put an upgrade installation on their web site for download. Of course if you don't have an MSP this might be the time to think about it again. Rolf Kalbermatter