7/19/2016 9:57 AM | |
Joined: 7/9/2015 Last visit: 4/18/2024 Posts: 3807 Rating: (554) |
Hi Toombs, you are right. I think, that the following OBs must be called: 83, 85, 86, 122. Perhaps you find a solution in the following FAQ - it contains a pdf named "I-Device in a standard enivorment". Configuration and application of PROFINET I-Device functionRegards, Towome |
|
|
7/19/2016 10:05 AM | |
Posts: 84 Rating: (8) |
Hi, In addition you can use DeviceStates function to get status information of your I-DEVICE. Regards |
7/19/2016 6:12 PM | |
Posts: 91 Rating: (4) |
Here is the answer to this question as well: https://support.industry.siemens.com/cs/mdm/49948856?c=72231594891&lc=en-US |
7/20/2016 12:35 AM | |
Posts: 91 Rating: (4) |
The Profinet manual isn't as clear as the Step 7 V13 Professional manual. It says for S7-300, 400 and 1500 - when you have an IO Controller and the I-device goes to stop mode, in the IO controller you will get: Error code in RET_VAL at updating of the process image with the instruction UPDAT_PI or UPDAT_PO. OB 122 is called in the case of direct access to the transfer areas to the I-device (OB122 is optional for S7-1500). I'm using an S7-1500. So it the best method for catching a problem with the i-device to change to unoptimized blocks and do peripheral addressing to initiate the OB122 if there is a problem? That seems to be the only way I could get it to call OB122. Doing optimized addressing and updating the transfer area via the process image table does not result in OB122. The other way I guess is to update the process image table every time I write or read from the i-device? Is that a recommended method? Seems like a costly burden to the processor -- I'd rather have the operating system handle the updating of the process image table. Is there any other way to detect a problem with updating the process image table? It doesn't seem to call any OB though it does know there is an issue. I could also look at the diagnostic LED status of the IO Controller and figure out there is a problem, then check the status of the i-device and see if that happens to be the problem. Seems a roundabout way of doing it. Any suggestions? EDIT: Actually I am mistaken. There is no reason to use unoptimized blocks -- peripheral addressing is enough. That will work for me. I was under the mistaken impression that to do direct access you had to be inside an unoptimized function block. |
Last edited by: Toombs at: 7/20/2016 12:38:38 AM |
|
7/20/2016 3:42 PM | |
Joined: 7/7/2010 Last visit: 4/17/2024 Posts: 14593 Rating: (2347)
|
If it were me, I would set a toggle bit in the remote I-device and toggle it at a rate sufficient for monitoring remotely via profinet and not so slow as to not be responsive enough for your process. Then on the master controller, if the bit is stagnant for more than a reasonable amount of time, you have lost communications. This is simple, works on virtually every platform, and does not require a certain special technique that depends on which PLC you are using on each end.
|
science guy |
|
Follow us on