1734-ACNR Intermittent problem

[matthudson 0]

Hello, as the title implies, I'm having a problem that I can't seem to track down the source of. I have a baggage conveyor with a 1734-ACNR and 5 1734 modules attached to it. Sometimes once a day, sometimes 10 times, I am getting encoder faults on one of the baggage conveyor beds. The encoder has been replaced. The wiring to the encoder has been replaced. When the fault occurs, the 1734 ACNR has a flashing red POINTBUS status, and the module associated with the encoder has a solid red status. I have swapped the module that is showing the error. I have removed and reseated all module bases and terminal blocks, and the 1734 ACNR. I cannot find any signs of damage or even dustiness anywhere. There has been no work done in the IO box where these parts are contained and no changes made to the baggage system. I have been unable to "force" one of these faults to occur, and there seems to be no rhyme or reason as to what causes them or what time of day they happen. I currently do not have any new module bases or 1734 ACNR adapters, but I could "swap" out some bases from another IO box, but I dont have the knowledge as to how to program the 1734 ACNR to know how many modules to expect, and have only gotten the flashing red POINTBUS status when attempting to swap it out. Does anyone have any idea what I am apparently missing? Also, out of curiousity, is it possible to swap out a 1734 ACNR adapter programmed for say, 9 modules, and put it somewhere that there are only 5, and simply leave 4 module bases empty at the end? Any help is appreciated!

[ASForrest 12]

Hi matt and welcome to the forum :) From the 1734-ACNR manual, a red flashing pointbus light means "recoverable fault". It lists the possibilites as: • at power up the number of expected modules does not equal the number of modules present (clearly this is not your problem, although this is why you get the same flashing light when you put a different ACNR in. That's also the answer to your question about whether you can put in a chassis programmed for 9 modules when there are only 5: no you can't. It has to match exactly. Note that the ACNR itself counts as one module, your your chassis size would be 6) • a module is missing • node fault (I/O connection timeout) The manual is here if you don't have it, it might be of use: http://literature.rockwellautomation.com/idc/groups/literature/documents/in/1734-in582_-en-p.pdf Without knowing which encoder card you have I can't say for sure, but a solid red Module Status on all the 1734 cards I've ever checked means "unrecoverable fault", which means throw it away and buy another one. So that would make sense as to why you have the flashing red light on the ACNR - the encoder module has died and the ACNR can't talk to it any more. If I were to come into this situation, first point of call would be to swap out the 1734 encoder card, which you say you've done. The fact that you've swapped out that module and you're still getting the same fault is just odd. Was the "new" card actually new, or used? In any case, I'd still be leaning the same way - I've had two 1734-IB8 cards go into unrecoverable fault straight out of the box in the last 6 months. My next move from where you are now would be to double check all the wiring and cabling. Make sure the wiring is 100% correct, make sure there's no cable damage, make sure it's not run next to a big power cable, etc. Look for anything that could be interfering with or damaging your cable (and by extension, your module). Then I'd try replacing it again. Maybe send the faulty one back to your distributor and get them to test it, see if they get the same issue in a test rig of their own. You could swap the base out just to eliminate that as a possibility - I think it's extremely unlikely to be the culprit (it's just plastic and copper), but at least it'll put that one to bed. You could replace the ACNR if you wanted, but I'd be pretty confident at this stage it's not your issue. To change the chassis size, you'll have to use the software, and I think you'll have to attach it to a PLC to do so. You'll have to do it offline and download to the PLC. - In the controller organizer, scroll down and find the 1734 rack you're looking at (the one shown in the attached screenshot is on ethernet, so I had to drill down through the ethernet tree, but obviously yours will be different) - Right click on it and click properties (note: click the adaptor itself, not the PointIO chassis, see screenshot) - In the window that comes up click Change in the Module Definition section - Change the chassis size and do a download There *might* be a way to do it without a PLC using RSLinx, but I've never done it. If it's possible, chances are someone on here has done it and will chime in :) Hope that gets you somewhere! Edited 7 Jul 2014 by ASForrest

[matthudson 0]

Thanks for the help. The 1734 card is an ib8, I didn't mention it since as you said, it means unrecoverable fault on all of them. I have tried "new" ones (as far as I know they are new) and also tried to swap the card in slot 3 (where the fault occurs) to slot 2 or 1 when the fault has occurred with a flashing red status as opposed to solid. It will run for an unknown amount of time, then slot 3 will get the fault again, maybe in 6 hours or 6 seconds. 16 on a Sunday, 1 on a Monday. Maybe 10 in a row, maybe one. This setup is 4 years old and has not changed any aside from this mysterious new glitch in the system. I guess the next step is to start tracing all the wiring... I feel like I'm missing something.

