Joe E.

So, F059 is "Safety Open". Terminal 4 is a DC Common. It's probable that the system is using an external 24V supply and the drive's terminal 4 is connected to the system's 0V so S1 and S2 can use the system's 24V source. Lifting the wire on terminal 4 causes S1/S2 to lose their 0V reference and show open. Btw, that confirms that the STO function is not what's keeping your drive from running via the keypad. Have you tried to set P046-P051 back to their default values and t062-t068 to 0 "Not Used"?

May be a long shot, but are any of the digital inputs (other than terminal 1) wired to anything? I've seen weird things happen when an "unused" input was on.

Also, CCW is a free download from Rockwell. It's a very large file, so make sure your connection is good.

If you suspect the STO terminals may be making it stop, you can check parameter t105. By default, it enables a fault if the STO signal drops but it can be changed to disable the fault (I almost always do on these). If it's set to fault enable, you should get F059 when STO is dropped. You can also check bit 4 of parameter 6 to see the safety active status. I can't remember if the bit goes high when the STO signal is present or when it's gone.

You may also have to tick the box "Exchange high-low byte"

For PLCs, I'd start by going to YouTube and searching for Ron Beaufort. The videos are a little dated and are recorded using older AB hardware but the concepts are sill extremely valid and useful. What's your electrical/electronics background? If you download the datasheets for the PLC IO modules and the relays, can you figure out how to wire them together?

