Ken Roach

If you have an SLC-5/04 (not an SLC-5/03) controller with a free serial port that's still set up for good old DF1 Full Duplex, it is relatively straightforward to enable DF1/DH+ Passthrough and perform upload/download to PanelView Standard terminals on DH+ via a physical connection to the RS-232 Channel 0 serial port. The only two important steps are enabling DH+ Passthrough in the Status file of the SLC-5/04 (S:34/0 and S:34/5 = 1), and changing the Device Type in the RSLinx DF1 Full Duplex driver from point-to-point to "KF2/KE".  

The bad news is that rejected configuration parameters involving Rockwell's own module profiles are hard to troubleshoot.  Third party module profiles, doubly so ! With no extended error code, that suggests to me that there's maybe an identity or compatibility issue. Let's double-triple-quadruple check to be sure that the module profile matches the actual device.   You described it as a ProMag 400, and the module profile shows that it's configured for Firmware version 4.001. You posted a serial  number, " T711F49000".   The fifth screenshot shows a serial number "001AEA4A".   What does the web interface or a right-click in RSLinx Classic / Device Properties tell you about the firmware and serial number ? The IO connection fault is occurring when the controller sends the Configuration data block to the device, the Flow_MS_HSEast:C tag.    That configuration data assembly gets filled in when you configure devices offline and save the project.   I assume you've saved the Studio 5000 project then re-downloaded the program and cycled power to the ProMag. Do you have access to a network tap or mirrored switch port and Wireshark, to try to intercept exactly which parameter or object is being downloaded when the ProMag refuses the parameter setting message from the CompactLogix ?  

This probably is not possible with the EX600 and SLC-5/05.    The SLC (and the Ethernet-equipped MicroLogix 1100 and 1400) do not support I/O connections on EtherNet/IP like the ControlLogix/CompactLogix family controllers do. If the EX600 has a mechanism to kludge a timeout or send explicit messages, you will also need an SLC-5/05 that is new enough to support Ethernet Explicit Messaging (EEM). I'm wonder if I've got any EX600 stuff in the thrift shop shelves....

There is an "Add On Graphic" example in the RA Knowledgebase for the  PanelView 5000 platform: https://rockwellautomation.custhelp.com/app/answers/answer_view/a_id/1093164/loc/en_US#__highlight The document ID is QA58715, and you do need a TechConnect contract to see it and download the example code.

Welcome to the MrPLC forum community ! That *.ACD file is for a 1769-L33ER controller with v32 firmware.   That happens to be a version I don't have installed, so I just let Studio 5000 open it and convert it to the newer version before generating a PDF report. My guess is that this is a controller for a Char Technologies (Toronto) reverse osmosis water purification system.  It's a very well-organized and structured program. The maximum attachment size on this forum is 3.91 MB and even zipped the PDF is 14+ MB.   Send me your e-mail address via the Messages feature and I'll e-mail or DropBox/Google Drive it for you.

Thank you very much for those photos.    While the wiring is slipshod at best, at least it shows the pinouts !    The 1746-BAS has a 1980's vintage Intel 8051 microcontroller running a BASIC interpreter.  It has three serial ports and a bunch of custom routines for accessing DH485 networks and the backplane data interface for the SLC-500. One very popular use of that module is what you see here:  it is almost certainly polling a multidrop RS-485 wired network on PRT2.  The installers obviously used the same Belden cable for the RS485 network as they had on hand for DH+.   And that's fine:  it's ordinary shielded twisted pair, and low-speed RS485 is very forgiving.  When the jumpers are set for RS-485 mode, Pin 1 is Data(-), Pin 9 is Data(+), and Pin 5 is Data Common, and that's what pins are connected in the plug on PRT2. The most popular protocol for this purpose is good old Modbus RTU.    Prosoft sold a version of the 1746-BAS with their own firmware in it, and I wouldn't be surprised if you found a Prosoft chip stuck in an A-B labeled module. Honeywell, of course, has made hundreds of different models of controller that fit in a DIN cutout like that.   The odds are good that it does run Modbus RTU, but of course you'll have to identify it to be sure. There are dozens of ways to poll a Modbus RTU network with a ControlLogix.   The easiest-to-use are probably Real Time Automation's gateway, or the Spectrum Controls Universal Gateway.   If you told me "I don't know what protocol it will be on RS485 but you need to order the parts today" I would buy a Red Lion DataStation, because of their very broad range of serial drivers. To connect to upload this program, you'll need an ordinary serial terminal and an RS-232 cable.   Good old Hyperterminal or RealTerm will work.   You're literally going to send a Control-C to interrupt the program, LIST to make it print the BASIC program to the console (where you will copy/paste it to a document), then RUN to put it back in operation.

I would need more details about the type of "interlocking" and the nature or symptoms of the communication failures to guess. Most features that the 1756-ENBT version 4.x firmware supported are also supported by 1756-ENBT version 6 firmware.    Certainly ordinary MSG instruction and Produced/Consumed Tags would be supported.   I might expect some issues if one of the systems is ControlLogix Redundancy. You can read up on the details in the Release Notes: https://literature.rockwellautomation.com/idc/groups/literature/documents/rn/1756-rn591_-en-p.pdf Sometimes I have found that when you configure two devices and make a configuration mistake, you can mis-attribute it to the firmware revision, not to the mistake or difference in the configuration.    Or there's really a bug !

