Skip to Content

Register Login

Industry Online Support

Technical Forum

Navigation

?> PLC variables not stay changed when edited by HMI

Created by: William_B at: 12/17/2015 4:42 PM (20 Replies)

Rating (7)

Thanks 9

Result pages:: |; 1 | 2 | 3; |

21 Entries

Entries per page: 10 | 20 | all

12/17/2015 4:42 PM	Rate (1)
William_B Posts: 5225 Rating: (1182)	Hi everyone, The problem I have is described in the FAQ: Why is it sporadically not possible to operate the CPU via the panel when you parametrise the HMI tags with the input and output parameters? [LINK] The problem is when the process is running, there are some variables (counters) that sometimes need to be changed by the operator. It has happened before that the value is changed and then seconds later the value changes back to the original. My program style has process values in a DB which are handed to relevant FB code blocks via IN/OUT parameters. According to the above FAQ this is a problem. https://support.industry.siemens.com/cs/ww/en/view/109476062 Note In the case of InOut parameters the copy of the operand is written to the operand again when the block ends, even if the copy has not been changed in the block. This means that asynchronous changes of the operand (or parts of it) during runtime of the block (through write HMI access or higher priority runtime level) are lost because they are overwritten with the value of the operand when the block is called. The FAQ further makes a suggestion: https://support.industry.siemens.com/cs/ww/en/view/109476062 Remedy* Define your tags in global data blocks and parameterize the block parameters with the DB variables. Please help me.. what does this (underlined) mean? Thanks for your attention. w
William_B Posts: 5225 Rating: (1182)	Last edited by: William_B at: 12/17/2015 4:43:07 PM Last edited by: William_B at: 12/17/2015 4:48:19 PM Add a quote about InOut parameters
Suggestion To thank Quote Answer

12/17/2015 5:12 PM	Rate (1)
brian.grimshaw Posts: 61 Rating: (11)	Hello William_B, I think it is referring to this from the FAQ - it certainly isn't clear though: If you parameterize the block parameters with structured tags (like of the type ARRAY, STRUCT, STRING, …), STEP 7 transfers the data as pointer (Call by reference) So, put your data in a structure or array and it will be called by reference and therefore won't write back the whole thing at the end of the FB. I had a similar issue with four bits that I needed to set in a certain condition, so I just put them in ladder after the FB. Could you do something similar for the ones that you need to write in the PLC? Brian
brian.grimshaw Posts: 61 Rating: (11)
Suggestion To thank Quote Answer

12/18/2015 7:00 AM	Rate (1)
William_B Posts: 5225 Rating: (1182)	brian.grimshaw Hello William_B, I think it is referring to this from the FAQ - it certainly isn't clear though: If you parameterize the block parameters with structured tags (like of the type ARRAY, STRUCT, STRING, …), STEP 7 transfers the data as pointer (Call by reference) So, put your data in a structure or array and it will be called by reference and therefore won't write back the whole thing at the end of the FB. I had a similar issue with four bits that I needed to set in a certain condition, so I just put them in ladder after the FB. Could you do something similar for the ones that you need to write in the PLC? Brian Thank you Brian for your attention. My style of program is as follows... HMI <------> Global DB <----> (InOut) FB(a) <----> (InOut) FB(b) <----> (InOut) FB(c) .... The HMI connects to a global DB which in turn connect to all the relevant FB code blocks via the In-Out parameter. The reasons are: * The HMI interface does not change too much but the FB blocks may be exchanged for others in the library depending on the functionality. (think modular) * It is easier to monitor the system from one DB than getting values that are spread out throughout the program. * One starting point to work from when fault finding. The adjustable parameters are not hidden with the DB. ---------- The question for me is... what should I change to avoid the disadvantage of the HMI not being able to adjust the parameters? w
William_B Posts: 5225 Rating: (1182)
Suggestion To thank Quote Answer
This contribution was helpful to 1 thankful Users ravikaroria

