Hi Yannik,

sorry, in your description I can't find that you checked the DBs where you move the string to directly. You only mention that there are differences when retrieving the data by another system.

Did you ever check the DBs and can you confirm that there is different content where the same string is written?

How is that other system reading data?

Regards,
Frink

Hi Yannik,

in the screenshot you compare the source-string with one of the destination-strings. Isn't it possible that they are different?

When are ~bereit and ~quittiert set resp. reset?

Regards,

Frink

Suggestion:

Prior to moving the serial # to all 4 DBs, disable interrupts.

Now, copy every DB containing data needed remotely to a different DB.  Only do this is one place in logic.

Once the PLC DBs  - let's call them local DBs - are fully updated, copy the local DBs to other DBs - let's call them remote DBs.  Then enable interrupts.

In the put/get enable for each DB, disable all local DBs and enable for remote DBs.

By doing this, you improve odds of getting DB consistency with async remote GETs (or locally PUTs).

This should improve the problem from monthly to something closer to 50 years (or higher).

AutoGen_8746056

At the same time, we write a serial number in the header area of several DBs with the same structure using the "S_Move" command. Later in the process, these DBs are provided with measured values and then retrieved and saved by an MES system. We have the following phenomenon very sporadically (approx. once a month). The first time the DB is retrieved, the wrong serial number (the previous serial number) is read out; the second time the same DB is retrieved, the correct serial number is read out even though the serial number has not been rewritten.

Using a little logic, we compared the serial numbers of the different DBs with the same header and recorded a trace if there was a discrepancy. The trace was recorded, which is why I suspect that the DBs are written differently, but I cannot currently explain why. It is also strange that the serial number is correct again on the second readout of each DB. In addition, there are 15 minutes between the first readout of the DB "Component busbar" and the last DB "Measure" readout, but we have the same phenomenon. The first readout reads out the previous serial number and the second reads out the correct one.

I hope I have described the problem sufficiently and clearly. Please do not hesitate to contact me if you have any further questions.

We use TIA 15.1.0.8

Yours sincerely

Yannik Koudelka

Yes.  I suspect the remote async comms (DB GET) is happening every so often at a time when 1, 2, or 3 of the 4 DBs are updated but not all 4 when the PLC copies the requested DB into the send buffer.

That way, you control how each DB gets updated, maintain consistency across the entire DB, enforce DB data relationships are precisely what you want and intend.

For example, let's say you are preparing to update a DB being read remotely, and the first thing you do is update the serial #.  However, before you update all DB with all other changes, the remote system requests and gets the DB.  Now the serial # is not presenting the correct values to the remote system.

It is far better to control that process by having the PLC code manage what the remote system is allowed to see and when they can get it.

By managing the disabling and enabling of interrupts, you manage the "when" so the remote system can only capture data after every piece of data is updated.

By copying accumulated data to a separate DB all at once, you prevent the remote system from having a chance at obtaining partially updated data.

AutoGen_8746056

Hello Einstein,

thank you for your reply.

Is your suggestion also an answer for the strange behavior I described in my answer before?