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

QUOTE(orko @ Feb 21 2008, 05:58 PM) Very good point, orko! But our beloved crelf (I mean his ahem collegue) probably has his obscure reasons. Rolf Kalbermatter

QUOTE(Darren @ Feb 21 2008, 03:59 PM) A those double negatives!!! One should not assume :-) Well rereading it I see what you really meant, probably need to go to bed. It's been a long day. Rolf Kalbermatter

QUOTE(tcplomp @ Feb 13 2008, 09:19 AM) Ton you are right as far as LaVIEW's use of the socket library is concerned. But unfortunately it's not as simple as adding IPv6 capable sockets to the system. An application needs to initialize a socket with a network family before it can use it to tell the socket what protocols it should use. This is also for IPv6 necessary since the socket needs to be able to recognize the adress parameter for the network adress. For IPv4 this is a 32bit integer but for IPv6 this is in fact a 128 bit entity. As far as the LabVIEW nodes are concerned the only ones that need really some adaption on the Diagram side of things are the IP To String and the String To IP as they will need to support a 128 bit network adress. But for the adress string on those nodes as well as the various Open Nodes there will be some modifications necessery under the hood. They will need to regognize the new IPv6 adress format xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx as well as being able to resolve string adresses to IPv6 adresses. All in all not a very complicated addition but also not something you can just go and mess around with since you absolutely and under no circumstances can allow old functionality to break. Rolf Kalbermatter

QUOTE(Zerobite @ Feb 12 2008, 03:41 PM) It's not that trivial. The VI format is really a lot like the Macintosh resource file format. And that means the offset of particular information can be more or less anywhere in the file, depending on the order of how the resources were written. Admittingly if the VI was safed from scratch in a particular version, then the relative locations of those resources will be all in the same order, but for upgraded versions that is definitely not necessarily the case as new resources might get added during the upgrade and they may end up behind the already stored resources. However the other suggestion of using ResEdit on the Macintosh is probably not very likely to fly either. ResEdit expects the resources to be in the resource fork of the file, but since that doesn't exist on other platforms than the Mac LabVIEW puts its resources into the data fork. Also the LabVIEW resource format is very similar to the Macintosh resource format but it is not exactly the same. So even if you get ResEdit to pick up the data fork I'm not sure it could read that information without choking on them somehow. Also I'm surprised by Darrens suggestion that he suspects the file to not change much between versions. It's a binary format after all and even a single byte change somewhere is quite likely to be fatal when LabVIEW tries to load a VI. So no just changing the earliest possible LabVIEW version resource in a way is a quite likely case of messing up the VI so badly that it can not be loaded anymore by LabVIEW. Darrens suggestion however is also the only sane one in that respect. (Except of course the other ones like using source code control and such, but that is sometimes not very helpful after the facts ) Rolf Kalbermatter

QUOTE(NickyD_83 @ Feb 13 2008, 04:57 PM) The only thing I could think of is to write a shell extension to add this functionality to Explorer. And that would have to be done using COM and therefore C++ (although you could techically speaking do it in Standard C if you know your way around COM). Rolf Kalbermatter

QUOTE(ashwin @ Feb 6 2008, 07:09 AM) Sorry, I can't do much with that library. I have no idea why stopsampling would not work, but do think that you got something wrong with the parameter types despite you claiming otherwise. That or you are not initializing a parameter called by reference properly. The library is one big mess and 300% to complex I think. It could be done with just about 6 or so VIs and some helpers maybe. ActiveX is most probably unnecessary. Your use of queues seems not right and makes everything to complicated. But I can't see how to do it better, since I do not see anywhere the API prototypes of the DLL, nor can I see the VB code of the ActiveX DLL, nor do I understand the involved architecture of this seemingly simple driver. Rolf Kalbermatter

QUOTE(TG @ Feb 3 2008, 10:35 PM) Not just that. The average level of question is very basic on the NI forums in comparison with LAVA. And if you exclude the questions from a few very specific users on LAVA, you can consider the average level of almost every question to be professionel, and the answers as you say even more. On LAVA I often do not post since I don't know the answer good enough to feel I can add something. On the NI forums I usually don't post since I don't feel any desire to spend even one second in answering a particular question and knowing there are many others that will eventually step up anyhow. Rolf Kalbermatter

QUOTE(alukindo @ Feb 4 2008, 01:09 AM) Or you can usually put the column identifiers into square brackets to allow the SQL parser to recognize them as one entity. But not using spaces in column names is actually good practice. Rolf Kalbermatter

QUOTE(anima @ Feb 4 2008, 01:36 AM) What do you consider few data? And what is slow in that respect for you? How do you query it, row by row or as a result set? If it is really simple (a single row for instance) or you query them as a result set then the problem must be in the Oracle connector that the ADO Toolkit connects to and you will have to look for support from some Oracle centric support channel. If your result has several rows and you are not already using the method to query the data as result set try that first. When you say you tried with the Toolkits available for LabVIEW 7.1, what do you mean by that? The Database Toolkit from NI is at version 1.0.1 or something like that since a VERY long time and there was no specific release for LabVIEW 7.x or such. How does your VI to query very few data look like? A picture of the diagram or (God beware) a little VI would say 1000 times more than what you have told us so far. From the questions in this reply you do hopefully understand that the information you provide is still very minimalistic. Why do you think we should spend lots of our time to guess and second guess what your setup and specific implementation is, when you don't even take the time to sit down and consistently describe your problem as thorough as you possibly can? It is you after all that wants our help so doing some effort to get that help should not be to much asked. Rolf Kalbermatter