overall PLC program management...

[Control Freak]

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:

-----|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

 

[Hundikoer]

Nice text, Control Freak

I can only add, that when I worked for OEM, I developed a program for pick-and-place machine. The machine had one main sequence which activated specified subsequence in every cycle and did not start second run before the subsequence was completed. The main sequence was always same but depending on machine the subsequences were different (one or two gripper machine etc.).

It is not easy to describe but I think it looks quite same as you described here. Just inside the "program" it is not good to use direct IO addresses, only memorybits.

So, Control Freak, if you think it is the solution you are interested in you can ask some more specific questions

 

[Tark]

Basically what you want to do is to break your machine down into modules. You keep everything generic. So you might have a infeed module, inspection module, pick & place module. You might even create sub-modules depending on your “stations”, for instance if your infeed station might have many different options, you might want to create sub-modules for the infeed module.

Now you need to compile a master data list for each module. Since I work mostly in W&WW, I will use a pump and a chemical pump for an examples –

Pump
DI – Auto Switch
DI – Hand Switch
DI – Pump Running
DO – Pump Run
HMI – Auto Switch
HMI – Hand Switch
Bit – Reset Alarm
Bit – Reset Timer
Bit – Reset Counter
Bit – Alarm Failed To Start
Word – Runtime Timer
Word – Counter

Chemical Pump–
DI – Auto Switch
DI – Hand Switch
HMI – Auto Switch
HMI – Hand Switch
Word – Flow
Word – Flow Pace Setpoint
Word – Pump Output Speed

Now not every pump or chemical pump will have an HMI Auto or Hand switch but I want to map my PLCs memory as if every Module does have one. So next I start to map my master data list to the PLCs memory. When you do so, you want to start with the least customizable PLC that you use. I use AutomationDirect PLCs, so I would start with AD since AD’s memory is fixed. You also want to map physical I/O to internal memory, so if you have a pushbutton or an analog input, you want to map this to internal memory.

Now you can start programming your modules. When you start programming your modules you need to take into consideration what data needs to be passed between modules in order for your machine to operate. So in the case of my pump example I would need to pass data to and from the module like Pump Able To Run, Pump Request Run, Pump Is Running, Pump In Alarm. So I would go back to my master data list and add this data to it. You want to keep this data as generic as possible, does it matter to the other modules why the pump is not able to run? No. Does it matter to the pump module why it was asked to run the pump? No. Another thing to take into consideration is the instructions available to each PLC manufacture you use. For instance if AB has a nice function for doing math but AD does not have that type of function, you might want to program your module that is used by the AB processor the long way to keep your module consistent with the module for AD processor.

Once your done creating your modules, you’ll of course have to create these for all the PLCs you use, you can create a machine program. If I was programming with RSLogix I would use ladder 1 to link all the modules together. So ladder 1 would pretty much be used to send data to and from the modules, you could consider ladder 1 as the master module, or the flow chart. You then would insert what ever and how ever many modules as you need. The last ladders of the program would be used to map your physical I/O to the modules. You could create 4 ladders for mapping physical I/O, one for DI, DO, AI, and AO.

 

[CaseyK]

Stephen's point on standardization is excellant.

I stepped into a position years ago where my predwcessor had to try everything. That meant that we had two AutoMax units, two Sharks, two D-100's (with another 40 or 50 in dead storage), two SixNet's, two OMRON's, two horners, tow AB's, two Tele's, two Opto 22's, and then the company standard of several hundred GE's.

Pleanty of cables and adapters, and a shortage of manuals except for the GE's.

Is the customer always right?

With some of the requests that I have received over the years, I don't think so.

When at GE, when we got a mahine in from overseas, WE GOT what THEY SHIPPED. Period!

The sister plant GE had in Burlinton, IA, shipped considerably more panels with AB plc's then everything else combined (including GE).

Anyway, variety is a good teacher. But it can be carried to an extreme.

regards.....casey

BTW: UI don't think what Stephen did to be constrewed as advertising. Just my opinion, NO poll to follow.