LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Access x,y coordinates in the field of a graph in a page of a tab control. I would like to understand how it's done.

I use shift registers when I need to use them.  You like them.

 

I don't like the lines running through blocks as they physically get in the way of objects. Yes, I do see value in them and do use them, but apparently not as much as you.  So what?

 

I like local variables.  The key is to know what they're holding based on dataflow.  I find them convenient for getting and sending information, but, again, they have to be used wisely. ...after all, were this C I'd be using local variables.  To each his or her own.

 

Back when I was really green (relatively) with LabVIEW, after discovering the power of the shift register I had them all over the place.  But then I discovered the local variable, and now my vis are much cleaner, to me.  You see it as kludge.  Ok.  I'm not going for any awards here.  I'm just trying to solve a problem with the correct tool, as I see it.

 

If software is written in the most clever way possible then by definition one is not clever enough to debug it.  I forget who said that, but when I heard it it really rang true to me.  Right now my kludge is 127KB at my last look.  And so what?  It works.

 

Can it be written better?  I am quite sure the answer is yes, and as I learn more I'll be able to do what I've already done many times: look back and laugh about how I solved problems, not knowing enough at that time.  If all you have is a hammer, then everything becomes a nail.  I read the posts here and I can see many have loaded toolboxes.  I want that knowledge.

 

You should've seen some of the giant block diagrams I created ...before I discovered the ease of the state machine.  Anything that can be done in series can be easier done with a state machine, or that's how I see it, today. ...perhaps not two months from now.  I always reserve the right to do something different, later.

 

Do I like hearing you call my work a kludge?  No.  Do I really care?  No, not really.  But of course I'd like to hear about the better way of doing the same thing, especially when the advantages are explained.  Perhaps they truly are advantages. 

0 Kudos
Message 21 of 33
(401 Views)

@3d0g wrote:

I use shift registers when I need to use them.  You like them.

 

I don't like the lines running through blocks as they physically get in the way of objects. Yes, I do see value in them and do use them, but apparently not as much as you.  So what?

 

I like local variables.  The key is to know what they're holding based on dataflow.  I find them convenient for getting and sending information, but, again, they have to be used wisely. ...after all, were this C I'd be using local variables.  To each his or her own.

 

Back when I was really green (relatively) with LabVIEW, after discovering the power of the shift register I had them all over the place.  But then I discovered the local variable, and now my vis are much cleaner, to me.  You see it as kludge.  Ok.  I'm not going for any awards here.  I'm just trying to solve a problem with the correct tool, as I see it.

 

If software is written in the most clever way possible then by definition one is not clever enough to debug it.  I forget who said that, but when I heard it it really rang true to me.  Right now my kludge is 127KB at my last look.  And so what?  It works.

 

Can it be written better?  I am quite sure the answer is yes, and as I learn more I'll be able to do what I've already done many times: look back and laugh about how I solved problems, not knowing enough at that time.  If all you have is a hammer, then everything becomes a nail.  I read the posts here and I can see many have loaded toolboxes.  I want that knowledge.

 

You should've seen some of the giant block diagrams I created ...before I discovered the ease of the state machine.  Anything that can be done in series can be easier done with a state machine, or that's how I see it, today. ...perhaps not two months from now.  I always reserve the right to do something different, later.

 

Do I like hearing you call my work a kludge?  No.  Do I really care?  No, not really.  But of course I'd like to hear about the better way of doing the same thing, especially when the advantages are explained.  Perhaps they truly are advantages. 


Just sharing my perspective on the conversation.

I have seen some of the messiest codes that work like a charm, but anyone new will be trying to find a needle in a haystack to debug it. I believe none of the guidance from the experts was to discourage your approach but just try to make it streamlined and neat so that you can systematically debug when the code becomes very complex with a lot of functionality.

 

