ssommers

I have several 900 ft lines in the plant with multiple e-stops along the path and I always go for a larger e-stop wire gauge. 14 AWG will only drop 1.3 V @ 24 VDC at your 3500 ft length. This means that it should have less drop for any 5VDC pulses that the system might do for checking as well. Your milage may vary, (pun intended) Susan

I agree with everyone here. The NC portion of an emergency stop belongs in the hardwired portion of the circuit, not the PLC logic. However, you can monitor the e-stop in the PLC circuit and for that I usually use a NO contact on the e-stop button (pull cord, guard, etc) to signal a light (HMI, etc). This can be especially helpful when you have several different places with e-stops so the operator can tell that all of them have been reset before trying to restart the machine. Definitely evaluate the risk for each point where you want to put an e-stop. Remember, it's for the operator's safety, not the machine's.

I remember using a homemade one of those back at a former employer. The tilting to horizontal feature is very handy on large panels! For small panels, I've used an artist easel with kindorf attached to the cross members but that didn't have (or need) the tilt function.

Good topic Sleepy! Here's my 2 cents... from #1: "Often a problem presents intermittently, these are generally the worse type to come across. Intermittent problems are the ones I like to term "F**k, I've never seen that before!" moments." Actually, the more correct quote is, "Oh f***, not that again!" because intermittent problems tend to go undiagnosed for a while because we've all become accustomed to hiccups when we shouldn't be. Definitely don't walk away from the problem, but it may take some time to recreate the conditions that caused it. I had a seasonal temperature problem that hits random variable frequency drives (VFD). I could almost time WHEN the fault is going to happen by the outdoor temperature after watching it for 2 years, but I couldn't tell which drives were going to be affected. Always happened in the early Spring when the temperature first gets above 85 deg F, but never happened during the rest of the year. With two 90 deg F days this month, I was able to observe the problem again. The cooling tower's VFD overheated and I found a tiny dead fan buried in the middle of a very dirty heatsink. After swearing heartily while replacing the fan, the senior electrician "remembered" that there was a Spring Cleaning PM where all the drive heatsinks get spray cleaned with canned air. I went back to the maintenance office and looked at the PM records. Yep, Spring Cleaning is scheduled for May & June. Guess what PM is getting moved to March & April and is being done right now? So I didn't walk away from it, but it did take time & the right questions to get to the root cause and figure out how to prevent it for the future. Actually, it will take until next Spring to see if moving the PM truly works, but I should know if cleaning the heatsinks earlier helps before the end of July based on the reduced number of overtemp faults. from #7: "People who come after you may not be aware of what you have done and how you have solved the problem." Someone else must have noticed this "phenomenon" several years before my time and instituted the Spring Cleaning PM as their attempt at a documented fix. It also makes sense that I wasn't seeing more drive overheating in the Summer because the heatsinks had been cleaned by that time. All I'm doing is adjusting the timing of Spring Cleaning to have it done before the outside temperature gets above that critical level. Now if I could just find an easy way for all of the drives to call for a Spring Cleaning PM after XXXX many hours of the heatsink fan running, I'd have a real winner!

I have a Cscape HMI that I inherited. It's never given me any problems in 4 yrs, though I may have just jinxed myself by saying that... The nice thing... Their software is free with the hardware so I have the system backed up. And yes Sleepy, I think it's time to hit Tim Horton's on the way home for a few donuts!

Thanks for the comments Sleepy. I don't think the situation would have been so frustrating for me if I had been in my own plant. I was "invited" to our Buffalo plant which has no permanent maintenance people, looking at the machine for the first time and both setup men were off that day. The senior setup man had been on vacation for a week. The junior setup man had tightened the screws, but didn't associate that with why the machine was stopping midcycle. The maintenance manager (who's newer than either setup man) had no idea what had or hadn't been done. So back to the PLC and the machine... I was fortunate to have a readable copy of the electrical prints. The spaghetti code in the PLC was not too bad, but I wish it had come with meatballs (aka comments). The thing that made me really crazy was trying to change the wiring inside the switch from NC to NO simply because of the cramped physical location. Based on other sensor locations on the same machine, I think that the original design engineer from 20+ years ago had never changed a sensor in his life. Re-thinking this situation... The people communications were messier than the PLC code. I yelled at both setup men by phone the next day - the senior man for allowing/knowing about and leaving the loose switch & miswire for years, the junior man for not telling me what he had done when I talked to him on the phone the day before I arrived. I privately chided at the maintenance manager for letting both setup men be off on the same day. If either setup man had been there, I would have given them instructions and walked away from it. Instead, the maintenance manager rolled up his sleeves and worked with me. I showed him everything all the way through debug and the sensor change and he got a good lesson in what his people do and don't do. What was really crazy though was that the company president visited while I was there and asked me if the PLC should be updated... and I actually said no. (Yep, I said leave the 20 yr old PLC alone because it's actually doing a good job, the handheld programmer works and they still have lots of spare I/O cards for it. The only thing I asked for is another time to visit and document the other 3 Gould PLC programs.) I think I may have gone way off topic, but I think these are things that newbies need to know. Manufacturing systems are more than just PLCs. They include the people - operators, setup, engineers & managers - as well as the machines. Communication is the real key. Well constructed comments in any program are just communication from the original programmer to future debuggers.

