Help - Search - Members - Calendar
Full Version: micrologix 1100 PLC Program For review
Forums.MrPLC.com > PLCs and Supporting Devices > Allen Bradley
skjomcs
Attached is a PLC program (micrologix 1100) i have been working on. I am realtively new to PLC programming. If anyone could take a look it
would be greatlt appreciated.

there is a machine with 3 lanes. THe lanes index at the same time. The lanes consist of a metal plate with a product positioned on them. the plate index is
approx 605 ms

THe sequence is:(this occurs on 3 lanes)

The sensor goes high when it sees the edge of the plate
This starts a timer.
During interval 370-400ms of the timer a camera system is inspecting the first half of a product
If there is print present the camera system passes back a pass signal to the PLC
During interval 480-550ms of the timer a camera system is inspecting the second half of the product
If there is print present the camera system again passes back a pass signal to the PLC
When the timer is done, if both halves have passed the product is a pass and a signal is generated to another machine
If it is a fail no signal is generated.
The machine then pauses (approx half a second) and the index occurs again with the sensor seeing the edge of the plate and the process being repeated
If 3 consecutive fails occur (individual lanes, not at same time) an alarm signal is generated and a key is switched to reset the line.


If anyone can take a look to see if there are any obvious mistakes or recommendations

Thanks
jimdi4
your file is corrupted : .........Unexpected file format....

TWControls
File opens fine for me.

First I wanted to compliment you on your great documentation. This will help you years down the road when you need to go back and do some troubleshooting. I would add a processor name and be a little more descriptive than PLCPROG for the file name

I just wanted to highlight a few things I would have done differently.

I would combine rungs 2 and 3. They serve the same purpose. If I were troubleshooting the machine, by having two separate rungs, when I am doing a quick browse of the file I would assume that it is a different set of conditions that resets C5:4 and C5:5

I'm not sure your ONS does anything in rung 4. It may be able to be combined with rung 5 but...I really don't like rung 4 or 5...have to think about them

If your timing windows between the 3 lanes will remain the same, I would combine rungs 7,8, and 9...10,11 and 12(Did you mean for the LIM in 12 to be 490 instead of 480, if so forget this suggestion)

Rungs 13 through 21 need to be rearranged and perhaps combined. It would be easier if they went 13, 16, 19, 14, 17, 20, 15, 18, 21. This way they are grouped by function. I'm not particular happy with the way I combined the rungs, maybe someone else can jump in. What is B3:8/15 for?

Are the presets going to remain 1 on C5:0 through C5:5? If so they really don't serve a purpose

I don't like the use of O:0/2 and T4:0.TT/DN in so many rungs. I would create two bits based off of these conditions. One to say your in your timing window and one to say that the timing window is done.
skjomcs
QUOTE(TWControls @ Nov 22 2008, 09:45 AM) [snapback]76076[/snapback]

File opens fine for me.

First I wanted to compliment you on your great documentation. This will help you years down the road when you need to go back and do some troubleshooting. I would add a processor name and be a little more descriptive than PLCPROG for the file name

I just wanted to highlight a few things I would have done differently.

I would combine rungs 2 and 3. They serve the same purpose. If I were troubleshooting the machine, by having two separate rungs, when I am doing a quick browse of the file I would assume that it is a different set of conditions that resets C5:4 and C5:5

[i]Thanks i didnt know how to do this

I'm not sure your ONS does anything in rung 4. It may be able to be combined with rung 5 but...I really don't like rung 4 or 5...have to think about them

Yes i think myself this may be wrong. Once the sensor goes high it should start the timing window, if the sensor goes high within the timer window it should be ignored. Im not quite sure what ive done here is right.

If your timing windows between the 3 lanes will remain the same, I would combine rungs 7,8, and 9...10,11 and 12(Did you mean for the LIM in 12 to be 490 instead of 480, if so forget this suggestion)

Thats correct didnt know till now you could write the code like that

Rungs 13 through 21 need to be rearranged and perhaps combined. It would be easier if they went 13, 16, 19, 14, 17, 20, 15, 18, 21. This way they are grouped by function. I'm not particular happy with the way I combined the rungs, maybe someone else can jump in. What is B3:8/15 for?

B3:8/15 was used in testing i have deleted it now.

Are the presets going to remain 1 on C5:0 through C5:5? If so they really don't serve a purpose

Thats correct originally the camera passed back 2 passes during timing window but now its only one. I have put latch bits in now.

I don't like the use of O:0/2 and T4:0.TT/DN in so many rungs. I would create two bits based off of these conditions. One to say your in your timing window and one to say that the timing window is done.



0:0/2 is Online signal to the machine the lane pass signals go to. If the failure level is reached the system goes offline. The TT/DN bit i am a bit unsure ,of what i want to happen is that when the timer is done all 3 lanes generate there results only once (turn on output long enough for the other machine to see them) and when sensor goes high again it starts over again



Thanks for the suggestions and any other comments, im trying to figure out will it work in the correct sequence with the reset, alarm signals and everything working. I noticed during a test on the machine the outputs seemed to come on okay but on the odd occasion the output to signify the lane had passed came on but it came on then again straightafter where a second sequence couldnt have occurred that quick
.
skjomcs
anybody?
skjomcs
added the fle in PDF, if anyone could take a look
Thanks
TWControls
No time to look right now. In the US, Thursday is Thanksgiving. That means we've got to get 5 days of work in 3 days if we want the weekend off. I'd say that's most peoples situation and why your not getting a response
skjomcs
okay thanks
KidPLC
Hi skjomcs,

I had a quick look at your code and I think it looks pretty good the only comment I would make is that if your trigger signal I:0/0 flickers or miss triggers during the cycle you can potentially reset the pass information you have already captured in your first half camera check. Maybe drive a "trigger latch" with I:0/0 so it is positively set until the end of the cycle would help.


QUOTE(TWControls @ Nov 23 2008, 01:45 AM) [snapback]76076[/snapback]

I don't like the use of O:0/2 and T4:0.TT/DN in so many rungs. I would create two bits based off of these conditions. One to say your in your timing window and one to say that the timing window is done.


I also agree with TW's comments above.

In large programs it is handy to create status bits like "Timing Window Active" and use it in many places in the program. You would then just drive it in one place using the T4:0/TT bit. If in the future you want to change the way the timing window behaves you only have to modify one rung of code and drive the "Timing Window Active" bit with your new code and the rest takes care of itself....much simpler than trolling through the code and replacing T4:0/TT with what ever the new code is.

Sorry you are not getting many replies to your post, in essence the code looks pretty good however none of us on the website have the benefit of running it on the actual process line and that is where the gremlins (if any) really start to present themselves. I have written plenty of code that I think is bullet proof and feel I have forseen every contingency but sure enough when it is on the machine problems pop up that you never thought would.

skjomcs
Thanks for the comments
jfwoodland
It looks like it should work fairly well. If this were a larger program, I would lean more toward a state machine programming method (or something resembling it). I always try to break the operation of a machine down into logical and exclusive steps and split the program into different ladder files as necessary. It makes editing and debugging much easier.

In case you're interested in checking this out, I'll attach a version of your program written with this in mind. It's kind of quick and dirty, but maybe you'll get the idea. Also, it may seem more complicated than it needs to be (and probably is), but the idea is that it can be easily modified and expanded.

[attachmentid=6991]


jfwoodland
Oops, you said the fault should trigger only if three CONSECUTIVE failures happen on any one of the lanes. That's what I get for being in a hurry.

Sorry, try this:

[attachmentid=6992]


This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2010 Invision Power Services, Inc.