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

QUOTE (normandinf @ Aug 22 2008, 11:32 PM) No! Conversion and Typecasting are NOT the same. Conversion tries to maintain the numveric value. "Tries" because it can't always do that if you try to convert a number into a representation whose range is smaller than the current number. In that case the result is clamped (coerced) to the maximum/minimum possible value for that range. Typecast maintains the binary representation in memory. This means the numeric representation will in most cases change significantly. In the case of typecasting enums into numerics and vice versa you also have to watch out that both sides use the same number of integer bits (so a 16 bit unsigned/signed integer for instance). LabVIEWs Typecasting uses internally Big Endian stream representation. So Typecasting an i32 into an U16 enum will normally give you the value corresponding to the first enum entry since the upper most 16 bits of the i32 are likely 0. Rolf Kalbermatter

QUOTE (Val Brown @ Aug 26 2008, 01:37 AM) Ohh and don't even attempt to try and run a timed loop. It's internal mechanisme was last time I checked tightly coupled with drivers that go directly into the Windows kernel. Wine is an application level API translation software. They do not have nor want to try to provide a kernel level translation layer so far. Rolf Kalbermatter

QUOTE (Michael_Aivaliotis @ Aug 18 2008, 11:12 AM) I haven't tried it recently! But CrossOver is basically based on Wine (with some extra hacks to make it sometimes work better for standard applications like the unavoidable Office Suites from an unnamed company in Redmond and in the case of Mac of course for the unmatched apps like iTunes etc.) LabVIEW 5 and 6 did run already many years ago (around 2000 or so) fairly well on Wine of that time. But its installer was also a lot lighter and less problematic than the super duper multi mega monster installer of recent LabVIEW versions. And also before LabVIEW 7 you could in the worst case just copy an entire LabVIEW tree over to the Wine system and run it from there without the need for an installation. On the other hand Codeweaver has done tremendous work on Wine to support the MSI installer technology and it is currently in a state that allows a lot of applications to install with little or no problems. So I think you have a realistic chance to get LabVIEW itself running on Wine and/or Crossover. Wine versus Crossover is here likely to make no difference since CodeWeavers has LabVIEW for obvious reasons not on their radar, although I think installation of Wine on a Mac is still supposed to be quite a bit of a hassle whereas CrossOver would seem to give you a smooth installation experience. Of course things like IO drivers are most probably not gonna work at all. This likely is even true for VISA and slightly possibly even TCP/IP. NI-DAQ and just about any other NI-something would be a waste of time to even attempt to try. I stopped with dabbling with LabVIEW on Wine after LabVIEW for Linux got available. It simply made not much sense anymore to deal with difficulties and some strange screen drawing artefacts when LabVIEW was run on Wine. Rolf Kalbermatter