Siemens Portal "Download without Reintialization"

Can someone explain to me how "Download without Reinitialization" works?
I believe it allows me to keep my retained information when making changes to the DB without initialization to the start values. However, I have the box checked and it does not appear to work.

What can I change and not change without have to force reinitialization?

How do I get this to work?

JDCROCKETT724 said:

Can someone explain to me how "Download without Reinitialization" works?
I believe it allows me to keep my retained information when making changes to the DB without initialization to the start values. However, I have the box checked and it does not appear to work.

What can I change and not change without have to force reinitialization?

How do I get this to work?

Click to expand...

The big trick with DL W/O Reinit is that you need to activate it and download it BEFORE you need to use it. Essentially the system is pre-creating a bunch of spare tags for you to use later, and hiding them from you until you actually use them, except that you get to use whatever data type you want.



As a side note, you said you want to keep "retained" information. If you meant "retentive", you need to create a special retentive memory reserve, with the 2nd field in your screenshot. If by "retained" you mean "whatever data my PLC currently has" then carry on.



Workflow could be something like:
1) Nearing end of project, turn on feature to minimize future impacts to production. Make one more DL.

2) You can no longer make changes to tags in DBs where it is activated, but you can add new tags.
3) at some point in the future, you need to add a couple tags. You add the tags to the DB, download, and your existing tags aren't affected. You have X amount less memory reserve available for that DB.
4) at some point in the future, you reinitialize the DB to get all the memory reserve back.



However, the most common thing that I run into is that people don't usually need to add a few tags to a DB. What I usually need to do is add a few tags to a data type, or expand an array of something. It's less helpful there.



In my view, this feature isn't good for a system being comissioned. It's helpful to activate when a system is being put into production and PROBABLY won't need more changes, but if it does they'll hopefully be small and you won't want to impact production.

mk42 said:

2) You can no longer make changes to tags in DBs where it is activated, but you can add new tags.

Click to expand...

Can you change the initial value of existing tags ?
That is something I think would be useful since you often dont know the good initial values when you start writing a new program.
I know I can make a snapshot of the actual values and copy them to the initial values, but that is something else.

mk42 said:

However, the most common thing that I run into is that people don't usually need to add a few tags to a DB. What I usually need to do is add a few tags to a data type, or expand an array of something. It's less helpful there.

Click to expand...

That is a serious limitation.

Have been thinking about trying out the Download without Reinitialization, but now I am not so sure it is worth it.

JesperMP said:

Can you change the initial value of existing tags ?
That is something I think would be useful since you often dont know the good initial values when you start writing a new program.
I know I can make a snapshot of the actual values and copy them to the initial values, but that is something else.

Click to expand...

Tag name and data type are locked in (also Retain/accessible/writable/visible). Comments and start value can be changed (also Setpoint).



If you a UDT changes, you need to actually disable the feature to get the block to compile.

JesperMP said:

That is a serious limitation.

Have been thinking about trying out the Download without Reinitialization, but now I am not so sure it is worth it.

Click to expand...

If you're at an end user, I'd say give it a shot. Worst case, you need to turn the feature off and reinitialize, which is what you would have been doing anyway.


If you're a machine builder, it's a bit less useful.

mk42 said:

Tag name and data type are locked in (also Retain/accessible/writable/visible). Comments and start value can be changed (also Setpoint).



If you a UDT changes, you need to actually disable the feature to get the block to compile.




If you're at an end user, I'd say give it a shot. Worst case, you need to turn the feature off and reinitialize, which is what you would have been doing anyway.


If you're a machine builder, it's a bit less useful.

Click to expand...

As I learned Siemens with old S7 PLCs, I still add extra spare variables to DBs, even to UDTs sometimes.
That way DB lenght won't change and it is easier to make modifications later, if you only change these spare variable names and not add any lines to DB block.



(Optimization cuts only space which is between different address types. Non optimized DB reservers allways DBW addresses to next whole number, even that there is some addresses missing between bits and words.)



TIA has snapshot and you could first copy actual values to snapshot and then to as setpoints which are downloaded at DB change.


If you do it fast and make modify fast, data is allmost same.


Or add new DB-block for new variables

Lare said:

TIA has snapshot and you could first copy actual values to snapshot and then to as setpoints which are downloaded at DB change.


If you do it fast and make modify fast, data is allmost same.

Click to expand...

As they say in the movie, 60% of the time, it works every time!



Seriously, though, this is a pretty good option for a quick DL while operators are on break/lunch/etc.

Lare said:

Or add new DB-block for new variables

Click to expand...

I should have mentioned this option above. It is a great alternative in a lot of situations. Doesn't help for instance DBs, but a big help for general data.