Rolf Kalbermatter

QUOTE (rajprj81 @ Oct 12 2008, 10:39 PM) There are many threads about accessing serial instruments in general and AT command modems specificially here on this forum. Basically if it works in Hyperterminal but does not seem to work in LabVIEW you have likely forgotten to append the carriage return and/or line feed to the command. Hyperterminal does this when you hit the Enter key. LabVIEW simply sends whatever you tell it to send in the string. You also can enable VISA to append a single character automatically through VISA properties but I do prefer to disable that explicitedly and instead append those characters explicitedly to the command strings. Rolf Kalbermatter

QUOTE (jgcode @ Oct 7 2008, 05:52 PM) I think the virtualization for INI files inside the Program Folder is not realized by virtualizing file IO access to that location but is part of the Windows OS API (GetPrivateProfileString() and friends) used to read INI file settings. Since the LabVIEW INI file VIs are however build entirely in LabVIEW and access INI files through basic Win32 API File functions, this virtualization is not available there. Rolf Kalbermatter

QUOTE (Val Brown @ Oct 9 2008, 12:35 AM) I'm not sure there is much that NI could do here. It seems really more like a bug in WMP to me. Rolf Kalbermatter

QUOTE (Aristos Queue @ Oct 9 2008, 10:24 AM) You are completely right here :-). Not that I would expect anything else from you! Rolf Kalbermatter

QUOTE (PJM_labview @ Oct 8 2008, 12:26 PM) No! LabVIEW uses its own completely self cooked widget library. Basically a highly object oriented thing but all implemented in standard C way back in LabVIEW 2 days. So a LabVIEW window is in fact an OS window but anything inside that window are simply self generated widgets using drawing primitives of the underlaying OS. In the case of Windows LabVIEW actually draws lines (vectors) using Windows GDI, for the Mac it uses (used?) Quickdraw, and for Unix it directly uses XWindows drawing primitives. So as far as the OS is concerned there are no UI objects on a LabVIEW front panel but simply lines, circles, rectangles and text. That said it should be possible to capture the EMF drawing of a LabVIEW frontpanel by getting Windows to render the redrawing of a window into an EMF context instead of into the window. How to do that is however probably quite tricky. I know that it worked perfectly in Windows 95 as I have often gotten screen shots into MS Word that scaled nicely. In newer Windows versions it was a bit more tricky but it is usually possible. The way I do that is by using the Crtl-PrntScrn keyboard shortcut which gets various capture formats of the currently active window into the clipboard. many applications choose to pick the BMP format from the clipboard when it is available but Word seems to prefer EMF resp. WMF if it is there. You do of course need to have an application that does know how to deal with these metaformats properly. PS: Mesa aka. OpenGL is only used for the 3D controls and there mainly for the alpha shading but for the rest those controls are simply native LabVIEW widgets as all other controls too. Rolf Kalbermatter

QUOTE (jpdrolet @ Oct 1 2008, 08:12 PM) lol! In C you wouldn't even think about asking for something like that I wonder if Perl has it. From all those strange programming languages I would expect it to be the first that would come up with such a universal superduper format specifier. Rolf Kalbermatter

QUOTE (shoneill @ Oct 6 2008, 06:08 AM) Nice ! That's what you can call International relationships. QUOTE (normandinf @ Oct 6 2008, 08:54 AM) If she left Romania, then she might be in the 2%... That may seriously messup alfa's calculations, if more do that QUOTE (Phillip Brooks @ Oct 6 2008, 10:05 AM) I think alfa suffers from one or more of the following: Martyr complex Superiority complex Malignant narcissism And I think you missed a few He's the typical forum post attention seeker. Putting out wild statements, and when people react he simply adds more wild statements to it. Rolf Kalbermatter

QUOTE (shoneill @ Oct 6 2008, 04:39 AM) Just a short hyjacking of this thread Looking at your national flags I wonder if you are Irish and living in Switzerland or if your Irish flag is to something else related Rolf Kalbermatter

