SCP instruction

I have been using a SCP instruction in my program, but I only want a "slice" of the total range scaled.... hence, the SCP instruction. However, I noticed that the output is still scaled after the INPUT exceeds the parameters. What can I do to avoid additional limiting instructions. It has faulted the PLC due to overflow when this happens.

Thats the way the SPC instruction works, it just keeps on going in a straight line.

Why don't you want to use limit instructions?

See link to take care of the overflow.

http://www.plctalk.net/qanda/showpost.php?p=596953&postcount=6

The additional LIM instructions catch the "overhang", but I prefer simplicity whenever possible. Also, technicians with less experience than me will have to troubleshoot this program someday. Thank you for the quick response.

I presume you are using rs500.

But if you happen to be using rs5000 and the SCP AOI, I would suggest instead using the Function Block (SCL) instruction. It has a limiting function built in that can be toggled on.

HI

Sorry to sound harsh but if a guy has trouble understanding a GEQ or LEQ or a LIM instruction then he will be in trouble with a SCP.
I always agree the code has to be as easy to follow as possible but you can not limit yourself from doing a good and correct job because you fear the next guy may not be able to read it.

If it stops your plc from faulting then it is the correct way.
I would use a GEQ and if above a value move the upper limit value back in.
This way you are only adding a GEQ and a MOV instruction.

Donnchadh

Why is the PLC faulting?

Is the result of the SCP in N register exceeding 32767? Put the result into an F register.

This way you will always know where you are.

If it is RS5000 SCP AOI and you want limits. Make a copy, modify it so you have the limits built in the AOI. It is quite easy to customize it for you individual needs.

The SCP instruction is just an easier version of the SCL instruction. They both do the same thing: y=mx + b

All you're doing is figuring out a line slope. The limits of that line need to be set with other instructions.

If you're getting overflow errors, you probably need to put the value into a larger-bit address. If you're using an N address, move it into an F address. F addresses are 32-bit and can handle any number from -2,147,483,647 to 2,147,483,647 as opposed to -32767 to 32767.

If you want to limit the output of the SCP, simply add compare and mov instructions after the SCP. If for example, you want to SCP to "Clamp" at 100. On another rung or branch below the SCP, do a GRT instruction to see if it's over 100, and if it is use a MOV instruction to move 100 back to the value. Of course, this won't help with your overflow problem. The internal calculation of the SCP will inevitably result in a number than overflows the address before the MOV can correct it, so I suggest if you're using a 16-bit address for the SCP result, change it to a 32-bit address.

FactoryTalktotheHand said:

The SCP instruction is just an easier version of the SCL instruction. They both do the same thing: y=mx + b

All you're doing is figuring out a line slope. The limits of that line need to be set with other instructions.

If you're getting overflow errors, you probably need to put the value into a larger-bit address. If you're using an N address, move it into an F address. F addresses are 32-bit and can handle any number from -2,147,483,647 to 2,147,483,647 as opposed to -32767 to 32767.

If you want to limit the output of the SCP, simply add compare and mov instructions after the SCP. If for example, you want to SCP to "Clamp" at 100. On another rung or branch below the SCP, do a GRT instruction to see if it's over 100, and if it is use a MOV instruction to move 100 back to the value. Of course, this won't help with your overflow problem. The internal calculation of the SCP will inevitably result in a number than overflows the address before the MOV can correct it, so I suggest if you're using a 16-bit address for the SCP result, change it to a 32-bit address.

Click to expand...

The values you quoted (highlighted in red) are for a 32-bit INTEGER number, not a FLOAT !!

But back to the original problem... the OP only wants the scaled value of an input variable when it is between certain limits.

When the input value (before scaling) is outside of his "scalable values", he should use LES and GRT to either set flags, or to MOV detectable unique values into the output address/tag of the SCP, as an example he could use -9999 for "below scalable", and +9999 for "above scalable".

I would prefer to use flags (bits), because it's easier to use these in following logic, such as the SCP, than looking for specific numbers, i.e. you only need to execute the SCP if neither "below" or "above" bit is true. You can use the "below" or "above" flag bits at anytime to say the data isn't being scaled, and the destination for the SCP instruction contains invalid data.

Oh, and Happy New Year !!!

calibrate the input

osmanmom said:

calibrate the input

Click to expand...

what good is that ???

the op only wants scaled vales for a section of his input range, nothing to do with calibration ...

I have noted that the PLC has "Faulted" due to a "Math Overflow", so this has to be an SLC.

In their wisdom, they programmed the SLC range to fault out on math overflow with a "trap" bit, which if set at the end of the PLC scan causes a major fault. Don't confuse the overflow "trap" bit with the overflow "status" bit, they are separate. The "status" bit will be set or not by every instruction that affects it, the "trap" bit will be set every time the status bit is set, which means the first time....

I don't know what they were thinking when they built this functionality, it's about as much use as a chocolate teapot !!

This is what the overflow trap bit does ... - "Somewhere in my program had a Math Overflow" - I'm not going to tell you where, I just remember it happened somewhere..."

The processor will go into MAJOR FAULT if the overflow "trap" bit is set at the end of the scan, regardless of whether the program actually looks at the overflow "status" bit after critical instructions, and deals with the consequences of that overflow...

I honestly can't remember seeing an SLC program without an OTU S:5/0 instruction as the last rung, the program will shut down without it, even though several hundreds or thousands of rungs of code have been executed, who knows what damage that might have caused - it is best to deal with possible overflows on an instruction by instruction basis, so this "trap" bit becomes even more redundant.

I have noted that the PLC has "Faulted" due to a "Math Overflow", so this has to be an SLC.

Click to expand...

The Microloigix series also does this.