Skip to Content

SiePortal

The integrated platform for your product selection, buying and support workflow - bringing together Industry Mall and Online Support.

SiePortalDeutsch

Search

Home
Support Support
{{(apiData.Support | filter:{'rank':1}:true)[0].title}} Support
- Menu temporary not available
- Menu temporary not available
- Menue temporary not available
- {{item.title}}

Products & Services
- Menu temporary not available
- Menue temporary not available
- {{item.title}}
Support Support
{{(apiData.Support | filter:{'rank':1}:true)[0].title}} Support
- Menu temporary not available
- Menue temporary not available
- {{item.title}}
MySiePortal MySiePortal
{{(apiData.MySiePortal | filter:{'rank':1}:true)[0].title}} MySiePortal
- Menu temporary not available
- Menue temporary not available
- {{item.title}}
Cart ({{apiData.CartCount}})

Navigation

Question about UPDAT_PI

Created by: Toombs at: 12/19/2014 5:59 PM (11 Replies)

Rating (1)

Thanks 0

Result pages:: |; 1 | 2; |

12 Entries

Entries per page: 10 | all

12/19/2014 5:59 PM	Rate (0)
Toombs Posts: 91 Rating: (4)	Hello, I have some remote IO that I have assigned to a process image table (e.g. PIP6). I want to update and read in those input values. What is the best practice for calling UPDAT_PI? Does it really need to be in a hardware interrupt OB as I've read one place in this forum, or can I simply write a FC and use UPDAT_PI inside that function call? Or should I assign the PIP to an OB and call that OB to update the values? Thanks...
Toombs Posts: 91 Rating: (4)
Suggestion To thank Quote Answer

12/19/2014 8:33 PM	Rate (0)
hdhosseini Diamond Expert Joined: 1/28/2009 Last visit: 3/8/2025 Posts: 6860 Rating: (1366)	Toombs Hello, I have some remote IO that I have assigned to a process image table (e.g. PIP6). I want to update and read in those input values. What is the best practice for calling UPDAT_PI? Does it really need to be in a hardware interrupt OB as I've read one place in this forum, or can I simply write a FC and use UPDAT_PI inside that function call? Or should I assign the PIP to an OB and call that OB to update the values? Thanks... Hello Toombs, For other CPUs like S7-300/400, when you assign a partition of process image to a cyclic interrupt OBs, the update procedure(for module on that partition) is done by calling "Update Input PI" at the beginning of the mentioned OB for input signals. I hope this idea helps you! Best regards, Hamid Hosseini
	Last edited by: hdhosseini at: 12/20/2014 7:49 PM Demo Channel on Youtube
Suggestion To thank Quote Answer

12/19/2014 9:14 PM	Rate (0)
Toombs Posts: 91 Rating: (4)	What about for a 1500 series? Same thing?
Toombs Posts: 91 Rating: (4)
Suggestion To thank Quote Answer

12/20/2014 7:52 PM	Rate (0)
hdhosseini Diamond Expert Joined: 1/28/2009 Last visit: 3/8/2025 Posts: 6860 Rating: (1366)	Toombs What about for a 1500 series? Same thing? I am sorry to say I can not give you a "yes" or "no" answer.You have option of testing if you have the actual hardware plus you may aske from here (Support Request). To provide all related information, I also suggest checking THIS link also.
	Demo Channel on Youtube
Suggestion To thank Quote Answer

12/22/2014 8:46 AM	Rate (0)
AutoGen_405229 Experienced Member Joined: 2/18/2013 Last visit: 3/12/2024 Posts: 102 Rating: (23)	Toombs What about for a 1500 series? Same thing? Yes, it's the same thing for the 1500 series. However note that the mostcommon practice for reading input values is tohave them in the default process image, which is updatedby the system at the beginning of a program cycle. I didn't understand your reason to assign it to a different process image part, e.g. PIP6. Normally you would do that, if you need the value in another OB with a different runtime behavior, e.g. in a cyclic interrupt OB. But from your question ("Does it really need to be in a hardware interrupt OB as I've read one place in this forum, or can I simply write a FC and use UPDAT_PI inside that function call?") I think you don't havesuch a case.

Suggestion To thank Quote Answer

12/22/2014 5:14 PM	Rate (0)
Toombs Posts: 91 Rating: (4)	I guess the problem is I'm trying to figure out a way to read these inputs without using direct addressing. So far, the only way I've figured out how to do it is by putting these inputs or outputs of a DP Slave device on my network in the process image table. I've been using Cyclic OBs to update them. Is there a better way? I'm used to using an instruction like DPRD_DAT and copying over large chunks of data and specifying the Byte size and where to place it. Without direct addressing, I don't think this command is of any use. If you see the attachment, with a 300 series PLC I could read words with DPRD_DAT and copy them to a data block just by specifying the starting address. Any suggestions on how to have the same functionality for the 1500 series PLC without using the process image table? Attachment DPRD_DAT.jpg (369 Downloads)
Toombs Posts: 91 Rating: (4)	Last edited by: Toombs at: 12/22/2014 5:15 PM Last edited by: Toombs at: 12/22/2014 5:15 PM
Suggestion To thank Quote Answer

