Rolf Kalbermatter

QUOTE(Wolfram @ May 29 2007, 10:01 AM) While this is all correct there is one extra caveat. You can not use scripting for changing VIs that are non idle. This means to do what the OP would want you would have to write a different VI that loads the VI to modify into memory, modifies it and only after all modifications are done, does start it. And whenever you want to change it again the VI needs to be stopped, modified and restarted. Basically not something I would ever consider to do. Rolf Kalbermatter

QUOTE(george seifert @ May 21 2007, 02:43 PM) Well first some sort of perl server must be running. How this is done and where it is I do not know. It could be a special proxy server app or it could be a build in server in the Perl interpreter. What port it will use will depend on the server that provides that interface and unless you spcify this when starting up the server application (or in some ini file configuration) it will use a more or less application specific arbitrary default port. So find out what will provide this TCP/IP server interface to your Perl environment (Active State Perl or maybe a Unix Perl?), find out its default port or define the one you want to use in the configuration or startup command, and make sure that application is already running when you try to connect to it. Rolf Kalbermatter

QUOTE(PJM_labview @ Jan 15 2007, 03:42 PM) I think I can see the logic about doing it the new way in order to avoid extensive UI redrawing during a window resize, but agree that the old behaviour was better. However it may have been a glitch in 8.0 because as far as I remember did earlier versions also not dynamically resize the front panel objects during window resize. Unless I had only one control that needed to resize and nothing else that needed to move on the front panel I have always done this so far myself in the panel resize event case and that gives a very smooth effect, although I do need to test that this still works in LabVIEW 8.2. Rolf Kalbermatter

QUOTE(Hieutq @ May 18 2007, 11:06 AM) How about buying a license form NI? Rolf Kalbermatter

QUOTE(Darren @ Apr 24 2007, 06:00 PM) In that respect just something that came up on Info-LabVIEW again. It would be useful to add to the error translation routine that handles file IO an explicit DWarn call when a "generic IO Error" gets generated. Not sure if DWarn can do that now but a complete stack trace with it would be fine too. This would allow the LabVIEW R&D guys to possibly get a better feeling, which strange or obscure Windows API error resulted in a generic IO error. They are not likely to be very common errors, (or they would have been translated in a more useful error code) and the according log would give some better hints to the developers where to look for the cause of this error. Of course there are other errors (for example network routines) that can end up in some sort of catch all unexpected errors into a single generic XXXX error. Rolf Kalbermatter

QUOTE(TiT @ May 17 2007, 12:42 PM) If you want to run the two exes on the same computer you should not use the same IP port number. Only one application (and even thread) can open a specific IP port on a machine at the same time, so the second executable that starts up will fail to initialize a VI server instance if it is run on the same machine. Should probably still allow the second app to access the first app as client but otherwise around can't work as the second app has no properly initilialized VI server. Rolf Kalbermatter

QUOTE(rkesmodel @ May 16 2007, 10:41 PM) I don't think it is an application thing really. It is the more likely the "current directory" Windows maintains on a per process base. Various Windows APIs such as the File Dialog box do adjust the current directory to the last directory accessed. So that is where the notion of applications locking a drive may come from. Another one is that LabVIEW keeps a handle to DLLs open as soon as they got loaded into memory until the application closes down completely. I'm sure the new LabVIEW 8.2.1 feature to define the DLL path dynamically at runtime for Call Library Nodes can actually remove that annoyence once the VI accessing that DLL has gone idle. Rolf Kalbermatter

QUOTE(Bryan @ Apr 29 2007, 04:41 AM) Programming a parallel port with direct IO access VIs is possible but not trivial at all. Apart from differences between computers in setup and differences in what mode a parallel port is initialised in the BIOS that can change how you have to access that port, there is one other important issue here. While notebooks nowadays seldom or never have a built in parallel port anymore (and serial ports too!!) there are even desktop systems that come without a built-in parallel port anymore. So in terms of ease of use and overal compatibility a low cost USB DAQ device is certainly a lot more friendly for nowadays modern systems and will get even more unavoidable in the future. While you can plugin a cheap 10$ parallel port PCI card in a desktop this is usually no option for notebooks too. Rolf Kalbermatter

