Ken Roach

You cannot use POINT Guard modules as though they were ordinary I/O modules, or with a non-GuardLogix CPU.  

Disclosure:  This is the sort of thing I do for a living, but obviously it's a pretty expensive thing to contract out.   I'm happy to discuss it directly.

Followup:   I got out my Hilscher SyCon.net configuration software and created a new project for a NetTap NT100-DN-RS, which is a DeviceNet Slave on one side and a programmable serial device on the other. The Configuration screen does let you change the default ID object Vendor, Type, Code, and Revision from representing a Hilscher NT100 gateway to anything you wish.  So that would let you get around the electronic keying issue.    You can set the I/O connection size to anything you like, so you could emulate the data size of the existing pressure controller. I have never used Hilscher's NetSCRIPT engine to program a serial interface.   That might or might not be a way for you to use the NT100 as a gateway for this application.  

Unfortunately, without access to the DeviceNet master configuration, what you want to do is either impossible or very difficult. While that MKS device is very useful (and a classic;  I wrote some of the first A-B technotes using it in 1999) it has a slave data layout that's built for ASCII string transfers and almost certainly doesn't match the pressure controller's data layout.     Imagine you're exchanging eight 16-bit words of data.   The "group 2 only slave" standard just means that the data gets from Point A to Point B every X milliseconds.   It doesn't say anything about what each word means or does. There's also the issue of electronic keying;  most master devices check the Identity Object and won't connect to a device that doesn't match what they expect.  If I was going to take this on, I would need a DeviceNet slave whose ID object could be modified, and which is custom programmable on the serial slave side.   The Hilscher NT100-DN-RS might do the job, or a Red Lion DSPSX with a DeviceNet slave.    I have used both of those devices but never tried to change their Identity Object. To analyze the network, you would need either a raw CANBus analyzer (and a very strong DeviceNet background) or a more sophisticated tool like Frontline Test Equipment's NetDecoder. Compared to paying the OEM to modify their program to work with a different pressure controller, how much effort and time can you put into this ?

Check the sticker on the side of your MicroLogix 1100 to see if it has Series B firmware, and check the Processor Type in RSLogix 500 under Controller Properties to be sure it's set for "Bulletin 1763 MicroLogix 1100 Series B". As far as I know, the original MicroLogix 1100 Series A firmware did not support CIP Generic messages, while Series B does.   I think Series B is defined as FRN 5 or later.   You can indavertently select a "Series A" controller in RSLogix 500 and still download and run the program on a new controller. While the MicroLogix 1400 controllers had a hardware change to support Series B firmware, all MicroLogix 1100's can be upgraded.   

Ethernet transports hundreds of different protocols, and there are dozens of common ones in industrial use. So please, post some details about the device. Unless it supports the "PCCC" command set and the Rockwell Automation specific "CIP" transport protocol, it very probably cannot communicate directly with a MicroLogix 1100 controller. The bigger MicroLogix 1400 controllers (Series B and later) do support an "open sockets" feature that lets you connect to more devices, especially those with simple text or binary data protocols, but it's still not super-easy to use. A gateway or protocol converter device might be appropriate for you.     Post more about the air pressure sensor and folks can provide more advice.

There are three related parameters in the drive:   Encoder Counts, User Units, and Measure Units.     Encoder Counts of course is the number of counts per revolution of the encoder.   I think the Kinetix knows this value (often 128 or 1024 PPR) based on the motor part number. User Units (parameter 181) is the number of motor Revolutions per "User Unit".   This is typically a floating point number that expresses the ratios in the physical drivetrain. Since your slide moves 5.890 inches per 1 motor revolution, then the User Unit is 1/5.890 = 0.16977 revolutions per inch. Measure Units are the number of User Units in a Measure Unit (parameter 676, an integer multiplier and parameter 678, a selector for micro-meters, meters, or inches). When you command the drive to move 10.0 inches, it calculates 10.0  inches x 0.16977 revolutions /inch = 1.6977 revolutions.   It calculates the number of encoder pulses it needs to travel based on the Encoder Counts per Revolution.  

