coolhand

What is a good method for numbering/tagging wires? I/O is obvious for wire tags as is L1 to the MCR and 3 or 30 afterwards. This seems pretty standard on American machines. What I have is a project involving a bunch of interconnection between safety modules, safety relays, and interfacing with the processor. My modules have terminations to OSSD1, OSSD 2, EDM 1, EDM 2, FSD 1, FSD 2, Y1, Y2, Y3, Y4, etc. Since Y1 connects to OSSD1 I have considered Y1/OSSD1 for a tag. Another thought is simply starting @ a block of numbers. This wire could be 1000 and move on from there. Is there a standard for such interconnection? We have several machines in house that have I/O tags as simply a number. I: 2/04 might be something like 168. This is a real pain for troubleshooting. I would have to get the prints out or go to the rack and look for 168s address. This OEM has since moved to using I: 2/04 which makes tracing much faster and easier when doing online troubleshooting. Any thoughts? I don’t think NFPA 79 went into great detail on this. Luke

We just had a situation in the plant where we now want to limit programming access to only two people. We have both RS Logix 5 & 500. Using it as a tool for troubleshooting a machine is invaluable and we don't want to take that away. The PLCs are now password protected, but we still need to give others "viewing rights". What do we need? And what obstacles will we see? Thanks for the help. I'm sure this has been discussed out here several times. If you know of any past discussions please give me a link. Thanks

Is RS Ladder processor specific? or will it work with both 5 and 500?

Thank you very much for all the responses. Thank you also for the links -some good sites and some very good insight and info. I'll be referring back to this info a few more times J One thing I have realized through this whole process is that an assessment can be a bit ambiguous and not always clear cut. If I were safeguarding a punch press for instance, there are definite standards on how this is to be done and how the operator is to work with it –anti tie downs, etc. Now after an assessment is completed for a certain area, a solution has to be made. Hardware is purchased; and integration of that solution begins. One company I have dealt with has some very helpful application engineers and has not tried to over sell their goods to us. In integrating one solution I had some troubles with shutting down AB servos and after talking with AB, they want to sell me more hardware stating that it needs it to meet a cat. 4. I guess what I am finding is that I have to educate myself to ask the right question, and not to always trust the application engineer or phone support. Fortunately for me, we had a corporate Health and Safety manager in the plant last week. Since we are a small division of a large company, I asked if there were folks at corporate who would be able to assist in answering questions. I called the first name and found that they had already assembled a team for light curtains and machine safety on some similar equipment. I also found that a recently acquired plant that is similar to ours has done quite a bit of this already. It's kind of amazing that I would ask my boss and the plant engineering manager and get no help in tracking down a contact person within the corporate realm. Oh well. Thanks again for your time in responding. Luke

A lot of great advice. I am more of an “end user” since my job is industrial maintenance. Work is done on the fly, and unfortunately I usually don’t get a lot of time for planning a project out to as much detail as needed. I do enjoy working on equipment that has excellent prints. We have several Siemens AGVs in the plant and their drawings are probably the best I have seen. They use the same grid and line method you speak of. They also have taken the time to give a drawing for all boards and component locations, communication interconnects, etc. With this project I have already completed all I had time to do was create a spread sheet of my 25 conductor tray cable and the two other multi conductor interface cords. Along with this sheet I also indicated which modules interconnected and assigned the various pin-outs to the terminals. This is where I ended up using the scheme OSSD1/Y1. This represented the light curtain muting module (OSSD1) connecting to the safety relay (Y1). This worked for my purposes of wire assignments and integrating the hardware with in a four hour PM. I doubt if I will be allotted the time to have this drafted as mentioned in the previous postings. I hope those that follow behind and trouble shoot can glean from looking @ the hardware literature and the way they are tagged. It was defiantly not a résumé building print. I have to say that after 12 installs on six differing Palletizers it went well and has been functioning w/o complaints from those that operate them. It never did occur to me to grab one of the equipment OEMs prints and start with one of their blank pages. After working and troubleshooting a machine for six years prints are seldom referred to since I know where most every thing is terminated. Trouble shooting also usually just involves getting online to the PLC with the laptop and working from the I/O back. I am not savvy with Auto Cad nor will the plant outlay the funds for any add-ons for print documentation. Is there a “cheap” alternative out there for drawing schematics and diagrams? Thanks to all for posting. Luke

