Rolf Kalbermatter

QUOTE(Aristos Queue @ Jun 4 2007, 05:46 PM) Actually I think LabVIEW is smarter than that! If I remember correctly LabVIEW is reallocating the output array on While Loops in 2^x steps, meaning it doubles the array size each time it gets to small and resizes it one last time at the end. Otherwise a While Loop with auto-indexing would have little or no advantage over one with a Build Array primitive inside. QUOTE(eaolson @ Jun 5 2007, 03:48 PM) The closest I can find is Application Note 168, "LabVIEW Performance and Memory Management," where it says a DBL-to-SGL conversion on an array is done better inside the For loop, rather than outside (page 15). This App Note came with my 7.1 distribution, but I can't find it on the NI website anymore. This is mainly about memory consumption. The earlier example won't really make any difference here as they both will require a complete buffer for the floating point array and integer array at the same time. But if you have a loop that produces somehow lets say a double precision number (the random generator) and you want to have an integer instead, converting inside the loop will only use 8 bytes + the output integer array while converting it outside will first generate a complete double precision array before converting it to an integer array. This is not so much about execution speed, probably only a little difference, as more about memory consumption. Rolf Kalbermatter

QUOTE(Aristos Queue @ Jun 10 2007, 10:58 PM) Of course the machine code (not assembl(y)er code as that is what a disassembler will create or an assembler will use to generate the machine code!) is there but inside the VI that is inside the LLB and that is somewhere inside the executable. Any disassembler I know of will only find code that is located in segements specifically marked as code segments. And its disassembly starts at the normal executable entry point and goes from there. Code embedded in some ways in the resources or as in LabVIEW in some proprietary binary structures won't be found at all. So the output from disassembling a LabVIEW executable only shows the startup stub that launches the LabVIEW runtime library. Only the LabVIEW development environment (well not in 8.2 anymore it seems) and runtime system knows how to locate the VIs inside the executable and from there extract the machine code embedded in there. QUOTE(Ben @ Jun 11 2007, 07:41 AM) Does this info about the "required vs" really make any difference? If I am already marking required inputs as required then is it really practical to mark optional inputs or recomended as required? Well, as has been pointed out already, for required inputs the subVI won't need to check if the input was wired and provide a replacement default value if it wasn't, since it can savely assume that there is a value at all times (otherwise the VI couldn't have been called obviously). So I guess it is this little extra code that makes the difference in execution time and probably will also result in a few bytes less machine code for required inputs. And no, making non-required inputs required just for the purpose of saving a few nanoseconds execution time won't be a useful thing to do as the convinience of not having to wire an input if it is usually not necessary makes a lot of sense to me. Rolf Kalbermatter

QUOTE(yen @ Jun 11 2007, 02:36 PM) Not exactly! That second task bar button is a "hidden" window that serves internally in LabVIEW as message dispatcher to help LabVIEW with asynchronous operations and such. With Win32 this wouldn't strictly be necessary I guess as threading could solve that too, but this was implemented for Win3.1, as having windows message queues was the only way to achieve some sort of multitasking back then. Removing it would probably have all kinds of strange effects and require a lot of work to make LabVIEW behave in all aspects the same as it did, so nobody went that path so far. To make that second task bar button disappear you can add the HideRootWindow=True key to you labview.ini and all your executable ini files. As to the OP question, my splash screens simply terminate AFTER they launched (Run) the main window AND made sure it's window was open, which the main window will do after having initialized everything. Rolf Kalbermatter

QUOTE(Val Brown @ Jun 2 2007, 05:29 AM) As already mentioned it is old code in the LabVIEW source code together with a just as old external file. It won't be adapted in any way to support new platforms, the tools to create the old serpdrv file are long outdated (serpdrv being similar to an LSB in some ways), it is sooner or later going to break on OS revisions, does not support many features of serial ports (port enumeration etc.) and so on. With the device manager in the Macintosh OS being completely different nowadays, the only reason to keep that code in LabVIEW is by now serpdrv. Nothing else can and will make use of it. While the actual code in LabVIEW probably does not account for more than a few 10kB, it is always a good idea to keep an eye out on things that can be removed. As it is LabVIEW has mostly just continued to grow from a 4 MB executable in 5.1 to a more than 20MB executable already in 8.21. While serial port communication isn't always trivial, fact is that VISA works very well for me in all applications that I have. If your code needs the old serpdrv to work correctly there is something wrong with it and you better start to schedule some time to look for a rewrite instead of waiting until it is breaking somehow, which will be always at a moment you have 20 other projects too that need to be finished yesterday. Rolf Kalbermatter

QUOTE(karim @ Jun 10 2007, 04:53 PM) I would say the existence of a serial port is one of the most important "conditions". Not really something that is always there nowadays in modern computers. Honestly, be a bit more specific about what you want to know. What do you want to do? What doesn't work if any and what have you tried so far? Rolf Kalbermatter

QUOTE(Jim Kring @ Jun 7 2007, 11:02 PM) Sorry I'm lazy, but does the SOFTWARE also include executables created with LabVIEW or just LabVIEW itself? QUOTE(Jeff Plotzke @ Jun 7 2007, 08:53 PM) This looks like it's false and it doesn't make any difference... I just created a quick VI that contains a subVI. I originally set the connector on the subVI as optional... then built the application as an EXE. I then used a Win32 dissasmbler to convert the EXE into an ASM file. Then, I took the subVI, marked the connector as required, built, and disassembled again. I did a compare between the two disassembled files. No difference. The files were identical. I did this several times and tried also with dropping down the subVI several times on the BD of the top level VI. Still in all instances, changing the connector pane between optional or required made no difference in the EXE produced. Your test shows most probably nothing. The only code your dissassembler can see is the startup stub that loads the LabVIEW runtime system and then passes the reference to the internal LLB to that. The machine code located in the VIs inside that LLB, can only be located and invoked by LabVIEW. There is no disassembler that could possibly know how to find the LLB, not to speak about the VIs inside it nor the LabVIEW generated machine code in each VI. Basically every LabVIEW executable of a given LabVIEW version will give you exactly the same assembly code. 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