From Friday, January 17th 11 PM CDT (January 18th 5 AM UTC) through Saturday, January 18th 11:30 AM CDT (January 18th 5:30 PM UTC), ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
@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! 😄
@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.
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!
