Rolf Kalbermatter

QUOTE(tcplomp @ Dec 29 2007, 01:09 PM) It's complete. ASCII doesn't define more than that. The rest are extended characters that depend on the currently set local, the font used etc, etc. Rolf Kalbermatter

QUOTE(psi @ Dec 29 2007, 05:47 PM) Hmm, you will have to buy a runtime license per system, and that is about 500 Euro in single quantities. Interesting yes, not expensive only if you are not planning to make an embedded device, although I'm sure you can negotiate volume license prices. QUOTE LabVIEW Real-Time supports not only NI hardware device. LabVIEW Real-Time can supports Third Party Device. Can I Use a Third-Party Device with LabVIEW Real-Time (RT)? Third-Party Compatibilit Configuring the NI Real-Time Environment and NI-VISA toRecognize a Third Party Device Porting a Windows Device Driver to the NI Real-Time Platform Yes for desktop PCs but not for arbitrary embedded development systems. For some reasons I was assuming that embedded was the route the OP wanted to go. Rolf Kalbermatter

QUOTE(psi @ Dec 28 2007, 05:51 PM) But LabVIEW realtime only supports NI hardware targets (some of them use Pharlap OS and other newer ones with PPC CPU use VxWorks) and somewhat specific x86 hardware with Pharlap (ETS). If the OP wants to use NI hardware targets or can live with a more or less standard PC hardware platform then LabVIEW realtime of course would be best. Rolf Kalbermatter

QUOTE(Dr. Dmitrij Volkov @ Dec 28 2007, 09:07 AM) The equivalent of DLLs in VxWorks are .out files. They are basically shared libraries created with either the VxWorks development system or the free GCC compiler. I've only created one of them so far using the freely downloadable GCC version for VxWorks to create a shared library for NI's newer real time controllers. But I'm not sure what you are trying to do here. LabVIEW for VxWorks is only available for the NI realtime target systems. For your own VxWorks based systems you would have to go the LabVIEW Embedded route. Not very cheap but maybe you are doing that already. Rolf Kalbermatter

QUOTE(Yen @ Dec 21 2007, 07:59 AM) A well Heinlein :thumbup: . Certainly an interesting author. Although I wouldn't share every of his visions and he seemed to have some militant ideas at time, he also had a very impressive way to describe environments and social interaction that were strange and bewildering, while at the same time still somehow believable. My first contact with him was by stumbling more by accident over "Stranger in a Strange Land" and it took me quite some time and writing an essay over this book for school to see the finer points of this book. And it changed the way I looked at many things remarkebly. Rolf Kalbermatter

QUOTE(Yen @ Dec 19 2007, 03:15 PM) Well, yen, I think you might be right that the built in nodes may not really have a string name in the palette menu, but only a resource identifier, that points back into LabVIEW (or one of the .rsc files in the resources directory). It's a long time since I looked into this. I'll see what I can do in terms of getting the resource information in a more user friendly way into LabVIEW. But I need to search that stuff and most probably clean it up a bit. Rolf Kalbermatter

QUOTE(thomas2609 @ Dec 19 2007, 09:10 AM) That should get you the exact same time that is displayed in a LabVIEW timestamp set not to use UTC!! So not really sure what the benefit of that function would be. Rolf Kalbermatter

QUOTE(tcplomp @ Dec 19 2007, 07:44 AM) Indeed I concentrated on the technical ability to do what Tit asked for, but in hindsight I would be interested to know, what he wants to fix. LabVIEW 8 has great control over if you want to show UTC or local time and since LabVIEW 7 the date/time conversion for local time considers the timezone that was active at the time the timestamp represents rather than the current time. There are potential issues with the recent dynamic daylight saving time periods, caused by massive adjustments of that period all over the world. In Windows at least, only Vista allows for such dynamic daylight saving time periods. Older Windows versions will always use the current daylight saving period to calculate the local time for any timestamp, even in times where another period was valid. I would expect that these things can be even a bit less perfect on RT targets, but there you usually shouldn't need to display local time anywhere. Instead just save the numeric timestamp, which was always UTC as long as LabVIEW was multiplatform and then interprete it on the desktop application accordingly. Rolf Kalbermatter

QUOTE(Yen @ Nov 8 2007, 01:06 PM) If I only had more time! I hacked once into these files and once you understand the Macintosh like resource format basics (same as used for VIs, LLBs and most other pre-XML LabVIEW file formats) it's not that difficult to get at the info. Problem is my hacks were never really getting out of proof of concept state with the exception of the VI Library shell extension, but that was entirely written in C. But it reminds me that LabVIEW itself exports a Resource Manager API and it should be not to difficult to target that one with a small VI library. I think it is in fact what the palette API does too. From there figuring out the structure of the palette resources won't be to difficult anymore. Rolf Kalbermatter

