PLCS.net - Interactive Q & A

PLCS.net - Interactive Q & A (http://www.plctalk.net/qanda/index.php)
-   LIVE PLC Questions And Answers (http://www.plctalk.net/qanda/forumdisplay.php?f=2)
-   -   ML 1400 error code 0020 (http://www.plctalk.net/qanda/showthread.php?t=103129)

sharkyh2o May 20th, 2016 02:36 PM

ML 1400 error code 0020
 
2 Attachment(s)
I replaced a direct plc with a 1400 7 days ago with no problems until today. Now i am getting an error code 0020. Here is the description.

(Control Register Error- The LFU, LFL, FFU, FFL, BSL, BSR, SQO, SQC, and SQL instructions are capable of generating this error. When bit S:5/2 is set (1), it indicates that the error bit of a control word used by the instruction has been set. this bit is ever set upon execution of the END or TND instruction, major error (0020H) is generated. To avoid this type of major error from occurring, examine the state of this bit following a control register instruction, take appropriate action, and then clear bit S:5/2 using an OTU instruction with S:5/2.)

I am not using any of these instructions, just 2 SCP's. I cannot duplicate this error. If anyone has an idea i sure would appreciate it. Also have a Red Lion Interface.Attachment 40855

Attachment 40856If

sharkyh2o May 20th, 2016 02:55 PM

Just set s:5/0 and s:5/2 and received the 0020 error

Ken Roach May 20th, 2016 03:06 PM

You can self-create the fault by setting S:5/2 by poking a value into the Status data table or using an instruction to set the value to be true.

But you can prevent the fault by setting S:5/2 false with an OTU instruction. This is an "unlatch" instruction whose symbol looks like

---------( U )------

In my opinion it's poor programming practice to do that because it means that your logic is malfunctioning in some other way, but it's OK as a troubleshooting tool while you try to figure out exactly what instruction caused the fault.

Ken Roach May 20th, 2016 03:14 PM

Remember that this major fault code 0020 can be caused by any of the first seven bits in Status word S:5.

While bit 2 means it was a Control Register, bit 0 is the most common because it can come from an ordinary math overflow.


It can be tricky to trap exactly which rung caused the fault. A good Knowledgebase document has some tips: RA Knowledgebase Article ID #31778 (Access Level: TechConnect) describes one method.

Also check your HMI application to be sure nobody can use it to enter a negative or out-of-range value into a data table element in the PLC.

sharkyh2o May 20th, 2016 03:14 PM

i seen the otu reset and i agree. I want to work my problem out. Leaning Twards the s:5/0. Just that my guys are resetting it before they tell me about it. Would there be an obvious math error if the processor is left in fault status?

OkiePC May 20th, 2016 03:15 PM

1 Attachment(s)
You don't want to set those bits, you may want to reset (unlatch) them, but it's best to know why you had the error to occur before doing that.

A math overflow is the most commonly seen type of minor error that will fault the processor if it is not trapped (unlatched) before the END instruction in LAD2.

In your SCP blocks, you may want to condition the input values to make sure they can generate a legal value for your output data type.

Your error could have been caused by some other minor error bit. Are you sure it was s:5/2 that was set when you found it faulted?

You can use logic similar to this to "trap" the math overflow condition without killing your process. If you put logic like this after each potential offender and use a unique internal latched bit for each location, you can identify where it happens:

sharkyh2o May 20th, 2016 03:16 PM

Thank you Ken

Geospark May 20th, 2016 03:19 PM

Yes, that OTU "fix" is only intended as a temporary workaround while you try to narrow down the instruction(s) that's producing the math overflow.

If the only "advanced" instruction you are using is the 2 x SCP instruction, then it is possible that they are scaling a value into an integer "out of bounds".

Any mathematical calculation that results in a value greater than 32,767 or less than -32,768, and placed in an integer, will set the math overflow trap bit, resulting in a Major Fault Error Code 20h.

If you use the OTU "fix" then you can monitor the SCP instruction's integer operands by moving their values to temporary holding registers of float data type when out of bounds. This would allow you to store and view the overflow value if and when it occurs.

Limit checking is very important here for the SCP instructions.

EDIT: this is similar to what OkiePC is suggesting...

Here is another useful technote...

39338 - Math Overflow (S:5/0) - How to locate the problem Rung/File (Troubleshooting)
Access Level: TechConnect

Regards,
George

sharkyh2o May 20th, 2016 03:24 PM

I am using a floating point in my scp instuction as the input. Should i be sending an Integer.

Geospark May 20th, 2016 03:26 PM

Quote:

Originally Posted by sharkyh2o
I am using a floating point in my scp instuction as the input. Should i be sending an Integer.

Ok, if using float then it is most likely not an integer overflow error but something else.

G.

sharkyh2o May 20th, 2016 04:25 PM

Going to try this for the weekend and see if i can find it. Thank you OkiePc

You can use logic similar to this to "trap" the math overflow condition without killing your process. If you put logic like this after each potential offender and use a unique internal latched bit for each location, you can identify where it happens:[/QUOTE]

sharkyh2o May 20th, 2016 09:55 PM

In my scan I have an instruction to set f8.0 to zero when my drive ote is false. I have a few move,add, subtract instructions and my scaling after that but thought i had an overflow protected by some comparison instructions. The speed was controlled by a motorized speed pot from an old unix cpu that had a mechanical contact to open at zero so the input to decrease speed is true the whole time the drive is off. 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?

ASF May 22nd, 2016 07:43 PM

Quote:

Originally Posted by Geospark (Post 691886)
Ok, if using float then it is most likely not an integer overflow error but something else.

G.

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?

sharkyh2o May 23rd, 2016 10:56 AM

3 Days and no fault yet. 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.

Geospark May 23rd, 2016 01:41 PM

Quote:

Originally Posted by sharkyh2o
...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.

Quote:

Originally Posted by ASF
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.

Quote:

Originally Posted by sharkyh2o
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


All times are GMT -4. The time now is 08:00 AM.

.