Siemens MMC's & those damn actual values

[RMA]

Hi guys, better late than never,

Well, we're discovering all sorts of interesting things here, but I'm having difficulty deciding how to arrange them in order of importance - in fact I think I'll leave that to Jesper, as he'll do a better job than me, because of his greater experience and more detailed as well as wider knowledge of S7. (grovel, grovel!)

For me the most important thing is the discovery that there is no such thing as a S7-3xx CPU - they are all different! And not just as Siemens would have us believe, between Firmware V1 & V2. Jesper doesn't say (or I missed it) which Version Firmware his 313C has, but it really doesn't matter, because neither of my CPUs react the same way his 313 does i.e. it apparently saves the the current actual value, during the first power fail - I would hope it also does it during the first OFF-ON cycle (did you try that Jesper?), otherwise some people are going to get an unpleasant surprise some day.

Come to think of it that may be the most important thing of all - when you get a new MMC 3xx CPU, play with it immediately to find out under what conditions it saves what it considers to be the Initial Value of the DB to the MMC!

Next Point - Prize for the most misleading nomenclature of all time must go to Siemens for the "Initial Value" field when creating a DB - as you can see on the next post, it's not used anywhere - that's right, nowhere, under the conditions under which I tested!

To be considered if you're playing around a lot before doing your final project on a used MMC - get yourself a prommer so that you can see - and delete - what's on it. Otherwise if you create a DB for your new project, it's Initial Value will remain the Initial Value that was generated when the DB with that number was first created - which might be something quite different from what you were expecting!

I've included a bit from the Siemens handbook describing how V2 handles the DBs, if you take it at face value and think that the value you entered in the Initial Value field is what you'll get from a non-retentive DB, you're in for a big surprise if you didn't also set it in the "Actual Value" field on creating the DB! Unless of course, your CPU behaves like Jespers!

Once again, apologies for the widescreen, but it was barely legible at 800x600.

 

[RMA]

Since I don't know how to post two screen dumps in one posting, here's the summary of what happened with my two CPUs.

Apology as before!

 

[JesperMP]

Hi Roy,
your effort forces me to drop my current activities and respond with equal resolve (which I do gladly, despite of a looming deadline, or maybe because of that).

1. It looks like your tests confirms that the values on the MMC are not stored at every powerdown, but only when a DB is written directly to the MMC or at first powercycle after download to RAM.
This because the values in columns D/E are the same as in column L.

2. Yes, you have pinpointed a difference in the behaviour of DBs that has the non-retentive bit set. Older firmware versions simply do not have the non-retentive functionality. My firmware was v1.

3. About the INITIAL VALUES:
Ah, yes these has also confused me from day one. I have to admit that some of the things that I have written in previous threads are simply wrong.
The thing is, INITIAL VALUEs are only used when editing a project in STEP7 (!). When an instance DB is created, or a UDT var is created in a DB, or "calls are updated", or "project is reorganised", then STEP7 uses the INITIAL VALs. Apart from that they are ignored.
(disclaimer: This is my opinion at this time, it can change !).
It arises a question: Then why are the INITIAL VALs downloaded to the PLC ? Maybe because you must be able to do a complete upload.
Or if you create an instance DB while online ?

4. When you dont enter an ACTUAL VAL then it will be "0" zero, not empty. So the "xxx" values in yor column C7, C8,C14 and C15 are really "0". There MUST be an ACTUAL VAL. STEP7 enters "0" for you if you jump past it.

edit: I also HATE that you have to switch between declaration view and data view. Its too easy to forget to set both INITIAL VAL and ACTUAL VAL. Many problems come from this simple mistake.

5. Whats the difference between "power cycle" and "OFF/ON" in your post ?

 

[RMA]

It arises a question: Then why are the INITIAL VALs downloaded to the PLC ? Maybe because you must be able to do a complete upload.
Or if you create an instance DB while online ?

This is an interesting question, if you remember, I mentioned in one of the earlier posts, not sure which one now, must be about half-way through, that I created a new DB and downloaded it from the editor and it retained the initial value.

Now this WAS the real Initial Value in the Initial Value field, at the time I wasn't considering the actual value field. The trouble is, I can't remember EXACTLY what I did on that occasion and so far I haven't been able to duplicate it.

4. When you dont enter an ACTUAL VAL then it will be "0" zero, not empty. So the "xxx" values in yor column C7, C8,C14 and C15 are really "0". There MUST be an ACTUAL VAL. STEP7 enters "0" for you if you jump past it.

Yes, I was aware of that, I was just meaning to emphasise that I hadn't entered anything myself.

Whats the difference between "power cycle" and "OFF/ON" in your post ?

The "power cycle" column has the value seen in the VAT after switching the power OFF and then switching back ON without doing anything else.

The OFF/ON Column has the values after setting the CPU in STOP with the Lever switch and then setting it back to RUN - I included it just in case there might be a difference, which there wasn't. I guess I must be getting paranoid, I don't trust anything now!

 

[ivo.maenen]

For the novice this should also be interessting to know;

If you make a new DB then there is already one variable, named db_var if i am correct. When you enter an initial value here, the actual value in the data view still has the value '0'. Or you change this actual value or you should delete the variable-row.


If you copy DB's then the actual values will also be copied. You should swith to data view and then select 'edit' and 'init datablock'.

 

[JesperMP]

To RMA.

Roy,