QUOTE(Aristos Queue @ Dec 18 2007, 06:52 PM) I do pin them down occasionally and intend to keep them there. But I also have a habit to close as much windows as possible so automatically, that whenever I need that damn pinned palette again, it is already gone Rolf Kalbermatter

QUOTE(TiT @ Dec 19 2007, 05:49 AM) Windows API: Get/SetTimeZoneInformation http://msdn2.microsoft.com/en-us/library/ms724944(VS.85).aspx' target="_blank">(link) But it's not a trivial API and you have to do potentially some extra stuff such as getting a system Time structure correctly filled, etc. The one thing you can't avoid is that you need to adjust the application privilege before you can change the system time information. Because of that it would be best to write an external code DLL that does this all in a neat and proper way and import this as a single function into LabVIEW. In the discription to the TIME_ZONE_INFORMATION structure it states that to disable daylight saving time you need to set the month value in both date structures to 0, among a few other conditions. Rolf Kalbermatter

QUOTE(tcplomp @ Dec 15 2007, 02:30 AM) Well, not entirely true. You could download the LabVIEW evaluation version at that time and install it over the old one, preserving your license file, and everything was fine. The only difference between the upgrade and a full install was in fact preservation of already set things such as the license file. Also installing theat version and activating it with the LabVIEW 8.2 serial number worked too, since they were both in terms of the license manager 8.2. Unfortunately they pulled the 8.2.1 evaluation download and replaced it with the most recent one for 8.5 and here a non active SSP will render your 8.2 serial number invalid for this installation. Also 8.5 is in quite a few things more like a regression to 8.2.1 than anything else. But 8.5.1 is coming out somewhere next year. So if you upgrade now with SSP you get that upgrade automatically. Rolf Kalbermatter

QUOTE(Cool-LV @ Dec 13 2007, 08:29 PM) Don't do that! This source code is protected by copyright laws and NDAs. Either you got it as illegal copy from internet and then are not allowed to use it or look at it or under an NDA which you would just have preached by making it available for download. Rolf Kalbermatter

QUOTE(M.M.K @ Dec 13 2007, 05:49 AM) Simple office network with DHCP. Obviously with a cross cable DHCP won't work but that you must have found out otherwise ping couldn't work either. Rolf Kalbermatter

QUOTE(LV Punk @ Dec 12 2007, 10:37 AM) Yes but probably for analyzing their C source code, not for including that technology in a LabVIEW analyzer tool! Would be nice but I think the complexity of such a task would be very high. Coverity has been getting some publicity this year by offereing their services for free to some Open Source projects. But they did have some problems in getting those code scans be performed regularly. Apparently they had not enough staff to do the regular code base scans for all the projects they had offered that service. Rolf Kalbermatter

QUOTE(jbrohan @ Aug 1 2005, 07:43 PM) Your DST calculation might be flawed a bit. Before LabVIEW 7.0 LabVIEW always used the current time to evaluate if a timestamp had to be adjusted for DST. So if you run a VI using that in the summer it will return a different DST status and timezone offset for a specific timestamp (not the current one) than when you execute it in the winter. In LabVIEW 7.0 I think they remedied that by taking the DST status that was actual at the time the timestamp itself represents except for timestamps that are before 1970 or something like that. For those it still uses the current time independant of the DST status that was actual at the time represented by the timestamp itself. Rolf Kalbermatter

QUOTE(Jim Kring @ Feb 23 2007, 04:49 PM) I think you wanted to say absolute times here. QUOTE(JFM @ Feb 27 2007, 09:18 AM) Thanks for all your comments. I'm not arguing that it should be possible to add two absolute times, what I'm trying to say is that I would like the TimeStamp data type be able to contain relative values as well. Then the addition/subtraction nodes would make sense. Why should the TS be limited to absolute times, when this internally is in fact only a relative time (but displayed as absolute time)? Trying to force your way here? Since you want the addition to work on timestamps they should be made to support relative times? But the timestamp was just invented to be able to properly distinguish between absolute and relative times. Before the timestamp datatype was available it was simply a floating point (well very early in LabVIEW it was in fact an unsigned 32bit integer but that got slowly remedied in later LabVIEW versions) number too. This gave problems as it was not really clear if a value was supposed to be absolute times or not So the timestamp was added just for that reason. To have a unique datatype that could represent absolute time so that LabVIEW could make smart decisions how to operate on that. The disallowence of the addition operator on timestamps is one of those smart decisions. QUOTE Another point is that the TimeStamp (TS) data type is not a floating point value (as far as I understand it), but rather a more accurate representation. It is in fact a fixed point representation. 64 bits for the integer part and 64 bits for the fractional part. As such it is obviously at least as accurate as a double floating point number for integer numbers but in fact can't represent the same range as a flaoting point number. While a flaoting point number can represent numbers from ~ -10^308 to 10^308 seconds the timestamp only can go from ~ -10^19 to 10^19 seconds (+-3*10^11 years relative to 1904). The difference is however that the integer part of the timestamp has still a resolution of 1 seocond when representing such a number while the floating point will have a resolution of ~10^293 seconds when representing its maximum value. In fact a 64 bit floating point number will get a resolution higher than 1 second as soon as it goes over ~ +-4.5*10^15 seconds (only ~1.4*10^8 years). The additional 64 bytes of a timestamp for the fractional part allow for a total resolution of 2^-64 seconds which amounts to ~ 5*10^-20 seconds. Not sure if quantum theory allows for such a small time interval at all but I think LabVIEw 8 only used 32 bits of those 64 fractional bits anyhow. Still all this number theory is really not that interesting and if it would be only because of the range and resolution a double floating point could have worked for a few more thousend years for sure as long as you don't require sub millisecond resolution. But the additional benefit of a distinct datatype really made the timestamp extra interesting. The only complain I have is that they didn't think about extra features such as allowing for timezone information being encoded in the timestamp too. I guess reserving 16 bit of the 64 fractional bits for this wouldn't have made the timestamp less useful. After all a resolution of 3.5*10-15 for a timestamp (around 3 femto seconds) still seems quite above any possible need even for hyper physics. Rolf Kalbermatter

