Hello everyone, I am currently working on a migration project and have encountered an issue with FC: BLKMOV. My goal is to transfer a variety of non-unified data types stored in the local L Memories of the program (starting from LD8 onwards). The migration is from a PLC S7-317 running Step 7 with a program written in STL to a S7-1517TF-3PN/DP on TIA Portal with a program also written in STL. In Step 7, the program was scripted as follows: L DW#16#10130001 T LD 8 TAKT LD 36 TAKL W#16#7D0 T LW 12 L LD 36 OD DW#16#84000000 T LD 14 L B#16#3C T DBB 2754 L DW#16#10130001 T LD 18 L W#16#C7 T LW 22 L DW#16#84005610 T LD 24 UC "BLKMOV" P#L 8.0 P#L 44.0 P#L 18.0 From my understanding, the block is unconditionally called (UC) as BLKMOV, with the next three lines representing parameters, which point to temporary stored addresses in the FC itself as follows: P#L 8.0 (Source Pointer) P#L 44.0 (Destination Pointer) P#L 18.0 (Length) My question is regarding the order of these pointers and their purpose. Are they truly in the sequence of Source, Destination, and Length? According to TIA Portal Help, the parameters for BLKMOV should be as follows: Source Return Value INT Destination As I aim to move a wide range of data from %L8.0 to %Ln.n, which includes different data types (Word and DWord) for the Temp Tags within this range, I have also come across MOVE_BLK in TIA, which supports the movement of a block of data. However, this function block can only accept an Element of an Array. How should I configure BLKMOV to achieve this task effectively? Thank you.
Share the source code of the function in textual form, along with the interface for better understanding and implementation.
Hello LD[AR2P#0.0], Here is the source code in text format for an interface: Interface: - Inputs: Last_Step (Integer), Current_Step (Integer), Next_Step (Integer), OP_Prompt (Integer) - Outputs: Out_CurrentStep (Integer), Out_CurrentStep (String[254]) - Temp variables: t_Last_Step (Integer, 0.0), t_Current_Step (Integer, 2.0), t_Next_Step (Integer, 4.0) - Return: RET_VAL Code snippet: L #Last_Step T #t_Last_Step L #Current_Step T #t_Current_Step L #Next_Step T #t_Next_Step L #t_Last_Step ITD L #1 -DL L #496 *DL DW #16#10130001 T LD 8 TAKT LD 28 TAKL W #16#7D0 T LW 12 T LD 28 OD DW #16#84000000 T LD 14 B #16#3C DBB 2690 L DW #16#10130001 T LD 18 L W #16#C7 T LW 22 L DW #16#84005410 T LD 24 UC "BLKMOV" P#L 8.0 P#L 36.0 P#L 18.0 This code snippet includes instructions for manipulating various input and output variables in an interface program.
In a recent discussion, hoang199849 expressed a desire to streamline the process of handling various types of data in the program's local L Memories. What exactly is a non-unified data type and is it necessary to utilize the Standard Template Library (STL)? It is advisable to steer clear of using STL in the 1500s era for optimal performance. For a more efficient approach, consider declaring the data structure as a specific type and managing it accordingly. In cases where the type is unknown, a Variant datatype or an array of bytes could be utilized. By following these 1500 best practices, data manipulation can be significantly improved.
The data you mentioned about "Temp Tags having various data types (Word and DWord)" is not saved in the L data section of the FC. What makes you think otherwise?
In response to L D[AR2P#0.0]'s query about the data types of Temp Tags (Word and DWord), it should be noted that this information is not stored in the L data area of the FC. The assumption that it is stored there may be incorrect. Could it be that these Lx.x addresses are actually offsets from the Temp Tags? It is worth exploring this possibility further.
Yes, you're correct. The order of these pointers is Source, Destination, and Length. BLKMOV in STL is indeed unconditionally called, and the parameters represent pointers to temporary addresses stored within the FC. Moving to TIA Portal, you may need to factor in differences in how memory is managed. The MOVE_BLK function can be a good alternative, but it does have its limitations with non-array data types. In your case, you might consider arranging your non-array data as an array of UDTs (User-Defined Types) where each UDT consists of word and DWord. Then, you can use MOVE_BLK to transfer the entire array. This requires some reorganization, but it should help you achieve your goal.
The rules for BLKMOV in TIA are a bit confusing, I agree. Yes, the sequence you mentioned is correct. The source pointer refers to the start of the area you're copying FROM, the destination pointer is the start of the area you're copying TO, and the length is the number of bytes to be copied. Remember that both Source and Destination pointers must be in aligned addresses (Address mod 2 = 0). When it comes to migrating different data types, you need to ensure the data structure remains the same in the areas of source and destination (it must consider word and double word alignment). In case your data structure changes, BLKMOV might not work as expected. In relation to your query about MOVE_BLK, you're correct that it only allows the movement of block data with elements of an array. To ensure smooth migration, you might have to modify your program's data structures or use a different method to transfer the data. It's a bit more time-consuming but it helps you troubleshoot potential issues that may arise. Good luck with your migration project!
✅ Work Order Management
✅ Asset Tracking
✅ Preventive Maintenance
✅ Inspection Report
We have received your information. We will share Schedule Demo details on your Mail Id.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.