How to monitor #TEMPS of a FC on Siemens S7?

Not sure what you are trying to achieve, but you do realise that LW0 and the bool TEMP1 are overlapping ?

One should NEVER use the local "L" addresses such as L0.0 or LW0.
If you see an L address, it is a sign of bad programming habits, or that the block has become messed up.
 
Not sure what you are trying to achieve, but you do realise that LW0 and the bool TEMP1 are overlapping ?

One should NEVER use the local "L" addresses such as L0.0 or LW0.
If you see an L address, it is a sign of bad programming habits, or that the block has become messed up.

Couldn't agree more!
 
rachid29,

Maybe this is a stupid question, but why are you trying to do this?

If you want to monitor the code, can't you just go online and monitor the logic directly?

If you want the internal memory of the FC to be remembered from scan to scan, why not just use an FB?

It feels like you're trying to solve a problem that doesn't exist.

Not sure what you are trying to achieve, but you do realise that LW0 and the bool TEMP1 are overlapping ?

One should NEVER use the local "L" addresses such as L0.0 or LW0.
If you see an L address, it is a sign of bad programming habits, or that the block has become messed up.

I agree that normally this is something that wouldn't be done. However, I think OP is trying to do something crazy, and so is intentionally doing crazy things to make it happen.

Thank you for your reply.

The MW20 has to change when the I2.0 and I2.1 are HIGH, but my MW20 stays at 0.

I THINK he is intentionally trying to copy out the internal TEMP memory of the FC so that he can monitor it elsewhere in the program, or at least so it can get reused from scan to scan.
 
rachid29,

Maybe this is a stupid question, but why are you trying to do this?

I THINK he is intentionally trying to copy out the internal TEMP memory of the FC so that he can monitor it elsewhere in the program, or at least so it can get reused from scan to scan.

Thank you all for your replys,

Like I mentioned before, I want to understand how to work with FUNCTIONS.

An FB is a function that "remembers", or "keeps score" of its last operations.
Both FCs and FBs can hold parameters (IN, OUT, IN-OUT and TEMP), it allows the re-use of the blocks with different calling environments. But FBs have an extra type of parameter: STATIC not available in FCs.
When you call an FB, you are required to generate an instance DB (IDB) that accompanies this particular call of an FB; this DB contains all the STATIC parameters of the FB, and these are available at any time by any other block in your program. You could do this with an FC, a general DB and MOVE instructions that would write results of the FC program in that DB. With an FB it is automatic.

Instead a DB, I used a MW.
 
You could do this with an FC, a general DB and MOVE instructions that would write results of the FC program in that DB.
No. If you code a move inside an FC, and you use the FC several times, the move will use the same address. This is probably not what you want.

The proper way to have memory with an FC is to use IN_OUT pins, and be sure to place unique addresses on these pins for the different calls to the FC.

It is actually quite simple. Dont make it so complicated. Avoid the legacy variables such as Merkers inside FCs and FBs. If you need memory, in FCs use the IN_OUTs, in FBs use the STATs.
 
Like I mentioned before, I want to understand how to work with FUNCTIONS.
Say you need to convert Celsius to Fahrenheit. Does it need to "keep score"? No, it doesn't... so you'll go with a function.

Say that you have a block that creates a runtime meter... it gets the running input, the running hours alarm limit and outputs the alarm and the number of running hours. This block will need a timer of sorts, and will need to "keep score" of the running hours. Additionally, this block will be called as many times as motors (for example) as you have in the plant... In this case, you'd use an FB.

A way of achieving a similar result with an FC, is to have IN_OUT parameters. In Out parameters are addresses to variables, so the FC will be touching the contents of a global DB.

Instead a DB, I used a MW.

Never use M memory for writing to it, which means only the Memory bits selected in the Hardware config should be used.
 
An FB is a function that "remembers", or "keeps score" of its last operations.
Both FCs and FBs can hold parameters (IN, OUT, IN-OUT and TEMP), it allows the re-use of the blocks with different calling environments. But FBs have an extra type of parameter: STATIC not available in FCs.
When you call an FB, you are required to generate an instance DB (IDB) that accompanies this particular call of an FB; this DB contains all the STATIC parameters of the FB, and these are available at any time by any other block in your program. You could do this with an FC, a general DB and MOVE instructions that would write results of the FC program in that DB. With an FB it is automatic.

Instead a DB, I used a MW.


Seems to be lacking some information/understanding here.

What is a FB?

A FB is a block which can have a instance DB connected to it. When you create IN/OUT/IN_OUT/STAT variables, then that FB will require an instance DB to work. This instance DB will be generated automatically when you call the FB. Your editor will ask you whether it should create it or not in most cases.

NOTE: a FB without IN/OUT/IN_OUT/STAT variables does not need a DB and one will NOT be created for it.

The IN/OUT/IN_OUT data you supply to the FB will be copied to the instance DB. This is why you can leave these parameters empty. Because zero is a valid value.

In your case if you use MW10 as an IN_OUT parameter with a FB, the data from MW10 will be copied to the instance DB at the start of the block. And then copied from the instance DB to MW10 at the end of the block.

