Hello Everyone,

I just lost a lot of time on a strange problem and now it seems magically resolved, which is not a good thing!   So I'm hoping somebody can help me understand what happens so when it happens again in a more critical situation I know what I did wrong and can rectify much quicker.

I have an SCL generated FC that does some straightforward math (couple polynomials, absolute value, etc, nothing special).  2 real inputs, 4 real outputs.  2 of the 4 real outputs are not needed right now so I have them assigned to the same dummy real temp variable.

I wrote and tested the block with no issues, and now have come back around and doing a double check before some integration testing and lo-and-behold, it isn't working correctly!  One of the results is correct, but the other is definitely wrong.  But it is wrong in a way I can see, on of the variables "Exc1OverlapAct" somehow is getting the value of "Exc2Overlapact"!.  I must have checked the  code 30 times, I thought I was losing my mind, but there was, with absolute certainty, no errors.  So I went online with the SCL and for some reason wouldn't show the value of the variable I knew was incorrect! (See Photo).

So the next day (I gave up and went home) I decided there must be some issue with corruption in the generated STL from the SCL even though  i recompiled and downloaded several times.  I created a whole new source file and new FC # and started from scratch.   Then I ran into a new issue; every representation of the FC showed a different value for my Exc1Angle input!  If I looked at FB calling it in FBD, it showed an input of '3.64882e+22', in STL it showed once the correct value and another the value of the variable below, Exc2Angle.  And looking directly online with the SCL source file I saw the correct value.  Even more confusing, the function was being evaluated with the incorrect value, the one from the FBD image.

So fast-foward a little more.  I figured out my inital problem was I used the same dummy temp variable for the two outputs.  This was causing only one value assignment to the two internal variables of the FC.  I guess this shows a misunderstanding on my part, I thought the processor worked with the variables internally and then wrote them at the end of execution but it must actually use the output variables as holding registers as well.  But the problem of incorrect input values wasn't fixed until I "checked and updated block consistency" for the FB.  Then the function finally worked correctly, but variable representation is still incorrect in FBD for the first variable.

Has anyone expierenced these issues before?  It was pretty bizarre, and I'm not 100% confident in my solutions, but so far I think the two items below are my lessons learned:

1) When using FC's, make sure each output variable is unique because if it's used internally it will create issues -->  Is this really the case?  I've recreated the problem with this, if both outputs are "#TempReal" variable, the two internal variables to the SCL that are assigned to them hold the same value.

2) After modifying a FC, FC/FB's calling it should be updated.  --> I thought this was only necessary to incorporate changes in the symbol table that occurred with the block open?

Nate@SMS

1) When using FC's, make sure each output variable is unique because if it's used internally it will create issues -->  Is this really the case?  I've recreated the problem with this, if both outputs are "#TempReal" variable, the two internal variables to the SCL that are assigned to them hold the same value.

2) After modifying a FC, FC/FB's calling it should be updated.  --> I thought this was only necessary to incorporate changes in the symbol table that occurred with the block open?

Nate,

I took only a brief view of your case, so I will not comment the case itself, but the conclusions:

1) You should never use output variables of FC for internal calculations (read them). Inside FC, your inputs should only be read, and outputs only be written. The reason for this is not so simple, and is related to how FC parameters are actually handled internally. If you want to know more about this matter I would certainly suggest chapter 26 of Hans Berger book about STL/SCL;

2) You should update block calls only when you change block interface. This relates both to FB and FC. You can do it manually or using Check Block Consistency which will recognise all outdated block calls. If you change only code then no update is necessary whatsoever.

Hope this helps.

Regards.

Interesting, I was unaware that an output variable should not be used for internal processing in an FC.  I can see why, it clearly had some unpredictable behavior in my application.  I'll change it to use some temp variables in the FC and write all my outputs at the end.

But one question still remains, why was I seeing a different value for the first input value depending on how I was viewing the FC? (STL vs FBD vs SCL)  is this just a bugin the Step 7 software when online? 

Nate@SMS

Interesting, I was unaware that an output variable should not be used for internal processing in an FC.  I can see why, it clearly had some unpredictable behavior in my application.  I'll change it to use some temp variables in the FC and write all my outputs at the end.

But one question still remains, why was I seeing a different value for the first input value depending on how I was viewing the FC? (STL vs FBD vs SCL)  is this just a bugin the Step 7 software when online? 

Nate,

when FC processes it's vaiables, output are written at the block end, so using output value is actually using some udefined value inherited from the V stack. It's always safer to use internal variables for internal manipulation.

Regarding your other quetion, sometimes you have to right click online editor and explicitely state which representation you want to use (binary, floating point, decimal, hex...). If you want to make sure you can always move your vaiable to some arbitrary M area and monitor in VAT.

Hope this helps.

Regards.

Actually, I thought it would write the variable at the block end but it did the exact opposite.  It was following this behavior:

Let's say I have an FC where OutputVar0, OutputVar1 and OutputVar2 are outputs.  In an FB calling it OutPutVar1 and OutputVar2 are both being assigned to DummyVar.  Theyr'e all Real type.

OutputVar1:= 100;

OutputVar2:= 200;

OutputVar0:= OutputVar1 + OutputVar2;

The result was 400, not 300.  The only way I can explain this is after OutputVar2 is evaluated, it is written to DummyVar, and then in the final instruction it recalls the value of DummyVar for both of the variables.

Also, the problem was not with represenation, I toggled between Floating Point and Hexidecimal.  It was pretty strange, I banged my head on the desk for a while.

Nate@SMS

Let's say I have an FC where OutputVar0, OutputVar1 and OutputVar2 are outputs.  In an FB calling it OutPutVar1 and OutputVar2 are both being assigned to DummyVar.  Theyr'e all Real type.

OutputVar1:= 100;

OutputVar2:= 200;

OutputVar0:= OutputVar1 + OutputVar2;

The result was 400, not 300.  The only way I can explain this is after OutputVar2 is evaluated, it is written to DummyVar, and then in the final instruction it recalls the value of DummyVar for both of the variables.

Nate,

the thing is that, when summing up OutputVar1 and OutputVar2 and calculating OutputVar0, you actually do not know what you're summing up. It's simply unpredictable: you will load indeterminate value from the V area, regardless if it's 300, 400 or any other value.

Regarding variable representation, it indeed looks strange. Maybe a little more help can be provided if you upload your project.

Hope this helps.

Regards.