Joe E.

Those are signs of a relay failing. I'm not surprised that it's happening after 6 years in service. For something like that, you're far better off using a solid state output or, like you found, use the indicator light's built in flash function with the relay output staying on steady.

That's good to know about, actually.

I don't see the RTBs listed in proposal works or the user manual. What's the catalog number? Have you tried a 3rd seller like Radwell or PLC Center?

So, when you say the output is "burnt", what exactly do you mean? Can you hear the relay clicking when the output is cycled on and off? If you disconnect the wires and measure the resistance across the relay contacts, what do you get? How long (in terms of months/years) have the PLCs been in service before the outputs fail?

From an end user's perspective... We're working with an integrator to design/build/test/refine a prototype for us that will then be copied 3 more times (4 total). The quote for the first one included a lot of engineering time but the subsequent units were a lot cheaper because they're just building/installing them. The software will already be done and will require little if any modification. We had it stipulated very early on that we own the final product, including the design and programming and will receive a full package of documentation including drawings and source files (and not as pdf either). Locking the code, charging more to "license" the software, etc., is a good way to make me not want to buy from you again. Of course, licenses for installed runtimes that you have to have, like for a SCADA package or something, are different. Those licenses, however, should be included in the cost of the build and transferred to the end user. The fact that the end users don't have technical folks on staff may change things slightly, but I'd say only to the extent that you build in whatever you need for remote support.

How long were you flashing the light? That model has relay outputs, which have a relatively limited lifespan compared to solid state outputs. The manual (pages 133 and 135) talks about relay lifespan, which varies according to the voltage/current you're switching. Mechanical life is 20,000,000 cycles, which is about 2800 hours (115 days) if it's cycling continuously every 0.5s. The electrical life is shorter but depends on the voltage/current/inductance/power factor of the switched load (graph on p135). For something that blinks quickly/a lot, I try to use solid state outputs. The 1766-L32BXB and 1766-L32BXBA have some relay and some DC solid state outputs.

I'll have to check that one out.  

I think he's concerned about the possibility that the drive has some DeviceLogix code inside it in addition to the parameters. I've deliberately chosen NOT to use DeviceLogix, preferring to have any needed code in the PLC that controls the overall system, but I can see a system with a 75x drive that doesn't have a PLC finding a use for it. Since this drive is owned by a CompactLogix, I would be slightly surprised (and disappointed) if his system used DeviceLogix, but it's worth checking. Appendix D of the manual covers DeviceLogix and using the HIM CopyCat function. It also says that DeviceLogix code is edited using DriveExplorer, DriveTools/DriveExecutive, AOPs, and CCW so it should be pretty easy to see if the drive has any such code in it since it's integrated into the CompactLogix project.   At least it's not a 700S DriveLogix system...

I've used it several times when I didn't have an actual PLC available.

Is this an assignment for school? Show what you have so far and someone will likely help out.

The user manual covers at least some of the differences between series: https://literature.rockwellautomation.com/idc/groups/literature/documents/um/1761-um006_-en-p.pdf See page 1-7 (pdf page 19). In general, a higher series will generally work as a drop-in for a lower series and nothing in that list makes me doubt that you'll be fine. Since they specify series B, you should be ok with series B or higher. I would not be surprised if it does not work with series A.

Another vote for the 1756-DHRIO since you're talking DH+ between AB components. If you can't find one or if it's too expensive (they're "active mature" so AB has bumped list price to $3500), a colleague at my last position got a ProSoft module working between an HMI and a DH+ network. He had to do some magic to get it to work, but once it was working it was solid. ProSoft has some really good support folks who have been very helpful with that and with their Profinet-Ethernet/IP bridge module. Definitely reach out to them if that's the route you end up going. As an example application that I had to kludge together, we had a line controlled by a PLC-5 that had a bunch of RIO devices on one channel and one DH+ device on the other channel (a central gateway chassis that gave us remote access to the system). I had to add 3 strip resolvers, an HMI, and a bunch of code that was already written for ControlLogix. We had a bunch of 1756 hardware laying around (no CPU that was new enough, sadly), so I ended up installing a spare 5370 CompactLogix system to run the new code. It controlled a 1756 chassis via a 1756-ENBT module. That chassis had a couple of AMCI resolver modules and a 1756-DHRIO module to talk to the PLC-5. It was pretty simple to get it all set up and working and, even though it was kinda ugly, it's been running flawlessly for several years. All that to say, the AB -DHRIO module will give you a very solid, simple way to communicate between the DH+ network and the ControlLogix, but the AN-X2 will work too. I can't help you with configuration of it, though, since I didn't handle one.

