siemens sismatic manager STL mode

Hey guys, i'm studying my colleague's programming...
im wondering how he can do this type of STL writings?

The first picture is my colleague's work, there are a few Functions block inside, where FB42 CONT_S is the PID function called from the standard library, then, FB42 was put inside another FB11 where it contains the processes for the whole PID processes. FB65 calls FB11 and links the DB from PIW and IW. There is an instance DB65 for the FB65.

from my works, i managed to create until FB11 where everything looks same. but at FB65, where it needs to 'linked' with the PIW and IW, there is some addressing issue where i cannot link the inputs and outputs of the PID Process to my peripherals and internal addresses.

please refer to the pictures embedded below.

this picture is my colleague's work


This picture is my work.


BTW, my colleague is overseas now handling other job.
So, i temporary unable to contact him until he is back..


So, which should i make first? since the DB65 is the instance block for FB65, is the addresses should be made inside FB65?
Please Advice... Thanks alot!!

Create a library, copy the blocks to the library and post the archived zip see we can see all of your program.

hi there, this is the archive of the blocks..
please take a look inside

https://www.dropbox.com/s/w36w47g0agtdgmz/Troubl_1.zip

You need to post your colleague's version as well.

Hi, this is my colleague's version..

https://www.dropbox.com/s/kawp51oca9zxkyo/Troubl_2.zip

Neither of these projects make any sense. There is no reference to any IW or PIW. All the calls to the mutliple instance FB's are passing their own parameters back to themselves, in your version you are using the STAT variable name, in your colleagues version, he is using the symbolic name from the instance DB - they are both the same thing.

Is any of this code being used in a working system?

yes.. both FB and FC will be called into OB1 to operate. the IW and PIW is mapped on the another Series of FC/FB block to convert the PIWs into local data where it will be represented with their names. and there parameters will be passed on the PID to do processing.

I'm basing this purely on the pictures, as I have not downloaded the projects. However, I have seen numerous projects where the inputs and outputs of an FB just link to the instance, which allows you to monitor all the parameters. In those cases, they either wrote to the inputs in another section of code, or do it all internal to the block somehow.

Its a practice that makes sense for outputs sometimes, but it seems like it would be very confusing for inputs.

hi mk42, it would be confusing at the first glance on it, after going on study on this method. It appears that the proper way of making it was create your FB eg. FB41 then call the FB41 block with another FB1 created by u in STL format. Then by adding parameters u wanted to control by FB41 in to the interfaces tab, under stats. you can create items to be controlled by FB41 as many as u needed. Then u can generate the instance DB for this FB1 to obtain the addresses for your internal parameter that u can use for your scada/hmi.

i found this was hard to do on the first time, after few times of trying. It seems more convenient than doing it on a normal way before i know this method..

Thanks alot guys for your feedback, Hope to hear from you guys soon

A word of caution about your approach of having multiple instances of FB41 inside another FB.

Whilst this is a legitimate method there are things to be aware of specifically for FB41. FB41 stores all its gain settings etc. in the instance DB (you can explicitly attach them to another memory location). If the instance DB is regenerated for any reason then all of the gains etc. will be rest to default values. So any change to the interface or static data of the calling block will result in a regeneration of the instance DB.

For this reason, you might be better off using individual instance DBs for FB41.

Nick

Nick

Nick,

every instance inside calling FB will have direct address linked to each PID set point directly inputted from the HMI. so it won't be reset to default values.

for another scenario, let say if the hmi connection between the PID set point is broken or disconnected accidentally in a live running system, will it all of the PID set points?

Alan

The system will continue to run with the HMI disconnected no problem.

So setpoints will come from the HMI but they still get reset to default values if the iDB is regenerated and would need to be re-enterred on the HMI unless they go via another memory location. In addition, if the instance DB is re-created all of the gains will be reset to default values.

Nick

Nick has a really good point. I've seen projects really struggle because of exactly this, they had to add another instance of a block, and then had to re-enter their setpoints on all the others.

You might want to investigate recipes on your HMI, if you aren't already using them. It is a way to store save specific information (usually setpoints and other process data) for use later. You can store multiple sets of data, for producing multiple products. Then, when the operator needs to, he can go select from a drop down list what product is being made, and all the appropriate setpoints get sent to the PLC.

yeah, by using my method that require some iDB handling skills where we wont override the current set points, \

But the method u guys mentioned is by moving the set point from 1 location first, then using a program to constantly sending the data to the PLC?? Am i getting the correct idea?

Alan

my advice is to have a separate instance DB for each call to FB41.

As a general rule of thumb you should avoid external access to instance DBs. Even if you use symbol priority you will still need a recompile following any change to the iDB to put things right. Anything that uses an absolute address, such as an HMI, might also need to be reprogrammed.

Nick