Ken Roach

Explain exactly what's there between the DH+ and the "ENI".     Is there a 1770-KF2 or similar device connected to DH+ ? It's possible that the Net-ENI was previously being uses in its unusual virtual serial port mode, rather than the customary EtherNet/IP to DF1 Full Duplex mode. When it's being used for DF1 Full Duplex, the Net-ENI can *only* communicate with one device, in a point-to-point DF1 connection.   That packet won't have a DF1 target address that can be forwarded to a DH+ node. I don't know for sure if this can be simplified so that the Net-ENI can communicate with DH+ Node 0 only.   Not sure. The PLC-5/11 does have an RS-232 serial port, which a 1761-NET-ENI can be connected directly to.   Be sure to set the port for CRC error checking, as the Net-ENI only supports CRC error checking and the PLC-5 default is BCC.  

I've had people complain about Produced/Consumed compatibility in the past and assert that it absolutely had to be a firmware compatibility issue. 100% of those who followed up found something other than firmware was the issue.    I can't say about those who didn't follow up. Somewhere around v17, RA added the option of a status header on a Consumed tag, so that you could tell the run/prog/fault status of the Producer and (I think) the status of the connection.    I suppose if the v28 controller was configured to send the Status but the v16 controller can't consume it (there would be 4 bytes too many in the packet) there would be a size mismatch. A common issue is the path to the controller;  the modern 5370 series CompactLogix consider the CPU and the Ethernet module to be the same, rather than considering the CPU to be in Slot 0 and the Ethernet module in Slot 1 and requiring a hop through the virtual backplane.  Depending on which CPU is Consuming the connection (and thus initiating the connection), the workaround probably involves inserting a different model of controller into the I/O tree.  

That path is the only place that FactoryTalk View stores its project files. You can't change it.  You shouldn't access it with anything other than Application Manager. Yes, it sounds unnecessary and different from most other software packages.   But that's the way it works.   There are reasons that make a little sense when you're using the distributed project model of FTView Site Edition, but even Machine Edition has these fixed, un-exposed project file paths.

Any chance he's exiting the routine programmatically with a RET instruction ? That last rung is weird;  it uses the same tag for both argument A and B in an EQU, so it's logically always true.   In addition, you almost never want to compare REAL values with an EQU, since they can be slightly different while appearing similar. When I'm troubleshooting a routine and am not certain it's being executed, I put in a diagnostic rung with a new DINT, and just an ADD( MyDint, 1, MiDint) instruction.   If the value increments every scan I know for sure the logic is being called.

The MicroLogix 1500 doesn't support "bridging" to DeviceNet from its serial port like the CompactLogix or ControlLogix do through their network ports. To reload the 1769-SDN's scanlist configuration, you will need a direct connection to the DeviceNet network.    The most common ones are the 1770-KFD serial to DeviceNet interface, or the modern 1784-U2DN USB to DeviceNet interface.   The 1784-PCD card is obsolete. If you have another ControlLogix or CompactLogix also connected to the network, you might be able to connect by bridging through that.

One of the things that FTView Studio ME has actually been very good about historically is backward compatibility of runtime files.    You can take a *.MER file from a version 3.2 terminal commissioned in 2003 and run it without modification on a brand new PanelView Plus. And it's been pretty good at the creation of runtimes for older firmware terminals.   Excluding version 3.0 (which only lasted a few months), you ought* to be able to create any older runtime version with a modern copy of FactoryTalk View Studio ME. The 32 bit/ 64 bit database issue when Rockwell Software migrated FTView Studio from Watcom to SQL only affects *.APA archive and project files, not the ability to create runtimes. Unfortunately I can't verify this with Version 8.10 of FTView Studio;  my newest machine is Version 7.0, which gives me the option to create a runtime for version 7.0, 6.10, 6.0, 5.10, 5.0, 4.0, 3.2, and 3.10.    *Exceptions:   of course there are exceptions. The biggest one is that the Windows CE version changed with the PanelView Plus 6, which substantially changed the operation of both KepServer and ActiveX components.    Any runtime or project from v5.10 or before that used KepServer has to be rebuilt and re-created to run on a PV+6 or newer.    Similarly, any project that used an ActiveX from version 5.10 or earlier has to have that ActiveX removed and replaced with one that's compatible with v6.0 or later. In addition, some PV+ terminals are oddballs that were released in between revisions of FactoryTalk View Studio, and the software doesn't correctly know which firmware versions they support.   An example would be if you had FTView Studio 6.10 and a then-new PV+ 6 600.    If you told Studio that you had a "PanelView Plus 600", it would assume you meant a Version 5.10 terminal and would remove v6 and v6.10 from the available versions when you went to create a runtime.  The workaround was to change the hardware definition from "PV+600" to "Custom Resolution 640x480", which removed the hardware filters from the selection drop-down. That's why I asked exactly what hardware OP was using.   I'm not sure exactly what's going on with his system, but I would try to investigate workarounds to create a v4 runtime before doing any riskier changes. Most PV+ hardware that supported v4 can handle v5.10 firmware at the highest.   Ideally, OP can check out the hardware and figure out what it supports.   PV+ firmware upgrades are relatively low risk;  I've never had one fail if I follow the procedures to free up storage before proceeding. Upgrades of FTView Studio are high-risk;  I never do an upgrade, always a fresh install.   And "downgrades" of Studio are a path to madness.

