James Mcquade said:
CAUTION !!
when you call a subroutine, the logic is solved (just like its supposed to).
you turn on certain outputs.
then you turn off that subroutine and it does not scan.
several minutes later, you have a condition that needs those outputs turned off, BUT; the subroutine is not called so the outputs stay on.
subroutines are great don't get me wrong, I use them all the time.
I just want to point out an issue you can have by turning the subroutines off.
if I am wrong, someone please correct me.
james
Hi James,
You are not "wrong" in what you have suggested may happen, but I would suggest that the "issue" here would be down to poor programming more so than the fact that preconditional subroutines may have been used. Preconditioning JSR instructions is perfectly valid, as I know you are aware. But of course, yes, you do have to be careful when implementing such coding practices. I think that is what you are more saying here?
One example of using preconditional logic for a subroutine's JSR instruction may be an infrequent process event that may only happen once every so often to seldom. The logical subroutine required to be executed when this event occurs may be lengthy or quite taxing on the processor, or just unnecessary, and as such it may be undesirable to have this subroutine continuously executing while the event is inactive. A machine mode selector switch, for example - Here, other regularly executing subroutines may be required to temporarily or even indefinitely suspended their execution while the newly selected mode preconditions a different subroutine be executed. Often, the same input or output addresses may be used in more than one preconditional subroutine, where only one of these preconditional subroutines are executed at any one time.
If you have a scenario, such as the one you have outlined above, then you must make sure that all logic that is required to have control over any outputs has the means to do so. If programming, and a former function of the process requires a subroutine be preconditional and inhibited from executing under certain circumstances (this subroutine containing output instructions), then the latter function of the process, which must now further control these same outputs, must either precondition the same subroutine to execute under its certain circumstances, or, precondition another subroutine which also has control of the same outputs via further instructions.
Note: Again, both subroutines are not simultaneously controlling the same outputs via there instructions. Only one subroutine is executing at any one time.
That's a programming "method", which is valid (duplicate output instructions). Whether it's the best, clearest or safest "method", I'll not get into a debate over here. But to balance that "method" with another - I could also suggest that all output instructions be, where suitable, executed under one subroutine which is never preconditioned. Here, the preconditional logic for the output instructions within this subroutine may be executed within other subroutines, which themselves may be preconditioned. This way, no matter where the preconditions for the output instructions originate from, the output instruction logic is always executing.
In such cases, whichever method is implemented, they, and others, are valid. The key is to program these methods correctly so that the intended functions of the process or machine are achieved. Proper testing should help determine if any such anomalies, such as you have suggested, exist and then allow the programmer to address such issues.
Seeing, or using, preconditional Jump to Subroutine (JSR) instructions should not be feared, or avoided, but should be approached like most other programming features - carefully, thoughtfully, and with an open mind.
And for the Opening Poster...
Skidood said:
Hi guys, I am back in the game after a time away...and I have a real dumb question...
Dumb questions do not, or should not, exist on this Forum!
Welcome back.
Regards,
George