12/18/2015 9:35 AM	Rate (1)
brian.grimshaw Posts: 61 Rating: (11)	Hi William_B, I don't know much about your application, but if your data block contained a structure: Instead of: DB1 Name Data Type Var1 int Var2 bool Var3 real Use: DB1 Name Data Type Vars UDT_Vars in UDT_Vars: Name Data Type Var1 int Var2 bool Var3 real Then you can connect DB1.Vars to your FBs (InOut of type UDT_Vars). According to the FAQ, that should then be read by reference and should be OK. Brian
brian.grimshaw Posts: 61 Rating: (11)
Suggestion To thank Quote Answer
This contribution was helpful to 2 thankful Users socrames Amol V

12/18/2015 1:58 PM	Rate (1)
Cicero Gold Member Joined: 10/10/2005 Last visit: 11/27/2023 Posts: 1916 Rating: (132)	Hello William, the problem in this case are the two processes of the PLC and HMI systems which run parallel independently of each other. The variables will be overwritten when both systems write on the same. This is as system property. See also the informations in the FAQ with example and remedy (link): https://support.industry.siemens.com/cs/ww/en/view/109478253 With best regards Bilbo

Suggestion To thank Quote Answer

12/21/2015 8:54 AM	Rate (0)
William_B Posts: 5225 Rating: (1182)	@Brian: Thank you for your input. I understand your suggestions. It is something I will have to (re)test and see if it makes a difference. To my definition if you have DB1.Var1, it is already in a structure. Declaring a UDT or STRUCT makes it a double structure. It really would have been great if there was a proper example listed in the FAQ. What gives me doubt is the fact that most of my variables are structured in the way that you suggest. I use the format: process.{name of machine unit}.{functionality} I will however go back and double check all the variables. @Bilbo: Thank you for the link. This one is more informative and has more to work with. Again it would have been nice to have a sample code.. but I understand the intent. A previous project has double variables on the HMI. The upper layer is the read only value as used by the PLC and the lower layer has the write only value that is sent from HMI to PLC to change the process read only value. It becomes a little ugly to detect the operator has changed the write-only value. --- Thank you both for your insights and direction.
William_B Posts: 5225 Rating: (1182)
Suggestion To thank Quote Answer

12/21/2015 12:01 PM	Rate (0)
enof Silver Member Joined: 2/10/2012 Last visit: 11/30/2023 Posts: 314 Rating: (58)	Ha William_B, I think I can help you with this one (and finally do something back). Looks like it all has to do with communication being async (in-cylce) in case of s7-1200/1500. See also: https://support.industry.siemens.com/tf/ww/en/posts/communication-with-citect-scada-and-in-out-parameter-modification/121690/?page=0&pageSize=10&zone=Internet The faq's go a bit overboard with optimized/non-opitmized, fc calls, parameters. Fine and dandy but it is really not a good idea to do async comms and if you do at least document it thoroughly.I'm looking at you Siemens. Indeed separate read and write hmi comms. The read-only don't have a problem. The write-only also don't have a problem. Its the write from hmi, read in plc AND write in plc and read hmi that do strange things. That should be done atomically. This is classic theory but could be simply avoided if comms were at the end of cylce (during pip). But they aren't:( I will take some time to make a good explanation with illustration. Have to run now. See other thread for solutions.

Suggestion To thank Quote Answer
This contribution was helpful to 1 thankful Users RammRras88