QUOTE (eaolson @ Oct 1 2008, 10:15 AM) Hmm, lol At least one specific city in that state, can't comment on the rest as I haven't seen it, except death valley but there were definitly no prostitutes Rolf Kalbermatter

QUOTE (JiMM @ Sep 22 2008, 11:21 AM) I love Heinlein! Rolf Kalbermatter

QUOTE (jcarmody @ Sep 22 2008, 05:33 AM) You as a person quite likely nothing. The "people" as a whole however?! Democracy in theory is sort of an ideal but in praxis it's still one of the better solutions. If for nothing else than that the "people" can not say that they have absolutely no influence in who rules them Rolf Kalbermatter

QUOTE (alfa @ Sep 22 2008, 03:51 AM) It's the opposite really Every country gets the government it deserves. It's not the government that makes the people bad. Rolf Kalbermatter

QUOTE (alfa @ Sep 19 2008, 03:41 AM) Assassinated by a georgious half naked woman? Sounds almost like the ideal way to go from this physical world! Definitly much better than dieing from cancer. And that about the curch: Well I guess I will never see those women, as I haven't been going there for a long time already Rolf Kalbermatter

QUOTE (TobyD @ Sep 17 2008, 12:09 PM) He's just babbling! Let him be! Rolf Kalbermatter

QUOTE (Val Brown @ Sep 10 2008, 02:36 PM) Try http://www.ni.com/beta instead. I guess the original link was a copy paste action. This link will resolve to digital.ni.com/<something cgi alike>, the beta subdirectory is not valid on the digital.ni.com server. QUOTE (Gabi1 @ Sep 10 2008, 05:50 PM) thats so sad, i cant convince my bosses for LV 8.6... i would work for any company that would provide it for me (in Munich) in the mean time, can you expand on the beta? Ahhh, if there wouldn't be that: (in Munich)!!!!! In case nobody has noticed yet we would love to have an extra collegue or two here! Rolf Kalbermatter

QUOTE (alfa @ Sep 12 2008, 12:36 AM) What you write about is not scientific and therefore there is no way to proof in a scientific way that you are right or wrong. It's something everyone has to find for his/her own and where nobody can really tell anyone how it is. Therefore you should take my comment with a big grain of salt. It is my subjective feeling and made as a subjective comment. One thing I often feel in your posts is a bitterness about the world not giving you what you think you deserve. Work on that and you will see that the world has no obligations towards you. It only gives back what you seed. Rolf Kalbermatter

QUOTE (Pollux @ Sep 11 2008, 06:32 AM) He is deadly serious about it. And quite wrong too Rolf Kalbermatter

QUOTE (Val Brown @ Sep 10 2008, 05:18 AM) But in the case of dll based Toolkits porting them to their RT platforms or to Mac and Linux won't help you a single yota to use them on your custem uP system that you target with the Embedded uP SDK. Those DLLs need to be compiled and limnked into a shared library for the specific target with the toolchain for that target and possible with additional libraries needing to be ported for extra runtime support if those libraries use more than just the C runtime library. Without source code you simply can't do that. Rolf Kalbermatter

QUOTE (dannyt @ Aug 21 2008, 05:01 AM) There is no trick to get more information with native functionality. But there is an iptools.llb library over at the dark side I have posted there that calls into the Windows network management API and returns to you just about anything that you could get with ipconfig too, which by the way calls the same API anyhow. Rolf Kalbermatter

QUOTE (Val Brown @ Aug 14 2008, 03:27 PM) I have only played with the LabVIEW Embedded Version in LabVIEW 7.1 the predecessor to the Microprocessor SDK. There seems to have been quite some changes incorporated since but doesn't the Advanced Signal Processing Toolkit contain specific VIs that call out to some DLL. If that is the case I do not see how you could port that DLL to your target CPU at all without the DLL source code and I think you won't be able to get that from NI. Rolf Kalbermatter

