In our (BIN95) in-person PLC Training on-site and open seminars (which will now be webinars), we use the math overflow fault as a PLC troubleshooting exercise. So I can help you out here. First we start off explaining to our students, most 'PLC Troubleshooting' in the real-world will be using the PLC to troubleshoot equipment. But occasionally a person will need to troubleshoot the PLC itself, or troubleshoot an incorrect PLC program itself. (Incorrect PLC programing being defined by us as one that did not use the best practice programming we teach.
1. We show them they use the "Go to Error" to view that tab in PLC status data file. (which you already know because you found the fault was the S:5 overflow fault.)
2. If they see the S:5 overflow fault bit is a 1, look in each Counter and Integer data file for the magic number 32767.
3. When you see it, right-click on 32767, and select "Find All".
4. In each search results that shows rungs that could change the value in memory location with the value of 32767 in it, click on them and software will take you right to that rung.
5. Then fix that rung so it works the way the programmer intended, not the way it currently is. (One of the best practice programing procedures we teach, has been ignored by programmer.)
Most of the time, if properly taught how to do PLC programming, the solution will be straight forward. If it is not for you, get with the programmer to find a safe and reliable solution.
Some of the PLC programming best practices that may be related to the math overflow fault are for example ... Never use the value of 32767 in your program. Every counter must have an associated RES instruction. Most copy and math instructions must have a One Shot in series with it. Any code that adds a value to itself like Add instruction in pictorial, needs a failsafe or reset action to occur before it reaches 32767. Etc. Etc. ...
Also note, some cards(modules) like a thermocouple card, is designed to place ones in all 16 bits (binary value of 32767) on card failure. So if you view real-world input card datafiles, you may also spot the magic number of 32767, although TC card failure much less likely. Most of the best practices we teach like the above, are not taught by anyone else, be it PLC Vendor, college, etc. (There are a lot of these, but not all, at plc-training.org)
Assuming you checked all the integer files while the math overflow fault was present like I instructed above, try viewing the sensor input card's status bits. Use the sensor card's manual to see what bits are what in that memory area. It is possible the sensor replaced is not the same as the original, and the programmer did not conceive that possibility and it is running you into overflow. But you would first have to trace down where that overflow is occurring in the program. But your input card status bits might give you another indication the sensor is not the same as original and/or setting need changed for the new sensor.