Skip to Content

Register Login

Default Header

(header konnte nicht geladen werden)

Navigation

Tag monitoring issues on FB - Tia Portal V18

Created by: AlexBrt at: 11/15/2023 3:41 PM (5 Replies)

Rating (0)

Thanks 2

6 Entries

11/15/2023 3:41 PM	Rate (0)
AlexBrt Member Joined: 11/29/2019 Last visit: 7/11/2024 Posts: 5 Rating: (0)	Hello all, I am having a strange problem with an FB on my program. I will try to make it simple When i try to monitor the code in the FB the values of some static variables are different than the values in the IDB. This happens also with temp variables. These tags are not written in other parts of the program.The FB is called only once in the program. The only workaround i could find was to select "set in IDB" or "non retentive" a very large struct data that i have in the static area. It seems that having too many tags set as "retentive" in the FB static interface generates this issue. I attach some pictures with a few lines of code as an example of the problem i am facing. I am currently using Tia V18 upd3, the cpu model is CPU 1516F-3 PN/DP,6ES7 516-3FP03-0AB0, firmware 3.0. Best regards Attachment Bug monitoring.zip (358 Downloads)

Suggestion To thank Quote Answer

11/15/2023 8:54 PM	Rate (0)
Gustavo Antonio B... Silver Member Joined: 6/20/2017 Last visit: 10/6/2025 Posts: 486 Rating: (41)	Similar problem appens to me when for some reasons in the same FB I write a code that some times access to the data from an in/out structure and some times directly to the DB. When the FB it's closing and returning to the calling pointer, the in/out data are updated and the values writed with direct access, are lost. Impossible to say something more only the three pictures If you don't found the problem, try to post all the interesting parts of the project.
	Last edited by: Gustavo Banchetti at: 11/15/2023 20:54:54 Gustavo Antonio Banchetti Brucatori.
Suggestion To thank Quote Answer
This contribution was helpful to 1 thankful Users AlexBrt

11/16/2023 8:53 AM	Rate (0)
AlexBrt Member Joined: 11/29/2019 Last visit: 7/11/2024 Posts: 5 Rating: (0)	In this FB I don't access any data directly. Everything is passed through the in/out interface. I have other FBs similar to this one. The only difference is that this one has a data type with a large amount of tags declared as "Retentive". Indeed one of the things that I did was to delete this area and the monitoring started to work fine again. After that i just tried to declare it as "Non retentive" and "Set in IDB". In both cases the monitoring worked fine. I came to the conclusion that maybe having too many tags declared as retentive in the FB static interface is not a good thing. I don't know if there is any limit. I hope someone can give me more information regarding this. One thing i didn't mention is that the code is written both in KOP and SCL. Unfortunately there aren't any other interesting parts i could show you, the behaviour that you can see in the pictures just repeats for other parts of the code, also for SCL part. The status of the tags and the results of the instructions are not the real ones and so it becames hard to debug. Best regards

Suggestion To thank Quote Answer

11/16/2023 11:01 AM	Rate (0)
sancruz Gold Expert Joined: 3/11/2019 Last visit: 12/9/2025 Posts: 1653 Rating: (322)	Hi, I haven't checked this in detail yet, but as i can see that the terms "In/Out" are mentioned and structural datatypes are used, this may have something to do with call by value or call by reference access. There is a difference in handling of elementary and structural data types, furthermore the behaviour depends/is different according the used access type (standard access/optimized access or combination of both). Furthermore in one of the screenshots the datatype is called "HMI". If there is a HMI involved, please not that this HMI writes values randomly (not at an defined point/time in OB1 cycle) So it is not impossible that there are differences in monitoring. regards sancruz
	Feedback appreciated, please rate
Suggestion To thank Quote Answer

11/21/2023 8:28 AM	Rate (0)
AlexBrt Member Joined: 11/29/2019 Last visit: 7/11/2024 Posts: 5 Rating: (0)	sancruz Hi, I haven't checked this in detail yet, but as i can see that the terms "In/Out" are mentioned and structural datatypes are used, this may have something to do with call by value or call by reference access. There is a difference in handling of elementary and structural data types, furthermore the behaviour depends/is different according the used access type (standard access/optimized access or combination of both). Furthermore in one of the screenshots the datatype is called "HMI". If there is a HMI involved, please not that this HMI writes values randomly (not at an defined point/time in OB1 cycle) So it is not impossible that there are differences in monitoring. regards sancruz Hi sancruz, thank you for your answer. The used access type is only optimized access for this project. Is true that there is an HMI involved, but some of the tags which i highlighted are not written or read by the HMI. Furthermore i have the same problem even with the HMI disconnected from the machine. I can assure that there is no software design error in this way. I made sure to check every possible "human" error. I must repeat that the only way to make the monitoring work again was to change from "retentive" to "non retentinve" or "set in IDB" a large struct data in the static interface area of the FB. Also before changing this option i also tried to reduce little by little the amount of data in this area (by reducing the lenght of some arrays) and i saw that the problem disapeared as i reached a certain point and then showed up again when i added the data again.

Suggestion To thank Quote Answer

11/21/2023 11:24 AM	Rate (0)
sancruz Gold Expert Joined: 3/11/2019 Last visit: 12/9/2025 Posts: 1653 Rating: (322)	Hi, as everything is checked and the behaviour can be reproduced i recommend to report this topic via an offical support request. regards sancruz
	Feedback appreciated, please rate
Suggestion To thank Quote Answer
This contribution was helpful to 1 thankful Users AlexBrt

|

Share this page:

Share this page on...

Follow us on