S7 Function Block Question

[snydl0ga]

I am using a function block to do repetative math calculations. I noticed that the results were coming back incorrect. After playing with the Function, I tracked it down to a constant that I was setting. Is there a special way to set constants in FB's?

I am taking a Real number and sending it to the Function where I divide it by 100000.0 and do other math on it. I noticed in monitor mode the constant actually had a large random looking number in it.

To troubleshoot it, I Replaced the constant with an address to one of my DB's (shared).

I noticed also in a different FB that it did not work and it seems the internal temp registers do not transfer to the next network. Is there a trick to that too?

Lance

[S7Guy]

The internal registers will transfer to the next network, so you must be doing something that affects the value. Can you post a snippet of the code? Even of you switch to STL and cut/paste the code as text, that would be fine.

There is no special way to set a constant in a function. You can even set it literally without using a variable. Or, you can use any of the other data types (even local data, as long as you initialize it).

[jvdcande]

I noticed in monitor mode the constant actually had a large random looking number in it.

This indicates you're not really using a constant, but a constant stored in a variable. Constants are what their name indicates: constant. I have never seen a real constant change value in S7 in whatever situation. Are you maybe storing the constant in a variable first? As S7Guy already indicated: a snippet of the code you're using would clarify a lot.

I noticed also in a different FB that it did not work and it seems the internal temp registers do not transfer to the next network. Is there a trick to that too?

Temp variables are temporary, meaning if you leave the block these variables are lost. If you want to retain internal variables in a FB you have to make them static variables (STAT).

Kind regards,

[snydl0ga]

Here is the STL code for the FB that is not working properly.

"Real to Int High/Low"

This FB receives a Real number and breaks it down to High and Low order Integers.

Example: 123456 Real would become 12 High 3456 Low.

When I use the 10000.0 as a constant it does not work but if I point these two locations to
a DBlock with the 10000.0 value in it, it works.

O(
L #Real_IN
L 1.000000e+004
/R
T #Real_1
AN OV
SAVE
CLR
A BR
)
O(
L #Real_1
TRUNC
T #Dint_1
AN OV
SAVE
CLR
A BR
)
O(
L #Dint_1
DTR
T #Real_2
SET
SAVE
CLR
A BR
)
O(
L #Real_2
L 1.000000e+004
*R
T #Real_upper
AN OV
SAVE
CLR
A BR
)
O(
L #Real_IN
L #Real_upper
-R
T #Real_3
AN OV
SAVE
CLR
A BR
)
O(
L #Dint_1
T #INT_High
SET
SAVE
CLR
A BR
)
O(
L #Real_3
T #INT_Low
SET
SAVE
CLR
A BR
)
= #Dummy

[snydl0ga]

here is the LAD shot. Nope File too large. If you need, I will email it.

[SimonGoldsworthy]

There is a coding error in your processing, the last "move" loads a floating point number and moves it to an integer, this will produce what appears to be a random number in the result. You need to use ROUND to convert the floating point to a double integer, and then move the double integer to the integer.

When testing a function block like this, I always call it once but use flag words for the inputs and outputs. I put test data in the flag words using a VAT table and then monitor the output to verify the block is operating correctly before calling it more than once.
Be sure that the data you feed the block will not cause you problems later, for example what if you fed 3.4e+038 as the input ?

[snydl0ga]

Simon, Thanks for the explanation. I wrote this originally in ladder and was under the impression that the MOVE statement allowed any type to any type. Should that not work. That is why I had it there. I will test further though. I am still getting familiar with S7 and have a lot to learn.

Lance

[S7Guy]

Lance, one thing you may consider when doing math like this is STL representation. It is much faster and easier to troubleshoot because you can follow the math in the accumulators as it is being processed. For instance, in ladder you needed about 65 statements, but in STL it only needs 13 to do the same thing (I think this will work, but I didn’t try it. Still, the concept stands.):

	 L	 #Real_IN
	 L	 1.000000e+004
	 /R	
	 TRUNC 
	 T	 #Int_High
	 DTR 
	 L	 1.000000e+004
	 *R	
	 L	 #Real_IN
	 TAK 
	 -R	
	 TRUNC 
	 T	 #Int_Low

STL is also much more tolerant when using mixed data types, so a lot of the conversions can be eliminated. You just need to think in terms of the accumulators.


Also, like Simon says, you need to put in some range checking, unless you are clamping the input values to make sure you can never get an out of range number.

[snydl0ga]

Gotcha....I have been doing some STL and plan on getting better at it. I have begun to see the advantages.

Thanks for da help!

Lance