277 where I'm at as well. A couple years ago we looked into converting the factory to flouresent. I can't remember the model of the bulb, but if interested I can investigate. We figured the outlay for relamping the facility would pay for itself in ~18 months. There would also be much less heat load on the building as well. One of the models we are sampling has a switching transformer (balast??). It will operate on either 277 or 110. I have been hoping these would come down and I would get a pass . One other nice feture was that the light put out about the same lumens but the light seemed brighter. I can't remember if it was because of the wave, cycles, color spectrum, etc. If interested I can probably get a couple of company names and contacts. BLI was one: http://www.budgetlighting.com/store/agora.cgi And this is one of the fixtures hanging on the floor: http://www.budgetlighting.com/fluorescent_...ting/index.html Luke

We had a bit of an accident last week on one of our Palletizers. The operator was reaching through a light curtain to fix a problem when he dislodged a part that was being held. The machine retracted to get another part and pinned him in the process. Fortunately he was not injured. This machine had light curtains installed 10 years ago and is simply sending a signal to the PLC. Unfortunately part of the logic was not there to prevent this from happening. Looking over the rest of the fleet of palletizers shows that this was the only one with a problem -but that does not mean it can't happen again. My remedy for that morning was to isolate the motors run command output with a Banner IMTA-9A safety relay. The relay is being powered by the Banner MUSC-1 light curtain controller via its FSD output. Now even if a light curtain is broke the signal to the drive is interrupted. Looking further at the literature for this relay and looking over the Light Curtain controller I still have a problem. The relay has four terminations labeled as Y1, Y2,Y3,Y4. These are supposed to be feed back to the Light Curtain controllers monitoring circuit. The MUSC-1 does not have an EDM circuit (external device monitor). After talking with the application engineers from Banner I will have to go about this "the way they did it in the old days". They speced that I use a force guided contactor with 2 NO/NC contact. This contactor will be mechanically linked with an add-on set of contacts to control the outputs to my drives. The Light Curtain controller will provide power to A1 and A2 for the coil (just like I had done originally) and the NC/NO contacts will allow power to the light curtain controller. -It's a bit confusing. They sent a pencil sketch of the basic idea of what will happen. It took awhile to find the needed hardware and I am still waiting for the stuff to arrive. We have been in the process of doing machine safety assessments and installing light curtains (modern ones) and other safety up-grades on door switches, etc. I do know that running a safety through a PLC is bad practice, but explaining that to Management and others has been difficult. Now that an accident has occurred for such a situation it will be easier to show the results. I have found that safety is not like running conduit and specing motor overloads. Doing Arc Flash is even easier. These all have charts and tables. Safety is a variable. Standards change, machines change, variables change. What I feel is safe can soon be disproved with -"did you think of this?", etc. Safety can cost a LOT of money. I would like to find a book/s like my NEC, or NFPA 79. Has anyone written a book for the tech to help understand what is needed in a safety control circuit, how to do a proper assessment, what installation standards are needed....? If it were only one machine with this problem I would be inclined to spec a newer light curtain controller for this spot. Unfortunately the plant has ~40 of these "legacy" controllers. We also have sister plants that will be following our example as well. Any thoughts, comments or suggestions are welcome. Thanks Luke

