# Conveyor Systems



## lefleuron (May 22, 2010)

Yes.


----------



## ampman (Apr 2, 2009)

dronai said:


> Any of you guys work with Conveyor Systems ?


 some what do you want to know


----------



## micromind (Aug 11, 2007)

Miles of them on rock crushing plants and mines. 

Some are small, 5HP or so. Others are a bit larger; 300HP or so. 

They're almost always interlocked so if one fails, every other one before it will stop. Otherwise, at 1000 tons/hour, it's a BIG mess!!

lol.


----------



## dronai (Apr 11, 2011)

lefleuron said:


> Yes.





ampman said:


> some what do you want to know





micromind said:


> Miles of them on rock crushing plants and mines.
> 
> Some are small, 5HP or so. Others are a bit larger; 300HP or so.
> 
> ...


 
I may be working with a large conveyor system soon, and wanted to know about the PLC troubleshooting. Are more of your problems field related, or do you also get some bugs in the programming ? I have other maintenance guys to work with, but I would like a heads up. Any advice is welcome.


----------



## John Valdes (May 17, 2007)

dronai said:


> I may be working with a large conveyor system soon, and wanted to know about the PLC troubleshooting. Are more of your problems field related, or do you also get some bugs in the programming ? I have other maintenance guys to work with, but I would like a heads up. Any advice is welcome.


Rarely are machine problems due to the controller (PLC). Once the PLC is installed, programmed and debugged, most every single problem will be due to electro/mechanical failure. Mechanical failure being the major area of concern. A good PM schedule can be of tremendous help in preventing and identifying problems before they occur.
Do not be pressured into program tweaks by existing personnel or management. This is common when an application must run 24-7. It will be little things that can cause major headaches.
An example could be the simple adjustment of a limit switch arm, instead of a slight timing adjustment to the program. The switch should be adjusted, not the program. Always address the issue, not the program.
The beauty of the PLC is the ability to make adjustments to fit the application. The downfall is letting PLC program adjustments be the solution. It is not.
A well written and proven PLC program should require no changes. Of course the introduction of new/replacement peripheral equipment, environmental changes and new requirements of the system do require PLC parameter changes.
In my personal experience, PLC's rarely fail. Lightning strikes and power disruptions are usually you main concern regarding PLC failure/loss.


----------



## dronai (Apr 11, 2011)

Thanks John ! Makes me feel a little at ease.


----------



## jbfan (Jan 22, 2007)

In all my years here, we only had 1 plc problem.
Everything else are photoeyes, limit swithes and other external controls.


----------



## lefleuron (May 22, 2010)

I agree here.

If a program was written, and has run flawlessly for a few months- its a done deal. The program loaded into a PLC should never give you trouble, and even when it does after a couple weeks its usually something like an overflow bit or that type of thing. Once the program has been run out over time, its not that. The program does not change.

Wear to ball-screws in motion control, wear to bearings and rollers can cause "expected time" issues, limits, photo eyes and relays as mentioned are major problems- things external to the PLC.

Besides the RARE power supply, input/output card, or even more rare processor, the PLC itself is not the fault.

But it will sure help you to find the fault, using the I/O indicator lights.

when you have 50 proximity switches, its very easy for two guys to find the bad one. One guy watches the lights, the other guy trips the proximity switches.A Light will flash one and off at each sensor on the input card. The one that does not, is the problem.

Same for outputs. If the output light comes on, you know all the inputs needed are good. If its for a motor starter, you are now down to an O.L., blown fuses, bad coil, bad motor or a mechanical issue. Or RARELY an output card itself, and this can be checked by proper voltage at A1 on the starter or relay itself.

Using a PLC for troubleshooting confirms huge chunks of a system are working, and leaves you with little else the problem could be.


----------



## Hamer (Oct 5, 2010)

Something our former electrician told me is to never forget the PLC is a tool. There's no magic in it and it's not a band-aid. In our case, supervisors were quick to ask for the very thing mentioned above. "Well, can't you just adjust the timer, delay, yadda, yadda... or 'force' the input on so we can run?" My response now is that if it needs fixed (e.g. a switch) we fix it. I won't use the PLC to bypass or cover up mechanical or field electrical problems and there can be a lot of pressure to do so. No time to do it right, but apparently enough time to do it twice

However, as a tool... as mentioned above it can save massive amounts of time troubleshooting when you know what to look for. I'm no expert and this is just my $0.02


----------



## dronai (Apr 11, 2011)

lefleuron said:


> I agree here.
> 
> 
> Wear to ball-screws in motion control, wear to bearings and rollers can cause "expected time" issues, limits, photo eyes and relays as mentioned are major problems- things external to the PLC.
> ...


I think they told me the sensors have lights on them indicating they are working.

Much thanks for all the pointers. Nothing beats the hands on day to day getting to know the whole system.

Are those sensors usually DC NPN Sinc, or low voltage AC ?


----------



## lefleuron (May 22, 2010)

dronai said:


> I think they told me the sensors have lights on them indicating they are working.
> 
> Much thanks for all the pointers. Nothing beats the hands on day to day getting to know the whole system.
> 
> Are those sensors usually DC NPN Sinc, or low voltage AC ?


 
Some sensors have lights, but not all. And even if they do have the red/green lights its no guarentee the light itself works. Trust the input lights in the rack, then you know for sure the signal is getting to the controller.

Any type you can think of. Sinking (NPN), Sourcing (PNP) DC, low value AC, hall effect, proximity, etc. etc. etc. Anything that will give you a clear state of change can be used as a sensor.

One of the worst plants we service has cube relays everywhere because they buy used equipment. That way they can make any card work, by switching 120 AC, using low voltage DC relays and vice versa. Its a chore figuring out how they just get a state change back to an input card.:laughing:


----------



## micromind (Aug 11, 2007)

I agree with the others, it's VERY rarely a PLC problem. Almost always, the PLC tells the machine to do something, and the machine doesn't do it. Or, the PLC is waiting for some sort of feedback so it can continue with its program.


----------



## Dhfisher (May 6, 2011)

When one "forces" a input, one should know the program very well, if there are inputs of the same address you are also changing the state of them also, this may cause unintentional movement in the machine. ( bad juju)

Sent from my iPad using ET Forum


----------



## Geoff C (May 26, 2010)

We've had bits get stuck, but easy to find. Oh yea, supervisors try to swap out cards hot and make a puff of smoke lol.


----------



## Frank Mc (Nov 7, 2010)

dronai said:


> I think they told me the sensors have lights on them indicating they are working.
> 
> Much thanks for all the pointers. Nothing beats the hands on day to day getting to know the whole system.
> 
> Are those sensors usually DC NPN Sinc, or low voltage AC ?


Hi Dronai

Most of the plc stuff that i haved wired or worked on use PNP Logic.....The Japs tent to use NPN Logic.........

Frank


----------



## oliquir (Jan 13, 2011)

i hate npn logic!! i know it was easier to do in the past with basic electronics in sensor but now it is over. some modern sensor accept 24-250V ac/dc are have bi-mosfet outputs :thumbup:


----------

