pturmel

This fits the definition of SCADA (Supervisory Control And Data Acquisition), particularly the "DA" part. As a systems integrator with a relationship with Inductive Automation, I tend to recommend their Ignition platform for such tasks.  In large part because they are much more cost-effective than the major competition.  I suggest poking around on their pricing page--the platform is modular.  For the limited purpose you state, you would need only the Tag Historian and the Reporting module, as the Allen-Bradley suite is part of the platform nowadays.  Most buyers of a SCADA package will also want to do supervision, too,  so you might also consider the Vision module or Perspective module so you can deploy user interfaces.

It seems a bit extreme to lose a job when you are given a task you've never been trained for.  I'm not a Schneider expert so I can't help directly, but it seems to me you need training if you are going to do this yourself.  Ask your employer for the training you need on this technology. { If you are a contractor that offered to fix this without the actual background to fix it, then that is on you. }

All of the PLC and HMI code I deliver is unlocked.  As is 90% of my SCADA work. I have a handful of generic SCADA plugins that I sell as products.  The source code will be delivered over my dead body.  That is, my heirs have instructions to sell that IP to an entity that wishes to maintain it, and/or to the users.

Irony is the perfect complement to pedantry.  Sarcasm can be appropriate, too.

Sysmac Date_and_Time is 64-bit integer nanoseconds from the Unix Epoch.  If you transfer using a tag set on Ethernet/IP, the other end can simply re-interpret the bytes to get the precise time. (It isn't UTC, though, in contrast to AB's WallClock.  I recommend using UTC on all Omron PLCs' clocks.)

Look at the socket inside the module.  It might not be there.  (I've seen installs that relied on the battery and ran entirely from RAM.)

I found this download link for the Honeywell UDC 330B (UDC 3300 Basic model): https://industrial-stores.com/files/Honeywell - Model DC330B.pdf On page 34 (pdf page 42) is the communication setup.  Please check the "ComSTATE" setting.  If enabled, your devices are using classic modbus, and you should use a modbus master module, not a BASIC module.  If disabled, you are using a the "MB3K" protocol, about which I know nothing. Consider just changing to Modbus mode unconditionally, since you don't have a basic program to reverse engineer.

I'm pretty sure there's no difference in electronics.

I wouldn't be surprised if the SD card simulation is entirely in simulator RAM.  Omron's simulators are not supposed to be able to communicate to the real world, and any real external storage would violate that rule.

That is "special" indeed.  Omron really butchered the standard.

I'm not familiar with either of those models, but I have had consistent success with USB/Serial devices based on the FTDI chipset.  Look for that.

Get the right battery.  Sounds like the substitute is not the correct voltage.  (A tiny difference matters.)

No, as alan says, RS485 is a physical standard, not a protocol.  It defines the electrical characteristics for sending bits.  That's it.  You will need the Honeywell documents to know the protocol.  Or decipher it from the BASIC program.

Yes.  You will have to stop the running program to LIST it, though.  So plan on some downtime.

And L81 ControlLogix to replace a SLC 5/04 is like cracking a walnut with a pile driver.  Way overkill.  Consider one of the small CompactLogix models.  If the BAS module is really doing custom serial comms, consider the ProSoft equivalent for the CompactLogix family.

I would not expect most people to consider a localhost-only connection to be the "outside world".

Pretty sure those are part of the Sysmac Gateway product and/or Sysmac Gateway SDK. Big $$$

Some USB-Serial converters are not sufficiently capable to operate these connections.  Also, there's a power pin on the MicroLogix round connector that can mess with a serial converter if the wrong cable is used (the pin supplies power to a net-aic or similar, using a special cable). Anyways, try a USB-Serial converter that is based on the FTDI chipset.  Those have been rock-solid for my uses.

You'll have to change your moniker now.  You're no longer a Greenhorn. 

The 24V power for the unit is not internally connected to the output rail. Show how you actually wired it.

Look at all the instructions with "Ary" in the name.

It is much like RSLinx in that it provides communications services to Omron products for all of its PLC models.  But unlike RSLinx, it provides no end-user tools.  It simply provides a uniform API for software to call. End-users would attach "Sysmac Gateway" to it, possibly having used the "Sysmac Gateway SDK".  I looked at that for a project and got sticker shock.  (Project died.)

With the goal of placing wireshark/tshark where it can see the traffic, the simplest option is to add a USB ethernet device to your laptop and make a bridge.  HMI on one port, other port continues to the switch.  Since the HMI's packets then have to traverse the laptop, wireshark there can see them. { I don't recall the incantations required in Windows, but I do similar in Linux all the time. }

Default for AB scanners has connection drop timeout at 4x the RPI.  Other scanners may make it configurable.  With that assumption, anything on the network that drops packets for 400ms will break the Point I/O connection.  Grounding would be a possible cause. I recommend using a port mirroring managed switch that can feed wireshark/tshark in ring-buffer recording mode.  Examine the ring buffer after the next upset.

Yes, with the v20 application open, and v20 firmware available to Rockwell's ControlFlash tool, when you start a download to that processor, it should report the need for updated firmware. And will offer to do so right there (and continue with the download after the firmware change).