pturmel

This writes a single holding register.  Modbus function code 16, 0x10, writes multiple sequential holding registers in a single operation.  Devices that implement this latter function often do not implement function code 6, instead expecting you to use code 16 with length == one.

That makes me suspect that there's a hardware issue (whether robot or USB interface) that was triggered/exposed by the power cycle.  Have you tried swapping USB interfaces from a working PC/converter/Robot combination to see if the problem follows the converter?  Or swapping a known-good PC w/ converter to hook to the affected robot? (I am not an Epson Robot guy.)

When working to produce the Omron NJ/NX support in my Ignition EtherNet/IP driver, I was shocked to learn that these models don't use UTC internally.  Running an Omron PLC's clock on anything other than UTC is therefore a problem, IMNSHO.

I've never used the RSLogix Micro Starter edition.  Does it have a restricted instruction set?  If so, does the legacy program use any of the restricted features?

SQL is still the way to go, IMNSHO.  (I'd use Ignition before any of Rockwell's software, though.)

Well done.  Possibly worth posting outside the Rockwell category, as it looks like it would apply to a wider collection of targets.

It's fairly common in the Rockwell world for those strings to be generated solely in the programming software, and not be present in the PLC at all.  Wouldn't surprise me if that is true for Omron as well.

I haven't had to do something like this in FTView in many years, but it has VBA.  You should be able to define a list of strings as a constant, and upon changes to a text field, loop through them to produce a filtered list.  You could assign that to a list component's choices for the use to make the final selection.

Sounds like the kind of thing that happens when IP addresses collide but the devices involved are too old and stupid to throw an error.  (ARP poisoning, if you want to suggest something for IT to check.)

Relatively simple in a competent SCADA package.  What is available to you?

Generally, to capture packets between two arbitrary devices other than the computer running Wireshark (or similar), you need: Two NICs on the wireshark computer, in bridge mode, with the two devices somewhere on either side (and no other path), or The wireshark computer and at least one of the two devices on a true Ethernet Hub (not a switch), or The wireshark computer on the mirror port of a port mirroring switch, with at least one of the two devices on the same switch, and the mirror configured to duplicate all traffic to/from that device port to the mirror, or a High level mirroring configuration on commercial grade managed switches. A VPN is likely only compatible with the last of those. When not in my own networks, I tend to use command line wireshark (tshark) on an appliance-style Linux box in the first configuration.  Then transfer the file to my workstation to view.

By packet captures, I meant Wireshark or tcpdump actual packets, not stats.  You may need a lightly managed switch with port mirror capabilities to do this, or a computer with bridging functionality in between the two PLCs (this is what I usually do, with my office Linux hypervisor).

Can you collect packet captures of the working (unconnected) and failing (connected) situations? (That is a really strange/inappropriate error code from the Micro8xx for a buffered messaging connection.)

Normally I would export to either .L5K or .L5X format, and use a smart text editor to perform the search (for a complete instruction) and replace (with an empty string).  Then import back in.

Just delete it.  The rung will reshape accordingly.  (There is no instruction corresponding to your description.  Such are only needed when logic is constrained to a grid.)

Only if your DHCP server understands/responds to BOOTP.

DHCP is the successor technology to BOOTP,, and some DHCP servers can reply to the simpler BOOTP request format.  But the most common DHCP servers do not.

That doesn't look like Modbus at all.  RS-485 is just a signalling standard, not a protocol.  Are you sure the device supports Modbus?

Have you tried Siemens?  (That's who bought the brand--even continued it for years.)

EDS files document what is in the device.  Changing the EDS yourself doesn't magically make those parameters/assemblies/features exist in the device.  You even say: I don't see why you would guess this.  One product is from HMS Networks and the other is from Mitsubishi themselves. The HMS device is exposing a set of parameters in CIP classes 0x29 and 0x2a that are well-defined in the CIP spec.  The Mitsubishi EDS documents many vendor-specific class object parameters that are not.  I suspect you will only succeed if you purchase the full-featured interface from Mitsubishi.

Can you swap the v6 and v7 units to see if it is a physical difference?

You necromancer, you. Do note that Omron NJ/NX only respond to services 0x4c, 0x4d, and 0x4e.  In my experiments for my Ignition driver, they did not support services 0x52 and 0x53 for fragmented transfers, and will therefore be unable to bulk transfer structured data types larger than can fit in a large connection, and they only support large connections a bit under 2000 bytes.   Hmm. Not so sure about 0x4e, now.  Will have to experiment some more.

Interesting.  I should probably make a wizard to do this with my Ignition driver.

First, IPv6 doesn't have wide support among PLCs, so anything that is going to talk to a PLC needs to use IPv4. Second, DHCP servers can be configured to hand out dynamic addresses in one range, but offer specific IP addresses to specific MAC IDs in a separate range.  With this approach, no laptop or guest system will clash with an IP address reserved for an OT device.  Many PLCs can use DNS names instead of IP addresses in their configurations, too. (All modern Rockwell stuff can do this.) That said, I'd still set static IP's on critical systems.  There's no reason your IT department needs DHCP to have a complete DNS picture.  That's what zone files are for.

Interesting.  No longer shown as available for download with my integrator toolkit (but I have it activated for the current year).  You should talk to your Rockwell distributor.  I know they have formal channels to handle this kind of situation.