ShaunR

Unfortunately not. LV 2009 has problems if trying to save to a version less than 8.6 (like completely crashing).

There is a NXT toolkit for labview. It has its own separate "G" compiler. And I believe you can write code in labview which can be imported into the NXT software. How that works, I don't know. Perhaps one of the NI lurkers could shed more light.

Version 2.0.0.0 is now available. Now includes the following: Added support for Tip Strips Now also scans the block diagram of vis and extracts string constants. Added an example build.

The language "behind the scenes" in Labview is C++. "G" IS labview.

As you probably read on the other thread. I cannot save to a version less than 8.6. I did try to download 8.6 and install it to see if I could do what Asbo did, but it fails to install in Windows 7. Perhaps some kind soul will convert it for you as Asbo did for the other poster.

Well. Its not the only reason. It also creates a copy of the data.

I'm no expert on compilers (and I avoid knowing about low level stuff like the plague when I can). But i don't think LV continuously compiles. If I remember correctly, it only does it when you click the "run" button. But that may have changed in recent versions. So all we are really talking about is a "macro" for creating polymorphic vis? We can certainly make polymorphic vis (like the read from spreadsheet file.vi). The only difference between the prims is you cant see the source. There may be a technical difference since we all know LV is really just a big API with a graphical front end, but from the users view it is the same. Its the same with XControls and native controls.

I think his definition is "A sense of superiority to all others"

Nope. Lost me again Indeed. But most of your article was about specifying dynamic types. Well. Except for terminology (I think). I was talking about "Strict" type checking rather than "Static" linking. LV doesn't type check at compile time. It does it before compilation to make sure you don't do anything the compiler will object to. Its more like "syntax" checking. OK. I was under the impression that you were promoting dynamic type checking rather than "Generic Programming" (which I've never heard of before) since most of the article was about types. Re- reading it for the 8th time and in that context, your comments in this thread make a bit more sense (hopefully ). We can already wire a number of types to (taking your example) an add function. Is the only concern that it fixes the output to the same type? Are you saying that we should also be able to wire the inputs of an add function to (say) 2 double numbers and wire directly to a string without converting first? Hmmm. Obviously not what I said previously then. This is what is really confusing Don't most of the primitives do this already (numeric functions, comparisons etc)?

I think I see what you are saying. I think the difficulty is that the type philosphy of a language is generally defined at the languages conception as to whether the reponsibilty of type information should be in the compiler or the run-time environment (or both and how much in each). Those that choose "compiler" or "run-time" are pretty much stuck with it and only the hybrids are capable of moving towards natively supporting one or the other. Thats not say though that strict typed systems are unable to "emulate" dynamic typed systems or vice versa. Its just its not natively supported which is I think is what you are suggesting for LV. I think also its a personal choice as to what a particular programmer programmer is comfortable with. The arguements are stacked equally on both sides. Dynamic typing has the advantages you have outlined. But it is also a lot easier to shoot yourself in the foot. Even with the polymorphic vis that Labview provides, it is considered good programming style not to use this feature and instead explicity cast it to the receivers expected type for this reason. For that (amongst others), I prefer strictly typed languages and (if there is a choice of equivelents) choose the strictly typed every time since I don't have many feet and theres too many holes already .

NXT-G is very different. It doesn't have the granularity of LV and is more akin to a LV toolkit rather than G itself. Saying they are both "G" is a bit like saying Delphi, C++, PHP, Java etc are all "TEXT". This is what NXT-G looks like. You can also see that it is completely sequential.

Search and replace SQL on the database with PHPMyAdmin. heres an example. Its not that difficult. http://www.zimmertech.com/tutorials/php/60/mysql-search-replace-phpmyadmin.php

I don't get it Labview IS a strictly typed language (only functions of the same type can be connected and a conscious decision to "cast" must be made to other types) as opposed to (say) PHP which isn't (anything can be assigned to virtually anything). Delphi is another example of a strictly typed language whereas C is loosely typed (I think). The add function you describe is a strictly typed primitive with polymorphism which, in other strictly typed text based langauges, would be an overloaded function. So I don't really see what your getting at. What am I missing?

Do you think that will let me save it in 8.0 then?....lol.

How's your PHP?

Aha. Because mine isn't 8.6 its 2009. BUG!

Whilst a "State Machine" (action engine) has many advantageous features. A state machine is used to "break" the dataflow feature of LV so that so that a program can "branch" dependent on dynamic conditions. Your requirement has a sequential nature and doesn't really require one ("Do this" THEN "Do That" THEN "Do It All Again"). What you will end up with in your situation is either sections of code waiting in a particular state until something happens (which deteats the object), or lots of code to check state information to enable a decision to be made on which state to execute next (messy). I would put each "action" into a sub and vi use labviews dataflow to sequence the operations so the top level vi would be farily simple and look something like.... Initialise.vi Heat Up.vi Stabilise.vi Aquire.vi Shutdown.vi But I like simple things

Me too. I even deleted bits until I had just an event case left.....still crashed when trying to save. One point to the man with the magic digits. The secret?

Is anyone able to save this to a previous version other than 8.6 for the OP? Both LV x32 and x64 crash if I try to save below 8.6.

Ooooh. I'm getting confused between this thread and the axis one Have a look at this A little bit of thought and it can be extended to acheive what you require.

Well. Getting the length of an array and wiring that to the "N" terminal (I think the LV equivelent would be an array of clusters or objects) isn't that inefficient. But labview arrays are "self indexing". If you wire an array through a for loop and don't wire anything to the "N" terminal, it will iterate for the number of elements that are in it.

Well. If you can't spell "peeling" then why not?

I knocked up a quick version of what I was talking about earlier about creating "views" of logged data. If you were to use it you would still need to figure out how to get "Month" data in properly and slide the scale (don't want to do all your work ) But should give you an idea.

ทุกเวลา