Subtraction with GX Works 3

[Simo99 0]

Hi guys,

I have a problem in a FB of GX Works 3, I am trying to do a subtraction of two variables that have Double Words Signed as type. These two variables increment, the second variable is lower than the first, but the result is always high and this is strange.

So there is an error I have not understood, who can help me?

 

[AndreasW 21]

hi Simo99,
just some thoughts:
- did you use the DSUB/ D- instruction? if you use SUB/- instruction with DWORD the result is wrong?
- is the second value realy smaller the first one?  you can check the Carry, Zero and Borrow Flag 
( SM700, SM8022 Carry When the operation result exceeds the upper limit of the data setting range, the carry flag is turned ON.,
  SM8020 Zero When the operation result is 0, the zero flag is turned ON.
  SM8021 Borrow When the operation result is less than the lower limit of the data setting range, the borrow flag is turned ON.
)
- did you select DWORD inside your monitoring window ?
 

[Simo99 0]

Hi AndreasW,

I am using the "D-" instruction and the results are wrong. I have not found the "DSUB" instruction on GX Works 3, where can I find it?

The second value must be less than 500.
To get closer to solving the problem by doing this test, should I put "Carry" in parallel with subtraction?

How can I select DWord within the monitoring window?

Many thanks in andvance

[AndreasW 21]

hi Simo99,

can you post a screenshot of your program and what values do you want to substract?
 

[Simo99 0]

I'm trying to explain myself better, I'm using a function called "D-" in an FB, the first value of the subtraction should be 500 larger than the second one, because these numbers are the results of two operations in a Program and they always increase depending on the number of times they enter certain ifs.

The variables I am using are labels, specifically the first number is an input variable, the second number is an IN/OUT variable and the result is an internal variable.

Edited 22 Jun 2022 by Simo99

[AndreasW 21]

looks like that your PlsActMemory is zero when the FB is called?
if this FB is called and PlsActMemory is zero, your delta will be equel to PlsAct :
"DeltaPls= PlsAct - 0 => DeltaPls= PlsAct"; like in your video

if PlsActMemory is an IN/OUT variable do you set the saved output value of the FB to the input when calling your FB?
if you don't set it, then PlsActMemory will set to zero when the fb is called

[Simo99 0]

Thank you very much.
I have solved something, but not everything because the subtraction is still wrong.

Do you have any other advice please?

[AndreasW 21]

i still think that "PlsActMemory" is always Zero when the function block is called, and that the value of PlsActMemory isn't stored between
the functions calls, because this seems to be the only way that  "DeltaPls" is always calulated to the same value as "PlsAct".

PlsDelta = PlsAct - PlsActMemory ([D- PlsAct PlsActMemory PlsDelt]) =>
PlsDelta = PlsAct - 0 =>
PlsDelta = PlsAct

Maybe you can save the current value of "PlsAct" and "PlsActMemory" to some temporary variables
before the [D- PlsAct PlsActMemory DeltaPls] instruction to see what values both variables have before the
substraction takes place
e.g.:
---|  SM400 | -------------------------------[DMOV PlsActMemory Temp1]
---|  SM400 | -------------------------------[DMOV PlsAct Temp2]

as i wrote before PlsActMemory will be Zero when its defined as IN/OUT parameter and the the value is not passed
again to the input signal of the function block. In this case the current value (PlsAct) first is stored in PlsActMemory
by the [DMOV PlsAct PlsActMemory] but will be reset to zero with the next call of the function block.

 

 

[panic mode 245]

exactly, copy values to additional (and unused) memory locations to see what values are before and after subtraction. it should be an eye opener. you can remove this later. also check what other instruction writes to PlsActMemory.

testing instructions to see exact behavior (and build experience and confidence) is also important. always do that on memory that is not used anywhere else. that way there is nothing ele that can change the instruction parameters and give you unexpected result. 

[Simo99 0]

I did the test but the values are negative.
The values became negative after the correction of the FB call.
I don't know how this is possible

Edited 22 Jun 2022 by Simo99

[AndreasW 21]

looks strange, but i think this is because PlsMem is now saved between the fb calls like it was intended.

I think you have a problem with your PlsAct value:

1.) you wrote that the difference of PlsAct and PlsMem should be less than 500 (pulse) ,
but if i look at the both temporary values:

PlsAct (Temp1) = - 903.443.592 (currente value)
PlsMem(Temp2)= - 930.792.352 (last value)

=> PlsAct was increased by 27.348.760 between the fb calls, and PlsAct isn't changed inside the FB
 

2.) PlsAct gets negative, so i think that your actual Pulse counter exceeds the DWORD Range of +2.147.483.647 and then
the values will be negative. And if your PlsAct value changes within the range of 27.348.760 this can happens easily after a short while.
You can check/detect the overflow of PlsAct with the Carry-Flag (SM700), that will be set if addition or
substraction exceeds the range limit, but this will only work if you use DADD or DSUB instructions to modify PlsAct,
if you use D+/D- instruction to change PlsAct the Carry-Flag won't be set.

I would check:
- are all variables of type DoubleWord (Signed) ?
- is the FB called only once per scan ?
- check the calculation of PlsAct
 

 

 

 

 

[Simo99 0]

I solved the problem, thanks a lot

[BobLfoot 290]

4 hours ago, Simo99 said:

I solved the problem, thanks a lot

Care to elaborate so the next user doesn't have the same issue.

[Simo99 0]

In fact, the problem was nothing more than the previous one, because after changing the words from unsigned to signed (they were already this way before) the program started working again.