pturmel

You'll probably have to get the download from Rockwell, but yes, the license should work.

Consider making a diagram that shows the connections between your switches and routers, plus the two devices in your OP (showing which switches they connect to).  Ask your IT person what the routing behavior is for those two devices in that setup.

Unlikely, highly dependent on the router implementation.  Lots of simple ones will choke on sending a routed packet back out the same port it came in on.  Even the best routers will choke if a given subnet reaches the router via multiple paths. Mixing subnets on one switch is simply unsupportable (unless you are segregating by VLAN, and the router knows the VLANs). Supported layout, if you are not using VLANs: Every switch must have one and only one subnet assigned. Routers must have single (logical) ports connecting to each subnet. If you are using VLANs, each VLAN can be considered a separate switch, even across multiple physical switches, and then the above rules apply to the VLANs themselves. (An IT person who set up what you described is incompetent.  IMNSHO.)

Huh.  I'm not so sure this isn't just someone's disappointment with the DH+ data rates, which, even at its fastest, is multiple orders of magnitude slower than ethernet.  The CLX/DHRIO combination won't go any faster, I would think.  (My experiences with Prosoft devices are entirely positive, fwiw.)

Nope.  Let me summarize: An ethernet hub broadcasts packets coming in one port out the other ports.  This behavior matches the original coaxial taps and can be implemented with just switched amplifiers. An ethernet switch examines the MAC address on packets entering a particularly port and attempts to direct the packet out the port that is known to have that MAC address, eliminating excess traffic on other ports.  Where not contended, modern ethernet switches will stream the packet from inbound to outbound ports with just the latency of the header.  Switches fall back to broadcast for unknown MAC addresses, and apply various rules to deliberate broadcasts, multicast, and certain other kinds of packets. An internet protocol router examines the destination IP address of a packet entering one port (and if ethernet, addressed to the router by MAC) to determine which of its ports, if any, have a compatible subnet.  If configured to do so, the router will forward unmatched packets to an upstream router. When you have two incompatible subnets living on the same switch, packets destined for the opposite subnet will be directed to the source's gateway MAC address for routing, since the subnet indicates that the packet is not local.  If there's no router to echo the packet back out onto the switch with the corresponding MAC target (learned with ARP), the packet will simply land in the bit bucket on the floor.

You will almost certainly need a router, not a switch.  (Fire the IT guys?)

I'd lean towards option 2, with a new panel for just that processor, and no I/O there.  With a UPS for the controller and a new ethernet switch just for the PLCs in the room.  Then remote I/O to replace each micro.  The remote I/O doesn't have to AB, either.  Anything with EtherNet/IP support will run great, and might have better supply chain options.

And how can a PID controller do that?

If your measurement method is slow or imprecise, fundamentally, the only solution is to alter your measurement method.  If you have a high speed clock available, a common technique is to count clock pulses from sensor leading edge to leading edge, giving you the signal period.  From which you can take the reciprocal to get frequency.  If the available clock rate isn't high enough for the desired precision in one period, count it for multiple periods. Using a PID controller or not has no bearing on the measurement of your process.

If the contractor did a firmware upgrade from v33 to v34 newer than your current file, they should have supplied a new file.  Consider looking for that.  (You might want to find out why the upgraded the firmware, too.)

You will certainly lose the existing program when changing firmware. If you must maintain it, save a copy of your offline file to another location, upgrade the current file to version 34, upload the file from the processor, and compare.  If the offline file represents new work by a contractor, then they must have downgraded and you probably have a cluster-[expletive].

It is offering to update the firmware (downgrade in this case) as the only way forward before downloading.  The other solution is to change the controller definition in the project to the newer firmware and then download.

Hmm.  Now I have to go play with that.

Umm?  You haven't provided ANY details.  All we can say is that something about your kit or your procedure is different from your coworkers.

You cannot have station numbers above 63.  The numbers correspond to virtual DH+ addresses for ancient software that only talks on that protocol.  #63 is reserved for the PC itself for such devices to receive replies. Most modern software completely ignores the station number, so trying to associate with the trailing octet of an IP address is unnecessary, even if it were possible.

Windows wants to make everything conform to the latest and greatest format.  Don't let it, as that is not friendly to long-lived industrial devices.  It is part of Microsofts' "Embrace, Extend, Extinguish" methodology.  (To force you to use modern Windows wherever possible.)

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.)