QUOTE(M.M.K @ Dec 13 2007, 01:42 AM) Does it work with both applications locally? Are you sure you use the correct IP adres? If the first answers no, you have messed with the VIs somehow rendering them unoperable. I know the examples you mention work fine for me. If you know your IP adress is right too, this is definitely out of LabVIEWs control, and something in your system, network setup or whatever is blocking you. In that case there is not much we could do for you as we can't see the system and check its settings. Rolf Kalbermatter

QUOTE(Cool-LV @ Dec 12 2007, 08:36 PM) I'm not sure they have an ActiveX component. The entire SDK is completely written in C without any traces of C++ or whatsover. And Macrovision wants to see money from anyone using their FlexLM solutions. Not likely that they will give a a free to use FlexLM ActiveX control to call. But I could be wrong. I only looked into this some time ago for a client who wanted to have his software application protected. It's probably easier to check out Microsofts MSDN site and look for their licensing API. Although they do not document all details, they do allow use of this API from other applications. Maybe that you can retrieve the machine ID from there somehow. Just be aware that this machine ID is in fact an arbitrary ID compiled together from an arbitrary selection of machine identification parameters. So this ID will always only work in comparison to the software that created it, meaning a machine ID computed by FlexLM is something that should be considered completely different than one computed by the MS Licensning API. Rolf Kalbermatter

QUOTE(RONIN10 @ Dec 12 2007, 11:03 AM) Hmm if it is still crashing then something is not right. What, I really can't tell you from what you show so far. Without more details about the last parameter or some short C code excerpt showing how it is normally called my possibilities to help are completely exhausted. Rolf Kalbermatter

QUOTE(frentzen @ Dec 12 2007, 08:24 AM) Are you sure this is not just your actual homework or assignment that you want us to do for you? Figuring out what this all does, shouldn't be to difficult if you know a little bit about LabVIEW, Java and XML. If you don't, I'm afraid you will fall through anyhow during your presentation, trying to explain some precooked explanations you don't understand yourself. Rolf Kalbermatter

QUOTE(george seifert @ Dec 12 2007, 08:36 AM) Sorry, I've never seen these errors and if a LabVIEW repair didn't help, hmmm! Maybe try to do a device driver repair too?The timed loop goes deep into the system and and could depend on some low level NI device drivers that might have gotten belly up. Rolf Kalbermatter

QUOTE(Karthick.v @ Dec 12 2007, 03:00 AM) It says you must have the IMAQ Vision library 7.1 or higher not LabVIEW! You have an IMAQ Vision Library and valid license? Rolf Kalbermatter

QUOTE(Val Brown @ Dec 11 2007, 10:23 PM) Specifically some of the components on the Driver CDs/DVD was updated and Upgrading them can mess up your MAX configuration and cause "bodily harm and death". I found this last one quite entertaining but I guess that is American cautioness. Otherwise someone installing this in a life support system (which you are strongly adviced to not do with any NI material in all NI manuals) could cause some serious casualties. Rolf Kalbermatter

QUOTE(Cool-LV @ Dec 11 2007, 10:57 PM) NI didn't do it. They just bought the Macrovision FlexLM source code license and use that one. I've had a look at that code at some time. It is not a piece of C code anyone would want to dig into and make modifications to. Very convoluted, complicated and all in all unmaintainable IMHO. Means you try to compile it and hope it works and once it does leave your fingers from it. It's also sad that around 1MB of the LabVIEW executable concists of this FlexLM code. LabVIEW itself does in 1MB assembly code a lot more and a lot more useful stuff. FlexLM supposedly takes some specific machine parameters such as the HD serial, CPU ID, MAC adress etc. etc. and using some hash algoritmes calculates such IDs. Rolf Kalbermatter