Rolf Kalbermatter

QUOTE(crelf @ Jun 14 2007, 02:08 PM) I have had one other reason in the past for a huge Datalogger application I had developed for them: We use Linux for just about anything else in our automation departement except for desktop PCs in adminstration. But even that didn't get the project finally ported as the application had to be installed on notebooks and the low budget notebooks they used back then were not very well supported by Linux. Just for clarification this was back when LabVIEW 6.0 and 6.1 were still the actual development version. Nowadays I'm sure it would be almost a no brainer to do, but after some 6 or 7 years of being used to Windows it's not likely they will want to change to Linux that fast anymore for that application. Rolf Kalbermatter

QUOTE(ragglefrock @ Jun 14 2007, 11:28 PM) I'm pretty much sure you are right here. Wouldn't make sense trying to use a constant value directly as default input value instead of allocating the necessary memory space and initializing it accordingly. As such it could of course have a serious impact if the controls default data was not one of LabVIEWs default default data but rather an 100 MB data array. Rolf Kalbermatter

QUOTE(Eugen Graf @ Jun 14 2007, 04:56 PM) I haven't exactly done this but it is not impossible. A WDM driver is however a driver that uses an object oriented architecture. Not something you could directly access in LabVIEW. Also a WDM driver runs in the context of the Windows kernel. What this all means is you will have to write a user space DLL, that does access the WDM driver and provides a standard C API to be called by LabVIEW. Rolf Kalbermatter

QUOTE(PaulG. @ Jun 12 2007, 08:30 AM) Ohh those good old days with my C64. But then I didn't really do much with it's Basic. Was learning Pascal for my vocational education and didn't feel Basic could keep up with it. Even dabbled into C64 assembly for a short amount to try to do the really funny things, but my younger brother was way better at that. Later did a Turbo Pascal program during an internship and immediately after that got exposed to LabVIEW in 1992 and felt at easy with it the first instant. Even did at some point rewrite in LabVIEW the app I had done for the most part of my 4 months internship in something like half a day. Of course it had been an app reading in acquired data from binary disk files and displaying them in a wafeform graph. Doing that in Turbo Pascal had been a major thing to do as I had to write the code to draw a complete waveform graph on screen and then rewrite it to a plotter in HPGL. Ok I didn't do the HPGL part in LabVIEW :-) at all. Printing out the front panel was good enough. Rolf Kalbermatter

QUOTE(crelf @ Jun 12 2007, 08:09 AM) Will with nowadays MultiGigaHz CPUs it is definitely more in the order of a few 100 ns than many us. Rolf Kalbermatter

QUOTE(dbyers3 @ Jun 12 2007, 09:08 AM) Could be a policy setting disallowing the change of the desktop background. Window policy editor does allow a myriad of settings being changed, that control such things as this. Rolf Kalbermatter

QUOTE(Aristos Queue @ Jun 1 2007, 09:41 AM) At least not yet . And probably never for the already existing platforms. Rolf Kalbermatter

QUOTE(Ulrich @ Mar 8 2007, 09:52 AM) Ouch! HP Basic! I thought that is dead for a long time. I have never been a fan of any Basic, but HP Basic was definitely not the best one I've seen. Rolf Kalbermatter

QUOTE(LV Punk @ May 29 2007, 06:23 AM) There will be always people liking something and others not. Heck give me VB and I start to bitch just as bad as one or two of those comments (and I obviously don't agree with them about LabVIEW). While some comments about LabVIEW have a point or two that is valid, it is mostly just opinions. But then that is what /. is mostly about. And the rest goes about how hard it is to get parallelisme in procedural languages. Not a big surprise to anyone. 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