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

QUOTE (shoneill @ Sep 5 2008, 08:44 AM) And who created the begin of all? It's by definition an unanswerable question. Rolf Kalbermatter

QUOTE (shoneill @ Sep 5 2008, 06:56 AM) I think that goes over his book. How to create God. So those 2% are not created by God but do create it/him/her. An idea I would not completely dismiss but in the way he brings it it is not something I like very much. Rolf Kalbermatter

QUOTE (alfa @ Sep 3 2008, 03:11 AM) By saying that 98% of people are at animal level do you want to hint in any way that you are not part of those 98%? By making you stand out from the rest you would do really only one thing: pleasing and strengthening your ego. And that makes one being further away from any form of enlightment than any "intelligence on animal level". Rolf Kalbermatter

QUOTE (ragglefrock @ Aug 28 2008, 05:38 PM) Several reasons typecast could be slow with that. 1) Typecast is using BigEndian byte ordering internally. You may say now: but these are both numbers and not a bytestream, but for some very strange reasons, the byteordering for floating points in LabVIEW is not following this BigEndian scheme. So as far as I remember it will probably byte shuffle the data too when doing a typecast between integer and floating point. I know it doesn't do the right byte shuffling between byte stream and 2) Floating point values are put in the FPU to operate on them. Maybe Typecast does something unneccessary there since for a mere typecast involvement of the FPU certainly wouldn't be necessary. 3) 64 bit integers is a very recent addition to LabVIEW. If this was with LabVIEW 8.0 or maybe 8.2 it could have been that the typecast operation when 64bit integers were involved was anything but optimal. Rolf Kalbermatter

QUOTE (ragglefrock @ Aug 26 2008, 01:07 PM) You can typecast from any data into any datatype as long as both are flat. And there shouldn't really be a huge overhead by typecast. Since the memory stays usually the same. Its more a thing of the wire type (color) changing than anything else and that is an edit time operation, not a runtime one. For instance typecasting an uint16 enum into an int16 integer should not involve any data copying (unless the incoming wire is used somewhere else also inplace, but that is a simply dataflow requirement not something specific to typecast. If the memory size is not the same then yes there will have to be some data copying. But typecasting a 1D array into a string should really not cause a memory copy. The same memory area can be used and only its compiler type def is changed and the array length indicator adapted to indicate the size in bytes instead of in array elements. Rolf Kalbermatter