If all that matters is the functionality, you can do anyway to get it done. But once you hit a snag along the way it would be hard for others to debug as your implementation is "your" own approach that may or may not be easily understood by others to help you. If nobody else will be looking at the code to add functionality or debug, then it does not matter how the code looks as long as the functionality is achieved.

 

Santhosh
Soliton Technologies

New to the forum? Please read community guidelines and how to ask smart questions

Only two ways to appreciate someone who spent their free time to reply/answer your question - give them Kudos or mark their reply as the answer/solution.

Finding it hard to source NI hardware? Try NI Trading Post
Message 22 of 33
(390 Views)

@3d0g wrote:

I use shift registers when I need to use them.  You like them.

 

I don't like the lines running through blocks as they physically get in the way of objects. Yes, I do see value in them and do use them, but apparently not as much as you.  So what?

 

I like local variables.  The key is to know what they're holding based on dataflow.  I find them convenient for getting and sending information, but, again, they have to be used wisely. ...after all, were this C I'd be using local variables.  To each his or her own.

 

Back when I was really green (relatively) with LabVIEW, after discovering the power of the shift register I had them all over the place.  But then I discovered the local variable, and now my vis are much cleaner, to me.  You see it as kludge.  Ok.  I'm not going for any awards here.  I'm just trying to solve a problem with the correct tool, as I see it.

 

If software is written in the most clever way possible then by definition one is not clever enough to debug it.  I forget who said that, but when I heard it it really rang true to me.  Right now my kludge is 127KB at my last look.  And so what?  It works.

 

Can it be written better?  I am quite sure the answer is yes, and as I learn more I'll be able to do what I've already done many times: look back and laugh about how I solved problems, not knowing enough at that time.  If all you have is a hammer, then everything becomes a nail.  I read the posts here and I can see many have loaded toolboxes.  I want that knowledge.

 

You should've seen some of the giant block diagrams I created ...before I discovered the ease of the state machine.  Anything that can be done in series can be easier done with a state machine, or that's how I see it, today. ...perhaps not two months from now.  I always reserve the right to do something different, later.

 

Do I like hearing you call my work a kludge?  No.  Do I really care?  No, not really.  But of course I'd like to hear about the better way of doing the same thing, especially when the advantages are explained.  Perhaps they truly are advantages. 


Obviously, you like to write long paragraphs instead if trying to learn. It is also obvious that you are coming from a programming background that is text based where "variables" are central to identify data. Nothing wrong with that, but you need to change your approach playing to the strength of dataflow, and not fight it by using text based paradigms.

 

Local variables just point to the transfer buffer of front panel objects. Front panel objects are for user interactions, not for data. Typically "the wire is the variable". With a wire, you can tell immediately where the data comes from, where it is modified, and what depends on it. All this is lost when using local variables. So you are saying that a 2D object "local variable" goes less "in the way" as a 1D object (wire)? (Even with a local variable, you still need a wire to connect it!) Often all you need is one wire containing a cluster of all properly named data in a shift register. You can access/modify is by using (un)bundling by name for perfectly self-documenting code.

 

Your aversion of sharing any complete LabVIEW code tells me that you are embarrassed about it. A perfectly normal feeling, that however blocks you from quickly advancing in your quest to the perfect code (small, elegant, readable, maintainable. expandable, scalable, bulletproof, ...). I still recommend that you attach your code and I will demonstrate how to do it correctly (80% smaller, cleaner, readable, fully functional, etc.). Nothing to lose! 😄

 

Cutting your development and debugging time in half is like doubling your paycheck! Well worth it! 😄

0 Kudos
Message 23 of 33
(363 Views)

Santhosh,

 

Still getting used to how this forum works, but had a moment to respond.

 

I don't think my code is messy and difficult to read for another, but yeah, you get it it seems.  Thank you for chiming in!  ...how hard is it to follow a state machine?  The states are clearly readable, right there!  You wouldn't have "bounce the ball" when you were really doing "write the memory."  ...or that's how I view it, from my cryptic coding lair. 🙂 

 

