Skip to Content

Register Login

Industry Online Support

Technical Forum

Navigation

V13 SCL Function Block Compile changes

Created by: Scott at: 3/7/2014 8:55 PM (28 Replies)

Rating (1)

Thanks 3

Result pages:: |; 1 | 2 | 3; |

29 Entries

Entries per page: 10 | 20 | all

3/7/2014 8:55 PM	Rate (0)
Scott Bronze Member Joined: 10/23/2005 Last visit: 3/31/2020 Posts: 81 Rating: (9)	Loaded the new TIA Portial V13. Loaded program from V12sp1 and compiled al. Why do I get all of these errors in the new version? The Parameter '<name >' might not be initialized A function Block has data associated with it so read the data and remember it. It I wanted a function call then I would have made it a function call. I don't want to have to make everything and INOUT or a STAT variable. This make the Function Block useless. So tell me why the change?

Suggestion To thank Quote Answer

3/10/2014 10:43 AM	Rate (0)
Denilson Pegaia Platinum Expert Joined: 9/23/2005 Last visit: 1/17/2025 Posts: 4394 Rating: (1463)	Hi, I suppouse that you open a V12 program in a V13 software and then get some errors by compiling. Am I right? Did you just open the project or updated it to V13? You told that a message "The Parameter '<name >' might not be initialized" comes. When? It is associated to wich context? What you should do that you can't?
	Denilson Pegaia Siemens Industry Sector Technical Support
Suggestion To thank Quote Answer

3/10/2014 2:37 PM	Rate (0)
Scott Bronze Member Joined: 10/23/2005 Last visit: 3/31/2020 Posts: 81 Rating: (9)	Sorry I wasn't very clear on my post. My concern is "not really an issue" from V12 TIA Pro to V13 TIA Pro Siemens changed the SCL compiler to give a warning on the Function Block code. I.E. Alm is an output tag. Alm := (Value > Setpoint) or (Alm and Value > Setpoint- DB); In a simple latch circut, In version 12 and any Step 7 this compiled fine with no warnings. Now in Version 13 it gives you the warning. I would truely not want to change this to an IN/OUT or creat another tag in STAT to hold this value. I can see that this is a problem in a function Call because it has no data associated with it. But a Function Block has data it should get from the data Block when it is called. The code still works but it bothers me to have the warning. I guess I am wonder why they changed or added this warning to the compiler? Thanks, Pegaia

Suggestion To thank Quote Answer

9/17/2014 4:06 PM	Rate (0)
Marko Bursic Platinum Member Joined: 9/8/2009 Last visit: 7/17/2023 Posts: 1410 Rating: (153)	Scott I can see that this is a problem in a function Call because it has no data associated with it. But a Function Block has data it should get from the data Block when it is called. The code still works but it bothers me to have the warning. Ok, perhaps it has right to warn you. If you use temporary variables, you need to define it prior using its value. It should not warn you if you are using global datablock variableor STAT variable of a function block. Now it's not tottaly clear what kind of variable you are accessing.

Suggestion To thank Quote Answer

10/1/2014 11:15 AM	Rate (0)
bosandzeros Bronze Member Joined: 7/1/2013 Last visit: 12/16/2024 Posts: 85 Rating: (4)	I would like to support Scott. :) If I understood Scott correctly, we have the same "problem". Help says, among other: "You are using a tag that is declared as "Temp" or "Output". However, the program is structured in such a way that the tag may not be written under certain circumstances. Note that the tag may then have an undefined value. " So if it is possible, in any way, that program comes firstly to point where "output" or "temp" tag value is used before its is assigned some value we get this warning, because "Default value" in tag declaration does not apply to "temp" or "output" tags. For my programming pattern this is lack, but since there is nobody who complains we are going to use available workarounds. It is not solution to define tag as "inout" because it is output only (at least in my head), and appears at "wrong side" of block if block is called in FBD routine. :) In FBD or LAD language it is even impossible to use "output" tag inside block (without (meaningless) absolute addressing), if I'm not mistaken.

Suggestion To thank Quote Answer