QUOTE (osvaldo @ Aug 29 2008, 09:01 AM) It probably would run but will be quite a hog on the system. It's implementation from LabVIew 5.0 days was not bad for the tools and techniques available back then but it was definitly not written to be a concise application for resource constrained systems. On the other hand the PCs from those days had often less resources available than even the smaller real time targets nowadays, so it could still work well. Rolf Kalbermatter

QUOTE (jdunham @ Aug 9 2008, 06:22 PM) No! Unless they changed something in LabVIEW >= 8.2, casting or flattening will always give you a 16 byte memory for every single EXT. The reason for this is that LabVIEW tries to maintain a consistent flattened memory stream format on all platforms so it goes through the extra hassles of not only byteswapping the data to maintain Big Endian format on the flattened side but also of extending the plattform specific EXT format to the biggest possible common denomiator which is the now obsolete 16 byte extended format of the 68K floating point unit. Rolf Kalbermatter

QUOTE (Yair @ Aug 21 2008, 08:07 AM) The reason is that this time is actually generated and maintained by the good ol' 55 Hz timer tick interrupt counter from ancient DOS times. On startup some memory is initilialized with the time and date from the real time clock and this timer tick then continously maintains the increment of this memory. In regular intervals (not sure but usually once per 24 hours) the memory location is synchronized with the real time clock and/or an external time server (Windows Domain server or internet time server). Direct access to the real time clock is minimized since it is accessed through IO space and that is an extremely slow operation in comparison to nowadays computer components. In Windows 3.1 days there was a system.ini setting that allowed to make the system time being updated with the multi media timer instead which could have a 1ms resolution. But on heavy interrupt loaded systems (network traffic, IO boards such as DAQ and Video) this could lead to an overall degradation of the entire system to the point where normal application execution was almost impossible. Even on nowadays computers and with the default 55 Hz timer tick you usually see a significant drifting of the system time in between synchronization points when heavy interrupts occur such as with intense network traffic or a fast non DMA DAQ operation. Rolf Kalbermatter QUOTE (giopper @ Aug 31 2008, 04:32 PM) My explanation is that the error in the determination of the parameters of the linear relationship, although very small, on the long run can produce a large time error (I got 50 ms over one hour.) Another explanation is that only the PC clock is drifting (after all, 50 ms/h = 1.2 s/day only) but at the moment I have no way to verify this. As said the system time on Windows which is used by LabVIEW for its absilute time is really only synchronized on regular intervals with the real-time clock in the PC or an external time server. For the rest it is a purely interrupt driven software timer tick that can and usually does get some drift from other interrupt sources in the system. But even the real time clock, despite its name is anything but real time. It is a timer driven by a local quartz based oscillator whose quality is not to bad but definitly nothing to write home about either. 100ppm clock deviation is certainly something that should be already considered rather good in that respect so that would be in the worst case already up to 10 seconds a day. In reality the deviation of that real time clock is actually more in the range of a few seconds a day but it definitly is not real time. You can however setup Windows to regulary synchronize with an internet time server including NTP and should then get a more accurate timing. Still the default resolution of ~16ms will remain even then, although I thought this was at some point 10ms for NT based OSes. Rolf Kalbermatter

QUOTE (JiMM @ Aug 25 2008, 08:31 AM) One hit wonder and internet domain as user name :thumbdown: Seems like spam with a probablity bordering so close to certainity that I can't calculate the difference to real certainity with a double numeric in LabVIEW. Rolf Kalbermatter

QUOTE (Jon Sjöstedt @ Sep 3 2008, 03:39 AM) Not sure about Solaris really and Solaris in many ways is often a bit special. But on Linux it seems to be implemented by range locking the entire file. fcntl(fd, F_SETLK, &amp;lock) Rolf Kalbermatter