Automated equipment controlled by pascal program

[DuDe9899]

Hello,
I work at a company that uses some testing equipment that is automated by a program written with turbo pascal. I don't have very much programming experience, just a little. This equipment has worked fine up until a few months back when it opened and gave an error a few seconds afterward: "Runtime error 207 at 2757:000C.rol". I found that this indicates an "invalid floating point operation", but I'm not exactly sure what that means or what would cause that to occur so suddenly. The location part confuses me also. I was thinking that this problem might be because of a piece of equipment malfunctioning, but that has not been made clear.
Does anyone have any advise that may help me find the source of this problem?

 

[Glenn9999]

Is the source code still available for this program?

A floating-point operation is a calculation using a floating-point variable. Likely what is going on is that there is a division where the denominator is zero or very close to it.

Hope that helps, though that doesn't seem much. You really need the source code available to know more.

 

[lionelhill]

Had anything changed about the equipment or how it was being used at the time the error first appeared?

 

[DuDe9899]

Yes, the source code is still available. But the program has worked fine for years now. That may help, but I don't know how I would find where that occurs.

Nothing obvious changed about the equipment. My boss and his grandson went and turned it on and tried to use it the first time the error came up, but they said they didn't change anything, just simply turned it on.

 

[Glenn9999]

Yes, the source code is still available. But the program has worked fine for years now. That may help, but I don't know how I would find where that occurs.

A program working fine for a period of time is no indication that the program is working at the current time.

Case in point is the CRT RTE 200 error. Programs worked fine for years based on certain assumptions made that worked for the time. But when faster processors came along, the assumptions were invalid and the error occurred in these programs.

As for this program, you need the source to be able to debug what is going on and fix it if necessary. As I remember you can take that address and run it through the compiler somehow. But the more likely thing to do is put writes into the app (back up the original source of course) indicating different points in the logic to narrow down the statement that causes the Run time error.

Once you locate the offending statement in the source, you can make the decision from there as to what is required to remedy the situation. For the situation you describe, it might pay, even if it is a once in a lifetime thing, to write some error-handling code to trap the error - if an expected input from the system is not there, come back with a "Unexpected input from machine, please call for service." message or some such thing.

 

[Actor]

Where are you located? I'm asking because I've written such a program and I just might be the author of this program.

Actor

 

[DuDe9899]

I'm located in Carson City, NV.