Thanks for the replies. I have a few of the safety catalogs and it may be time to go back and read through them again. One of the things you hear at any company is “Safety First”. That sounds great until you try and drum the troops together for support. To me it seems odd that my boss and all the bosses up to the plant manager and even the president of the division are leaving a critical solution to a maintenance guy in the trench. –Sure I have gained the respect along the way, but it would be nice if there were some others within the division to lean on. I’m afraid that I’ll end up being the go-to guy for solutions and don’t want an incident to occur ten years from now with my name attached to it. I guess it’s a bit of a vent for me. I was not aware of the NFPA site and will have to give it a perusal. I have read only a little on the safety rated PLCs. I am curious how they work, or how they “fail in a safe” condition. I’ve been installing new light curtains, muting modules and safety relays at the palletizers exits. The only thing I take to the PLC is an input halting the logic. I have various drives I have been inhibiting from getting a run condition by controlling the drives common threw the safety relay. Every module is checked by the one it’s connected to for functionality- i.e. redundant. What would be nice for a system like this is “patch cables” to go from one device to the next. I’ll be I made ~50 terminations for each one of these exits. If I were to have done this with a safety PLC what would eliminate the human error of programming? Having hard wired like my explanation above, even if my program in the processor got changed the drives will still not be able to run. As for risk assessments- when you perform them who does them with you? We did them a few years ago for this same palletizer with my boss, a couple of other maintenance techs (they used to run these lines as well), and my-self. Not being aware of all the regulations a lot was left to speculation. Last week we had a guy get his arm caught in an un-guarded area and the week before the incident with the old light curtain. Both of these were never considered on the initial assessment. It’s hard to see every thing that can go wrong or anticipate where a new hire might stick an arm. I am amazed at how many people I see working around machines with no thought about the dangers that are present. There does not seem to be an age limit to this observation. Much like people driving cars I guess. I’ll give my catalogs another read. It would be nice to have a good book like the NEC written for the layman- this way the decision makers could see why things have to be done a certain way. You know what I mean. Luke

We're experiancing a similar trouble where I work. I don't know the fault code anymore, but it was a bit vague -something to do with a bad card. The guys have gotten into the habit of simply "keying" the switch to reset the processesor. This is on a line that has run for ~8 years with little to no issues with a relatively simple program. It will fault 2-3 times durring a shift and then not come back for awhile. There is a D-net card in the rack that is not being used -it could be the culprit. Anyway I searched the forums and came across this one as a "good fit" for what would work for us. Ron, I tried a bit of the logic from your example. I did not put anything in to shut the files off, but simply put the unlatch at the end of the first rung. I do have a 5/04 @ home that I did try your full example on. It does fault out the processor quite nicley. I was only able to get it to shut file 3 down twice after several atempts. What am I missing in the example? The 2 times that it did work, it worked per the comments in leaving a nice "trail to follow". I tried downloading your example over at PLCs.net but am having no luck getting registered (I have tried several times in the past with no success). Any help on this "home project" would be apreciated. Luke

i was taught that you always control the flow on the exhaust side

I have a pair of old 504's for home use. One works fine the other does not. With battery unplugged I shorted GND & VBB to clear old program. I'm communicating serialy. Part # 1747-L541 with O.S. 1747-OS401 ser b frn 7. I have two racks and the problem follows. Linx recognizes the SLC and when I attempt to download I get message: "Download Failed- Could Not Get Processor Ownership" I have swapped racks and the working processor accepts the program in both. The failed unit does not. Any hints to what is going on? Luke

Well, I finally found an EEPROM. Since I have two idectical processors I started by saving a program (configuration) on the working 5/04. I then put defalted the bad 5/04 and installed the EEPROM and put it in the rack. As before I tried downloading to the 5/04 and got the same error and option to load from an EEPROM and this worked. I was now online in program mode but it did not want to go to Run mode. I went to the S files and toggle S:2/14 (i think) and a few others in that area to force it to load from the EEPROM on power-up, to clear the fault at power-up (fault light was on) and to go to Run Mode on power-up. I saved this set-up to the EEPROM and powered down and up. It came up in Run Mode. I set the S files back to ignore an EEPROM. It powers-up fine now. Thanks for the input! Luke

I've tried multiple baud rates. Still the same result. I can see it on the Super Who, load parameters from the rack, but can not down load to it. The plant I work in used to have about 30 5/04's w/ eproms that have been removed. I'm sure there are a couple around -just need to find the box. On another note: I just replaced a 5/04 last night. It had faulted out and could not communicat with it either. I would reset the processor to default and power-up. The fault light would flash rapidly, but as soon as linx tried talking to it the DH+ light went solid red. Trying to com with DF1 did not work either. The DH+ light would go red again -didn't even seem to want to talk. Anyone ever see this or know which boards could be swapped around? Thanks for all the suggestions. Luke

