F_1[2]:=(F_1[1]/1000.0)*60.0
F_1[3]:=(F_1[2]/GEARIN)*0.262
I'm assuming that everything involved is a REAL. GEARIN is a REAL, not an integer, and guaranteed to not be zero.
If integers are mixed in there you usually want to do the multiplies before the divides.
A PLC with good FBD and strong data typing would let you program this stuff so that you can see the intermediate results. You could see F_1[1]/1000.0 before it hits the *60.0 part. In this case you do not have that luxury. Just because you cannot see the intermediates does not mean that you do not have to think about them.
The old Symax Model 300 used 16-bit math. An analog input ranged from 0 to 9999. Lets say you wanted to scale it to 0-1320 for a 132 foot water tank in tenths of a foot. The rung looked like this:
Let Scaled = Raw * 1320 / 10000
The problem was the intermediate result blew up over +32767. It became a real headache to do scaling - probably why it was sometimes done in the HMIs back then.
They fixed the problem in the Symax 400 which allowed 32-bit intermediate results.
The tendency today is to just push anything into a 32-bit REAL and don't sweat the details. Many times that works. Sometimes it doesn't. Check out the thing where the Patriot missed the SCUD and 28 people were killed. That Raytheon programmer loved REALS a little too much.
The moral of the story is to keep data types in mind. We're not JavaScript programmers who don't even know what data type is.