12/22/2014 5:51 PM	Rate (0)
AutoGen_405229 Experienced Member Joined: 2/18/2013 Last visit: 3/12/2024 Posts: 102 Rating: (23)	Toombs Any suggestions on how to have the same functionality for the 1500 series PLC without using the process image table? I don't understand what you mean by "process image table". For the 1500 I would suggest to assign the inputs to the "Automatic update" Process image (see Online Help - Assign process image/process image partition (1500)). Then you can access the inputs from anyblockyou callin your program cycle using PLC tags for the respective inputs (I, IB, IW, ID e.g. Name: myInput - Data type: Word - Address: %IW256 or whateveryour Name,Data type and Addresslooks like).

Suggestion To thank Quote Answer

12/22/2014 10:25 PM	Rate (0)
Marko Bursic Platinum Member Joined: 9/8/2009 Last visit: 7/17/2023 Posts: 1410 Rating: (154)	UPDAT_PI and UPDAT_PO is to be used, in my opinion, only with cyclic interrupt. Let's presume that you want to read data from DP slave, compute and send result back to slave, all this at deterministic time, like fast PID controller. But you do need to configure another PIP for that. DPRD_DAT reads data from PIP, I think. Use of UPDAT_PI isn't a replacement for DPRD_DAT. Anyway I do not fully understand what your itentions are, and whyDPRD_DAT isn't good for you.

Suggestion To thank Quote Answer

12/23/2014 10:49 PM	Rate (0)
Toombs Posts: 91 Rating: (4)	Hello Marko, The problem is with the documentation of how DPRD_DAT works for a S7-1200 or S7-1500 PLC versus how it works for a S7-300 or S7-400 PLC. With the 300 or 400 PLC, the Laddr input is simply the I/O address you want to start reading in. Then in the Record output, you specify the number of bytes and where to write it to. With the 1200 or 1500 PLC, the documentation says that the Laddr input is now the "Hardware ID of the module from which the data is to be read" It says nothing about addresses. So for example, in my application I have a Siemens breaker I'm trying to read data from. The addresses span from 40 to 83. With the 300 PLC, I could start reading at W#16#28 (40 in hex) and specify 4 bytes a time to read. Now I have to put in that Hardware ID of 263 (which is what it happens to be in my program). No address start location. Furthermore, the documentation for the 1500 PLC says that for the Record "The target range has to be at least as long as the inputs of the selected module." So that makes me wonder how I can read all the addresses from 40..83 when I can't specify where to start reading, and what would I copy those addresses into as there is no data type that is 40+ bytes long. Part of my problems are compounded by not having the hardware in front of me to test this program on. I'm writing the code as the workshop builds it and wires it up. So I'm thinking DPRD_DAT isn't going to work. The suggestion to move everything in to the Automatic Update process image will likely work, but I have another question about that. How do I detect read errors when I put everything in the process image table? With the DPRD_DAT, there was the RET_VAL that I could monitor for read errors. Now if I have everything in the process image, I'm using just Move instructions and there is no error monitoring for that that I know of. Does anyone have a suggestion? Or do you typically handle that with an OB of some sort? EDIT: Note, the Siemens breaker I am referring to - in the past I would have set the addresses to be outside of the process image and thus used DPRD_DAT to read them in. As I currently have it configured, they are in the process image and I assume will be constantly updated.
Toombs Posts: 91 Rating: (4)	Last edited by: Toombs at: 12/23/2014 10:51 PM
Suggestion To thank Quote Answer

12/24/2014 12:05 AM	Rate (1)
0_Einstein Diamond Expert Joined: 7/7/2010 Last visit: 3/21/2025 Posts: 15745 Rating: (2490)	If your device(s) shows up in the project tree, it likely has a diagnostics feature you can enable. If so, enable it. Now you can read the diagnostics / device and/or module states and see whether the system is acting properly. If that does not work, perhaps the LED status instruction will work for your application. Now that I understand your very specific problem of trying to iterate through device addresses and find a new way to do it, I have to wonder if during commissioning you could create your hard-coded table of user constants in an array. Copy the values from your array to your LADDR before calling, and it will capture your value properly. Instead of reading directly, you have to do an address lookup and pass that to the LADDR param input. Maybe that will solve the problem. I have not tried creating an array user constant. If it does not work (it probably will not), you can create it in a DB that is basically used as a read-only DB with the array of HW_ID's you need, indexed as you would address them. SO, it might look like this: db definition: MyHWID.Address : array [ 40..83 ] of HW_ID, with start value for the first element (40) is the HW_ID of 40. Now you can loop through each device. I can see this as a major pain to maintain, but it would work similar to your old scheme. I think the device or module states and/or LED status would work better. What you really want is to discover and loop through all hardware in your project, or accessible from your PLC. Maybe Siemens has a simple method and sample project they can send you. Try Support Request?
	science guy
Suggestion To thank Quote Answer

|

Share this page:

Share this page on...

Follow us on