Ken Roach

DeviceNet devices are isolated from the PLCs, drives, and I/O block main power.     For this reason, you must provide a separate DeviceNet power supply to power the network. This can seem counter-intuitive when you are accustomed to networks like Profibus or AS-i, or when you're connecting only one Input block.   But many DeviceNet products like photoeyes or proximity sensors don't have  separate power supply, so they must receive their network power and signal from the bus cable.     And PLCs aren't always part of a DeviceNet, so we can't rely on them to be the power supplies or load up their internal power supplies (a big DeviceNet can consume several amperes).

The default STRING datatype in ControlLogix consists of a 32-bit DINT that represents the Length, and a SINT[82] array that represents the data, one character at a time. In your case it sounds like you have BCData.Data[0] that holds the Length (but it's only 8 bits), then BCData.Data[1],[2],[3],[4] that holds the letters "6 8 2 8".    The last character is shown as "$r" which is shorthand for 0x0D = 13 = Carriage Return. The easiest way to handle this would be to use a MOV instruction to move the BCData.Data[0] value to the StringTag.LEN tag.     Use the MOV because it automatically converts from SINT to DINT and it's easy to understand. Then perform a COP instruction, with the Source = BCData.Data[1] and the destination StringTag.Data[0].   Make the Length of the COPY the number of target elements (SINTs), so use StringTag.LEN as the Length.    If you don't want the carriage return on the end, subtract 1.    

Check the DIP switch settings on the backplane carefully;   they are different for PLC-5 processors vs. 1771-ASB or -ACN15 communication adapters. A solid red PROC LED generally indicates an unrecoverable hardware fault, but it can also be an empty RAM memory if there is no battery installed.    If these were not reconditioned by Rockwell, it's likely you just got damaged and untested processors.

In general, the SLC-500 and MicroLogix controllers do not support I/O connections over EtherNet/IP.     Their Ethernet interfaces were never designed or intended to do so. I am a vocal opponent of attempting to work around this with MSG instructions.    The A-B drives allow you to do so by emulating SLC-500 data tables and having a timeout parameter after which the drive will stop if no MSG instructions reach it. And the V1000 may have something similar that lets you send CIP explicit messages to its Assembly objects with a timeout, rather than establishing an actual Class 1 Cyclic I/O connection like a ControlLogix would. But you'll have to find that info in the Yaskawa interface documents.    What exact interface module are you using on the V1000, or does that drive have an integrated EtherNet/IP port ?

I built "poor man's encoders" when I first got into controls as well. I stopped doing it after 1998, when an operator who had tried to repair one of those arrangements while the sprocket was still running shook my hand with his three remaining fingers and told me it wasn't my fault. If you're building solid equipment and writing programs that are reliable, accurate, and easy to understand, that's good.       

The PanelView 550 ran a proprietary OS, so ordinary Windows tools won't do the job. Ask the IT department to double-check to be sure they're looking at the right device.    I've never heard of SNMP being implemented on the  PanelView Standard terminals, and they don't show up in any of the Rockwell technotes or whitepapers about SNMP features or SNMP vulnerabilities.    I've read lots of third-party vulnerability search whitepapers on Rockwell products and PanelView Standard has never appeared in them. If they're sure that the PanelView is responding to SNMP inquiries, I think all you can tell them is that they can't be changed or turned off.

What kind of device are you using ? About 12 years ago (long before I arrived) my employer built a machine with sixteen Mitutoyo AT715 linear scales.    These use a simple serial protocol on RS-485, but it lacks a multi-drop address so we contracted with an encoder company to build a custom interface to bridge RS485 to RS485.   For reasons lost to the mists of time, we didn't use Modbus or any other industrial protocol, but rather a variation on the AT715 protocol, connected to Prosoft generic serial modules and an SLC-5/05 controller. A month ago there was a small disaster at the factory and half of these interfaces were destroyed.    We have the original designs and can get some of these boards built in six weeks for a thousand dollars each.    Or, we could pay an engineer to build the same sort of thing out of Arduino parts. Or we could do what I did:  order a box of Red Lion DSPLE protocol converters and write a program to go in them.       More expensive for hardware, yes, but far less risk and cost for engineering and troubleshooting.     The month of time I'm saving, and the reduction in risk that the devices won't work, is keeping a factor that employs a couple hundred people open and operating.   Arduinos are wonderful, but folks who do industrial embedded systems for a living usually don't start with them for their first look through the toolbox.

In general, a tag that will be Produced/Consumed must be a Controller-scope tag.    Tags that are in a Program-scope database or are instantiated inside an AOI cannot be Produced or Consumed. I would be skeptical of the need to directly reference anything involved in an AOI instance in a Produced data assembly.    Set up a mapping or data handling routine and use tags that are dedicated to inter-system communication.

You mentioned two instructions that are specific to the MicroLogix 1100/1400 operating system;   Read High-Speed Clock (RHC) reads the fast free-running clock in the controller, and Compute Time Difference (TDF) that calculates the number of "clicks" between two timestamps captured by the RHC. Is there a reason you don't want to use one of the hardware High-Speed Counters in the controller ? I haven't actually ever used those instructions, but I can think of how to use them. Are you literally counting gear teeth with a proximity sensor ?   What kind of tooth count and RPM will you be trying to measure ?  What's the response speed of the sensor itself ?

The UDT will contain all of the data that you are Producing/Consuming.    The first element of the UDT has to be a member with the type CONNECTION_STATUS.     I would also keep it simple and make the tag name also "Connection_Status".  

There is an option when you create a Consumed Tag to add a status header that gives you the status of the Producing controller.   The option was added in RSLogix 5000 v17, so it's definitely present for a CompactLogix 5370 series controller. You have to make your P/C tags into UDTs with the first element being of data type Connection_Status. https://rockwellautomation.custhelp.com/app/answers/detail/a_id/60813  

You need a 1761-NET-AIC interface device to convert from the RS-485 on the RJ45 jack on the 2711-K5A2 PanelView terminal, to the RS-232 type of signals on the Channel 0 serial port of the SLC-5/04. I replied with some cable part numbers to your post on another PLC forum.

That matches my recollection;  you can't change the Chassis Size or ignore the mismatch on a modular SLC-500 program. You're already doing the usual unlatch of S:5/0 to ignore math overflow errors, but your Major Fault is being caused by the condition noted in s:5/4, the M0/M1 Referenced in a Disabled Slot. Try doing an unlatch for S:5/4 as well, to see if that allows the controller to ignore the minor fault, thus preventing the major fault.

Welcome to the MrPLC forum ! When FactoryTalk View Studio creates a Runtime, it gathers up all the drivers configured on the Runtime(Target) tab of the RSLinx Enterprise communications setup window so they can be run in the PV+ terminal itself.    I think that when you shrink the driver browse, or click on the Runtime(Target) tab, you will see a ControlLogix Emulator driver configured.   You just have to delete it from the Runtime(Target) tab. The "Compact" PanelView Plus terminals only support one driver and one PLC.    The software could in theory delete all the drivers that are not part of the path to the one Shortcut, but instead of doing so it gives you an error message asking you to do it.

I think you've encountered one of the unsolvable problems in the PLC-5 world. I would approach it by finding every indirect address instruction and carefully examining the bounds of each index.    There just isn't another way to find out if that memory is not going to be used by an instruction that uses indirect addressing. If the risk is high, you've just got to wait for a shutdown in which you can create reserved data tables.

The best publication to have on hand when designing a POINT I/O system is the Selection Guide: https://literature.rockwellautomation.com/idc/groups/literature/documents/sg/1734-sg001_-en-p.pdf Pages 58-62 in particular have some good diagrams that show how the power bus is divided up. If you use the Integrated Architecture Builder utility to select bills of materials, it does a lot of the power calculations for you as well.

Also, there's no substitute for the classic texts:   http://modbus.org/specs.php    

OK, the Circuit Status Flags start at offset 8001 and are five hundred 4-register blocks. Those are described as Modbus "Input Registers".     Here's one of the ways that Modbus protocol can get confusing. Back in the Modicon controller days, Input Registers were prefixed with a "3".     So your first Input register was often called "Modbus Address 30001". These are different from the most common type of Modbus register, a Holding Register.   Holding Registers were prefixed with "4", so "40001" was your first Holding Register. The twist ?   The Function Code 3 was used to read Holding Registers (40001) while the Function Code 4 was used to read Input registers (30001). Determine how many blocks of that Circuit Status Flag data you want to read, and test polling it from the PentAir device by using a Modbus master emulator like that Chipkin program or the classic ModScan32.

What exact block of data is the circuit status for the heat trace zones ?   I don't know that device so I get confused by the difference between status and alarms. There are a bunch of different devices you can use to bridge between EtherNet/IP and Modbus RTU, with a wide range of prices and ease-of-use. My recommendations, from easiest to hardest: Real-Time Automation 460ETCMM (polls Modbus RTU slaves, writes their data to ControlLogix) MicroLogix 1100 with 1763-NC01 communication cable HMS Fieldbus Communicator Modbus RTU Red Lion DataStation Plus (DSPLE model) Digi One IAP GridConnect Net485 EtherNet/IP to Modbus RTU RS-485   And a tool you should have any time you are using Modbus: https://store.chipkin.com/products/tools/cas-modbus-scanner   If this were my project, I would grab either the HMS Fieldbus Communicator or a Red Lion DSPLE.     I know both products well and I generally want more flexibility and power and don't care as much about hardware cost because my time cost is high. If you're a complete novice and want the easiest-to-use thing, get the Real-Time Automation bridge device.    Their browser-based setup and device-initiated tag reads/writes are probably the easiest way to set up a Modbus RTU to ControlLogix/CompactLogix interface.      Call to be sure you're getting the right one for your application; I initially cited the wrong model number above. A colleague of mine put it succinctly:  "I use RTA because I'm hungry and want to be done before lunch."

Ugh.   I don't know your OEM's intent, but I'd say they delivered an almost-unusable device for your application. I think that LanTronix has hardware/firmware keying that prevents you from loading the "IAP" firmware onto an ordinary XPress-DR, so you're stuck with a device that provides reliable serial tunneling over IP, but is not appropriate for converting from EtherNet/IP to Modbus RTU. Do you have any other tools at your disposal in this system, like a PC-based HMI that could read this data ? The PentAir manual even says "this interface is meant for our HMI and software and is tricky to use with a DCS or PLC".      The first thing I would do is narrow down the Modbus data you want to read, and use a Modbus polling utility set up on a PC with the XPress-DR acting as a "virtual serial port".    Once you get that going you will have established that the serial port on the PentAir device works, and that the data is accessible. Then determine what you're going to replace the XPress-DR with.    There are a bunch of options, all in the $400 - $1000 range, with a wide range of ease-of-use.  It is (probably) technically possible to use the XPress-DR with the CompactLogix by modifying the Rockwell sample code for Modbus/TCP.     I'm an expert with industrial automation protocols and I wouldn't invest my time to do it when a hardware solution is available.

Second question:  are you tied to the XPress DR-IAP, or do you have the option to buy a different device ? My reading of the firmware release notes is that this is purely a Modbus TCP to Modbus RTU Serial gateway, and you would have to use the Rockwell example code to implement a Modbus/TCP Client on the CompactLogix.     This is not a job for a novice:  it takes up a large amount of memory and is tricky to troubleshoot.

Is your Lantronix device the ordinary XPress DR, or an XPress DR IAP with the "Industrial Automation Protocol" features ?     What sort of Modbus serial device is it connected to ? My understanding is that these devices are delivered with only the standard serial tunneling firmware installed, and that you have to download and configure the "IAP" protocols. I am not sure that the IAP models support EtherNet/IP on the Ethernet side, or only Modbus/TCP.   What is your reading of the manuals ?

Thanks very much for posting that photo !    It brings back memories of my childhood poring over the TTL Cookbook. The chip looks like an SN7407 "hex buffer", which interfaces "high" voltage to low voltage TTL and CMOS circuits.    It looks like Pins 2 and 3 or 3 and 4 blew up, which would be Input 2 or Input 3.    I can't say why those would be damaged by a 24V supply power inversion to the encoder.   That should have been prevented by one of those big honking diodes. All I can recommend is carefully applying 24V to the encoder, only after terminating all the DC outputs to the Input module so they can't short to ground or touch anything else.    

I can't give you direct advice because I have not specifically done this migration. The 1771-DL is electrically pretty simple, but has a wider input voltage range than most DC input modules (from 10 to 27 volts DC).    You can see the simple sinking inputs in the user manual for the module: https://literature.rockwellautomation.com/idc/groups/literature/documents/td/1771-td029_-en-p.pdf The 1756-IB16IF should have been ideal for this application.    It has fast inputs (the -DL had 1 ms filtering and the -IB16IF has 14 us) and isolated DC inputs that accept 10-30 V DC as either sinking or sourcing circuits. The 1771-DL also had a triac zero speed switch on the bottom two terminals that was intended to be used with 120VAC motor control circuits.   You definitely don't want to hook up any of the conductors that might have been involved in that to your 1756 module. The 1771-DL used sinking inputs:  you connected +24V DC to the module, and the encoder drew the input signals to DC Common.    The user manual says: So the encoder should be sinking 15 x 8 = 120 mA or so. How did you hook up the 1756-IB16IF ?    I can't imagine a way to connect these devices that would damage one of them unless you put greater than 30V DC on the circuit somehow.

Oh, that made me crazy too !     I couldn't understand why it was refusing connections from my computer specifically.   I had to flush my browser cache and then it started working. Kinetix 300 is a little clunky.   The fact that they used a Java-based configuration applet didn't help, as browsers and security issues quickly made that difficult. What's your exact problem ?