-
Posts
4,940 -
Joined
-
Days Won
306
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by ShaunR
-
-
Hi ShaunR
Is it possible to get it in version 8.2.(1) please
.
Regards Bjarne
Unfortunately not.
LV 2009 has problems if trying to save to a version less than 8.6 (like completely crashing).
-
What you say about calling the code in the runtime is of course correct.
Reading the site it seems that they simply do a web crawl and assign the number of hits to the number of users somehow. Not terribly reliable but it's at least SOME kind of indicator I suppose.
I've never used NXT so I'm not aware of the differences. I was led to believe it was more or less LabVIEW (or at the very least based heavily on LabVIEW). I suppose exposing kids to inherent parallelism might not lead to much joy on Christmas morning....
Shane.
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.
-
While the IDEs may be radically different, are you so sure that the language "behind the scenes" is so different to warrant calling it a separate language to G?
Shane.
The language "behind the scenes" in Labview is C++. "G" IS labview.
-
thanx alot but there is one problem i am using labview 8.2 and the attachment saving in 8.5
could u plz reupload in 8.2 version
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.
-
It is!?
I've never heard that and strongly disagree with it. (Until someone can convince me otherwise.) It seems plain silly not to use them in places where they are appropriate.
Well. Its not the only reason.
It also creates a copy of the data.
-
Actually Labview does type check at compile time. Labview is always compiling your code behind the scenes while you're in the dev environment. Ergo, in Labview compile time == dev time. (Compiling is part of the process of building an executable, but building an executable != compiling.)
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.
No. I imagine a properly implemented generic vi in Labview would behave in much the same way as a polymorphic vi, except that you wouldn't have to write individual sub vis for each data type you want to support. You create a single vi with 'type placeholders' and Labview automatically creates the correct "sub vi" based on what you connected to the input terminal.
So all we are really talking about is a "macro" for creating polymorphic vis?
Some prims do, but we can't create classes or vis that do this. That's what Tomi is asking for.
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.
-
What is your definition of "spirituality"?
I think his definition is "A sense of superiority to all others"
-
Nope. Lost me again
Err.. I think you misunderstood. Sorry, I need to try to be more clear. I am talking about only static i.e. compile time type systems. Forget dynamic languages for now, I am not referring to dynamic type systems. I don't think dynamic type systems fit to LabVIEW dataflow paradigm very well.
Indeed. But most of your article was about specifying dynamic types.
In a statically typed language like LabVIEW, type checks are done at compile time. In LabVIEW the type checks are done actually at development time, but it doesn't matter for now. The whole idea of static type checking is to prohibit type mismatch at runtime. This far we both agree.
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.
Now generic programming IS NOT the same thing as dynamic type system. Generic programming can be made 100% type safe using type parameters and compile time type checking with a static type system. All type related bugs can be avoided like currently in LabVIEW.
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
).
The actual type comes into play when you place a VI that uses generic types on a block diagram. When you connect a wire with a specific type to a input that depends on some type parameter T, the type parameter T gets bound to the type you connected. That fixes the type of all inputs and outputs that depend on this particular type parameter. In dynamic programming, the type of the output terminals would be of type Dynamic. With type parameters the type of the output is fixed to something specific instead.
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?
As an example, consider a method creating a LIFO (last in, first out) stack of anything. In dynamic programming you would have an input of type Dynamic. The output terminal returning the stack would be of type Dynamic as well. In type parameter based generic programming the input would be of generic type T and the output would be of type Stack[T] (stack of items of type T). When you connect say integer I32 to the input of the create stack method, then the output would become fixed to a type Stack[i32] (stack of items of type I32).
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 (Mindstorms version of LabVIEW?) is listed at # 35 (0.237 %), one place above LabWindows CVI (#36 - 0.226%) whereas LabVIEW is at #48 with 0.162%.
This would place the Language G at a total of (0.237% + 0.162% = 0.399%) which would place it at #26, one place ahead of FORTRAN.
Aren't NXT-G and LabVIEW actually the same Language (G) ?
Shane.
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.
-
1
-
-
Do you mean all the links you've ever posted? Hmmmm - I don't think there's an easy way to do that other than editing each individual post. Anyone with php knowledge got any ideas?
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
-
Hi
I posted a new article to ExpressionFlow regarding type parameters. For me it is the one of the most missed features in LabVIEW. Check out the post.
Introduction to Type Parameters
EDIT: Seems like the links to expressionlfow still don't work from LAVA. Please copy paste from below
expressionflow.com/2009/10/23/introduction-to-type-parameters/
Tomi
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?
-
Ahhhh ... you should update your profile then ...
Do you think that will let me save it in 8.0 then?....lol.
-
Is there some way to get rid of that or put something else in its place?
How's your PHP?
-
I'm inclined to say, "I'm just that good" but I didn't do anything special. I wonder why my 8.6 install is so much more friendly than yours ...
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
-
Nope. No luck. I even tried rewriting portions of it to see if could get it to save. Crashes every time.
Sorry...
Me too. I even deleted bits until I had just an event case left.....still crashed when trying to save.
Victory!
One point to the man with the magic digits. The secret?
-
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.
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.
-
thanx alot i will try ur advice
but i can't achive "comper with real time " in case structures
if anyone have example uploaded plz
Ammar
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.
-
I'm wondering if anyone knows a better solution to this...
If I call a (for instance) Visual Basic DLL, and it returns a reference to a VB Collection (since LabVIEW doesn't directly support Collections), what is the best way to perform the equivalent of VB's 'For Each' on this Collection in LabVIEW?
If the Count of the items in the Collection is known, you can wire that to a For Loop in LabVIEW. However, if this Collection is an arbitrary length, the only option I know of is to use a While Loop and attempt to index an Item each iteration. Then I wire the Error Out of the property node to the loop control terminal to tell it to stop when we receive an error (which should mean we are out-of-range on our index).
This method seems inefficient and just plain wrong. But I don't see any other way to do this. What do you all think?
(Sorry if few of you have experience with Visual Basic...)
-Ian
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.
-
Are you saying I couldn't make a common, ordinary, everyday connection between "ringing" and "pealing"?
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.
-
1
-
-
To Michael, Thank you very much!
To Shaun: Korp Khun Mak Mak!
Rob
ทุกเวลา
Beginner question about indicators
in LabVIEW General
Posted
The "Event Structure" has a mouse event case you can select and tie it to your indicator. Then you can invoke another vi with the cluster on its front panel from within the event case.