LabVIEW
Change values elements in arrays
toniaz wrote:1st of all, are we allowed to use a wt* in this forum? 😄
wt* are you talking about? 😮
No, just do what the professor wants you to do. I guess it's not about the game per se, but an easy way to learn some simple array operations and general programming techniques. That's a good thing! 🙂
toniaz wrote:Not quite, but 1st since our cover is blown, i will answer you specifically, what I want to do when I press right is
It wasn't that much of a cover. 
Do you really think that you're (plural since I'm including your classmates) the first ones to ask fpr help on school projects? If you're honest with us up-front you will find the community much more amiable and willing to help, though we still won't do your homework for you. We remember that we were students once also. 
Although for a lot us, we didn't have the internet. Imagine that.
toniaz wrote:
Well thanks Alan 🙂 it's just that I need time to comprehend the VI before I start doing a similar one
That's a good idea. Just make sure you don't develop any bad habits. Alain uses some rather strange constructs and you might think about what's more efficient. Here are some clues.
Alain uses an empty timeout case to poll the stop button 100x per second, just pumping hot air. I use a stop event and no timeout case. Place an indicator on the loop iteration terminal [i] to see what's more preferable.
Alain abuses a control as indicator and for array storage, writing back to itself via a value property node. Since the array is functionally an indicator (It's value is changed programmatically and not interactively!), making it a control is backwards, because the operator can mess with it's value (e.g. clicking several LEDs on). Writing to a control/indicator via a value property node is also several orders of magnitude less efficient because such an operation is synchronous. Without changing anything else, replacing the value property with a local variable would already significantly improve the code performance. Value property writes should be reserved for scenarios where a local variable cannot work, e.g. when changing a value from within a different subVI via a control reference. It is always better to keep the data in a shift register or feedback node instead of a front panel object.
In contrast, I keep a static array in a tunnel, modifying a single element for display of the final result. Alain uses 7 array operations, I use only one. 🙂
Alain does not use the boolean values at all (unwired!), but gets the event details via a control reference and value property. This is rather indirect and hides a lot of code inside other cases. It is also more error prone and difficult to debug, e.g. of you would mispell a label or case by accident. ("Down" vs. "down" for example).
While these considerations are not very important for a simple program, you should always code in the best possible way. If you don't, your next huge project with gigantic data structures and complicated UI will have performance problems and be unmaintainable. A factor of seven in code complexity for the same functionality can make the difference between a diagram that comfortably fits on one small screen and a diagram that is unmanageable, covering several screens.
Happy coding! 🙂
toniaz wrote:Ok is there a way to delete this thread?
Of course there is a way, but it probably should not be done!!!
Excessive Orwellian editing of posts distorts history, meaning that the same class next year cannot learn from it and will make the same mistakes again. In addition to the programming issues, this thread (and several others on this same topic) contain useful information for the entire community, such as how, and how not to ask questions.
Not every thread needs to be an archetype of prose, wit, insight and depth. 😄
Moderating posts should be kept to an absolute minimum and should be reserved to a small a well defined set of cases (spam (cheap fake ED pills from china!), offtopic (how do I unclog my drain) , obscene, illegal (here are some LabVIEW 2009 activation codes that everybody can use for free!!!), personal attacks, copyright, NDA violations, privacy issues (I accidentally posted my home address and social security number!!!), etc.) and the bar should be set rather high.
If in doubt, don't moderate and don't request moderator actions!
A forum has ways of self regulating that works well. We've just seen it happen. 🙂
toniaz wrote:Third of all, LabVIEW is very new to all of us, imagine that after just a couple of weeks of taking LabVIEW classes, we are asked to complete this rudimentary task, we have LAbVIEW classes but we haven't touched arrays yet (not in any way whatsoever), all what we do is work around with SPEEDY-33.
Fourth, well we do have internet, we do not have handbooks, okay if this is not an excuse, try considering that we weren't expecting anything to do with a project!!! There wasn't any buffering, any intro, just plain hit-on-the-head tic tac toe...
Well, I'm sure you've heard this said before, but in real life you are often asked to do things that are beyond your current level of knowledge. What's important isn't getting the final solution - it's what you do to find out what you don't know, what you need to do to go about getting the knowledge, and what you do to apply that knowledge to getting to the final solution. As the saying goes, it's not the destination that matters, it's the road and journey you take that does.