Obviously that's a light load of details to work on, but you've got what you've got. First, please verify that when you say "RIO" you mean I/O on EtherNet/IP, through a 1756-EN2T module.     The term "RIO" is a bit of legacy vernacular in the A-B world, referring to the old "blue hose" Universal Remote I/O network that the PLC-2/3/5 used for decades. Do you think that the comms problem on the Slot 1 Ethernet module was the reason that the Secondary was disqualified ? Did the disqualification and the failure to function as expected occur at the same time, or close together in time ?   Do the loads connected to the 1756-OW16I have inductive suppression or other circuit protection on them ?   Obviously "a relay failed to open as expected" suggests a stuck or welded contact in the relay. How was the system "stop" eventually accomplished ?   Did it happen later than expected, or not until another mechanism like E-Stop was used ? What version of the Redundancy firmware bundle does this system run ?   Have you verified that all the modules in the system are correctly loaded with firmware that is compatible with that bundle ?

What, precisely, do you mean by "loses its parameters" ? My guess is that you mean that parameters that you have recently adjusted or modified are set back to their default values, or to the values from before you set them. The PowerFlex 525 does support a feature called "Auto Device Configuration" that stores the parameters in the ControlLogix program.    Every time the drive is power cycled, the ControlLogix will check to see if the parameter set is consistent with the configuration, and download the configuration to the drive. If your saved set of parameters is the default set, then that's what the ControlLogix will download. The first thing to check is the "Automatic Device Configuration" tab in the vertical menu for the PowerFlex 525 in your Studio 5000 Logix Designer I/O tree.

It should have worked with a custom path, as long as the path existed on the USB drive. In my limited experience, though, if you use a filesystem path that can get disconnected, the Data Log will fail to reconnect.   That includes a networked drive that might get disconnected, or a removable media device that will get removed and reinserted. I've use Batch scripting command files on removable media to grab the log files off a PV+;  that generally works correctly.   It's a long standing irritant to me that RA put such a weak and unreliable data logging subsystem into the PV+, and stopped putting effort into it once they got it minimally stable.

"Not working" is too general a message to be a built-in part of the Citect software. You need to examine the Citect project to figure out exactly what sort of event or tag or diagnostic function that alarm message represents. "Missing" graphics in any HMI are typically those whose data is not available from the controller, so they are removed from screen or represented as "wireframes". I would strongly recommend examining the networking hardware and cables between your Citect computer and the SLC-5/05.     The SLC also has a built-in Web server that can give you some statistics or diagnostic information about errors on the Ethernet port.

The original A-B protocols for the PLC/SLC controllers are called "Programmable Controller Command Code", or "PCCC". The modern ControlLogix uses a set of commands they call "Common Industrial Protocol", or "CIP".    CIP's most common connection is over TCP/IP and Ethernet, but it's the same commands if it's transported by ControlNet or DF1 serial transports. Much of the CIP protocol and commands are published, especially for ordinary data access. But much of them are not.   You will get zero support from Rockwell Automation if you're trying to roll your own protocol to edit the controller user program.  

Parameter 388 and 389 are meant to be used together, as the High and Low Word for the "Units Traveled" parameter in the PowerFlex 525. Did you increase the data size so you could read two 16-bit words ?   It would not surprise me if the drive won't respond to a 1-Word request for Parameters 388 or 389 separately. Parameters 388 and 389 use an unusual encoding scheme;  instead of literally being the high and low 16 bit Words of a 32-bit integer, they are the value to the left of a decimal point (388) and the right of the decimal point (389). The manual also suggests that you can't Write 388 or 389 unless the drive is stopped.

If you are experiencing communication failures, you should condition your logic using the connection status of the remote I/O devices so that a "stale" value will not cause your system to malfunction.    I generally use a GSV instruction to read the EntryStatus value for a remote I/O module.   "Communication failure" is too general a complaint to diagnose.    Is the 1756-EN2T module firmware crashing ?   Is it losing connection to only one remote device ?  What is that remote device ?  Do you have any diagnostic ability on the switch ports or devices ports to determine if you have a cable or noise problem ?

You definitely cannot control 1756 ControlLogix I/O modules with a PLC-5 controller.    You could leave the 1771 chassis in place with the RIO network cable, and convert to a ControlLogix CPU, using the 1756-DHRIO or 1756-RIO as your RIO scanner.     That would end up costing more in time and effort over the long run because you would have to convert and test your program with a 1771 I/O architecture, then change it to a 1756 I/O architecture later.

