Jump to content

Rolf Kalbermatter

Members
  • Posts

    3,909
  • Joined

  • Last visited

  • Days Won

    270

Everything posted by Rolf Kalbermatter

  1. QUOTE(orko @ Jun 27 2007, 04:06 PM) Have you tried these? Rolf Kalbermatter
  2. QUOTE(yen @ Jun 26 2007, 02:35 PM) Nice to see you finally :-) A big mystery lifted and now we can all go back to our work and finally continue to write great programs. You did create a big enigma over at the dark side. And it was fun to read those that were mulling over what sex this overactive forum member might be. Unfortunately I won't make it to NI Week this year but have fun there. Shouldn't really be to hard with all those people from here and other LabVIEW related places. Rolf Kalbermatter
  3. QUOTE(Sherif @ Jun 26 2007, 10:05 AM) Well that is so true for some people! :-) Rolf Kalbermatter
  4. QUOTE(Nullllll @ Jun 24 2007, 07:07 AM) <br /><br /><br />Has the door of your home any mechanisme to control it at all???? I mean this is the most basic question and I haven't seen mentioning you anything in detail about that fact yet. You ask about if you should use a motor, yes and that tells me it hasn't such a mechanisme built in so maybe you should try to contact the tech workshop at your place first and talk with them about the mechanical construction to allow your door to be opened at all. Then when they have given you a solution to open that door somehow we can talk further about how to control it from LabVIEW. Rolf Kalbermatter
  5. QUOTE(Aristos Queue @ Jun 22 2007, 08:18 PM) Actually there is a primitive somewhere that returns the file name for a given file refnum. So it would be possible to find out the file name and open a new refnum to that file, provided the access and deny rights from the initial open allow for that. Rolf Kalbermatter
  6. QUOTE(Thang Nguyen @ Jun 22 2007, 01:58 PM) Not sure about your problem. Since it is UDP, routing should probably not be a problem. It either works (if it is on the same subnet) or it won't. However maybe your network, device or whatever could be slow and the default timeout won't work. Ever tried to increase the timeout? And about the LabVIEW version, higher LabVIEW versions can open lower version VIs. They have the diagram and all so you can do that conversion simply yourself. The changes were mostly in DNET UDP Get Devices.vi apart from some minor cosmetic ones. Do a VI compare on that one to see the difference. Rolf Kalbermatter
  7. QUOTE(Thang Nguyen @ Jun 22 2007, 12:08 PM) . Welcome to this library from yours truly. Why you would have to call the Open twice I'm not exactly shure. It isn't necessary for me and most probably is the cause for your runtime error since error 60 means that there is already a connection open to that specific address/port pair. Also I recently found a bug in this library that prevented it to work with PLC Direct systems equiped with the ECOM100 interface. Attached version (LabVIEW 7.1) fixes that so that it also works with that module. Also your attachment wouldn't help anyone not having the library much as it is missing utility functions located dnetudpu.llb. Rolf Kalbermatter
  8. QUOTE(yen @ Jun 19 2007, 04:18 PM) I do this for the Autorun program on CDs that installs my application (whose installer does use the normal NI installer technology). Basically it depends on the LabVIEW version but I use for this 7.1 and need following files: dir autorun.exe obviously my LabVIEW autorun program autorun.ini just for having the HideRootWindow=True lvapp.rsc lvrt.dll mesa.dll Probably only necessary since I use the "modern" 3D controls there vidialog.rsc models box_inc.ptc This is the graphics definition for the modern 3D buttons that are used Obviously if you go and use other 3D controls you will have to include more files from the models directory. Other things that could be necessary are lvstring.rsc (LabVIEW error messages and many more), lvobject.rsc (for other LabVIEW controls), lvpng.dll and lvjpeg.dll if you make use of jpeg or png functionality, lvanlys.dll for Advanced Analysis functions, but this won't really work as it also needs an intall of the MAth Kernal Library and that is also a question of correct registry settings for LabVIEW to be able to find that). If you use IMAQ too you also should forget about trying to get this all right yourself. It is not trivial at all. LabVIEW 8.x makes this all also a bit more complicated as the numbers of files that the LabVIEW rt system absolutely needs are growing with each version again. Rolf Kalbermatter
  9. QUOTE(Justin Goeres @ Jun 18 2007, 01:33 PM) Well it might have had to do with the fact that they misappropriated the BSD socket implementation when they wrote the TCP/IP socket library for Windows NT. As silly as it sounds considering that socket library was under the BSD license, they simply "forgot" to follow just about the only requirement that the BSD license asks for, namely to mention in the docs about the software origins. That they might be a bit paranoid about GPL I could understand. After all I'm sure the FSF wouldn't stay silent when they had reasonable suspicion that MS violated their license. But the whole idea about being contaminated just by having seen code under a certain license is rather something that MS promoted themself indirectly in the first place through thier shared source license. Rolf Kalbermatter
  10. QUOTE(Eugen Graf @ Jun 14 2007, 02:56 PM) To cut it even shorter you can't really. LabVIEW controls are just that: LabVIEW controls. As far as Windows is concerned they are just a few graphic lines inside a LabVIEW window. The closest you can get is embedding a LabVIEW front panel inside another Windows window, ActiveX or not. And that has some very tricky implications, one of them being message queue thread starving if you don't do it exactly right. Basically I would not think it worth the trouble to try it and yes I did attempt this a few years back, but with newer LabVIEW versions I would not expect this to having gotten easier, rather the opposite. Rolf Kalbermatter
  11. QUOTE(njkirchner @ Jun 16 2007, 07:04 PM) It's not a quirk. It's a convention. The picture control expects 16bit aligned scan lines. Windows bitmaps expect 32bit aligned scan lines. This is called padding and as with anything about bitmap formats these are simply conventions used for some simplification/speed up of certain operations. For nowadays computers this probably doesn't really make any big difference anymore but it could have a big impact a few years ago. Rolf Kalbermatter
  12. QUOTE(Karissap @ Jun 12 2007, 11:07 PM) This statement is wrong in more than one way. First LabVIEW does not necessarily have to be significantly slower than C. It will never be faster provided you use comparable algorithmes but much slower is a statement that holds simply not true for many algorithmes. I've done bitmap import and export back in ~94 completely in LabVIEW including supporting simple compression schemes such as RLE etc and the routines where actually faster than calling Windows 3.1 16 bit APIs for doing the same. The problem in LabVIEW is almost always not that it is in itself slow but that it is so easy to come up with a terrible algorithme that usually seems to do what you want but with a bad performance. Doing the same in C you do need to have a good understanding of what you want to do, how you are going to do it and how the C compiler will deal with certain thngs in your code. All this is most often absent when I see someone implementing an algorithme in LabVIEW and complaining afterwards about its performance. Also it is wrong in that writing an algortihme in C is never going to be faster than doing it in LabVIEW. It's runtime performance can be and does sometimes be significantly faster but the implementation is definitely a different thing. Of course assuming that you know both LabVIEW and C equelly well. Rolf Kalbermatter
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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
  19. QUOTE(Aristos Queue @ Jun 1 2007, 09:41 AM) At least not yet . And probably never for the already existing platforms. Rolf Kalbermatter
  20. 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
  21. 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
  22. 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
  23. 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
  24. 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
  25. 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
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.