QUOTE(Bryan @ May 16 2007, 06:01 AM) Well, I guess the 62+ USB sticks would be the cheapest solution in terms of both hardware and time investment. Installing a LabVIEW executable on that boot image makes everything even more feasable as a whole LabVIEW development environment might actually require some of the larger sticks, not to mention the legal licensing issues that would simply require you to buy one license per USB stick. As to the costs of a USB stick for test reasons I would bet that the ease of use of just plugin the stick, boot up the computer and start the test is going to be a real money safer after just two or three test runs of so many computers. I can not see where the cost for such a solution possibly can be a major showstopper, for a project that involves a military contract with very strict configuration control. If the additional one time investment of 30$ per system is to much I guess every minute spend on this forum to find an alternative solution will be already unproductive too. Rolf Kalbermatter

QUOTE(Eugen Graf @ May 16 2007, 07:23 PM) It is indeed legal but the text says "Commercial use not allowed!" This is a version of LabVIEW 6.1, fully authorised by NI, to be distributed with the German computer magazine ct, but with the limitation that it can not be used for commercial projects. The Windows version is on their DVD that comes with their 11/07 issue (it's a biweekly edition). In my opinion this is the single best German computer magazine and has been so for almost two decades already. They never would do anything illegal, although they sometimes have articles about technical issues that could allow someone to use them for illegal activities, but at the same time it educates the reader about how to prevent such illegal activites too, and that is clearly the main aim for them. Please note that it is just the plain FDS. Ni Toolkits, Application Builder, etc. which would be mostly things that go clearly into commercial use anyhow. Rolf Kalbermatter

QUOTE(Jim Kring @ May 15 2007, 04:50 PM) It is but it contains almost nothing in comparison to earlier versions. This is with VISA 4.1 and MAX 4.2. Rolf Kalbermatter

QUOTE(george seifert @ May 3 2007, 01:02 PM) It's a kernel driver issue in combination with your PC hardware or more properly your BIOS. I've seen HP BIOSes creating strange things lately a few times. A few months back I tried to install a PCI-1407 card in a HP PC and decided to also install the greatest and newest NI-IMAQ with it. The card simply didn't work. It showed up in the device manager but with an exclamation mark and indicating an error 10 had occured. While dealing with NI support about that I happened to try an older NI-IMAQ that I had from an old setup (Ver 2.5.1 or so) in comparison to Ver 3.6 and everything worked alright. Later that day I got a message from NI that the issue was known and could be resolved by downloading and installing a new BIOS for the HP computer according to this http://digital.ni.com/public.nsf/websearch/F69AB8D3B7C0261F8625723E007205FF?OpenDocument' target="_blank">Knowledge Base Article. I didn't go through the hassle of installing a new BIOS since it now worked and also because I was at a customer site with firewalled internet access and optaining the BIOS would have been problematic. Rolf Kalbermatter

QUOTE(zampala @ May 1 2007, 04:46 AM) Have you checked that NI-488 drivers for Linux support your GPIB interface? While the actual register interface is very common for all NI GPIB interfaces, the actual connection to it (PCI, ENET, USB etc needs to be specifically supported by the NI-488 driver for this to ever work. I would guess that NI-488 for Linux does not support all possible GPIB interface busses yet or maybe there is a newer release that does. Check out the NI site for this. Rolf Kalbermatter

QUOTE(Bryan @ Apr 20 2007, 07:12 AM) With >1GB USB sticks getting very common why not install an image of an OS with LabVIEW installation on them. If they can boot from there you should be able to do so too. Just need a stick that supports booting from. And then it should be quite simple to create as many of those sticks as you might need to get to test all machines in parallel. Not completely free but USB sticks don't cost that much anymore. You could even go with a smaller stick for DSL I think although not sure what are the smallest that support booting up. Alternatively you could use such a stick to boot up the system into a minimal configuration that connects to the network and downloads everything else necessary to the local RAM disk. Rolf Kalbermatter

QUOTE(Aitor Solar @ Apr 23 2007, 07:35 AM) OpenG has a VI that does this all in G. Works quite well and much less likely to create crashes :-) Please not that this VI does just what it is asked. Meaning if you ask it to get a certain page that has a redirection it will do so which will only return a short status message and some redirection code which you need to parse and use to get the real page. Rolf Kalbermatter

QUOTE(Michael_Aivaliotis @ Apr 22 2007, 05:59 PM) LabVIEW 3000 with AI and mind reader interface. It just reads the developers mind and creates everything as it finds it there. The AI is necessary to overcome fuzzy, non-existing and wrong knowledge about what the developer thinks she/he needs. Rolf Kalbermatter

QUOTE(Beri @ May 8 2007, 09:17 AM) Come on! Of course it is and it is a rather trivial exercise to write a VI that takes a byte array and formats it into a hex string. Not that I will do your housework but with a bit of thinking this should be doable in less than half an hour and if you add a bit more you can even spend time for optimizing it. Considering that you want to write something like a network analyzer I simply can't believe that you can not come up with such a VI yourself. Rolf Kalbermatter

QUOTE(Karlos @ Apr 23 2007, 04:32 PM) What version of LabVIEW? The always on top is called floating and is something that has changed about from 7.x to 8.x. If you use 8.2 then it is simply a property of the VI Frontpanel class, called "Behaviour" and one of its values is Floating or Floating w/ Autom-Hide. By removing the menu you should be able to disable the menu short cuts at runtime. Rolf Kalbermatter

QUOTE(BrokenArrow @ May 14 2007, 08:09 PM) I just checked in a 5.1 installation and yes it is not set reentrant. The write in itself may not be a big problem I would expect more trouble with the read in fact. Your boss probably will be in your neck again next time production tells him this application is not working and they can't meet the target with such an ugly beast. Then you should tell him to either reserve time for a proper redesign or at least a through clean up (I would at least expect a few weeks of work) or forget it as that application is simply unmaintainable and never can be made to work reliably without that. Rolf Kalbermatter

QUOTE(crelf @ May 4 2007, 09:46 AM) I've used a few times Inno Setup and was quite satisfied with it. For simple installations it is really easy to create a setup script and if you want to go further you can add real code based on a Pascal like syntax but that is really only necessary for your own specifc dialog templates or custom installation steps involving Windows API calls. And it is free too and often used by Open Source projects for their Windows installer. Rolf Kalbermatter

QUOTE(BrokenArrow @ May 7 2007, 10:53 AM) Ohhh my god! My current projects are around 800 Vis easily, contain probably less than 20 globals, and also less than that in sequences (most of them being single frame sequences to enforce some dataflow dependency). Your problem is likely some serial port timing. If you have VIs that do some waiting inside and use that same VI for something else that something else won't be able to run before the first operation has stopped. However I thought the Serial Port Write.vi you mention was set to be reentrant so that should not be a problem. If it isn't making a copy with your own name and setting it to be reentrant will save you some time since you won't need to create individual VIs for each place. A reentrant VI really executes the same when used in multiple places like the same amount of individually named copies of that VI. The drawback of reentrant VIs is that you can not debug them well before LabVIEW 8 and basically not at all before LabVIEW 7. Rolf Kalbermatter

QUOTE(bbean @ May 13 2007, 08:17 PM) Well you gave yourself in fact the answer already. The solution is to upgrade since it works in LabVIEW 8.2. It is likely a problem in Active X callback event handling inside LabVIEW, where you can do little short from rewriting the ActiveX component, which I assume is no option here either. NI does usually not release bug fixes to older LabVIEW systems once a new version is released (unless you own >500 licenses and therefore have a certain direct influence on the NI decision making). Rolf Kalbermatter

QUOTE(BrokenArrow @ Apr 29 2007, 08:45 AM) No certainly not! By using property nodes to set that value of controls in abandunce you will likely create a program that feels very sluggish. For just one time intialization of the front panel this would probably be not to bad but it is very likely that once you start to use value properties intensely you use it all over the place and if you do that in a generic update state of your UI state machine it can already get bad. If you do that in a subVI through a control reference that is called all over the place in your program, you can probably sell a coffee machine too with your program so that your user can do something while waiting for the UI to update after each mouse click :-) Rolf Kalbermatter

QUOTE(Tomi Maila @ Apr 19 2007, 12:54 PM) You could send the VI to Jim directly (or myself) and ask him to add it on your behalf. He (and me) will maintain your copyright notice. Or you get an account at sourceforge.net and ask Jim to have you added as developer to the OpenG Toolkit project. This will give you commit rights to the libraries but obviously this is not something you and everyone else would want to be granted to just about everybody. Once you start to commit your own VIs to the libraries there are a number of things to watch out although adding to existing libraries is really quite trivial. I usually leave the task of generating a package to be distributed to Jim for instance when he feels alright with it. Rolf Kalbermatter

QUOTE(crelf @ Apr 21 2007, 05:08 PM) You can also read the first post in a row of posts to come about LabVIEW external code at http://expressionflow.com/external-code-in-labview-part1-historical-overview/' target="_blank">http://expressionflow.com/external-code-in...rical-overview/ to get an idea about what CINs and CLNs are about, why they exist and why you should use CLNs instead of CINs nowadays. Rolf Kalbermatter