It's really annoying when a company goes out of business like that. I had an issue with a machine where the company was bought and that division went away with no records left. We were completely out of luck.

Can you get the code from the machine builder? We were fortunate in that we did have access to them and they were helpful. We also ended up buying a license for the "Easy Professional" software so we could make changes to the code in the drive. That was definitely an exercise in frustration trying to figure out, but it wasn't too bad once we did. I wish I had access to the instructions so I could share them, but they may not be super helpful with a different model drive. FYI, most of the drives we had were EVS9325-EKV004 and GDC was all we needed.The drives we used Easy Pro for were L-Force 9400 HighLine.

Not sure how much it will help your scan time, or exactly what processor you're using, but look at the FLL instruction: If your processor doesn't have FLL, use COP. It works similarly, but you'll have to use an address for the Source that's always zero. Or, use a MOV instruction to put a 0 in the first register and then a COP to copy that value through the rest of the array: Check out the online instruction help for FLL, COP, and MOV to get familiar with them.    

I have limited experience with Lenze drives, but I do remember having a multi-page work instruction (with screenshots) explaining how to upload/download/activate/store the parameters using GDC. It was very possible and very easy with the right procedure but the procedure was not obvious or intuitive. I had to do something similar with newer drives using Easy Starter. That was similarly involved. I'm not at that location any more and I can't find the instructions I had or I would share them here.

I was curious so I had to look it up. The user manual doesn't mention 888 but the installation instructions do (page 9) https://literature.rockwellautomation.com/idc/groups/literature/documents/in/1734-in041_-en-p.pdf You can use the thumbwheels to set the IP address, set the rack size without software, or perform a factory reset. I'd stay away from the 8xx range altogether to avoid any issues.

I've never encountered Point IO before, so I didn't know about the thumbwheels. That has definitely caught me before, I think it was on a 1756-ENBT. That's a good trick that I'll have to try again. I seem to remember trying it once and it failing, but I don't know what device it was or what went wrong exactly. If it's not a new module, it's also possible that it's already been set. In that case, you can use Wireshark. Connect your network adapter directly to the device and see what it does. You should see some packets that contain its IP address as the source.

I think it's at least partially because of our IT settings, but I've found that I have to disable all network connections other than the one I'm using. In the BootP program, you can select which network interface to use. Then I use a patch cable to connect the network adapter directly to the device. You may have to power cycle the device after it's connected.

Theoretically....maybe. I've worked on HMI migrations where I had old and new operating side by side and it went ok...on the bench. But I wouldn't try to do so in the field. Having two devices control the same thing is generally not a good idea.

Hopefully someone with ABB specific drive experience will chime in here. The behavior you're describing is not what I would expect to see either.

I have almost no experience with ABB drives, but here are my first thoughts as a starting point. Does it accelerate more accurately while running on internal or external control? In other words, calculate how long you would expect the motor to take to get to its target speed based on the max acceleration parameter. I would expect the encoder feedback mode to be more accurate. Check also for other parameters that might limit the acceleration. It's possible there are current limits or other parameters that are only active while using encoder feedback.

A quick Google search says it's part of the older TP family. I don't think I ever used a TP but did use the older MP series. I know the MP series used WinCC Flexible and I'm pretty sure the TP did as well. I agree that you're probably on borrowed time with the HMI; my experience with the longevity of the MPs was not good.

Another end user here who insists on access to the source. We have a bunch of machines here (they started buying them before my time) that have Beckhoff PCs and the OEM's custom HMI software. We're locked in to their stuff and can't do much with them. We have another machine builder now who's also using Beckhoff but who has agreed that we will have full ownership of and access to the source code. I kind of understand the impetus as an OEM, but if you lock your code, that's a hard "no" from me. If I have any say in it at all, we won't buy it. I've run into too many machines with locked code and an OEM who was out of business or who had abandoned that product line so we couldn't support it and they wouldn't. The only encryption I would even be a little bit ok with is if it was temporary until the last payment was received and even that would only be if the OEM provided full (free) support during that period. That, of course, would have to be negotiated ahead of time.

Personally, I think that the best practice is to write the code in whatever way makes it the clearest to the next person to look at it. I generally prefer rungs be small enough to fit on one screen without scrolling if possible. If you can be clever and write it in one rung but it's difficult to decipher....be less clever and break it up so it's easier to decipher. I'm a fan of avoiding 2AM phone calls. I've been called because "the PLC is the problem" and they stumbled on a piece of code they couldn't understand so it had to be the problem even though it was completely unrelated. I try to write code defensively whenever possible.