[ASForrest 12]

An IB8 with an encoder? I didn't think you could do that... So if I'm correct then, you're just counting pulses from the encoder on on of the input channels, and calculating your speed from there? I can't say for sure, because I've never seen that done, but it could be that a regular input card just can't handle the speed of the input cycling you would get from an encoder. Could it be that the belt was recently sped up, even very slightly? i.e. has the motor been changed recently for one that might have had a slightly different gearbox ratio? Or has the encoder been changed for one that could have had ever so slightly different characteristics? It wouldn't need to be much - as it only happens intermittently, clearly (assuming this IS the problem) it's right on the edge of it's happy zone, so a tiny change may have been enough to tip it over the edge. Without crunching the numbers I can't tell you for sure, but as an indication, the IB8 has an off-on change time of 0.5ms minimum, due to the hardware (you can then set another filter up to 63ms in the software). If it takes the same time to change from on-off, then you can do absolute max one pulse per ms, or 1kHz. A typical encoder card can do 250kHz to 1000kHz. So you can see how it could be the problem. If you have the capability to slow the belt down, slow it down by maybe 5% and see if your problem goes away. If you can't it might be worth checking to see if you can get a different motor/gearbox to slow it down 5%. It just might confirm this as the source of the problem. Your other option would be a card that's designed to handle an encoder. I can't give you a solid answer on which one you need - check out this page, hopefully you can pick one to suit your application. Or else I'm sure your local distributor will have someone who can. http://www.ab.com/en/epub/catalogs/12762/2181376/104830/2416241/104832/Specialty-I-O-Modules.html Out of curiosity, what else is on the IB8 that has the encoder attached?

[matthudson 0]

The same IB8 has an emergency stop pushbutton, start pushbutton, and jam reset pushbutton. Plus the encoder. The other 4 spots on the card are unused. There are 100+ encoders on our system and every one of them is on an IB8. If you're wondering, it is a photo craft inc. Model RSB-P64AJ/8-30. And if you're also wondering, the switches have been set the same to the new one as the original. Also, as I mentioned before, no changes of any kind have been made in this area to belts, motors, gearboxes, belt speed, tension, bearings, photo eyes, VFD's, PLC's, RPI settings, etc. Which is what's so irritating. The closest and most recent work done was a bearing change 4 months ago, 2 sections before the problem section, and the problem started about 3 weeks ago. At least not until the problem popped up and troubleshooting began with components.

[matthudson 0]

The same IB8 has an emergency stop pushbutton, start pushbutton, and jam reset pushbutton. Plus the encoder. The other 4 spots on the card are unused. There are 100+ encoders on our system and every one of them is on an IB8. If you're wondering, it is a photo craft inc. Model RSB-P64AJ/8-30. And if you're also wondering, the switches have been set the same to the new one as the original. Also, as I mentioned before, no changes of any kind have been made in this area to belts, motors, gearboxes, belt speed, tension, bearings, photo eyes, VFD's, PLC's, RPI settings, etc. Which is what's so irritating. The closest and most recent work done was a bearing change 4 months ago, 2 sections before the problem section, and the problem started about 3 weeks ago. At least not until the problem popped up and troubleshooting began with components.

[ASForrest 12]

Hmm. Well that does seem odd, although I always maintain that just because it's always been done that way and worked until now, doesn't mean it's right ;) My next move then would be to check the dip switches, measure the RPM, and crunch the numbers. Work out how many pulses per second you're getting out of the encoder - if it's getting close to the 1kHz figure then I'd still be leaning toward that as a problem. You've probably got the manual, but if not it's here: http://www.photocraftencoders.com/PDF_files/RS-P64AJ.PDF - it has a chart for pulses per revolution by dip switch setting. If it IS close, then you could try changing your dip switch settings to give you say 20% less pulses per revolution - obviously you'll have to change your calculation logic in the PLC at the same time. That would give you a way of testing whether this IS the source of the problem without changing any speeds. While you're at it, just make sure that there are no on/off filters set up in the hardware configuration of the IB8 in the PLC program. Although I can't see that there would be, that'd be counter-intuitive if you're trying to read an encoder signal.