My local support gave me this info from the Rockwell site. I brought the unit to work and tried downloading via DH+ and still got the same message. It seems that maybe this was taken oiut of sevice while an edit was taking place or had an EEPROM at on time and is still looking for it. I don't have a memory module to try the "back door" approach. So for now I'll have to wait untill I find one. -Bummer Thanks for the help guys, Luke ID 18360 Products Programmable Controllers SLC500 (1747) Category (optional) General Date Created 06/23/2000 Last Updated 11/03/2006 Access Level Everyone Prev. TN# G18579 Print Answer Email Answer http://""' target="_blank"> Download Failed! Could Not Get Processor Ownership. Question Download Failed! Could Not Get Processor Ownership Answer Download Failed! Could Not Get Processor Ownership Problem: The following error was generated when attempting to Download to a processor: Download Failed! Could Not Get Processor Ownership Cause #1: A previous Online Edit failed, thus leaving the processor in Online Edit status. Solution #1: Cycle power to the processor and re-download. If this fails, try solution #2b. Cause #2: RSLinx Super Who would see the processor. The User was even able to go Online with the processor, but would always generate the error when attempting to Download. The cause of the problem was that the Write Protected bit was enabled under the General Tab of the Channel Configuration. Solution #2a: Download using a different channel. Solution #2b: Factory default the processor and re-download without the Write Protected bit cleared. Cause #3 The user can go online with RSLogix 500 and monitor I/O. Online edits and program download do not function. The program Compare bit (S2:2/9) is set and an EEPROM is installed in the processor. Solution #3 If the Auto Load bits are not set skip to step 5. While ONLINE -- go to REMOTE PROGRAM and UNSET bit S:1/10, S:1/11 and S:1/12 Store to EEPROM while in REMOTE PROGRAM Save the program while in REMOTE PROGRAM Go OFFLINE Power down Remove memory module Power up Unset the S:2/9 bit Redownload the program without the memory module Save the program Power down and put memory module back in Power up GO ONLINE -- REMOTE PROGRAM Store to EERPOM Go back to RUN Catalog Number: 1747L511;1747L514 DocFullNum: G18579 Revision: Fixed in Revision: Package: Modual:

I added a card to the rack, went to the Controller, and then to I/O config and set it to "Read I/O Config". It recognized the new card and processor. I attempted another download and still have the same trouble. I notice that when the rack is powered up there is no Fault Light flashing and the DH+ port does not flash either. I shorted the pins on the other 504 and have a flashing Fault and DH+. It does recognize the serial cord. Since there is no program it should be jumping up and down for that. All the lights do cycle on power-up and I also unplugged the battery and get a light for that. Any clues here? Luke

Ken, I tried it in both positions. Right now it is in the same position as the working unit and that is on the right side according to the pic.

program -didn't work

Thanks for the replies concerning the accel/decel. Instead of hundreds of servos in our plant we have hundreds of VFDs that we are used to entering a time value. Now I have a better understanding of what's going on and warn the other guys

