sharkyh2o said:
...I had =< 0 for the float and was subtracting .175. it would have been possible to take the value into a negative. Could that have caused the fault.
What data type is "the value" being stored in?
If your calculations could result in a negative value greater than -32,768, that is being stored in an integer, then yes, the processor could overflow. If your destination value is a float, then no. The 32-bit float data type may store between + - 1.175494e-38 to + - 3.402823e+38, which is a relatively larger range. It is less likely that you would be going out of bounds on a float data type than an integer data type. Besides, the overflow check is based on the 16-bit signed integer data type which may store a value between 32,767 and -32,768. So, for an overflow to be triggered, you would have to be going out of these bounds in an integer value.
ASF said:
If the OP is using a float as the output I would have said that, but when using a float as the input, that still leaves the possibility of the output being an integer, and I would still assume that it could still be scaled out of the allowable range of an integer and cause this fault. But then, it's not often George makes a mistake like that, so perhaps I'm missing something?
My good man. I make mistakes every day of my life! Maybe not always here, but trust me, I do make them.
So thank you, ASF. I must have read that too quickly as meaning they were using all floats. Rereading it now, I think our friend was assuming that the only overflow that might occur here is the value being assigned to an SCP's input operand? And that the SCP instruction itself could not create a resultant overflow? So by stating that the input is a float, they assumed nothing else could overflow?
The SCP could indeed still possibly be overflowing its output operand, if it is assigned an integer. Often, we see users assign either all integer or all float values to SCP instructions, and don't see a mix quite as much. But you'd never know? It depends on what they are working with.
The MicroLogix 1400 supports two versions of the SCP instruction. An integer version and a float version. Depending on which data type is used for the output operand, and regardless of the data type used for the input operand, the instruction will set all other operands to the same data type as the output. So the Input Min. and Max. and the Scaled Min. and Max. may be automatically set to either as you change the output data type. The calculations that the SCP then makes will differ somewhat depending on the selected output data type.
I'm not pointing this out so as to come to some conclusion as to why this instruction might be overflowing. I'm just adding it for further information. It never hurts to understand these little nuances.
sharkyh2o said:
In my scan I have an instruction to set f8.0 to zero when my drive ote is false...If i am following this correctly does the processor fault out at ladder 2 main end instruction? If so could I set my zero move instruction right before the end and not see the fault or is this just as bad as letting the unlatch in my program?
The overflow minor error bit is set as soon as an instruction's calculation is finished and it's value is in error. If the bit remains set, then the processor faults at the end of the entire scan which is at the END isntruction of Ladder 2. If you reset this bit before the scan reaches the END instruction, then the processor will not fault and the next scan is initiated.
Remember, the F8:0 float value itself is not creating a math overflow. It may, however, be indirectly causing one. If you know that by not zeroing F8:0 before the end a math overflow will occur elsewhere, whereas zeroing it then it does not, then I would personally still prefer to find the overflow culprit. However, if you, as the programmer, are happy that you are trapping and preventing it, then you could leave it as is. Good practice is to eliminate though.
The only thing I keep thinking back to here is the mention of the S:5/2 bit being set. I wonder was that just an explanation that was read as to a possible cause of the error, or was it actually observed as being set at any time?
Because it represents an instruction's Control Word error, it would not add up here, if you'll pardon the arithmetic pun. The SCP instruction does not use any Control Words and so could not set this bit, if indeed it has been set?
My reading of the above is that the error was being reset before you had time to check this? So it is still possible that Error 20 is "just" a typical overflow error and not Control Word related.
Regards,
George
