Step7 - Copying a STRUCT in a STAT in an FB declaration

I need to modify a program which runs our new Cognex cameras to accept a new command. The command descriptions are included as STATS in the FB, so I wanted to copy and insert then modify an existing command description. As you can see in the following screen-dump, the commands are all grouped together as STRUCTS in the "Group" BefehleKamera.





In order to stay as near as possible to the original concept, I want to add a command "GD" - Get Data (STRING from a Barcode). This would be analogous to the existing "GR" (Get Result) command. Unfortunately, I can't find any way to copy or insert a new STRUCT. Is there an easy way to do this or do I need to go about things some other way.

I thought about creating a source file and then modifying the STAT declaration there - would that be a possible solution?

Cheers

Roy

The structure you are trying to modify belongs to the FB named BefehleKamera, not FB176. So close down FB176, open the correct FB and modify the struct in the stat area of that FB. (Of course you will then have to update the declarations "up the line").

Thanks Simon, while waiting to see what would come up, I decided to follow my own advice. I created the source file and digging through it I found the STAT simply declared as "BefehleKamera". A look in the Symbol table turned up a UDT176 (actually UDT175, since I was working with a copy of the original FB) and in its source code I found what I was looking for.

One interesting point, in the source files I couldn't find anywhere where either "FB176" or "UDT176" were defined, only the Title definition. Is the FB- etc. purely defined through the name of the source file?

By the way, in case anybody's wondering about the "KNOW_HOW_PROTECT" comment in the Title comments, no, I didn't crack it (although if you dig through my past posts, this wouldn't have been a problem), but Siemens-VDO, fortunately, requires its suppliers to lay their code open. In the second Network, I ran into this:



In another program I ran into a similar initialisation where the long list of Resets was preceded by a "CLR" - okay, I can understand how it happens, but it just goes to show that not everybody's Know-How-protected code is as thoroughly checked as it ought to be!

Roy, are you suggesting there is something wrong with the circled code ?

Unless I'm getting myself thoroughly confused again - not that unusual, I guess - the list of resets will never execute, because in order to get there the RLO has to be FALSE. If the two ANs are TRUE the resets are jumped over.

Or am I missing somethhing here?

After the JC instruction, the RLO is always true so they will reset.

Ahhh, silly me, I ought to have remembered that, because I've been bitten by it before! I now religiously put a CLR before logical ORs following a Jump precisely because of this problem - evidently it's become so automatic I've forgotten why!

Thinking about it, I probably assumed the RLO was carried as TRUE when the jump was executed and thought it would be FALSE if the Jump did not execute - must read the help files more carefully in future!

The other version I've seen though is:

...
CLR
R M0.0
R M0.1
...

which I don't reckon will work, although I believe this would:

...
CLR
= M0.0
= M0.1
...

yes, you are right.