10/1/2014 3:29 PM	Rate (0)
0_Einstein Diamond Expert Joined: 7/7/2010 Last visit: 1/17/2025 Posts: 15541 Rating: (2465)	bosandzeros I would like to support Scott. :) If I understood Scott correctly, we have the same "problem". Help says, among other: "You are using a tag that is declared as "Temp" or "Output". However, the program is structured in such a way that the tag may not be written under certain circumstances. Note that the tag may then have an undefined value. " So if it is possible, in any way, that program comes firstly to point where "output" or "temp" tag value is used before its is assigned some value we get this warning, because "Default value" in tag declaration does not apply to "temp" or "output" tags. For my programming pattern this is lack, but since there is nobody who complains we are going to use available workarounds. It is not solution to define tag as "inout" because it is output only (at least in my head), and appears at "wrong side" of block if block is called in FBD routine. :) In FBD or LAD language it is even impossible to use "output" tag inside block (without (meaningless) absolute addressing), if I'm not mistaken. I understand and appreciate this and the prior posts in this thread. I too find it annoying to be warned that I am using an interface defined internal tag in any way other than what I said I would use it. I do not like warnings, so have been adding Temp tags for anything that would otherwise cause a warning. If my output tag is MyTag, my internal use would be to instead turn on tMyTag (the temp tag). The last thing in the FB would be to put the value of tMyTag to MyTag. This way there is no warning. However, I would like to have the compiler nudge me right as I edit it, and then give me the intentional choice to IGNORE it before compiling it. Think of spell check in Word. If you type something, Word underlines in red squiggles (default action for me), but you can choose to IGNORE that detected problem and the red squiggles go away forever. In this way, we can use the coil bits naturally without concern for warnings later. Perhaps this causes more code to be inserted into the FB to handle it being used as an INPUT and an OUTPUT and this is the only way that Siemens alerts us our code will run slightly slower. Strange way to handle it but effective if that is indeed the reason for the warning. I have to wonder how many times Siemens Support gets projects with improper use of an output that caused project problems that came from this situation so they added a warning.
	science guy
Suggestion To thank Quote Answer

10/2/2014 7:46 PM	Rate (0)
Marko Bursic Platinum Member Joined: 9/8/2009 Last visit: 7/17/2023 Posts: 1410 Rating: (153)	If warning ragards using a temp variable before it is defined, then it is asmart warning, indeed.
	Last edited by: Marko Bursic at: 10/2/2014 7:46 PM
Suggestion To thank Quote Answer
This contribution was helpful to 1 thankful Users 0_Einstein

10/3/2014 7:58 AM	Rate (0)
bosandzeros Bronze Member Joined: 7/1/2013 Last visit: 12/16/2024 Posts: 85 Rating: (4)	It is not warning regarding defining, it is warning about it's usage, if you are not give it some value explicitly before using it. It would be better if temp variables are automatically initialized to its "Default value" given in its definition. But I suppose that it has something to do with memory management. If you don't define variable it is error.

Suggestion To thank Quote Answer

10/3/2014 8:45 AM	Rate (0)
Michael K Gold Member Joined: 9/3/2008 Last visit: 1/18/2025 Posts: 932 Rating: (163)	Scott, As bosandzerossays, the warning is not about undefined variables; it is about the reading variable values that has not been written to yet. If you look at the statement you posted earlier: Alm := (Value > Setpoint) or (Alm and Value > Setpoint - DB); Here you are writing to "Alm". But in the expression you are first reading "Alm": (Alm and Value > Setpoint - DB) This is where the warning comes from. In my opinion, the lack of the same warning from earlier compilers is the error.
	Michael
Suggestion To thank Quote Answer

10/3/2014 10:11 AM	Rate (0)
Marko Bursic Platinum Member Joined: 9/8/2009 Last visit: 7/17/2023 Posts: 1410 Rating: (153)	Temp varaible has no default value. When the FBx is called, an amount of memory is resereved for temp variables, after exit from the FBx these variables are purged - not realy cleared, they are only left unused. When you call FBy after FBx you'll get those variables back in the temp area (messed up), therefore you will need to write something (a temporary result) before reading the same variable.

Suggestion To thank Quote Answer

|

Share this page:

Share this page on...

Follow us on