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

QUOTE(RONIN10 @ Dec 7 2007, 04:34 PM) I had my local NI rep and another NI guy visiting from TX sit down with me and take a look at this together. It was beyond their certainty as to what was wrong, but they seemed to key in on the void pointer as being the likely culprit and (unfortunately) didn't have a solution in mind. So when I go to run this, the node execute succesfully in that I get a zero return value (specified in the source code as successful completion of the function), but the I32 I'm wiring to the void pointer doesn't get populated with information I'm requesting (number of parameters in teh data stream, in this case). It also causes an Error 15 code in LabVIEW and crashes the whole application after hanging for a few seconds. Any suggestions of ways to correct this and why it is behaving as it is? Thanks in advance! There are two things that could be wrong: datastream_t is not a standard C type so I'm not sure if treating it as an int32 is ok. If it is just a handle you get from some open function then it should be ok. The void pointer quite likely is the culprit here. Unfortunately C is not a language that describes parameters in itself sufficiently in terms of the exact meaning and context of their use. void pointers are especially bad in that respect as they can be really anything you can think of. What it is can only be decided by knowing the exact context of that function, which you didn't give in any way. It could be a byte buffer in which the function is supposed to write the data from the stream. In that case the caller (your LabVIEW diagram) needs to allocate that buffer. As the function has no parameter to tell the size of that buffer and therefore you would need to know that size before calling that function I can only think of a few possibilities: - The function works with a fixed size buffer always. - You can pass in a NULL pointer and get the needed size as return value of the func'tion to allocate that buffer and call the same function again. - There is another function that can tell you what size is required. These things can not be deducted from the function prototype you show but only from the source code, a possible code example or the function description in some programmer manual to the library. Another possibility is that the function allocates the buffer itself and returns a pointer to it in the void parameter. In that case you would need the exact structure of that buffer and hope it is a flat buffer. Retrieving non flat data (pointers inside that buffer) in such a way is a mature pain and for me ALWAYS a reason to write a wrapper DLL or in your case since you have the DLL source code an additional more LabVIEW friendly exported function. Also since the DLL allocated the buffer it should provide you with a function to deallocate it later on after you don't need it anymore as otherwise you are creating memory leaks. All in all there is way to little information available to tell you what exactly goes wrong and even less to give you detailed ideas about how to do it correctly. And that is not LabVIEWs fault but the nature of C which does not fully document the parameter datatypes of functions in general und the exact usage context in special. Rolf Kalbermatter

QUOTE(gammalight @ Dec 6 2007, 10:14 PM) Probably recompiling the low level support library of the Report Generation Toolkit for Office 2007 and installing that with your application instead of the default 2003 version would solve that issue. So MS most probably did it again and changed the ActiveX interface between Office versions enough, that LabVIEW gets trouble running it withoug recomiling its VIs. Rolf Kalbermatter

QUOTE(Vladimir Drzik @ Dec 6 2007, 06:33 AM) I was attending a presentation during the LV days all over the world that followed the NI week. The presenter, an active LabVIEW developer much into especially these areas of LabVIEW, only said that the number of executions systems was now more dynamical depending on the actual number of cores LabVIEW could find. He didn't say specific numbers because I think that is hard to do anyhow. There is most probably some heuristics involved that use to some point somewhat arbitrarily chosen values, with lots of tweaking, testing and such during the devlopment. And those heuristics will likely change again as different multi-core designs get available, different CPU architectures are introduced and different OS support is introduced. One possible starting point is above mentioned VI. It should give you an idea about what the currently used setup is for any particular machine. Interestingly on my system, an Intel Dual core machine it reports 4 CPUs Rolf Kalbermatter

QUOTE(gustav @ Dec 5 2007, 12:43 PM) The timed loop apparently calls into external DLLs. Somehow and somewhere that external code does not properly get informed about the shutdown so the process hangs on the exit callback of that external DLL, most probably. I haven't used the timed loop very much but I think this is one thing that has happened to me too in the past, including in the development environment. Asynchronous external code is tricky in LabVIEW, even for the creators of LabVIEW :-) Rolf Kalbermatter