pturmel

The default for .read() on a binary file is to get just one byte.  You probably want .readall(). https://docs.python.org/3/tutorial/inputoutput.html#methods-of-file-objects

The NJ and NX processors support symbolic access via Ethernet/IP using the same read & write services as Rockwell uses.  See Rockwell's Logix 5000 Data Access manual.

I do this all the time, just not with VMware (I use KVM in Linux).  Two typical approaches: Use the typical NAT networking with the Allen-Bradley Ethernet driver, where you specify the target IP addresses in a table. Use bridged networking (often this needs a 2nd virtual network adapter in VMware) to share the host's network port.  Then the VM should appear to be on same physical network as the host, using DHCP or manual addressing or whatever.  The Ethernet/IP driver should work in this mode.

Consider using something like python's "struct" class to read your binary file and print the decoded results.  It can handle mixed structure types.

Ground loops could be surrounding circuits and metal housings--anything conductive.  Otherwise within the positioner.

Sounds like the rack itself is failing.

Did you try reading the program while the PLC was stopped?

In my experience, ground loops are the most common culprit.  When an isolated device's insulation starts to fail, it can (intermittently, perhaps) impose unusual DC voltages.  Analog outputs aren't often protected from backfeeds or random reverse spikes.  Or not well protected. Less likely would be repeated shorts that break down the AO's short circuit protection. Even less likely would be the loop-powered device's internal power tap's isolation/filtering failing, putting spikes on the loop that, again, wear down the AO's protection. I'm sure there are other failure modes, but these are the generic ones that come to mind.

That doesn't sound right.  I haven't been using it lately, but I've connected to many 90-30 model with Proficy to pull old programs out.  They'll never show "Logix Equals" with a different programming tool, but that can be correctly by re-downloading. Do note: the 90-30 does not carry the comments in the processor.  The original logicmaster files, if you have them, can be imported into Proficy.

{ Looks like a nice device family.  The EDS file shows no access to the input data except through assembly 100.  Implicit would probably be easiest. }

Manual W502 says that when the ErrorID is 1C00 as you show, then ErrorIDEx contains the actual CIP error information.  Error 0x04 ⇒ "Path Segment Error".  That means your safety relay doesn't understand symbolic addressing, or possibly is choking on the subscript.

Hm.  Well, divide by 2π to get Hz. Can you tell that my Bode-plot-fu is rusty?

Are you sure that is bandwidth? Looks like a speed rating.  Multiply by 60/2π to get RPMs.

No, you have to monitor your comm state yourself and inhibit receiving logic appropriately.  It is easiest to use a separate tag for "confirmed good" data that you copy from the consumer tag whenever it is fresh.  Then zero it if the consumer tag is stale for a timeout. I recommend using a pair of DINTs to carry the producer's WallClock UTC microseconds within the payload.  That should change for every new packet.

Some of those older products didn't have flash memory.  Does it have a lithium battery?  Those tend to only last ~6 months when powered down.

It isn't just Rockwell's.  It is part of the spec for devices that need to know that their owner (scanner) is actually running.  And whether to provide it and/or accept it is part of the EDS file, also in the spec.  This fault is entirely on Omron.

FWIW, the code 0x0127 is specifically an error in the connection size for the output from the controller to the device.  This is common when the 32-bit header is not properly accommodated.  (I vaguely recall having this problem with Omron and having to fake it with an extra DINT in the structure).

Maybe you need to send it back for a refund and buy something with proper documentation. Hmm?

Do much machine language programming?  XORing a register with itself is an efficient way to zero it in many architectures, mainly because no constant needed in the instruction stream. Not so much for PLCs.

Take your exact target coordinates and obtain the eight combinations of +tolerance and -tolerance on each of the three axes.  Compute the distance from your start position to each of the eight extremes.  The min and max from those eight is the min and max distance you can traverse.  The whole point of setting a tolerance is trade speed/efficiency/time against precision.  More tolerance equals less knowledge of the final position. If you must know the final position ahead of time, you cannot use tolerance.

If you can't find a suitable PLC quickly, you might consider putting an external hydraulic controller between the 1400 and your device.  I've had good results with Delta's products in the past.  They support AB's SLC/PLC-5 register-style messaging. { Maybe not.  Brutal pricing. }

Yup, terribly slow.  A 1400 is just not a fast platform, and limits like this highlight that. The best you can do is a two-stage approach to the target.  Trigger decel early to a creep speed, then stop from creep.  The creep speed would be chosen to yield the desired target tolerance with a latency of (130ms + scan time).

In your top screenshot, parity bit is "None", so the "Even/Odd" is ignored.

An RS-232 framing error indicates that the sender is not using the same bits/parity/stop bits as the receiver.

That has not been my experience, but I haven't used Prosoft's Profinet in some years.