12/21/2015 1:06 PM	Rate (0)
William_B Posts: 5225 Rating: (1182)	enof Ha William_B, I think I can help you with this one (and finally do something back). Looks like it all has to do with communication being async (in-cylce) in case of s7-1200/1500. See also: https://support.industry.siemens.com/tf/ww/en/posts/communication-with-citect-scada-and-in-out-parameter-modification/121690/?page=0&pageSize=10&zone=Internet The faq's go a bit overboard with optimized/non-opitmized, fc calls, parameters. Fine and dandy but it is really not a good idea to do async comms and if you do at least document it thoroughly.I'm looking at you Siemens. Indeed separate read and write hmi comms. The read-only don't have a problem. The write-only also don't have a problem. Its the write from hmi, read in plc AND write in plc and read hmi that do strange things. That should be done atomically. This is classic theory but could be simply avoided if comms were at the end of cylce (during pip). But they aren't:( I will take some time to make a good explanation with illustration. Have to run now. See other thread for solutions. (smile) ..you do know the idea is not to pay me back - right? Your offer of help is most welcomed. I think I have a very good idea to how the async comms are messing up things. If you did not pass on information onto an FB, the issue would also not be that visible.. provided that the variable is not changed in the same cycle. So if the HMI linked directly to the variable declared as STAT in the FB, you will not have this problem. [BUT] making the FB a library capable code block then becomes very messy.. also so for fault finding. On the TD200 <-> S7-200 there was a bit that switched when a value was edited. Sadly you do not have this on the KTP700 Basic HMIs. Detecting "change" of the variable is not an option as the PLC has the right to change the variable too (when using a single variable). My proposal as follows... Top layer shows variable read (read-only) from PLC: This is the only number the user sees. Layer below is the read-write (2nd) variable: When the user touch the blue-yellow number the keypad jumps up for the pink-black number. The pink-black number defaults to -1. So if the PLC detects a change to a positive number, the blue-yellow number is changed and the pink-black jumps back to -1. The trouble with this idea is that the customer now asks why the keypad always have -1 as a number.. which is not possible for the process! Any ideas? w
William_B Posts: 5225 Rating: (1182)
Suggestion To thank Quote Answer

12/21/2015 6:46 PM	Rate (1)
enof Silver Member Joined: 2/10/2012 Last visit: 11/30/2023 Posts: 314 Rating: (58)	Ok, let my try to exlain this as simple as possible (but not simpler) (and hope this is indeed the problem) unknown user "I think I have a very good idea to how the async comms are messing up things. If you did not pass on information onto an FB, the issue would also not be that visible.. provided that the variable is not changed in the same cycle." Exactly, only it has nothing to do with fb but this can make it worse (processing time). Consider a simple var of type word named 'test'. Assign 1 to test at the begin of the cycle (ob1), do some processing, assign 0 to test, do some processing. Display test on hmi and gasp. On a 1200 it will show 0 and 1 depending whenever the read was done before or after 1 assignment. Try it! You expect a stable value 0 as is at the end of the cycle but it is not! How longer the processing the more prominent the effect. Now your case where a hmi writable var is used as a inout parameter for a fb. Especially when processing time of fb is long the chance of a hmi write occuring between the start of the fb and the end is not 0. You will lose this write! Probably the hmi changes the screen internally en change it back on a new plc read. If this is indeed your problem than using a (stable) copy of your hmi var as a inout para to the fb will work. Hence when the hmi update is between start and end of the fb call the update will fail but now the hmi written value is not overwritten by the fb call so next cycle it goes through!

Suggestion To thank Quote Answer
This contribution was helpful to 1 thankful Users William_B

12/22/2015 2:46 PM	Rate (1)
William_B Posts: 5225 Rating: (1182)	This question is now resolved!! To all that contributed to this thread - my sincere thanks. I have to make a special mention of Brian's contributions. He focused on getting a solution which I dearly needed. I tip my hat to you! It puts me to shame that the answer was actually plainly stated in the FAQ i have mentioned earlier and stated: brian.grimshaw ... If you parameterize the block parameters with structured tags (like of the type ARRAY, STRUCT, STRING, …), STEP 7 transfers the data as pointer (Call by reference) ... So how do I know that it works? I have constructed a simulation of the worst case scenario. That is where the HMI polls the PLC while the PLC is processing code that contains the parameter that is changed. For this I have created OB1 that calls FC1 that in turn calls FC2. FC2 is the one simulating the HMI trigger (#trigger and #valueHMI). A screen capture is attached to show all the actions and declarations. #data.V10 is passed on by value. It changes to #valueHMI for the duration of FC2, but jumps back to its old value when the scan exits FC1. #data.process.V1 however stay changed!! I hope someone learns from this. Greetings, w Attachment Visual notes_Testing parameter pass by value or reference.png (588 Downloads)
William_B Posts: 5225 Rating: (1182)
Suggestion To thank Quote Answer
This contribution was helpful to 3 thankful Users brian.grimshaw 0_Einstein S_Moderator

|

Share this page:

Share this page on...

Follow us on