TEMP data, or L-data is NOT stored in the DB. This is a data block shared among all other blocks.


What is a FC?

A FC is a block that contains logic. It has no DB linked to it. When you call it no DB will be created.

So what about the IN/OUT/IN_OUT parameters? Well when you use these parameters with a FC, they are created as pointers. If you use MW10 as an IN_OUT then the FC will use #INOUT1 as a pointer directly to MW10 and will read/write directly to MW10 when #INOUT1 is referenced in the code. And this is the reason why FC's must have all their parameters filled in at all times. Because a null-pointer is not accepted.

Because there is no DB linked to a FC it doesn't have any STAT variables.


So how does one achieve FB functionality with a FC?

Manually. You have to manually create a DB with the correct data structure. You'll have to write the code to copy the data to/from the DB.

Code:
OPN DB[#IN1]   // This opens DBxx, where xx is the value of #IN1
L #IN2         // Loads the value of #IN2
T DBW0         // Transfers it to DBxx.DBW0 where xx is the value of #IN1

... some more code ...

OPN DB[#IN1]   // Opens DBxx again in case you've referenced another DB somewhere else in the code
L DBW2         // Loads value of DBxx.DBW2
T #OUT1        // Transfers it to #OUT1 parameter
The code calling this FC might look like:

Code:
CALL FC1
 IN1   := 20   // Opens DB20 within the FC
 IN2   := MW10 
 OUT1  := MW20
In this case MW10 = DB20.DBW0 and MW20 = DB20.DBW2

Achieving the same while using a FB would look like:

Code:
CALL FB1, DB20
 IN1   := MW10
 OUT1  := MW20

Done. No additional coding required within the FB.
 
jeebs, you are confusing the guy with using STL code for opening of DBs and manipulating DB words in an FC to mimic an FB.
Stuff like that should be avoided. Keep it simple is my mantra.
 
Should not ignore/dismiss information just because you dislike it. What is shown is exactly what his source is referring to.
 
What is shown is exactly what his source is referring to.
I think your code is a correct reply to Rachids suggestion.
But I also think that your code is a bad style !
Essentially, opening DBs and accessing variables by byte offset only, means you have zero symbolics and no type checking. This is a big no-no in my book.

If one absolutely must try to make an FC have memory like an FB, then link to the desired variables via IN_OUT pins. If you have a big structure that would be too much to place on IN_OUT pins, then define the entire structure as a UDT and then make only 1 IN_OUT pin for the entire structure. You get all the structure symbolically. In fact, this is a simple and important method that everybody should learn.

If I posted a suggestion like your code, I would add an advice that even if it is possible to do it like that, one should avoid it.
 
If you want to monitor the temp data of an FC (or FB for that matter) copy the temp data to a DB and monitor the DB. Example attached. The size of the local data is available from the block properties.
 
Not sure what you are trying to achieve, but you do realise that LW0 and the bool TEMP1 are overlapping ?

One should NEVER use the local "L" addresses such as L0.0 or LW0.
If you see an L address, it is a sign of bad programming habits, or that the block has become messed up.




I would say, use overlapping memory only if you really know what you are doing, regardless of PLC type.

From internet you can find top ten siemens tricks, #6 shows overlapping local memory to pare data.



Better would be to use pointer to memory area on STL or AT commands on SCL.

I think that TIA portal shows at least warning if you use overlapping local memory areas.



https://www.slideshare.net/DMCChicago/dmc-siemens-summit-2011-top-ten-s7-tips-and-tricksslide-share
 
For a function you would like to use multi times, in this case you could create FC/FB.
In a old programming style, people use FC+FGDB, this is good if you are often modify the structure of DB, this will not cause any interface change conflict, but you have to make sure in FC you are still read and write to the correct position in the FGDB. Later people use more FB+IDB, this is good especially when you have a clear structure, so that you could use pointer like P#xxx, it's more easy and clear when you write a STL code.
For your case, you could use a MW for retain value, but you should only call you FC once, otherwise other calling of same FC will modify the M value. By the next PLC cycle, M will not be the expect value anymore.
Another issue for TEMP, any TEMP variable you read, should be initialize(Write) before, otherwise it could be also a unexpected value.
 

Similar Topics

We have a quad monitor setup with FT SE and we are utilizing a header screen at the top of every display. when we open a new page we abort the...
Replies
0
Views
77
Our plant manger/my boss wants each line to display the takt time above the line. I am trying to research the cheapest way to do this. Our plant...
Replies
3
Views
166
Hi Folks, Looking for support and ideas. We are trying to go online to monitor/fault find on an S7-300 programmed with TIA Portal V15. I can...
Replies
9
Views
304
We finally replaced our Cognex Checker with an IV-3 and I'm wondering if can replace the s/w in the monitor with anything else. I haven't been...
Replies
0
Views
77
Im very new to programmin,but i was wanting to try and set up a program that could monitor the speed of a roller. Would it be possible to use the...
Replies
4
Views
117
Back
Top Bottom