DB's : Optimized / Non-Optimized

HMI : Siemens, correct?  What O/S?  If possible, upgrade the HMI O/S to the highest version compatible with TIA Portal version you are using.  Or, use newer TIA Portal version and update HMI O/S to the newer version (install HMI Panel Images to make that easier to do).

SCADA : Does it use Optimized DBs

The key to HMI tags, at least for me, is to have the HMI change the value of the tag on a button press (to ON or OFF), and nothing happens to that HMI tag when you let go - except for JOG type buttons or other very specific hold-to-activate an action.

The PLC then detects the HMI changed the state of the button's tag (M or DB) using perhaps a P-TRIG or N-TRIG.  The PLC then responds to the change of state caused by an HMI button press - and of course verifying the HMI is currently displaying a page where that button exists - if it really matters).

Once the PLC fully reacts to the button change (or at least latches the change of state), the PLC then reverts that M or DB tag to the "default" state - either ON or OFF.

Let's say it's a Cycle Start PB that changes a DB (named HMI) tag (named CycleStartPB) from OFF to ON.

Someone presses CycleStart PB on HMI.

"HMI".CycleStartPB becomes true in HMI
HMI sends update to PLC according to update rate for that tag on that screen
PLC accepts update and changes "HMI".CycleStartPB to true.
In FB that monitors cycle start status, it has inputs CycleStart and CycleStop (among others).
[That FB stays enabled 100% of the time]
In the FB, it checks when CycleStart transitions from FALSE -> TRUE.
When it does, it SETs CycleStarted, RESETs CycleStopped, then outputs Done = true once it has reacted to a change.
In the block calling CycleMonitor_FB, after the call, it checks if Done = true.  If so, it resets "HMI".CycleStartPB and "HMI".CycleStopPB

These are hypothetical actions and approaches to give you an idea how to buffer HMI actions and set up tags so the SCADA can read the right value.

In this specific case, HMI would control CycleStartPB and CycleStopPB.  PLC would monitor those PB inputs and set/reset appropriate CycleStartPB/CycleStopPB in that HMI DB.  The SCADA system would then use "SCADA_DB".CycleStarted and "SCADA_DB".CycleStopped tags to detect when the system is operating in automatic cycling mode or manual (or even setup or initialize modes).

Having the SCADA and HMI using the same tags is likely to cause troubles because of how they interact.  HMI tags should probably be "transient" in nature, where they cause an action to take place.  The background color of the HMI CycleStart PB could be tied to "SCADA_DB".CycleStarted, though you are now trying to send data to 2 devices from the same DB which could cause communications conflicts (depending on how Siemens handles sharing of DB data to multiple devices and whether they are async or not.  Regardless, it is generally better to have UDTs to help manage tags / state changes so you can duplicate multiple sets of tags to multiple destinations - like to "HMI" and "SCADA_DB".  I skipped over that because it was more important to share a way to organize and architect the design of data transitions and especially system state changes around the system so they are less likely to interfere with one another.

Hopefully that made sense and was not something you already knew more about than me.  I know generically about a wide range of PLCs on how to avoid problems - regardless of PLC designs and implementations. 

If you or others are aware of better ways to generically design a system that works across many PLC manufacturers, or even how to take advantage of Siemens hardware/software to make life easier, please post your ideas/concepts/suggestions/known working solutions.

red__line

After this message I managed to have a better behaviour and faster response (seems like no fails) using M bits instead of DB. But I am not happy with this solution... This will make me have to use different memories for SCADA and HMI, which is not the intended solution. 

It kind of looks like the HMI can't go though all the memories in the DBs in some cycles of the PLC.. It is strange and an unexpected behaviour in a simple integration of two products of the same manufacturer.

If anyone has some some insight why this could be happening and how I could use the DB memories directly in the HMI I would be thankful.