Leaderboard

LGAS

Actually that is not true either. Generally, compiled VIs in a x.x.1 version can be loaded into x.x.0 runtime and vice-versa and executed. It could in some corner cases give strange (visual) effects or calculation artefacts but in general it works. But before LabVIEW 8.5 if you loaded a VI that was not EXACTLY the same version into the development system, it always got recompiled automatically. That is true if you try to load the VI through VI server. It is not true if you compile those VIs into a DLL and call that DLL through the Call Library Node. If the LabVIEW version the DLL is created with does match the caller version, the VIs in that DLL are loaded into the current LabVIEW system and executed there. If the versions do not match (not sure about the bug fix version difference here), the DLL is loaded through the according runtime system and run in that way.

Actually, that's a bad example, as 8.5 and 8.5.1 were binary compatible and you did not have to recompile VIs written in one to run in the other. This actually presented a problem in fixes made in the code generation in 8.5.1, because if you had a VI which was buggy in 8.5, it remained buggy in 8.5.1 until you forced a compile (either by editing and saving or by force or mass compiling). The example is valid for older bugfix versions (and maybe newer as well). That's correct. Version X of the RTE can only run VIs saved in that version of LV. As such, the points made here: are also correct. For the last part, I'm pretty sure you would need to explicitly load the VIs in the correct RTE by running an application compiled in that version and using VI server to call that application (the app input on the Open VI Reference function), although I believe DLLs don't need this, presumably because they have a standard mechanism of using the correct run-time. As for the actual question, what are you trying to get to? I don't know Java, but it seems to me that binary comptibility is akin to the different versions of LV and source compatibility is akin to not being able to open code written in a newer version or to having your code stop work if the API's interface was changed (like the report generation VIs in 8.6 or the config file VIs in 2009 which were put into libraries and therefore caused you to lose the ability to do certain things (which, admitedly, were not in the public APIs as represented in the palettes). In any case, I don't think you have to borrow things from other languages. Some concepts apply and some don't.

I am homeschooling my kids as well. You can get a copy of the Student edition for homeschoolers, in fact NI encourages this. I teach a class to several homeschool kids. I talked to NI and with the help of my local rep, I was able to get some free copies of LVSE. granted they were LV8.2 but they were free. Here is a picture of my son with James Kring (He thinks James is a LV god) He wrote his first program when he was only 10 and his project for the class was to make a radar gun for hot wheels cars. We took a Hot wheels car ramp and some photo diodes (I think, its been a while) the kids had to write a program that read the start and the stop with a NI 6008 and calculate the time and how fast the car was going. Very neat project, they loved it. http://lavag.org/ind...ewimage&img=181 Hope this helps,

Yes. Homeschoolers are allowed to buy the LabVIEW Student edition. (Good idea, by the way. ) From the Acedemic Superstore website you can get the LVSE for $80 as long as you can provide one of the following: Membership in Home School Association Receipt for Home School Curriculum Letter of intent to home school from a state agency The only reason I knew how to get this info so quickly is that I was looking to get LVSE for myself. Hey, I consider myself a life-long student, but alas I don't meet any requirements to get LVSE.

Maybe this awareness shows up during the teen years. That's why teens have a reputation for being difficult - they are trying to reconcile their past and current lives.