Posted 26 Apr 2019 Hi, I have been helping a client overseas to upgrade and install some CPE330 PLCs configured as CRU320s to replace their faulty CRU320s. They had been previous controlling primarily from the Secondary (PLC B) for the last 6 years or so until PLC B finally failed due to a power surge. Having configured and downloading the previously working project to the PLCs in their respective hardware configuration, the system refuses to allow PLC A to control via the Citect SCADA, despite showing as Active and Ready on both Citect and the RMX Modules, although no outputs are read through Citect when PLC B is switched off at all. I found this forum from searching a previous post about drivers and if 90-30 and Rx3i required any changes (their previous setup before being Rx3i was 90-30), but as you confirmed in that thread, that the driver should be fine, unless you know of any issues with it working alongside newer PLCs configured as older ones? I should note we have discovered that the firmware revisions on each PLC is different and will be getting them to upgrade the later one to coincide. Each PLC has been tested in either HWC and both operate when configured as PLC B and neither operate fully as PLC A. We've had a GE technician check over the project and extracted text files from the PLCs and has confirmed the code and config looks correct. We're running out of ideas and out next step is to try and borrow 2 PLC racks and try to run them all first hand to see if PLC A runs on the SCADA in our office to try and rule out the software altogether! Any help you can provide would be much appreciated, Gene 3 people like this Share this post Link to post Share on other sites
Posted 27 Apr 2019 (edited) It sounds to me like there are two issues at play. First, which PLC is controlling the I/O and second, which PLC Citect believes to be in control. There are six %S memory bits which you can use to determine the situation. They are: #PRI_UNT (%S00033) which is true in the PLC designated as the primary. #SEC_UNT (%S00034) which is true in the PLC designated as the secondary. #LOC_RDY (%S00035) which is true when the PLC is ready to the active unit. #LOC_ACT(%S00036) which is true when the PLC is the active unit. #REM_RDY (%S00037) which is true when the other PLC is ready to the active unit. #REM_ACT(%S00038) which is true when the other PLC is the active unit. An example situation: PLC A is the primary PLC, Citect is monitoring it, but PLC B is controlling the I/O. #PRI_UNT is true, #SEC_UNT is false, #LOC_RDY could be either state, #LOC_ACT is false, #REM_RDY is true, #REM_ACT is false. I don't know the details of how CItect handles redundant PLCs, but I have to assume there is a mechanism to switch between which PLC it considers the one in control. The one in control being the PLC that Citect sends HMI commands to. Edited 27 Apr 2019 by Steve Bailey 1 person likes this Share this post Link to post Share on other sites