4/29/2016 3:51 PM | |
Joined: 12/8/2009 Last visit: 10/19/2023 Posts: 21 Rating:
|
I have a similar experience with TIA v13. In the former STEP 7 5.5 I used a byte member of a UDT placed in a DB to display the state of a device, one of the bits of that byte was used to control the device using the WinCC function SetBitWhileKeyPressed. The UDT was passed to a FB as INOUT parameter. Now with TIA I do the same with S7 1500 and S7 1200 CPUs and with various basic panels. The bit gets not always set or reset using the function SetBitWhileKeyPressed which is very annoying and possibly dangerous. As Siemens does not recommend to use this function I switched to an extra single command bit (which is more labor-consuming) and I use two events with SetBit and ResetBit functions. It does not work either. The data structure (PLC data type) is passed as an InOut parameter to a FB and therefor it should be passed as a pointer by reference. It looks to me that it is passed as copy instead and if the OP writes the tag asynchronously just when the FB is processed, the write (bit set/reset) fails and the data in the DB is overwritten when the FB call ends. The FB only reads that bit. Setting and resetting another bit using all above mentioned functions in the same DB works well if the bit is not passed to any FB. It seems to be a firmware issue in all TIA PLCs or I don’t understand what passing parameters by reference means… ------------------------------------------------------------------------------------------ |
Last edited by: The Helping Hand at: 4/29/2016 3:56:35 PMNew subject after splitting |
|
4/29/2016 4:21 PM | |
Posts: 5225 Rating:
|
See if this is of value to you... ?> PLC variables not stay changed when edited by HMI |
5/16/2016 9:41 AM | |
Joined: 12/8/2009 Last visit: 10/19/2023 Posts: 21 Rating:
|
The problem was solved by Siemens support. It was caused by mixing optimized and standard FB access. The documentation is not very clear on this issue, one must read everything thoroughly. Structured InOut parameters are not always passed by reference as one could assume. Programming guideline, page 19: "However, this does not apply if one of the blocks has the property Optimized access and the other block the property Standard access. Principally, all parameters are then transferred as copies" https://support.industry.siemens.com/cs/de/en/view/90885040 My function block originates from a S7-300 and therefore the optimized access was off. I missed that information and unfortunately the online help is somehow misleading in this point. On the page Programming a PLC/Creating a user program/Programming basics/Block calls/Parameter transfer of block parameters/Transfer parameter as copy or as pointer there is written: "Note Declare structured data types in the "InOut" area If possible, use the "InOut" area in the block interface for structured tags (e.g., of data type ARRAY, STRUCT, STRING, …). As structured in/out parameters are always transferred as pointer, the required data memory is not increased more than necessary." Always means always with no exception... In the table below is listed only Pointer for Structured data types and the information about a different behavior for standard access is only in a note below the table "When optimized data is transferred to a block with the property "Standard access", it is always transferred as copy." I suggest the information about problems when combining optimized and standard access should be made more obvious, the first note should contain some hint and the table too. I know several programmers from other companies complaining about bad behavior of HMI devices. Now it is clear that the problem is mainly caused by reusing old functions. |
Last edited by: Tom B. at: 5/16/2016 9:42:47 AM |
|
This contribution was helpful to
6 thankful Users |
5/16/2016 10:25 PM | |
Posts: 5225 Rating:
|
Thank you Tom for highlighting this case. --
huggy_d1 has highlighted that the access to the "optimized" structure is quicker and not just have a smaller memory footprint. (Focussing on the S7-1x00 range.) The two trouble areas are indirect addressing and data communication where it is essential for the code to know how the data is structured. The S7-1x00 code loves to have data in structures (read: UDT) and arrays. Especially the array handling can substitute some of of the indirect addressing one would want to do. Be warned - You may be surprised that accessing an array element (runtime defined index) is just marginally better than the traditional indirect addressing. See attached PDF. It would be interesting to know where "variant" instructions fit in. There is not much substitute for communication though. This is where I think the warning from Tom plays a role - data being accessed by multiple sources giving unpredictable results. Also.. mixing standard and optimize access have potential processing penalties (see PDF). crazyCow- I think frankly that your question needs an expanded answer more than said already. Coding only in optimized structures does not seem to be an option to me. Some data processing is just too expensive to execute on optimized structures. Mixing optimized with standard access needs some understanding of the inner workings to do this optimally. Do we users have enough information at this moment? w AttachmentProgramming Guideline for S7-1200 and S7-1500_page59.pdf (290 Downloads) |
Last edited by: William_B at: 5/16/2016 10:27:52 PMReplace PDF with newest version. |
|
This contribution was helpful to
2 thankful Users |
Follow us on