The only Studio 5000 family controllers that support real "Redundancy" are the 1756 ControlLogix, when equipped, configured, and programmed properly with the appropriate firmware, network modules, network architecture, and Redundancy Manager modules. There have been some attempts over the years to implement "hot backup" with ControlLogix and CompactLogix.   I am aware of a Application Technique document for High Availability CompactLogix that was last updated as version 4.0 about five years ago that used 1769-L30ER and 1794-AENTR products and architectures. The document and the accompanying "hot backup tool" code generation software is not publicly available.   You can only get it from a Rockwell Automation sales office, and only if you are approved by them and their country manager and/or Commercial Engineering at RA. Support for those systems is only available through the local field sales office that approved you to use it.    You are correct to be looking at the Fault Action configuration for the 1794 FLEX Output modules;   they should be able to be set for Hold Last State during a Fault condition.   Remember that Program Mode and Fault Mode are separate settings for FLEX I/O. Testing it is simple: set up a single-controller system with FLEX outputs configured to hold last state during a Fault, set some of them = ON, and unplug the CompactLogix.    If they work correctly and stay on when their connection is faulted, then the problem must be when they go back into RUN mode. Also remember that you must use a direct Module connection to each Input and Output module;  "Rack Optimized" connections to the FLEX adapter are not supported. You probably cannot easily solve the PanelView problem.    PanelView Plus terminals are specifically not supported in this kind of system because they cannot switch between IP address targets.   I've built systems like this using RSLinx Classic OPC Alias Topics with PC-based FactoryTalk View HMI stations. Again, this is something that your local RA sales and support office should be involved in.

Hi James ! The good news is that your wire-draw encoder is a really good device compared to how most wire-draw encoders work, with simple voltage divider and potentiometer. Yours has one of SICK's EtherNet/IP absolute encoders bolted to it.   That looks nearly identical to the Allen-Bradley 842E because it is. To scale your actual mechanical stroke as installed, Panic Mode is exactly right:  you need to capture the encoder counts at zero inches of your mechanism, and at 150 inches of your mechanism, and do a straight linear equation. You can get some insight into the encoder by converting those counts into hex: 1073741824 = 0x4000_0000 = half of the maximum value of a 32-bit signed integer 262144 = 0x4_0000 = 1/4096 of 0x4000_0000, so it supports up to 4096 turns.   The important specification that I got from the SICK website is that while the total wire draw is 5.2 meters for that model, the wire draw *per encoder revolution* is 385 mm. 150 inches is 3810 mm exactly. 3810 / 385 x 262144 = 2594204.26 counts for the full 0-150 inch stroke, or about 17294.7 counts per inch.    

Turning on all the segments of an LED display is a normal part of low level self-diagnostics for any embedded system with that type of a display, so the main control board probably isn't getting past the power-on self-test stage.   It likely won't communicate with anything or even flash lights for diagnostic codes. It can't hurt to try to flash the firmware with a 22-SCM or 1203-USB, in case it's only the display subsection that has failed.   But I think this is just a glowing brick at this point.

I have never seen that exact sort of display behavior on a PanelView 800, but it's surely a self-test process for the display driver section.   It won't hurt to power down the terminal, disassemble it, and look for a damaged cable or debris causing a malfunction. But otherwise, it probably cannot recover and needs to be replaced.

Because the indicators are on the POINTBus, it means a problem with the module itself or the POINTBus configuration. Is the module newly installed, or has it been running for a while ?    If it failed after running for some time, and simple re-seating it or cycling power does not recover it, then the module must be replaced. If it is newly installed, maybe the problem is in its slot number configuration.

In general, a motorized roll up door isn't going to be an acceptable means of emergency egress, because it can't be opened during a power outage. In my facility, every roll-up door also has an ordinary personnel door that opens outward with a crash bar and is accessible only with a key-card from the outside.   Access hours and authorization is handled through our central alarm and security system, not through any PLC-based equipment. As noted, any PLC that's going to be used to perform time-of-day work needs a Real Time Clock feature, and comparison instructions are generally how you program features for time window limits. The more challenging part is how you get a PLC to accurately keep time for its location, through power losses or battery failures or time drift.   Even the common method most computers use of getting the time of day from a Network Time Protocol (NTP) server on the enterprise LAN or the Internet is not built into many PLCs.  

The length of the string might differ by device;  mine was 20 bytes, not 33.   I agree that it might be simpler to get the Device Code from that identity object, and use its value against a table of known CPUs you can update. That list is on Page 194 of the 1756-RM003 reference manual: https://literature.rockwellautomation.com/idc/groups/literature/documents/rm/1756-rm003_-en-p.pdf Here's the results from my testbench:

See if FactoryTalk View ME's application manager utility will let you decompress the *.MER and create a Runtime from it.   That's the easiest way to reconfigure the RSLinx Enterprise drivers that are pointing to the RN6 now, and need to point either to an Ethernet/DH485 gateway or directly over Ethernet to the two new CompactLogix in the future. It might be possible to carefully reconfigure the RSLinx Enterprise configuration on those terminals separately from the FTView ME Runtime, but you want to be very sure you have appropriate backup files before you go messing with it.