did you make the experiment with leaving the CPU powered down over the christmas holiday, to check if the actual values are reset to the values from the time where the DB was stored on the MMC ?

If you forgot it then you are forgiven.

 

[RMA]

Happy New year everybody!

I'm still on holiday - last day though. Yes the 314-2 DP is sitting on the desk powered down, (since about the middle of December), so on Monday we'll find out what has REALLY been retained and what has been forgotten.

See you Monday! :site:

 

[Terry Woods]

It appears that all of the effort in this thread is to understand how the 3XX manages particular variables under particular circumstances, such as Run->Stop, Power ON/OFF, Power Loss, etc. And then how it manages those variables on re-start.

I get the impression that, even if the cpu is configured to retain particular variables in certain circumstances, there are certain other circumstances that negate that retention.

It reminds me of the situation that old-time "bookies" used to find themselves in... sometimes. (I wonder how they do it these days... computers, cell phones, et al?)

At the "bookie-joint", if the "bookies" got a tip that they were about to be raided by the cops (very soon, but not immediately), they had time to gather up all of their records and dash out the backdoor before the cops showed up.

Situation: Pending Crisis... Data retained!

However, if they didn't get a tip and the cops were breaking down the doors, then the "bookies" put a cigarette to the notes ("flash-paper") and destroyed all of the evidence before the cops got their hands on it.

Situation: Immediate Crisis... Data lost!

As the doors were being bashed in, the "bookies" knew that they were being raided, however, they just didn't have enough time to save the data (and their a$$es!).

Now, if the "bookies" where a bit more "up-to-date" (I'm sure they are!), then everytime there was a change in their current data, they could send the new data into safe-keeping in the "ether" (the internet).

Then, even if they became aware of a raid only as the doors were coming down, all of the local data could be "flashed" and yet all of the lastest data would be retained... somewhere in the ether.

After the cops had no choice but to believe that this was nothing more than a monthly meeting of the Knitting Club, the "knitters" ("bookies") could relocate to a safer place, recover a copy of the saved data, and then resume operations where they left off... as if nothing had happened.

So, it occurred to me that the program needs away to force the CPU to save new data to a safe-place even as it is being created.

Is there a means to force the 3XX to save data to a retentive location while things are running normally?

For example, on an HMI, could a guy push a button to "SAVE DATA"?

Or... could the program be designed to "Save Data" anytime a particular variable is changed?

This could be initiated on a parameter by parameter basis whenever a particular parameter is changed.

Or, it could be a matter of comparing a table of current parameters to a table of saved parameters. If the saved parameter table doesn't match the current parameter table then save the current parameter table.

This brings up another question...
Is there a limit to the number of times that the retentive memory locations can be written to?


When I used to write programs in "C" on PC-Controlled systems, I used to save data to a floppy every so often. If a parameter was changed, then the program set a flag to update the "Saved Data". Data was saved to the floppy on a time-slice basis. If the system went down during a save-operation, then only the last change (just moments ago) was lost.

Whenever the system was restarted, the initial values in the code were loaded, but then, before the process could run, the PC would read the data on the floppy and update all pertinent variables with the last-saved values. When that was completed, a flag was set to indicate that the latest data had been loaded. Only then was the process allowed to run.

 

[RMA]

and the answer is

back at work after three weeks of doing nothing (workwise, that is) and after brewing the first pot of tea to try and persuade the brain to start thinking again, I switched on the 314-2 DP after a little more than four weeks pause.

The happy answer is - everything, including Merker, is as it was at power down. So it looks as though the whole of memory is written to the MMC on power fail. That leaves us with the interesting question, what happens when the MMC is smaller than the memory of the CPU?

Is there a means to force the 3XX to save data to a retentive location while things are running normally?

Yes there is, the SFCs 82 - 84 in the Standard Library enable you to create, read and write to datablocks on the MMCs. As with all Flash memory the number of writes is limited - I believe about 10,000 cycles is normally quoted - however, I recently found out the hard way, that this probably assumes random distribution of the writes over the whole memory volume. I had a CD-RW which I was using to keep backup copies of each new version of the PLC program die on me after well under 100 writes, presumably because I was always storing the program under the same name (and nothing else was being written to the CD).

 

[MacGyver]

Some Explanation

Linked DBs that are used by program... are copied into RAM of CPU. Some of them or first some kBs are retentive in never CPUs (in some CPUs you can determine which to be retentive). In spite of CPU has no battery, it has capacitor of 1F - goldcap, which could power retentive RAM areas for months.



On power UP / STOP to RUN is checked time of creation... of DB on MMC, and if it is the same as in RAM, then retentive data stays as it was.



If you do memory reset, all data is erased, including DBs and data that are already in RAM. Initial values are loaded with DBs from MMC. (Here is answer why all zeroed.)



You can store DB from RAM (linked one) to some DB on MMC (unlinked one) with SFC84. I have some problems with knowing that store is completed.



You can get back stored data from MMC to RAM with SFC83. In program you can not directly use unlinked DB from MMC to which data is stored, because it is not linked (copied) to RAM area of CPU as are linked DBs.



SFC 84 is not suitable for frequent (or cyclical) writing of variables to the load memory writing. This is because the technology of Micro Memory Cards means that only a certain number of write accesses can be made to a Micro Memory Card. It could be used for recipes...

 

[bgtpha]

You must program OB100 in order to settle the initial values... you can store all those parameters in some auxiliar MW (or DB) and then dump those MWs (or DB) to the parameters in OB100.