Control Freak
Member
OP
- Join Date
- Jul 2004
- Posts
- 44
Well it appears that this post has gone completely off topic because we suddenly switched over to splitting hairs over whether or not we are 'selling/advertising'. Dont get me wrong, Stephens input is very welcome, and certainly appreciated...thanks, It actually sounds like a nice product. Perhaps when i do get around to automating my home, since i will be the end user, I'll consider Entertron.
Switching over to one-standard PLC type would certainly simplify the process of standardizing. It's just not an option. If it were, I'd have pressed all of my current customers toward one platform, and focused on it alone.
The original post was asking for suggestions/input from other more experienced programmers on different approaches to standardizing the programming process.
Now that this has been established, let's get back to the topic at hand...simplifying.
Everyone who builds programs from scratch, mainly OEMs I would think, has to start somewhere.
My boss comes to me with a machine, and a list of processes involved on it. The machines all vary somewhat, but in many regards, most of the individual station types are the same.
(i.e. Infeed tracks turn on/off the feeder bowls, dereelers dereel, inspection stations inspect, pick & places pick and place, etc.)
Sometimes there is more than one feeder bowl, more than one dereeler, sometimes the machine is fed via servo, sometimes the machine is loaded by hand. Once a process is programmed (lets say a pick & place) that code would typically work for any other pick & place station. The next time a pick & place station is required, theoretically, that same code should do the trick.
My post to my fellow PLC professionals is asking for tips/suggestions to streamline program design. The platform doesnt really matter.
What are your opinions/tactics for handling a variety of machines, with a variety of stations?
Typically, I start with the a section for an ENCODER or CAM_SWITCH (if there is one). In it I put my one-shots from my required timing points.
Next, I create a section for MASTER_FAULTS. It would contain logic pertaining to overall machine issues: low-air, guard violations, emergency stops, etc
Then, I'd create a MASTER_CYCLE section to control the machine cycle. If the other stations are in a safe condition to start, then let the machine cycle.
Then perhaps my SHIFT_REGISTER section. Usually its only a rung or two, but it's easy to find and once it's setup, I never really need to even go into it.
Next, my individual stations:
BOWL_TRACK
SERVO_FEED
PICK_PLACE_1
PICK_PLACE_2
REJECT
INSPECTION
PACKAGING
Lately, in these sections, I have been starting each with 3 rungs each with an internal coil:
and then using contacts from those coils in the MASTER_CYCLE section.
If an instant stop occurs in a particular section, then the MASTER_CYCLE logic stops the machine instantly. Conversely, If an cycle stop occurs in a particular section, then the MASTER_CYCLE logic stops the machine at the end of it's current cycle.
If the machine hangs up, it's easy to open the MASTER_CYCLE section, see what is inhibiting the machine cycle, then go to the appropriate section, and right at the top of the routine, the 3 rungs should easily direct me (or the end user) to the problem. It's a new approach to me, but hopefully it will simplify things.
Of course there are other issues regarding addresses, and what to do if a particular section is not ready. I'm considering establishing pre-built screens on my touchscreens. I have 256 possible, and I rarely use more than 20.
Maybe I can build a PICK_PLACE_1_NOT_READY screen on screen #101 and a PICK_PLACE_2_NOT_READY screen on screen #102 and eventually end up with a large database of screens to import as needed. If I can establish a consistant address scheme with faults included for each screen, and the same addresses in my PLC, hopefully I can just cut/paste my rungs from each section and I'm ready to go.
sigh...it sounds so easy on paper.
Considering the scale of this undertaking, and the time it would take, it should be easy to see why I query my PLC brothers-in-arms for suggestions/comments.
John
Switching over to one-standard PLC type would certainly simplify the process of standardizing. It's just not an option. If it were, I'd have pressed all of my current customers toward one platform, and focused on it alone.
The original post was asking for suggestions/input from other more experienced programmers on different approaches to standardizing the programming process.
Now that this has been established, let's get back to the topic at hand...simplifying.
Everyone who builds programs from scratch, mainly OEMs I would think, has to start somewhere.
My boss comes to me with a machine, and a list of processes involved on it. The machines all vary somewhat, but in many regards, most of the individual station types are the same.
(i.e. Infeed tracks turn on/off the feeder bowls, dereelers dereel, inspection stations inspect, pick & places pick and place, etc.)
Sometimes there is more than one feeder bowl, more than one dereeler, sometimes the machine is fed via servo, sometimes the machine is loaded by hand. Once a process is programmed (lets say a pick & place) that code would typically work for any other pick & place station. The next time a pick & place station is required, theoretically, that same code should do the trick.
My post to my fellow PLC professionals is asking for tips/suggestions to streamline program design. The platform doesnt really matter.
What are your opinions/tactics for handling a variety of machines, with a variety of stations?
Typically, I start with the a section for an ENCODER or CAM_SWITCH (if there is one). In it I put my one-shots from my required timing points.
Next, I create a section for MASTER_FAULTS. It would contain logic pertaining to overall machine issues: low-air, guard violations, emergency stops, etc
Then, I'd create a MASTER_CYCLE section to control the machine cycle. If the other stations are in a safe condition to start, then let the machine cycle.
Then perhaps my SHIFT_REGISTER section. Usually its only a rung or two, but it's easy to find and once it's setup, I never really need to even go into it.
Next, my individual stations:
BOWL_TRACK
SERVO_FEED
PICK_PLACE_1
PICK_PLACE_2
REJECT
INSPECTION
PACKAGING
Lately, in these sections, I have been starting each with 3 rungs each with an internal coil:
-----|PRX 1|-----|PRX 2|-----|PRX 3|-----(READY TO START)
-----|NOT FAULT 1|-----|NOT FAULT 2|-----(INSTANT STOPS 1)
-----|NOT FAULT 3|-----|NOT FAULT 4|-----|NOT FAULT 5|-----(CYCLE STOPS 1)
and then using contacts from those coils in the MASTER_CYCLE section.
-----|INSTANT STOPS 1|-----|INSTANT STOPS 2|-----|INSTANT STOPS 3|-----(MASTER INSTANT STOPS)
-----|CYCLE STOPS 1|-----|CYCLE STOPS 2|-----|CYCLE STOPS 3|-----(MASTER CYCLE STOPS)
If an instant stop occurs in a particular section, then the MASTER_CYCLE logic stops the machine instantly. Conversely, If an cycle stop occurs in a particular section, then the MASTER_CYCLE logic stops the machine at the end of it's current cycle.
If the machine hangs up, it's easy to open the MASTER_CYCLE section, see what is inhibiting the machine cycle, then go to the appropriate section, and right at the top of the routine, the 3 rungs should easily direct me (or the end user) to the problem. It's a new approach to me, but hopefully it will simplify things.
Of course there are other issues regarding addresses, and what to do if a particular section is not ready. I'm considering establishing pre-built screens on my touchscreens. I have 256 possible, and I rarely use more than 20.
Maybe I can build a PICK_PLACE_1_NOT_READY screen on screen #101 and a PICK_PLACE_2_NOT_READY screen on screen #102 and eventually end up with a large database of screens to import as needed. If I can establish a consistant address scheme with faults included for each screen, and the same addresses in my PLC, hopefully I can just cut/paste my rungs from each section and I'm ready to go.
sigh...it sounds so easy on paper.
Considering the scale of this undertaking, and the time it would take, it should be easy to see why I query my PLC brothers-in-arms for suggestions/comments.
John