pturmel

I would make it precisely to fit my needs.  Maybe Mitsu has something built-in, but I'm not a Mitsu expert.

Since the master PLC is actually a modbus slave, and you want that slave to also respond to your monitoring, you will likely need to write a regularly changing value from each slave PLC to separate registers in the master PLC (heartbeat signals).  Then have code in the master PLC that will time out if a given slave's heartbeat stops changing.  Place the booleans for that status in other modbus addresses that the monitoring system can see.  (Or, perhaps, have the monitoring system watch the same heartbeat values.)

Share more details.  What is the network topology?  Are both PLCs Allen-Bradley?  Are you using message instructions in one to talk to the other? If so, show the three tabs of a message configuration. Embedded service error indicates that a request used message router service 0x0A to embed multiple requests in a single packet, and one or more of those inner requests failed in the target device.  You would have to inspect the nested responses to determine the true error or errors.  (Wireshark will help you do that.)

I would get an IT person to help you collect a wireshark capture, to see how far the connection attempt packets get.  And therefore let you focus on where they stop.

Sounds like a ground loop / isolation failure. (I have no experience with either those PLCs nor those HMIs, but that is where I would look.  With a scope, if necessary.)

I would expect you to need to use the SLC500 driver for that one.

Which model MicroLogix?  One of the new ML8xx family?  If so, you will need to use Control/CompactLogix(Tag) mode, for access to some global variables, or assign Modbus addresses within the ML8xx program.

Failure of the flyback protection on the contactor coil often proceeds to destroy the contact surfaces in the upstream relay.  But there are many possible reasons for mechanical failures, too.  You would need to dismantle the PLC output to determine anything for sure.

USB type A, type B, type B-mini, and type B-micro are not bidirectional.  I would be shocked if you could use any adapter there to plug in a mouse.

I remember these (with horror).

Fixed that for you. Siemens is as bad as Microsoft when it comes to vendor lock-in and other monopolistic behaviors.  Not to mention being extremely unfriendly to 3rd party use of their protocols. Going to modern Rockwell would also let you use their conversion tool for PLC5 => Logix.  Not the cleanest conversion, but saves a ton of engineering work.

I'm going to guess the time setting isn't a way to force the connection to close.  It may not be possible.

You can only use the switches for addresses like 192.168.1.x.  For anything else, you need to access the Module Configuration page of the device (via RSLinx)  through a temporary connection (like putting your PC on 192.168.1.y long enough to do this).

Have you contacted Rockwell support?

Oy!  That will make it extra difficult. I'd toss the PLC out, too.   (Or sell it on EBay for mega bucks.)

Wow!  I thought I was old enough to know about all the old AB stuff.  But not that one, sorry. You might need to take pics of every screen and start from scratch.

Have you examined the load resistance downstream?  Is it within the specs for the output card?  If any receiving component is not isolated, have you checked for DC offset?

EtherNet/IP Tag sets.  Set them up on each PLC, one to transmit, two to receive.  Ideally, create structure types with the content to transfer.  (This is similar to Rockwell's producer/consumer tags, and uses the same class 1 I/O buffer technology.)

Rockwell has wisely chosen PTP (IEEE 1588) for its time synchronization.  Much more precise, and auto-configurable in LAN environments.  Put a Time Machines TM2000B on your network, set it to PTP Multicast, and turn on time synchronization in all of the Rockwell products.  (Make sure the ControlLogix processors have time sync connections to their chassis ethernet cards instead of default connections.) Every controller will quickly be within single digit microseconds of the atomic clock that drives the GPS cloud.  The TM2000B also is an NTP server, so your less modern IT devices can synchronize, too. (I have no connection to Time Machines, other than as a very happy customer.)

No, don't ever do this.  Logix underlying clock (and all clock sync operations) run on Zulu time.  The checkbox in the controller properties just tweaks the local time offset.  Since not all timezones obey DST, with many crazy rules, the controller simply doesn't handle it.  Use an SSV to set/clear that checkbox programmatically if you need it.  The WallClock currentValue is always zulu, and should always be used for timestamping.

I don't have any specific recommendation for Mitsubishis.  In general, I would use a couple extra registers to hold valid conversions and look for repeat valid values before passing to a "final" value register.  That might be enough to not need a timer.

It is more than likely that you get noise on those signal lines when they change, which briefly, occasionally, yield an invalid combination.  You will need to disable the error and use a timer to debounce the value.

Do keep in mind that, unless you've encrypted the entire program, a motivated user can figure out where your blocking code is.  And then remove it.  If you do this, its engagement will punish the client for not paying you, but you will almost certainly end up black listed. If you get into a dispute over payment, take it to the courts.  Or black list them in the supplier world. Logic bombs are not a good idea, unless you've sold the software with the client knowing, from the beginning, that it will cease working on a particular date if not paid.

If I recall correctly, Windows won't let you mix DHCP and static IPs on the same interface at the same time.  Your middle screenshot of the advanced options would be where you supply multiple static IPs, but that is disabled because you have DHCP turned on. I get around this problem by running Windows in a VM on top of Linux, with a Linux software bridge on the real ethernet adapter.  I can then make multiple virtual ethernet interfaces in Windows, all pointing at the same physical interface on the Linux side, but with completely separate configurations.  Then I can enable and disable those adapters inside the VM as needed (or even run multiple simultaneously).

No, it IS a Profibus slave.  Because the OP HAS the master.  And IS a Modbus master, because the OP HAS the slave.