For RS232 connected to a PLC I would assume it to be comparatively easy. Maybe it is not, but it is probably easier than for modern usb or network attached devices, since you can easily spy on transmitted data.
I would also assume that the PLC just gets some commands from the master.
What are you going to do with just the transmitted data? That's just a tiny part of operations, when the machine is working correctly. What if something breaks? Do you know what all the possible error states are? What does the machine have to do if it gets an eg. "machine on fire" alert? Does your software even recognize the data sent by the machine, if it hasn't been sent before and correctly recognized?
Sniffing a protocol to reverse engineer stuff, is like trying to learn a new language by listening to conversations of a ground-level monitor and a crane operator.
You can download the program from a PLC that supplies the logic aside from labels and comments, if that isn't available anymore. Some PLC even supply the complete project, but that is unlikely on such an old device.
Modern USB/TCP connected PLCs just encapsulate RS-232 data into USB or TCP packets, nothing else (for backward compatibility). Also there are encapsulation and decapsulation devices which enables archaic PLCs and other industrial devices to be retrofitted to more modern systems.
Moreover, the OP noted that emulation speed was at critical importance so, the code is CPU speed sensitive. Missing specs, missing company, missing source plus time sensitivity makes this endeavor very risky if not hard.
I would also assume that the PLC just gets some commands from the master.
Granted, these might be too many assumptions.