I like this: "A well maintained structure is much easier to debug and much easier to modify than a large, kludgy 'rats nest' program." Having seen a lot of rat's nests & spaghetti programs, I appreciate the fact that memory is much cheaper today than it was 25 yrs ago and structured programming has become more the norm because of cheap memory. I spent 4 hrs working through an old Gould PLC program last week for a machine that would work in manual, but not auto. I hand wrote the ladder on paper using a handheld programmer. The program was only 15 rungs so I was able to struggle through and put names to all the internal bits & timers using the clues from the I/O diagram. It wasn't exactly spaghetti code, but it really took me back to my college days! The outcome... someone had miswired a switch many years ago and left the roller slightly loose, someone else came along last week and tightened all the screws when they fixed something else. It took another 2 hours to rewire that switch because it was in an awful spot and the broken sealtite had to be replaced at the same time. So rat's nests come in all flavors... programming, mechanical & electrical. I just hate when I get all 3 rolled up in one neat little package. Good basic article...

How many watts? Does it have to be 480 or could you use 240?

Cyclogram is a pretty good term for the machine cycle charts I've made in the past. I also use an Excel spreadsheet to create simple ones using XY Scatter chart type. My basic timer measurements are made off of Start movement & Movement finished bits in the PLC logic. (No HMI needed but I have to have my PLC programming software active to see the timers.) Once those are items defined, I can make timers to go from Start movement #1 to Start Movement #2 if I know that Movement #1 won't be finished. The only thing I don't measure per cycle is Idle time between parts. Idle time goes into a cumulative timer and gets divided by the number of parts made per run (Machine Start to Machine Stop). Once I have all the start times & durations, I can put it into Excel and determine if timers can be reduced or if I need to speed up a cylinder motion. Remember, just because a particular motion takes longer than any other one doesn't mean that you can always make it shorter. Sometimes trying to make things run too much faster makes the machine fall apart. The key is to balance speed with efficiency. A slower machine may reliably make more parts than a faster one that breaks down every half hour. I've been there & done that! Once you get some of the cycle times identified (including normal idle times), you could implement the starved indicator using a flashing stack light. Over cycle time can be done the same way if there's a problem that stalls the cycle.

HTH = Hope this helps

Let's not forget about the Autocad JIC Electrical Symbol library here at MrPLC. It's the only library I've needed and is a great basis for making your own symbols. And yes, it still works in 2010. HTH! Susan

Warning: Do not read while eating or drinking! Just in case you ever need to know the dielectric constant of peanut butter... Enjoy!

I love your commenting! Some 20+ yrs ago, I was a co-op student and spent a month commenting a PLC ladder because the engineer "didn't have time". The electricians loved me and groused about the engineer. Keep doing that and you'll make friends with the maintenance crew. Just thinking about other types of controllers... specifically AB ControlLogix... What you did with the internal bits is good. Some of the newer controllers actually want you to use internal bits for all the logic and then transfer them to the input/output image all at once. I would have mapped your internal bits a little differently. If you know your output order before starting, make your internal bit order match so you can simply do an array copy (1 rung) instead of bit by bit unless there's a specific reason for it.

Do you mean physical routing or logical routing? If you mean logical routing, I make a table of Conduit number vs. Cable numbers (ie. Conduit 1 -> Cables 1-10) as one of my electrical drawings. If you mean physical routing, you'd probably be looking at a 3D CAD package like Autodesk Inventor that connects to Autocad Electrical for cable & harness routing. I haven't needed that level of detail myself, but it may come in handy if you're looking to go through tight spaces. HTH, Susan

Hi Phil - Welcome to the forum! I don't know the answer to "is it legal" in your location. In my plant in the US, I have several machines with multiple power sources. Usually, there's the main power disconnect (480V) for this machine and then some type of control power circuit (120V) to interlock a line of machines together through an E-Stop or Run Allowed circuit. I use yellow wire to distinguish those interlocking signals that could be coming from an outside source & put a sticker on the outside of the cabinet that warns that there are multiple power sources within. What would happen if the management system doesn't report to central because the machine disconnect is turned off? Can you put a lockable circuit breaker inside the machine's cabinet next to the management system to isolate that portion? The key is going to be finding out what codes are applicable in your location. In the US, I use NFPA 79 which allows me to have multiple disconnects as long as I meet certain conditions - warning stickers, wire color code, etc. HTH! Susan