Well we just got a new palletizer with 4 Servos. In the past (this is their first stab w/ servos)this OEM built their machine w/VFD's and it worked OK. These palletizers are built with sheet metal and use #60 chain for the mechanical coupling to the hoist area and belt drive on linear bearings on the horizontal sections -it's rigid enough for the old style but I can see gusets and braces added on the new style. The reason for the move for servos was speed. With the VFD, if the "envelope" is pushed, controling the load is quite rough and the drive train takes a beating. We also see a lot of over bussing due to rapid deceleration or reversing speed too quickly. There seems to be a physical limit to how fast it could be run and not shake apart. Well the new machine has been in service for about a month now and does run fast and a lot smoother than we able to do with the VFDs, but a LOT of faults are occuring. I am seeing "thermal" and "folowing errors" in the Hoist (suspended on chain) and I suspect this may be from the back lash from the chain. And I am seeing a LOT of "over buss" faults on one of the horizontal sections (Rowformer). The rowformer brings the product onto an accumulation bed at a high rate of speed and then matches speeds with it before delivery. From what I can gather for info, I believe the overbussing is happening during decel when matching speed occurs and when the PLC (AB 504) sends a stop command to the drive (obstruction in the path, opperator, etc.). Since this is a new line for our factory politics will no doubt ensure between us and the OEM. In the meantime this machine is faulting about 4-6 times a day and I'm not ready (or permited because of the politics) to start making changes. I have a Rockwell Automation guy coming in first part of next week to survey the application and make recomendations for getting this line going. Do any of the gurus have any experience with the Serco 3000 series? Rather than using the AB 5000 and the Sercos drives as they were designed they are using a 504 and simply sending run commands for different steps and monitoring the motion with seperate encoders. I feel that backlash from the chain will become an issue for us within a couple months. Is there paramater adjustments for an application like this I sould be asking about? The other question I have is the drive undersized for the Rowformer? Would a larger drive offer more control of the load and re-gen less? And would a larger servo controler have a larger buss to control this re-gen. I do believe that there are some errors in there PLC logic in how this portion of the machine is controlling all this mass. I mentioned that when an opperator put the machine in hand mode, etc. It will come to an abrupt stop (i.e. re-gen). I think that if I programed it for a coast to stop and then applied the brake it may take care of a lot of problems in this area. So if there are any Servo guys out here I may start asking a few questions about this. Thanks for the help. Luke

Thanks for all the responses and input -I apreciate you all taking the time. It's been a week since Rockwell guy and no faults have occured! This is a huge plus to production since it was taking around a half hour to recove and clean the mess and a good part of the shift to smooth the line out again. The other downside I was starting to see was rejection/lack of trust from the opperators towards the new line. It turns out that the servos we have could have had different encoders. The ones that are on ours read 360* and then start back @ "0" hed they cept track of total movment we could have used the idea of aux. power to keep track of location. -If I am understanding all this correctly. I did price out the shunt for the drive and it will cost about $500. Not bad. I still have a question about the decel. Ours was at 2500 and stoped on a dime (and faulted out). The tech put 1000 in for decel and now it coasts a few inches in a more controled manner. My thought would have been to put a larger number in this setting rather than the smaller number. I have not had time to sit down and read all about the parameters yet but do have the Ultradrive software on my laptop for my reading enjoyment . The comment about the brake is true. The brake is only for holding the load and not controling or possitioning. As I was working with the guys on a changover today playing with VFDs and moving limit switches around I couldn't help but think servos would be a lot nicer. I don't see the bosses making a big move towards upgrading this new line, but at least I have a better insight to what was happening and have some answers to future events. I'm sure I'll be back this summer when things get "broke-in" and things start crashing and getting out of square, etc. Luke

Well, this is a progress update. The visit from the Rockwell guys was very helpful since I have no training or previous exposure to servo drives. For one thing it has been interesting and my impression of the Ultraware drive software is that it is a good tool. The problem with one of the axis is that it was overbussing and after looking at the drive step commands and the logic of the machine we were able to duplicate a fault. In the first 18" of travel the servo is moving this axis 55" per second and once 18" is met it goes to the second step which is continuing forward @ 6.8 " per second until 30". The overbussing was occuring in the first step when the movement was interupted i.e. out in pause, guard door opened, etc. The decel command was to stop within 2500 1/10" per sec/per sec. He moved that value to 1000 and now when the step is interupten it doesn't stop like hitting a wall but rather coast a bit. -Can anyone out here explain this 1/10" per sec/per sec? My thinking was to go from 2500 to 3500 to get more of a decceleration time. The second drive was faulting for a drive thermal fault and we were never able to see this happen. I spoke with opperators for this new line and new that sometimes they noticed that the gaurd door indicator light was on (door open) when they came to the faulted machine. The servo has an external brake that is activated when put in hand mode, the door opens, or power is off, etc. I looked at the PLC logic and verified this, BUT the drive was still recieving it "drive enable" signal. This meant that if the door came open while the servo was in motion (especialy up), tthe move command was stopped, the brake was engaged, but since the drive was still enabled that the servo motor was tring to "catch-up" to where it thought it was in its' motion. While the servo was catching up it was trying to drive through the brake and the current draw was going through the roof and then would fault the drive. I changed the logic so that the drive is now disabled when the door is opened as well. The drive keeps an hour meter and since they are @ around 1200 hours and had had about 30 faults between these two drives it should be obvious in a week if these adjustments were succesfull. Thanks for the input and if anyone can explain this deceleration of " 1/10" per sec/per sec " I would be thrilled. Luke

