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

QUOTE(crelf @ Dec 11 2007, 04:06 PM) Could that be because of intervention by some other significant person? Rolf Kalbermatter

QUOTE(RONIN10 @ Dec 11 2007, 04:03 PM) If it is really just an integer that is returned it's very trivial. Configure the parameter to be an int32 or whatever integer you expect and also tell it to pass that parameter as Pointer to Value (contrary to as Value). That should take care of your problem. Rolf Kalbermatter

QUOTE(george seifert @ Dec 10 2007, 03:33 PM) When you have to calculate the weighted average of several pixels, the result will be much more smoothly when you have 8 bits per color to distribute your values in, than in 8 bits altogether. Rolf Kalbermatter

QUOTE(menghuihantang @ Dec 10 2007, 05:32 PM) That is our resident http://forums.lavag.org/crelf-m181.html' target="_blank">LAVA champion in number of posts. He has for anything and everything here on LAVA an answer, but sometimes it is tongue in cheek. But he seems to slow down recently. Probably due to his preparations for a travel back home to down under. And his book on LabVIEW imaging is quite good. Rolf Kalbermatter

QUOTE(menghuihantang @ Dec 10 2007, 01:31 PM) I've made quite a lot of responses to posts about external code in LabVIEW on LAVA, the NI Developer Exchange, Info-LabVIEW mailing list and the German cousin of LAVA, and also published some short articles about this topic on http://expressionflow.com/author/rolfk/' target="_blank">Expression Flow but I haven't written a book so far Rolf Kalbermatter

QUOTE(Norm Kirchner @ Dec 7 2007, 11:36 AM) The modern version of our childhood telephones But it's not clear if that is a network outlet or a power outlet. I sure hope for the first. Rolf Kalbermatter

QUOTE(menghuihantang @ Dec 9 2007, 09:26 PM) Yes, http://msdn.microsoft.com/' target="_blank">MSDN (Microsoft Developer Networks) is your friend for any Windows API question. If it's not there it is undocumented and that means any other information you can find on the net might be right or completely off the tracks. As far as to your function prototype, where the heck did you get that from? It uses datatypes Microsoft never used so far and is also inherently wrong. The W suffix to the function indicates that it is a Widechar (16bit Unicode) function, but the third parameter is CStr, which is basically an 8 bit ANSI string. That simply can't be right. TIP: When searching for a WinAPI function on MSDN, never use the function name with the A or W suffix. While those functions are exported with the W or A suffix, Microsoft considers them equal as far as documentation is concerned. Which one is used and pulled in gets decided during compilation, based on preprocessor settings. For LabVIEW you always want to use the A version since LabVIEW strings are 8 bit MBC strings. For the general understanding of these things: Knowing a good bit of C will help very much. The DLL calling interface is inherently C based and so are all its terms and conventions. That means that the Call Library Node can't really make it in any other way either, as unfriendly that interface can look to a LabVIEW only programmer. And that means as tempting those API calls could seem to you, without learning some basic C knowledge first you are really in for a hard ride with lots of crashes when you go down that road. Rolf Kalbermatter

QUOTE(Norm Kirchner @ Dec 10 2007, 01:22 AM) Cool down! IMHO, MDI (Multiple Document Interface) is overrated and simply a pain in the ###### to work with. Saying that since you can't easily do it in LabVIEW, LabVIEW can not be seen as a general programming language is definitely more than stretching it. I do believe there is a reason why the Mac did not support SDI either and at least for me it is also because it is simply a useless UI concept. The reason that they do not want to have LabVIEW as a general programming language is because it would take the control out of their hands. It would need to be submittet to a standardization gremium and from that point on onwards NI would have much less to say of what the next direction in development would be. Also submitting it to a standardization gremium would mean lessening or even giving up the exclusive patent protection over some of the features as otherwise there wouldn't be any standardization gremium taking the submission serious at all. All in all lots of work, even more lobbying, as getting something accepted as standard requires lots and lots of lobbying, and all that for the doubtful benefit of loosing control over a very nice and interesting programming environment. I don't see TI doing anything like that very much either and from a business point of view it wouldn't make sense anyhow. Rolf Kalbermatter

QUOTE(Justin Goeres @ Dec 8 2007, 01:49 AM) Doesn't surprise me! They are two different processes that suddenly are tight together through Windows message queues. That's bound to create problems in newer Windows versions and most likely things will get even worse on Vista. I did that in the past with IMAQ Windows being embedded in a LabVIEW front panel. Works flawlessly at least up to Windows XP but here the IMAQ Windows are really LabVIEW Windows too, so no external process being suddenly forced into embedding in LabVIEW. Rolf Kalbermatter