Another thought. For something that super simple (and if you KNOW that it'll stay that super simple), you could just use a timing relay. This guy, for example, will probably do that in "single shot" mode. I'd have it drive other relays, though, instead of the loads directly.

Check out Automation Direct. You can get a Click PLC (free software download) with on board Ethernet and IO, with a power supply for about $250. They also carry relays (I've had very good service from the Klemsan slim line relays, $8/each). How much do you know about wiring relays and such? If you download the manuals for the Click and the software, you can try it out to see if it will work for you.

I would use a 32 bit Windows XP Virtual Machine. I've read stories of folks successfully getting ancient programs to work on newer PCs, but in my experience things work better if your OS reasonably close to the software.

Can you share what the oversight was in case someone else encounters a similar issue?

I've never tried on Win10 or Win11. I got it to run on Win7, but uploads and downloads were very unreliable. I've found that the simplest thing is to maintain a Windows XP Virtual Machine.

Hmmmm......that's interesting. My license here is standard as well, purchased in 2020, and it lets me get earlier versions all the way back to v6. Out of curiosity, what's the catalog number of your software? Mine is 9324RLD300ENE.

Are sure it's your license that's the issue? My understanding is that your license shouldn't keep you from downloading the newer version. Have you reached out to Rockwell activation support? Or your local distributor? I would not expect that particular error if it's a firmware conflict. Normally it will flag the firmware version as incompatible and give you an option to change it. I searched the knowledgebase but came up empty. That doesn't mean anything, though. There could be an article about just this issue but my search terms aren't quite perfect enough to turn it up. I didn't see anything in the release notes, either. By the way, version 20 is one of the weird ones where minor revision definitely matters. The newest minor rev will support all of the previous minors, but before a certain minor rev the minor revision has to match between the PLC and software. I strongly agree that you shouldn't flash the firmware unless you absolutely have to. I'd chase down the right (latest) minor revision of v20 of RSLogix 5000 first. From what I can see it's v20.06.00. According to AB's compatibility site, v20.012 firmware is the oldest version supported by that processor and is compatible with v20.05 of the software.

It may not be it, but I found a tech note (Access Level: TechConnect) that says the power supply input voltage selector switch can cause it to not be reachable if it's set to 240V (factory default) but connected to 120V: https://rockwellautomation.custhelp.com/app/answers/answer_view/a_id/37014/loc/en_US I would think it wouldn't power up, but it might. And I would think the indicators would be different, but maybe not. That same tech note also suggests changing the IP address via serial connection if it's showing a major fault (MS indicator is solid red).

That's interesting. When I type in my serial number and activation it gives me the same catalog number but I can go to v12.  I'd reach out to your distributor. Or you can put in an activation support request. They will should be able to tell you what's going on. I've had generally good results with their activation support, but have had mixed results from their other support areas.

I did not know that...pretty cool, actually.

alan_505 is right. Also, something to keep in mind about the old black bezel PV 300 Micros. Their RTC battery is potted onto the main board and not replaceable. When it dies, as I recall, the HMI won't finish its boot process. We took to keeping our spares powered on to prevent that.

I'm not sure if this is your issue, but I've seen Simatic Manager choke on projects that were saved on another workstation that had an optional package installed that wasn't used in the project. If possible, get someone who can open the project to go to File -> Save As and check the box "With Reorganization". It will take longer than a normal "save as" but it is supposed to strip out references to unused software packages. Then see if you can open it. I'd offer to do it for you, but I don't have the software any more.

It's likely that the reason they upgraded the firmware is just that they happened to have v34 on their PC and not v33. Do you have v34? The first thing I would try is open Logix Designer and create a new project "from upload" and upload the project from the PLC. If the contractor was kind, you'll have the whole project, including documentation. If not, at least you'll have something to compare to your offline file.

I'm fairly certain the V/Hz on the nameplate is correct since it's a new motor on the problem machine. The speed reference is via Ethernet/IP, which is configured to "hold last" on comm loss since the start and stop are hard wired. While trending, the commanded frequency never deviates from 45Hz while the output frequency drops. When we had similar issues on another machine that had a high-slip NEMA D motor, the speed reference was the drive pot and was limited rather tightly by min/max frequency parameters, yet was acting very similarly. I had to dig into a different problem yesterday, so I didn't get a chance to get into the data logs I captured. I'm going to work on that a little today (if I can...).

We have a handful of nearly identical flywheel-driven machines. About a year ago, we installed a 15HP Powerflex 525 drive in simple V/Hz mode with DB resistors on one of the machines. It's been running great for that whole time. We have it set up so the STOP input (terminal 1) is wired through the DB resistor thermostats, input 2 is Run FWD ,and input 3 is Run REV. Since it's replacing an across-the-line reversing starter that's in the midst of a bunch of hard-wired relay logic, the drive's output Relay 1 is Ready/fault and will cause the relays that control drive inputs 2 and 3 to drop if the drive faults. This arrangement has been running fine on machine #1 for over a year. We tried to duplicate that installation on another machine that has an almost identical motor (np is 1765 RPM instead of 1775, but otherwise the same including NEMA Design) but we're getting DC Bus overvoltage faults after the machine cycles for around 10 minutes. When trending in CCW, I see that the output frequency drops to 0 from one sample to the next while the STOP and Run FWD inputs are still ON and Relay 1 still indicates OK. The commanded frequency doesn't change. On the next sample, Relay 1 drops out, which also drops out input 2 (Run FWD). Then, about 400 ms later, the DC bus climbs past 810V and the drive faults on bus overvoltage. That's the only fault that's shown on the drive. The only parameter differences between the 2 machines are the network addresses and the v7 drive has flying start enabled since it doesn't have a flywheel brake that applies when the motor is stopped. This screenshot  the values of the trended parameters as the output frequency drops:   Here's the next trend sample, at which point Relay 1 has dropped, taking Run FWD with it. At this point, the DC bus (the visible graph) is still well within its normal range. It trips at 810VDC, which happens about 400ms after the output frequency drops: Per a suggestion from Rockwell, switching the drive to SVC (with a static autotune) accelerated the issue and I actually saw the STOP input open when the resistors got hot. The fault happened a lot sooner (in a few minutes of cycling instead of about 10 minutes). They also suggested changing p36 to 1800 to remove slip compensation and then to use P531 to disable the bus regulator, but neither improved the situation. In case we managed to get a bad drive out of the box (or broke something during installation), we swapped in another brand new drive and got the same result. The only difference between the drive that's working fine and the ones that are faulting is the firmware version. The older one is v6.001 while newer ones are v7.001. The release notes don't highlight any issues. I would rather not flash the firmware down, but that's about my last option that I see here. Any ideas?

Bob, thanks for taking a look. 1) P42 Decel time is set to 20s 2) The drive that trips is tripping while running, not while stopping. 3) P45 stop mode is DC Brake/CF I ran some more trends at a higher rate after talking to a distributor rep. He suggested that the DB Resistor protection circuit may be forcing the output frequency to 0Hz if the DB duty cycle is too high, which it looks like it might be. The problem I have with that theory is that the ready/fault output is dropping long before the bus overvoltage happens. I can see the sequence being off by a sample or 3 (in fact, trending in CCW shows a slightly different sequence than trending in Logix Designer), but I wouldn't expect the ready/fault to drop until after the DC bus actually goes high, which is about 400ms after the ready/fault goes low. Flashing the firmware back to v6.001 to match the working machine had no effect. I'll be back into this in the morning.

Thanks for taking a look, guys! I thought about that, and about flashing the firmware back to v6 (if it will let me). If I have time, I may be able to swap the drives on 2nd shift when they're not running production but we already have machine #2 down for this upgrade so they're not going to be happy if we take #1 down at the same time.

Don't forget to think about failure modes. What if the e-stop button sticks? What if its contact block falls off? What if the dump valve sticks? Etc.? If someone could get hurt, the system almost certainly needs redundant devices and circuits.

Wait, Rockwell left something out? Say it isn't so.... Sorry, that slipped out...