I mean this conversation all in good productive fun, understand.

0 Kudos
Message 24 of 33
(332 Views)

You AB, if I may identify you that way, for short, have me intrigued!

 

I want to hear more.

 

For instance, I view your shift registered cluster of variables cumbersome, but then I'm working with a hammer and perhaps a knuckle-buster.  You may just have a full Snap-On suite in a garage!

 

Seriously!  And do you really want me to pack up my whole project just to check out my kludge?  Maybe Vader someday later, but right now he's just a small fry.  I'll bite, but if the taste is bad...

 

Please explain how the shift registering of a pack of variables in a cluster passed through all states is the better route for understanding the code when viewed from the outside.  I want to understand your reasoning.  ...in a single block I can see it, but throughout the whole thing?  Please elaborate a little more, if you have the time.

 

My apologies if I tend to type just as I speak.  I view this as we're in a conversation, not a series of reduced bullet points in a company email.

 

I have to run, again.  ...busy busy.  Cheers!

 

P.S.  This:

 

"Local variables just point to the transfer buffer of front panel objects. Front panel objects are for user interactions, not for data. Typically "the wire is the variable". With a wire, you can tell immediately where the data comes from, where it is modified, and what depends on it. All this is lost when using local variables. So you are saying that a 2D object "local variable" goes less "in the way" as a 1D object (wire)? (Even with a local variable, you still need a wire to connect it!) Often all you need is one wire containing a cluster of all properly named data in a shift register. You can access/modify is by using (un)bundling by name for perfectly self-documenting code."

 

really has me intrigued, but the cluster in a shift register is my first interest.

 

And, thank you, AB  ...if you don't see it as insulting to shorten your name like that.

 

 

 

 

0 Kudos
Message 25 of 33
(330 Views)

@3d0g wrote:

 

My apologies if I tend to type just as I speak. 


A VI is worth a million words. I program (and think!) graphically and all your descriptions are way too ambiguous.

 

My offer still stands: Attach your VI (or a simplified skeleton) and I will rearchitect it (i.e. better functionality, 20% of the code, readable, scalable, maintainable, more efficient in CPU and memory, probably fits on half a postcard, etc.).

 

You'll be amazed! Trust me! And it's completely free!

 

I won't keep discussing things using words alone. It's pointless.

0 Kudos
Message 26 of 33
(317 Views)

I'll say this and then I have to run away again.

 

I say it is cumbersome because I can't create new on the fly.  Instead, I have to go back to the cluster definition and insert the new thing.  I can easily just create a control/indicator and now I have local variable access to it.  I can use it blocks away in my state machine. ...I can just keep moving forward.  Also, yep, I have a stray control floating out there.  And again, so what?!  I hide it off screen somewhere.  I have regular cities sitting out there off-screen, and I can easily just scroll over and look at them any time I want.  What was that last number?  Scroll over and take a look.  Aha!  That's not right.  Aha!  The sign changed on me!  Oops!

0 Kudos
Message 27 of 33
(314 Views)

plus my local variable can be a cluster, complicated as I want or don't want

0 Kudos
Message 28 of 33
(313 Views)

As your code expands with new features in the future, it will become exponentially more convoluted and unmaintainable. It is important to learn the right way before you dig yourself into an even bigger hole. Seriously. Over and out!

 

We all started once. Nothing wrong with learning. Even if you mowed your lawn all your live with nail clippers, you might switch to a real lawnmower once you learn how to use it. Same thing!

 

Message 29 of 33
(300 Views)

Sometimes it is dangerous to operate a lawn mower, particularly one with loads of bells and whistles.  This is my experience with LabVIEW.  I take it step by step, doing my best to know the ground will not give way, but if it does to have not shifted my balance just yet.  I would like to think I am not mowing the lawn with nail clippers, now, but to be honest about it, as I read this forum, the responses given, I sure do feel like it at times. 

0 Kudos
Message 30 of 33
(237 Views)