This is something that the Rockwell guy pointed out as an option and I think may be the way I'll lean. It will take a bit of time to weed through the logic that they have surrounding the homing sequence. Unfourtunatly we are within a month of our busy season and time will be at a premium -so if these nusiance trips can go away at least it is progress. Thanks for the help. I'm sure I'll be back. Luke

Thanks for the replies, guys. Paul, the commands for the drives are as you sugested -as a move command from the PLC. The "steps" are stored in the drive.Eachstep stores the paramaters for speed, position, accel, decel, etc. For a guy that has only been exposed to VFDs it's pretty cool. The Rockwell guy has been a big help in my digesting what is going on or what should be going on. The drive stores an hour meter and we are running around hour 1200 (not very old) because of the time stamp we were able to determine that only two of the drives are an issue. One drive has been getting a drive over temp fault. Acording to Mr. Rockwell this is a "calculated" fault. This means that if my Continuous Output Current limit is running high and goes over the 23A peak that is okay once in awhile (max is 46A) but if I go over that limit continually that current multipled by Time = Thermal Protection Fault. The Servo has been peaking @ around this limit all day and seems to do fine, but if the line is running 100% this means this axis is running a lot more (time) and then the faults start to occur. The RA guy found that the drive is sized small for our application. We could slow this area down -but it would not be what was "sold"to us. I think we will push for a replacement. The other axis has only been getting Overbuss faults. The buss is capable of 800 volts and faults @ 810. Looking at the drive and motor we found out again that the drive is too small. I priced out the external shunt for about $500. We could resize the drive, or we could slow things down. This is one axis that gets a lot of opperator intervention by being put in hand mode or the logic stops it because of a "jam condition". I am also able to get this area to fault. By looking over the steps we found that it moves for 18" @ 55 inces per second and then is commanded to slow to 6.8 inces per second until 30". This 18" area is where I see a lot of the faults occur. By looking @ the first move step it's decceleration was set to 2500 1/10 in/sec/sec. He moved that to 1000 and now if put in hand mode within the first 18" it coast more and does not hit the Buss. I think we will recommend the external shunt. Oneof the big problems is that when one axis faults all axis require homing. The OEM designed it so that the E-stop is pressed which drops power to all drives. My preferance would be to only home the axis that is faulted rather than see the half hour plus of downtime -work in process creates quite a mess. I'm hoping to get some good feedback tomarrow from the rockwell guy on how this could be better handled. Thanks for the input. More to follow... Luke

Thanks for the replies. The aplication is discreat I/O -Devicenet would have been a much better option. A couple of these axis are using a seperate encoder to verifiy position. Had Dnet been used the servos encoders data could have been used. Using Control Logix would have been the ultimate -but it is what it is. A trouble I am having with trouble shooting is figuring out what exactly is happening. The line opperator is not looking and communiating all the info as to where it was in the process. If another maintenance guy gets called they are not always looking for the same either -just get it going. We do have the Ultraware software and I have been using that to look at Fault History, etc. The Rowformer at last count had 19 Overbuss faults and I think I have an idea where this is comming from aside from the rapid decceleration. If the gaurd door is opened, put in pause, or a jam condition occurs it is stopping too fast. If this were a VFD I would lengthen my Decel or at least set it to "coast to stop". Are my stop selections also available with the servo drive? I'm sure I'll have 101 questions for the RA guy but I don't know how much "tweaking" will be allowed because of the politics surrounding this install. The OEM should be the ones in the plant fixing this 6 weeks after production. If it were a new car it would have been back to the garage. I did notice the Shunts on the drive and see that an external Shunt can be installed. This may be an easy option. I'll keep you guys posted. Thanks Luke

Wow! I just got 2 504's and was going to do the same thing. Great link. Luke