Input vs. Output vs. InOut vs. Static vs. Temp

[L D[AR2P#0.0]]

For the FB, STAT data is accessed using the following. I've used positive edge detection in the example blocks.

FP DIX[AR2,P#0.0]

For the FC using a UDT, the UDT is passed by reference, not value, the code in the FC must firstly access the DB pointer, then access the variable using code similar to that below:

L p#UDTName
LAR1
L W[AR1,P#0.0]
T iDBNumber
L D[AR1,P#2.0]
LAR1
OPN DB[iDB}
FP [AR1,P#0.0]

Each UDT variable has to be accessed using the above - this is why the FC will be larger than the FB.

 

[Genchan]

L D[AR2,P#0.0], thank you for your reply.
I agree "FC+UDT is larger than FB".

I have made a program "Processing UDT array". I had to open DB only once. I estimated FC vs FB in special case wrongly.

But I think FC+UDT is better than FB+Instance DB.
1. FC is re-entrant. This will reduce confusing bugs.
2. FC handles "Conplex Data Type" parameters for IN and OUT by POINTER. It reduces value copying cost.
3. UDT can be member of DB, UDT, STRUCT and ARRAY. (flexible).
4. Instance DB has type, it must be used with its FB. UDT can be used with any FC and FB, oppositely.
5. DI and AR2 can be used freely in FC. This means "Two data blocks can be opened simultaneously.". And it is useful to make block-copy function between Peripheral (PIW, PQW) and Data Block.
6. Someone may forget to set parameter to FB. Compiler doesn't check it.
Such careless mistake can not happen on FC.
7. Someone may overwrite Instance DB. L-Stack cannot be written by other logic blocks.

You may say, "These points must be considered case-by-case.". But I have selected FC in my project. I was not aware of this disadvantages, but I was lucky because the project uses fast PLC (WinAC RTX).

 

[TurpoUrpo]

7. Someone may overwrite Instance DB. L-Stack cannot be written by other logic blocks.

Im not going to other points now, but this is SO WRONG.

L stack is overwritten by other blocks and one can always use L stack in FB's too.

 

[PeterW]

L D[AR2,P#0.0], thank you for your reply.
I agree "FC+UDT is larger than FB".

I have made a program "Processing UDT array". I had to open DB only once. I estimated FC vs FB in special case wrongly.

But I think FC+UDT is better than FB+Instance DB.
1. FC is re-entrant. This will reduce confusing bugs.

Unsure what you are saying here? what does re-entrant mean.

2. FC handles "Conplex Data Type" parameters for IN and OUT by POINTER. It reduces value copying cost.

Unsure what you are saying here either?

3. UDT can be member of DB, UDT, STRUCT and ARRAY. (flexible).

UDT can be part of the STAT too, so what?

4. Instance DB has type, it must be used with its FB. UDT can be used with any FC and FB, oppositely.

No it doesn't, an Instance DB is just a DB at the end of the day, it can be accessed anywhere in the code just like any other DB.

5. DI and AR2 can be used freely in FC. This means "Two data blocks can be opened simultaneously.". And it is useful to make block-copy function between Peripheral (PIW, PQW) and Data Block.

When you call a FB your are running and processing the code in the FB, you can also open a DB, therefore you have 2 DB's open simultaneously. Not sure of your point about the Periphery area, you can copy periphery within a FB you can also move periphery into the IDB area external to the FB, something I did recently was exactly that.

6. Someone may forget to set parameter to FB. Compiler doesn't check it.
Such careless mistake can not happen on FC.

It's useful that you can not pass in a parameter, you can of course purposely leave IN parameters blank and condition the data in a totally different block if you want. If you do it as a mistake, well that would be what commissioning is for.

7. Someone may overwrite Instance DB. L-Stack cannot be written by other logic blocks.

As the programmer you are in control, if you want to write into an IDB from elsewhere, there is no problem with that. The L-Stack IS SCRATCH DATA, it is over-written in other blocks and that's the reason its used as scratch, you condition it and you use it, if you try to use it without first conditioning it this scan, you don't know what it contents are as some other block may well have used it since you last processed this block.

I'm not sure why you keep referencing L stack areas and UDT's as if these are not permissible in FB's, I use both extensively in FB's.


I must admit, when I first started programing S7's many eon's ago after using S5's for years, i too had a preference for FC's, but with a bit of experience I soon learned that both have their place and FB's are now the main preference for my programs with FC's doing the auxiliary work.

 

[Peter Nachtwey]

Unsure what you are saying here? what does re-entrant mean.

In basic terms it means that the subroutine can call itself or be used in a main code and in an interrupt. However, one still must be careful when referencing external data that is passed by reference. It is much safer to pass by value.

Unsure what you are saying here either?

This means that FC pass pointers to complex data types and not the data itself. FBs will copy a UDT variable or array to the FB. L D [AR2,#P0.0] failed to mention this. If the UDT or array is big this will take time.

Actually, whether a FC passes the data by value or by reference is not specified by the IEC specification but obviously one doesn't want to pass large data structures by value because that would take too much time.

This is one of the things that really screwed my up when I first started using S7. In C and C++ there are no FBs. One can make the equivalent in C or C++ but they are not the same. The way parameters are passed is much different between FC and FB. The Berger books do not make that clear.
The IEC specification allows the compiler writer to pass parameters either way. So much for being standard.

I think it makes sense to use FBs whenever there is a need to remember state.

The user shouldn't need to be bothered by these details.

 

[L D[AR2P#0.0]]

FBs will copy a UDT variable or array to the FB.

Concerning UDT's passed to FB's:

The FB does not do the copying, the calling block does the copying and is only done for IN and OUT parameters

IN_OUT parameters are passed by pointer the same way they are for FC's.

 

[Genchan]

This is one of the things that really screwed my up when I first started using S7. In C and C++ there are no FBs. One can make the equivalent in C or C++ but they are not the same. The way parameters are passed is much different between FC and FB. The Berger books do not make that clear.
The IEC specification allows the compiler writer to pass parameters either way. So much for being standard.

I think it makes sense to use FBs whenever there is a need to remember state.

The user shouldn't need to be bothered by these details.

Good morning.

PeterW, thank you your constructive reply.
L D[AR2,P#0.0], Thank you for your supplement.
Peter Nachtwey, you explained what I want to say. thank you!

I also make program in C++ and C++/CLI (Peter Nachtwey, you are right!). And I think it has better futures than S7. I wrote too many points, but I would like to make S7 program like C++. And I also bring general practices of C++ into S7. One of them is "Shorten the lifetime of the variables". According to this, if I can choose M, SharedDB, InstanceDB(STAT) or TEMP, I choose TEMP.
In C++ terms, I think FC is a function, and FB is a part of class.

PeterW, here is my answers (may be unsure for you, sorry.)

About No.3,4: I use Step7 V5.4. Instance DB has type of FB in symbol table, and editors(LAD and STL) checks FB and Instance DB at using CALL instruction. This is the reason "Instance DB has type".
I think Instance DB "should not" accessed except its FB. This should be "FB Private" data. But actually, they are public as PeterW pointed out. I don't prefer changing FB behavior by overwriting Instance DB from other logic blocks, it should be done by parameters to FB. I would like to apply "High Cohesion - Low Coupling" principle to make program simple.
According to this, an UDT variable in instance DB should not used by other blocks except the FB calls other blocks.

About No.5: My example is not good, I'm sorry. I made function "Any memory areas" to "Any memory areas", because BLKMOV does not support Peripheral. When its parameter is "DB" to "DB", this future of FC is useful.

About No.6: I think logic block should be handled all parameters (except S7-Graph FB), because the caller block may be irresponsible for the state of STAT variables in FB. PeterW focuses "positive" side, and I focus "negative" side of this feature.

 

[Peter Nachtwey]

I also make program in C++ and C++/CLI

I could tell by your questions/comments.

And I think it has better futures than S7.

Agreed, but the S7 instruction set and registers are not even able to address variables off the stack efficiently.

I wrote too many points, but I would like to make S7 program like C++. And I also bring general practices of C++ into S7. One of them is "Shorten the lifetime of the variables".

I understand but it is futile. I too limit the scope of variables by simply declaring variables within braces.

I think Instance DB "should not" accessed except its FB. This should be "FB Private" data.

Yes, there is no concept of accessor functions.
There is no concept of methods. However you can write 'helper' FC and call them from the FB and the AR2 will be setup already like it is a 'this' pointer.

Genchan, you have to realize that most people on this forum are not C, C++ or Java programmers. Most do not have a computer science degree to understand how compilers work and the issues involved or what you are talking about.

It is best to forget about preconceived idea of how you think an ideal language should be and learn to work within the limitations if you need to continue working with the S7. If you try to fight it you will be frustrated, believe me I know. It is too bad there is better documentation on the fine parts of S7 programming.

A lot of pain goes away if you program in SCL and ST but there are still limitations. One thing that I think is unforgivable is the lack of ability to have an array of instance FBs. I wish I could declare an array of axis instance DBs.

 

[Genchan]

Thank you Peter Nachtwey. You know what I want to do.

I made several functions and thought "S7 can be programmed like C". Furthermore, like C++. I was glad, because this is very hard on Mitsubishi-Electric PLC (Major in Japan).
I had to make "alarm object array", too. And I made "UDT collection" in a DB, and access by AR1. I also found "FBs" and "UDT composition" can be made as "virtual function" by UC instruction. I think S7 has potential, but language specification is not enough to develop it easily. Otherwise, we need not to think about such "low-level" operation.

You gave me a good advice.

 

[Peter Nachtwey]

Genchan, the Mitsubishi PLCs are not one of my favorites but the Mitsubishi PLCs do have a big advantage over other PLCs. The advanced Mitsubishi PLCs have the ability to easily access variables using the X,Y and Z index registers. You can use one of these registers as the 'this' pointer and still have two more registers for copying from place to place which is superior to what the S7 can do.

The problem with both Siemens and Mitsubishi PLCs is that structure offsets must be hard coded and this is unforgivable in the 21st century. Shame on both Siemens and Mitsubishi. They should have the resources to do better. The problem is that most people on this forum have no idea what a real development system is like and they put up with what the get and say "it is what it is".

My problem with Mitsubishi is that it takes code to drive many of their smart cards. Smart cards should be smarter.

Back in the dark ages ( 1980's ) TI had the concept of DMA. Our TI controller could work with TI505 PLCs with no code. Commands could be issued from DOS based software and the status monitored but all could be done with no PLC code. 30 years later there is no improvement. Shame on all. The PLC world is moving backward not forward. Try making a Siemens or Rockwell controller work without PLC code.

 

[dahnuguy]

One advantage of using FB+STAT over FC+IN_OUT/UDT is that the FB will be considerably smaller and thus will execute in less time.

I have been told in the past that FCs are faster than FBs in general, due to the slower access time of the instance DB over using presumably faster marker memory.

I have not been inclined to test scan times for each method yet.

Does your comparison take into consideration the time required to retrieve the data from the DB? and does the memory comparison in your image possibly omit the memory used in the instance DB of the FB?

I can see a difference in working memory being obvious, but the data has to sit somewhere regardless of method.

So the end question becomes: "Does it take less time to access marker memory or DB memory?"

The only way to really know if one is faster than the other would be to build 2 blocks that do the same thing and then make a full program with 1000 instances of each method and watch the scan time. Unless there is a high resolution method to measure scan time of individual blocks.

If I had more time I would do this, as I have always wondered which is faster.

 

[TurpoUrpo]

M is faster, im sure access times are in some siemens manuals.

 

[L D[AR2P#0.0]]

So the end question becomes: "Does it take less time to access marker memory or DB memory?"

The comparison is between FB+STAT over FC+IN_OUT/UDT and has nothing to do with marker memory - what leads you to believe this ?

See Post 16 for the reason the FC is larger and takes longer to execute.

 

[Genchan]

M is faster, im sure access times are in some siemens manuals.

Yes. It is written in "S7-300 Instruction List" and "Instruction List S7-400". But, I don't know how fast WinAC is.

 

[KalleOlsen]

... The PLC world is moving backward not forward. Try making a Siemens or Rockwell controller work without PLC code.

Okay, then my service would be redundant...
I could by a digger - digging is funnier than coding.
And I could put a codeless controller into the digger and let it dig by itself.
And my service would be redundant...