Joe E.

MrPLC Member
 View profile  See their activity

  • Content count

    1593

  • Joined

  • Last visited

Posts posted by Joe E.

  1. Posted

    I've worked on machines with the Banner safety controllers and have done upgrades on machines where we used Keyence. In general I prefer Keyence over Banner but I wouldn't be upset to work with either. We have other machines with Schmersal and ABB/Jokab controllers. The Jokab are ok but the Schmersal are kind of a pain, especially if you're not absolutely fanatical about keeping up with your source files. You can upload out of them but only a compiled runtime to transfer back into another controller. To monitor/edit you need the matching source file. In the AB world, they also have the 440C-CR30-... controller that's programmed in CCW (free) or can be embedded in a Logix project. I found them to be useful but their IO is very limited for the price and can't be expanded (with safety IO).

  3. Posted

    That's what I suspected would happen but I haven't used ADC before (heard "horror stories" from a colleague about the firmware versions having to be perfectly aligned and we very rarely had to replace one, so didn't seem worth it). I guess I expected that ADC would be contained fully within the Logix controller and wouldn't affect a disconnected drive at all, which seems to be what you found as well with your experiment.

    So basically, with the network unplugged, the drive parameters set to factory default, the STO satisfied, and all inputs disconnected except input 1....the drive should respond to HIM keypad control. I would think, at least...

  5. Posted

    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"?

  8. Posted

    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.

  10. Posted

    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?

  12. Posted · Edited by Joe E.

    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.

  17. Posted

    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.

    1 person likes this

  18. Posted

    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).

  19. Posted

    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.

  22. Posted

    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.

  23. Posted

    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.

    1 person likes this

  24. Posted

    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...).

  25. Posted

    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.