TimothyMoulder
Member
These are all good answers, but I think the question is pretty high level.
I just put out a post on a Unitronics experiment I ran :
http://www.plctalk.net/qanda/showthread.php?t=24898
In the past, I've always divided up my processes into discrete steps and written not subroutines, per se, but functions. "Loader Forward, Indexer Rotate, Unloader Down", etc.
This file is part of an examination I'm doing into a different sort of structure. Instead of "Loader Forward" as a separate routine, I would make the loader motion a part of the larger cycle, and call a generic routine such as this to execute it.
Like Terry, I'm not quite sure what to call this sort of arrangement, and I'm better at visualizing it than explaining it, I imagine. But what I'm hoping to get out of it is a collection of canned routines I can reuse over and over, without the need to incorporate them into a defined "station" routine. Think "macro". I think it will really speed my programming up.
I recommend first to ignore one oft-trumpeted piece of advice given out here - "Be consistent." Hooey. First, decide on a path you think will be easy and comfortable for you to work with, and do it. As problems, inefficiencies and issues appear, adapt and grow.
Choose a path stick to it until you finish the job, then re-evaluate and evolve. The next job will offer new challenges that will make you adapt what you have done, or strike out in a new direction entirely. And don't be afraid to play - in our line of work, we call that "research".
TM
I just put out a post on a Unitronics experiment I ran :
http://www.plctalk.net/qanda/showthread.php?t=24898
In the past, I've always divided up my processes into discrete steps and written not subroutines, per se, but functions. "Loader Forward, Indexer Rotate, Unloader Down", etc.
This file is part of an examination I'm doing into a different sort of structure. Instead of "Loader Forward" as a separate routine, I would make the loader motion a part of the larger cycle, and call a generic routine such as this to execute it.
Like Terry, I'm not quite sure what to call this sort of arrangement, and I'm better at visualizing it than explaining it, I imagine. But what I'm hoping to get out of it is a collection of canned routines I can reuse over and over, without the need to incorporate them into a defined "station" routine. Think "macro". I think it will really speed my programming up.
I recommend first to ignore one oft-trumpeted piece of advice given out here - "Be consistent." Hooey. First, decide on a path you think will be easy and comfortable for you to work with, and do it. As problems, inefficiencies and issues appear, adapt and grow.
Choose a path stick to it until you finish the job, then re-evaluate and evolve. The next job will offer new challenges that will make you adapt what you have done, or strike out in a new direction entirely. And don't be afraid to play - in our line of work, we call that "research".
TM