Is the Fault LED on steady red, or is it blinking (at about 1/sec) ?     A steady FAULT LED means an unrecoverable hardware diagnostic failure;  the PLC generally has to be replaced. A blinking FAULT LED means that the controller is simply faulted;  it might have drained the memory retention battery, or be reacting to being in a new hardware configuration, or something else.   For your comms, try sticking with the default MicroLogix settings when you press DCOMM and that LED comes on green.   19200/8/N/1 speed and framing, SLC-Ch0/MicroLogix device type, CRC error checking, DF1 Full Duplex.    That way you don't have to rely on Autoconfigure.    

Generally the module that has been replaced by a 1734-ARM will be inhibited in the Controller Organizer. Instead, you have inhibited the entire 1734-AENT Adapter, so none of the modules should have an active connection. The red POINTBus status LED and the extinguished Network Status LEDs on the ARM and OW4 modules suggests to me that the ARM module has failed or there is another problem on the POINTBus assembly.

The old PanelView 550 has that "2" in the part number indicating that it has a DH485 network port only.   So it would have connected to the SLC-5/03's Channel 1 DH485 network port, either through an AIC isolator or just directly with the "AMP->RJ45" cable. If you had to stick with DH485, you could do it with a 2711P-RN3, or you could use the serial port driver version and use a converter like the 1761-NET-AIC or equivalent.   It's not great;   you can't test it on a Windows 7/10 PC because that driver ONLY works on the CE boxes. It's easier/better to switch to using DF1 Full Duplex, so that you can more easily connect a modern Windows PC to the SLC's serial port or the PanelView's serial port.   Yes, you have to unplug the PanelView to connect to the SLC-5/03, but unless you're fully geared up for DH485 with a 1747-UIC interface and some isolators, that's a reasonable compromise.

By my recollection, the 1747-KE Series B modules could get their configuration from the Output data table instead of via the console port.    If there's no references to the I/O or M1/M0 files for that slot, then the module is a Series A or it's just not using that feature.   You'll have to connect to it over RS-232 to get the specific configuration of the serial port, but there's a 90% chance it's just set up to behave like a DF1 Full Duplex to DH485 bridge.    The 1747-KE does not route comms through the backplane;  the RS-232 port and the DH485 port need to be physically cabled to something.    They were often used to connect dial-up modems to a DH485 network to allow remote connectivity to an SLC-5/03 based control system.   If all the devices were wired into a DH485 network, the KE would give you access to both the SLC and the PanelView without needing a local 1747-PIC connection. The user manual for the 1746-OA16 and it says 2 mA off-state leakage, and the 1769-OA16 user manual shows the same.   I'd say those modules are equivalent. I tend to prefer to migrate simple old PanelView Standard applications manually to Red Lion, but you can migrate to PV+ using those tools as well, once you upload the program (or use a memory card to copy it out of the terminal).

What kind of HMI device are you using ? How does the HMI read the flowrate ? If the HMI reads from the MicroLogix 1400 data tables, that's fine.    We can figure out where the data is being scaled incorrectly by examining the MicroLogix 1400 program and the HMI program. If the HMI is reading directly from the Promag 50, or from some other instrument, we need to know that to figure out the difference between those signals.  

You have asked a variety of questions about this project for the past several months, including correspondence directly with other Forum members. If you are taking it up again, please provide details. You have repeatedly claimed that your PLC "pulse count" does not match your HMI "pulse count" but you have not explained if they use different instruments, or if the HMI shows a value from inside the PLC.   Do not start posting a new question and expect Forum users to research your past to understand the history of the system you are analyzing.

I cannot understand what you are trying to do;  you're forcing Inputs and Outputs off as well as fussing with the STI, and you're doing it all in the Emulator instead of using real I/O.   What is your purpose with this logic ?

Many of the hardware-related features like discrete interrupts don't work in the Emulator;  the Knowledgebase goes into some depth: https://rockwellautomation.custhelp.com/app/answers/detail/a_id/55723 But the STI is supposed to work with the Emulator. I don't understand why you are enabling and disabling the STI in the same File 2.   It's a timed function, and is going to be disabled except between the last rung and the start of the next program scan.   When did you expect it to execute ?

The MicroLogix operating system only automatically executes Ladder 2. All of your other Ladder routines must be called with a Jump to Subroutine (JSR) instruction from Ladder 2, or executed by a system interrupt.

Does the control room meter display get its signal from the same flowmeter output ? When you change over a PLC to a new model, most of the I/O and signals work in a similar way.   But they aren't always exactly the same, so you need to research signals like this one. I don't think it's fair to say "it's very strange" until you have examined the whole system and program.