This *could* work with RSLinx Classic set up as DF1 Half Duplex Master, and the two slaves set up as DF1 Half Duplex Slaves.    I've never liked the Half Duplex Master polling driver, and I know it has some shortcomings in modern Windows operating systems. Do you get any flashing port lights on the 1761-NET-AICs when the RSLinx driver is running and connected ?

I'm surprised by that.    I've always been able to compile FTView ME projects for terminals firmware back to version 3.2. What exact PanelView Plus hardware terminal are you compiling for ?    I wonder if the terminal selection somehow got changed when it got migrated forward, and that the available Runtime versions are being limited by FTView Studio based on the hardware.

It sounds to me like you have serial drivers configured in both RSLinx Enterprise and RSLinx Classic, and they are conflicting over control of the physical serial port. Whenever I work with serial-only controllers and HMI terminals, I make sure that I have two separate serial ports and dedicate one to RSLinx Classic and one to RSLinx Enterprise.   That eliminates hardware conflicts and software configuration conflicts. I recommend against messing with RSLinx Classic OPC;  it doesn't help you very much in configuration, and it's the wrong data server for runtime. If browsing online tags just doesn't work, the simple workaround is to just type the data table addresses in manually.

It's stored in the RA Knowledgebase server, as Answer ID 450509.   You do need a TechConnect contract to access it in the Knowledgebase. https://rockwellautomation.custhelp.com/app/answers/detail/a_id/450509    

Is there a special reason you're using the 485CIF style message instead of a PLC or SLC Typed Write ?    Or why you're triggering the MSG in the MicroLogix instead of in the ControlLogix ? Is the CPU in Slot 0 of the chassis with the 1756-ENBT ?   The Nodes 45-49 method will only work with "Logix family controllers with integrated Ethernet ports", e.g. CompactLogix, or with a ControlLogix CPU in Slot 0. Also, PLC/SLC/MicroLogix integers are always 16-bit integers.  While you can map your PLC/SLC Data Table File Number to a DINT[x] array in the ControlLogix, I always use INT[x] arrays so that the elements line up easily. This configuration ought to work.    I follow the old Knowledgebase article that describes writing from an SLC-5/03 to a ControlLogix: https://rockwellautomation.custhelp.com/app/answers/detail/a_id/49384  

And by "of course", I mean that the discrete I/O from a RIO adapter will be in similar, but not necessarily identical, locations in the I/O words for the scanner module slot. The 1747-SN and the 1747-SDN scanners both exchange 32 words of I/O data with the controller as their ordinary I/O scan. Both can also transfer more data than that;  the SDN via copies of the data map and the SN via Block Transfer functions. The addressing and supporting logic for those two methods will be different.   Not impossibly different, but different.  

Well, of course it will require re-programming. If it were me, I would retain the DeviceNet and replace the Cutler-Hammer D50 blocks with something modern and readily available like the 1734-PDN and POINT modules, or 1791D DeviceNet I/O modules. The 1747-SN and the 1794-ASB2 are both out of production and can no longer be purchased, so you're only trading an unpopular obsolete module for a popular obsolete module.

I think I figured it out. Because the CPU and the Ethernet module are both considered "one and the same", on the modern 5370 series CompactLogix, you don't have to include the "local ethernet interface" like you did with the ControlLogix and the old CompactLogix. When you browse to the Etherne entry in the Controller Organizer, then the CPU icon ... you're creating a loop back to the CPU. The CIP path that Studio 5000 should accept is just "2, IP_Address, 1, 0".

What protocol did you have in mind, specifically ?

Putting the "remote" controller into the I/O tree will create an idle I/O connection to it, which will waste a small but nonzero amount of connection resources.   You could Inhibit the connection, which will not waste any resources. The Path you described does sound correct to me, though.   The "1,0" on the end is still appropriate for a 1756-L61 controller in Slot 0 of the target chassis.

