about sending 1 email a time
- Thread starter BTCAD
- Start date
apostolakisl
Senior Member
You also are setting ram values to 0 at start up. That isn't needed, ram values always are 0 at startup, they don't get saved when power goes off.
In regular English, what is it you are trying to accomplish?
In regular English, what is it you are trying to accomplish?
Lou Apo said:
Values are set to 0 on startup, sure, but they are not set to zero on program reload (not sure about RAM, but VAR are not).
So if you have a program running, make a change, upload that - it will load and start running but with whatever WAS in the registers.
If you want your code to always behave the same, you may need to clear them to ensure consistent behavior.
apostolakisl
Senior Member
rossw said:
Ram values are set to 0 with each reboot and with saving plc code. You never need to have code to set a ram value to 0 as part of the initial running of the code. My comment said "You also are setting ram values to 0 at start up. That isn't needed". I didn't say anything about VAR.
apostolakisl
Senior Member
In fact, a good way to run a startup subroutine is as follows
Start
tsteq ram1 0
call sub startup
all the rest of your code
set ram1 to something not 0 (this line can go here, just before end, or just before ret down below, if you put it here it gets run every time the code cycles through, which is should only be done if ram1 might get set to 0 by other code)
end
startup:
everything you might want to happen at startup
set ram1 to something not 0 (this line is best to put here, unless you are using ram1 in your other code where it might have the value of 0 when the code gets to "end")
ret
You can still use ram1 in the rest of your code, just so long as it doesn't get set to 0 when the code passes back to start.
Start
tsteq ram1 0
call sub startup
all the rest of your code
set ram1 to something not 0 (this line can go here, just before end, or just before ret down below, if you put it here it gets run every time the code cycles through, which is should only be done if ram1 might get set to 0 by other code)
end
startup:
everything you might want to happen at startup
set ram1 to something not 0 (this line is best to put here, unless you are using ram1 in your other code where it might have the value of 0 when the code gets to "end")
ret
You can still use ram1 in the rest of your code, just so long as it doesn't get set to 0 when the code passes back to start.
Lou Apo said:
I have a great dislike for subroutines where they are not actually used to reduce code overhead/complexity.
In your example, I'd use:
start
do stuff here to initialise whatever you need
ie, set outputs, set variables, ram etc.
main:
do all you normal code looping here
goto main:
end
no unnecessary overheads, no spaghetti code jumping all over the place, just plain, linear, uncluttered code.
Of course, there is no, one, "right" way to do stuff, but there are a whole lot of "wrong" ways!
(I just find the obsession with callsub irritating)
apostolakisl
Senior Member
I would very much disagree with you.
Subroutines are very valuable tools for separating programming into logical sections. There is nothing spaghetti about it. To condemn subroutines is contrary to the basic tenants of programming.
Subroutines are very valuable tools for separating programming into logical sections. There is nothing spaghetti about it. To condemn subroutines is contrary to the basic tenants of programming.
