AutoGen_1801304

1. 
   
2. The UDT contains all the start / default values.
   
   
3. Create the DB of type {whatever UDT name}
   
   
   
4. Make a code block that has a temp tag of type {whatever UDT name}.
   

 Hello AutoGen_1801304,

thank you for your comment.

This approach doesn't work for me, because, as I have noted, my "default" values are not the "start values" of my UDT, but the redefined "start values" of each particular instance of the "parent" UDT.

 The method stated by AutoGen_1801304 below is NOT appropriate because complex data types declared as temp variables are NOT re-initialized at the start of every scan and will contain JUNK DATA.  Do not copy temp UDTs expecting to initialize to default values; this does not work.  You can use stat instead (but must ensure the values don't change).

AutoGen_1801304

_Pavel_

Dear huggy_d1,

thank you.

It looks pretty complicated. I think I have to use the method proposed above by Kai.A.

Do the idea that Kal.A is giving but make a variation. You will not need to make an extra DB.

1. Create a UDT that has the structure you wish to have in your storage DB.
   
   
2. The UDT contains all the start / default values.
   
   
3. Create the DB of type {whatever UDT name}
   
   
   
4. Make a code block that has a temp tag of type {whatever UDT name}.
   
   
5. Use a MOVE function (see Network 1 in below example)
   
   (Network 2 is not required for the actual solution. It is only there to make a demo code block.)
   
   

So, I discovered this by experience.  I was using a 'blank' temp UDT in a conveyor function block to shuffle a FIFO that was used for the pallet tracking.  And then pallets just started appearing everywhere randomly!  Sure enough, when 'zeroing' out the first entry to shuffle the array, I wasn't actually clearing the data... on that particular day... did some research, and found that this is known behavior:

https://support.industry.siemens.com/cs/document/109478084/

Section 8, SE002 Rule: Initialize temporary variables: 

Justification: As only elementary data types are initialized by the system, all others have an undefined value, which can cause unexpected program behavior

Now, I'm sure I had additional (and better) references than this obscure one above.  But I can't find them right now... so maybe it was just this.  If you really want to get to the bottom of this, I would raise a support ticket and get an official answer.  I've used stat variables ever since and not had a problem.  

 Got the answer from tech support:

only elementary data types are getting initialised (plus other information, but I mention the important bit here).

Have posted here:

When TEMP variables are initialized (and when not)

qwazee

 

cliff.pennalligen

So, I discovered this by experience.  I was using a 'blank' temp UDT in a conveyor function block to shuffle a FIFO that was used for the pallet tracking.  And then pallets just started appearing everywhere randomly!  Sure enough, when 'zeroing' out the first entry to shuffle the array, I wasn't actually clearing the data... on that particular day... did some research, and found that this is known behavior:

https://support.industry.siemens.com/cs/document/109478084/

Section 8, SE002 Rule: Initialize temporary variables: 

Justification: As only elementary data types are initialized by the system, all others have an undefined value, which can cause unexpected program behavior

Now, I'm sure I had additional (and better) references than this obscure one above.  But I can't find them right now... so maybe it was just this.  If you really want to get to the bottom of this, I would raise a support ticket and get an official answer.  I've used stat variables ever since and not had a problem.  

Thank you for responding to share your experience. 

In Case anyone is still looking for a Solution to this Problem.

I started using Read_DBL.

#status:=READ_DBL(REQ := "Test1".Triggerload, SRCBLK := "Test1".Var1, BUSY => #busy, DSTBLK => "Test1".Var1);

hi!

I do it like this:

- to restore setpoints: use system function "READ_DBL" (DB from load memory of PLC -> copy/restore to work memory)

- to save setpoints: use system function "WRITE_DBL" (DB from work memory of PLC -> copy/save to load memory).

Using this functions you can save/restore or all data of DB or separately any part/tag of DB.

during "WRITE_DTL" all "actual value" are saving into "start value" of DB in load memory, so it newer changes and it's not need to use 'retain' memory.