The PLC-5E and 1785-ENET do not support the Socket Services that are available in modern ControlLogix.   The only non-Logix controller in the A-B family that does support them is the MicroLogix 1400 Series B. The first couple of devices I would investigate for a "raw socket" interface to a PLC-5 would be a Red Lion DataStation Plus, or one of the gateway devices from Real Time Automation (http://www.rtaautomation.com/), or even the MVI71-GEC generic Ethernet communication module from ProSoft.   All of those have good legacy connectivity to the PLC-5 platform.

I should have noticed the CIP Data Table write... you are correct that the SLC can only accept an SLC Typed Read/Write style command. If your workstation is on the same network, try using the TCPING utility (www.elifulkerson.com) to test a TCP connection to Port 44818 and Port 2222.     44818 is EtherNet/IP, while 2222 is the old A-B CSPv4 protocol.    If the SLC doesn't accept a TCP connection on that port, then either it's very old or there's something wrong in the networking between the ControlLogix and the SLC.

While the SLC in theory should ignore the final "Slot, Port" segment of the CIP path, it can't hurt to delete it.   SLC-5/05 and PLC-5E controller Ethernet ports are themselves the endpoint of the CIP path because there is no backplane object similar to that of the ControlLogix. Error 0x0204 is an ordinary CIP Connection Timeout. Are you certain the SLC-5/05 is new enough to support EtherNet/IP ?   If it's more than about 15 years old it might support only the older A-B CSPv4 protocol.  

TagServer is just a component of RSView32;  it's not installed or activated separately. Probably one of those other licenses is activating RSLinx Classic Professional.   It's been long enough since I had to research the fine details of RSView32/RSLinx licensing that I don't recall every permutation.

FactoryTalk creates a unique computer identifier for its own use, and this was a frequent issue when we did Automation Fair and other demos that involved creating many duplicate VMs.   Unless this is a very new RSView32 system, it's unlikely to need the same unique computer ID's in the FactoryTalk Directory as FactoryTalk View SE would. RSLinx Lite will not serve data to RSView32 because it doesn't support the native RSView32 function calls or OPC.     There were RSView32-specific licenses that were sold to enable RSLinx Classic as the data server;  they were called "RSLinx for RSView".   In general, you're going to need the Standard or Professional or "for RSView" license, not Lite.

You expect me to remember, four years later  ?   I think I was referring to "startup programs" as the Complex Code that you can designate to run at Powerup or at Startup. In Crimson 3, go to the Pages section and highlight the very top item, which is a little person icon.   Not the first Page, but the icon above that in the tree. You'll see in the middle pane a bunch of general options for the Red Lion terminal, including code that will run on Startup, on Powerup, and On Tick, plus the timeout and popup settings. I think these should be in some kind of "Terminal General Settings" screen, but that's where Red Lion put them.

If you have verified that the connections are secure and that there is voltage on the connector on the front of the 1769-SDN but it is still showing "92", then the module is damaged. I have seen this when 120V AC or 480V AC has been applied to the module, but it's very uncommon. Has this module been operating continuously, or is it new, or was it purchased used ?

This thread started about eight years ago and is specific to the integration between a PLC-5E controller from Allen-Bradley and an Omron controller. Your question is more general regarding how Omron supports EtherNet/IP, so ideally this should be a new thread in the Omron section of the MrPLC forum. Writing a comms protocol in any language is difficult;  some of the replies you get are going to be "buy a pre-made software toolbox", and I strongly recommend that you consider that advice carefully.

There are a couple of companies that can splice a flatscreen monitor into the video output of the PanelView 1400 terminal, but it's not generally a DIY effort. https://www.youtube.com/watch?v=f9SAvxpdJNk Rockwell themselves used to offer this service, with a factory warranty.  I don't know if they still do. http://literature.rockwellautomation.com/idc/groups/literature/documents/pp/gmsa10-pp014_-en-e.pdf Note that your part number is a PanelView 1400 Standard terminal, which was fairly uncommon.  The "1400" part number was usually associated with the PanelView 1400E Enhanced terminal, which is actually older than the 1400 Standard. A 2711-T14C3 terminal will be used DH485 protocol, so it's going to be hard to run a converted copy of the PanelBuilder application in FactoryTalk View Machine Edition.   Not impossible, especially if you have a 1747-UIC USB/DH485 interface. That's what I would do if it were my system;  import the application into FactoryTalk View Studio, strip out the alarming or any other subsystems that would take time to fix, and try to run on a laptop until I could get the project converted to PanelView Plus or something else.