TiA v16 - Struct in constant declaration

Hi everybody,

does anybody know if it is possible to organize Constants in Struct inside the declaration table of an FB?

Thank you

Hallo BoletusEdulis,

you define the local user constants in the block interface of an FC/FB under "Constant" and you can then use them in the block program. Here you must define a data type for the use constants.

See the FAQ:
How do you define the constants in an S7-SCL program in STEP 7 (TIA Portal)?
https://support.industry.siemens.com/cs/ww/en/view/52258437

Ave Cicero,

thank you.

I have to conclude that there is no posibility to define a Struct of Constants

Helpful?

 Thank you, but that does not satisfy my goal.

When you create UDT, you declare variables, not constant. A variable that owns a constant value is a variable and cannot be used, for example, in CASE statement or to declare an array size.

I am just trying to have a not messy declaration for costants. If I have a state machine in an FB with 20 states, I want to give a name to each state. If they are group under a collector (Struct) they would not mix with other constants I have and they won't be spread in the declaration table.

qwazee

Hello.

What you ask is not possible.

There is a workaround which I use for S7-1x00:

* Create a UDT

* Populate the UDT with the internal tags.
   Assign the constant values as you need.

* Create a tag for the code block in the TEMP area.

   The tag is of the type from the newly created UDT.

* Use the new tag in your code.

   The values are already assigned

Helpful?

Nice to have.

If we had such a Struct for constants, we would not be forced to declare the same constants in all FB's that need them. As we cannot, to preserve code protection and versioning of tipified FB, access nor global tags (of course) nor even global constants.

If we had a Struct, we could pass it in Input to an FB, declare it only once as global constant, and pass it through the input section.

We already can assign a constant to an input of FB of the same type, but not in an organized way. So if I need 30 constants in and FB, I am forced to declare either 30 inputs or replicates constant declaration inside FB.

Last try in TiA v17, upd4.

BoletusEdulis

Nice to have.

If we had such a Struct for constants, we would not be forced to declare the same constants in all FB's that need them. As we cannot, to preserve code protection and versioning of tipified FB, access nor global tags (of course) nor even global constants.

If we had a Struct, we could pass it in Input to an FB, declare it only once as global constant, and pass it through the input section.

We already can assign a constant to an input of FB of the same type, but not in an organized way. So if I need 30 constants in and FB, I am forced to declare either 30 inputs or replicates constant declaration inside FB.

Last try in TiA v17, upd4.

Whatever you pass through inputs to the code block will compromise security and integrity of the code. Passing values via inputs from a DB or passing values from a "structure of global constants" has no difference to the code handling.

Changing the memory footprint/attribute of a DB can be done by selecting 'only in load memory'. That is as close as you can get to make a DB, a constant.

You are fighting representation of your code. Perhaps what you need is a way to 'show' a structured constant in the IDE. Another approach would have been to using something like Openness to augment the view of your code.

Whatever you pass through inputs to the code block will compromise security and integrity of the code. Passing values via inputs from a DB or passing values from a "structure of global constants" has no difference to the code handling.

• I strongly disagree. You can't use variables as constants. CASE instruction accept constants, not tags, for example. Moreover, is a required specification for tipification and good programming rule to go through standard interface.
• Security is managed at different level. I wouldn't care much since bigger vulnerabilties has been found where a Mitm can change source code and compiled code in order to make them different, almost without possibility to recognize it.

Changing the memory footprint/attribute of a DB can be done by selecting 'only in load memory'. That is as close as you can get to make a DB, a constant.

You are fighting representation of your code. Perhaps what you need is a way to 'show' a structured constant in the IDE. Another approach would have been to using something like Openness to augment the view of your code.

• you can do, in Codesys, with Beckhoff or others to structure constants. That is the world outside these limits. IT and OT are conveging, so must do the tools we use. This is the automation trend. We are still playing with underdeveloped tools, working with imposed limits by I don't know who, but somebody that does not have demonstrated yet the ability to think open minded.

In the German language forum,
Siemens is asking users what they want from Siemens.

Find those German forum posts relating to Step7
and make your wish list known.

Does anybody know if there is any improvement up to TiA 19?

Thank you