Loops
pnaidoo1502
Posts: 18
Can we use For loops in a netlinx program, eg
INTEGER i
for(i = 0 ; i < nLENS_STEPS ; i ++)
Thanks
INTEGER i
for(i = 0 ; i < nLENS_STEPS ; i ++)
Thanks
0
Comments
You can even use WHILE loops as well!
Keep in mind that NetLinx is not 0 based, all arrays start at 1.
integer i
FOR( i = 1; i < 19; i ++ )
The code above gives me the following error. Any ideas
ERROR: 764): C10567: Unrecognized node type [423] in compileStatement()
I had the integer i, within a function call. Got it fixed
Now I know I shouldn't ask this but wasn't that questioned covered in any of the courses that afforded you the title of "AMX Certified Expert Programmer", or were you playing hooky that day?
You can also have multiple loops going at the same time.
for(i=1, j=10, k=90; i<10; i++, j++, k--) { send_string 0, "'i:', itoa(i), ' ~ j:', itoa(j), ' ~ k:', itoa(k), "; }If designed right, loops are the key for writing limited amounts of code and for great rides.
mmmmm Train wrecks.... :P~
I've gotten into the habit of using nested for loops for feedback. For example, if I have multiple panels, thereby having several instances of input feedback, I may try something like this:
Dev TP[]={...} //19 Touchpanels Integer in_butt[] = {...} //64 input buttons Input [19] //Monitors panel's individual input selection local var integer TTPCount local var integer TTButtcount For (TTPCount=1;TTPCount<=19;TTPCount++) { FOR (TTButtcount=1;TTButtcount<=64;TTButtcount++) { [tp[TTPCount],in_Butt[TTButtcount]] = (input[TTPCount]=TTButtcount) } }The train wreck cones in when I do some quick coding, use local variables for counters named x, x1, x2,etc., and then accidentally transpose x1 for x2 or x.... I actually did that in my programmer 2 class and brought my processor to a screeching halt. Even my instructor was impressed at how elegantly I crushed the controller.
Just be careful when nesting for loops.
Get a new plate each time you go to the buffet, even if it is a few steps away and your current plate only has a couple crumbs on it.
I liked the clean plate correlation.
And though it's been said, I too agree; keeping variables which can be handled locally out of the global realm definitely helps to keep one clean of an over-excess of global variables which leaves one open for tying up code over a single variable.
For heaven's sake, don't be snooty; give the dishwasher kid a job.
I do, but I give the loop counters a descriptive name to keep them straight. I like to make them full-time variables so I can track them in the loop for debugging.
I have to admit that I almost never use stack_var or local_var myself. I just don't think it burns up that much RAM.
I had a system run out of memory and just stop because of too many non-volatile declarations in its component modules. Since then, I always declare variable either non-volatile or stack as a matter of course (when the situation allows it, of course), because I don't want whatever I'm working on to become that last straw in the next project. I by no means consider it necessary in every case, but neither does it hurt anything, and it saves that panicked re-write at the 11th hour.
Just be aware of the fact that a program with NO non-volatile variables will cause the debugger to freak out! You have to have at least 1 non-volatile variable, and it doesn't have to do anything
Jeff
Once a program is running properly, this is not usually an issue. I will often declare a variable local until it's debugged, then change it to stack afterward. But, more often, I'll bypass the buggy debugger altogether and use carefully placed send_string 0's.
Oh, I didn't say that I don't use Volatile. All my variables have one of those keywords before it. Volatile, Persistent...
I just don't bother with local_vars or stack_vars. It's no biggie. For me it's nice to not have to worry about keeping the value for a little time after the event and/or loop's done.
I see that this has gone a bit far afield, so I'll pile on.
I prefer to use Local_Var as I can check them in the "buggy" Debugger if I have problems (which is all the time). I was told that Stack_Var's were blown out as soon as the event was over and therefore uncheckable.
Is there REALLY that much of a memory savings from Local to Stack? Or is there another advantage I don't know of?
Thanks, and excuse my ignorance on this. Even though I've gotten my "certificationizationism" (sorry W), I've learned most of my AMX programming from trial and error, and cannot recall everything I learned in a classroom 3 years ago.....
Local_Var is simply, in a sense, more easily read, as it retains its value even after that particular method has been left.
I tend to use Stack_Var more often, as I don't particularly like relying on a method to perfectly retain the value of the variable since it was last entered. If I need the value elsewhere, I simply create a global variable, otherwise I don't mind reintroducing the value to the variable each time its used. The only exception I've encountered for this is when requiring the variable to be accessible from within a Wait - in which case a Local_Var is necessary.
I like this method, as it does keep memory rather cleared up, but mine's just one style among many.
Hope this helps.
There is no implication, it just doesn't work well. Try debugging a variable inside a module that is running multiple instances, or came from an include file. My special favorite is when you add a watch, and it asks you which of four includes it's named in to use ... and in fact, it's not in any of them ... even when you dragged it directly from the code. I'm not saying it's useless ... I use it all the time, in fact. It just has some serious flaws.
I agree that dragging in variables of multiple instances tends to work poorly. For this reason I tend to just type in the variable myself, such as: "FUNCTIONNAME:VARIABLE" and call it a day. Admittedly, however, I've little experience with debugging multiple instances of a module, so I'll submit that to you by default.
Out of curiosity, are you aware of any completely debilitating pitfalls of the debugger? I mean, something that does not work, causes problems, and/or has no workaround?
I have it crash to program many times. It seems to be when I'm monitoring several variables and they get a little verbose. It's particularly dicey if you're monitoring a buffer or two.
I've gotten in the habit of 'saving' a lot when I'm running the debugger.
And like a piggy bank this is just a penny. (I know, I'm old)
Thank you. So no real advantage, just preference. Any real memory difference?
As for debug, I've not had many problems with it (I recall at one point having the same problem that "ericmedley" did, but I think it was because I was doing serial communication to the master. 99.99% of the time I'm using IP communication even if the system is not on a network, and I no longer seem to have that problem). But I usually am monitoring only global variables in my main code. And I try to use proven modules for multiple devices (I'm currently working on a project with about 50 of the same LCD panels, monitoring variables inside 1 of the nearly 50 instances of these modules would be a daunting task).
But I HAVE noticed that if you setup Debug with a variable that has multiple instances, and isolate that instance once, EVERY time I restart Debug, I have to RETELL the Debugger which instance it is (after a reboot for example). This could be though because I do not save any debug info with the program.
But I'm pro Debug. It's got it's problems, but it's a handy little tool.
Hope this helps.