5/11/2016 3:51 PM | |
Posts: 24 Rating: (0) |
attached Pic 02 |
5/11/2016 3:52 PM | |
Posts: 24 Rating: (0) |
Attached Pic 03 |
5/12/2016 11:26 AM | |
Posts: 24 Rating: (0) |
And this is the Error Code what i missed? |
5/14/2016 11:19 AM | |
Posts: 24 Rating: (0) |
any one have an idea, i am still stuck. |
5/15/2016 12:39 AM | |
Joined: 9/27/2006 Last visit: 10/17/2024 Posts: 12289 Rating: (2687) |
Hello Electro Master; As you stated, the error you show points to an Area length with the destination and source DB. Now, comparing your screenshots 02 (data mapping of the slave) and 03 (details of your DB_Unilsab_2), there seems to be an array of 16 bytes inserted in the structure of the DB, between PKW4 and the Suction Pressure value. This array is not part of the data mapping of the slave; what did you plan to do with it, what data would it serve to exchange? That would modify the size and structure of the DB considerably and would make reading 84 bytes not consistent with the data you are trying to read. That could be a source for this error. Whenever I used source and destination DBs for sFC15 and SFC 14, our habit was to use two distinct DBs (different names and numbers) to make sure that we never overlapped the data sent to the slave and read from the slave. But before this is corrected, you could try to access the data from the Unilsab slave directly, without using SFC15 and SFC14. You need these only if you want multiple values transferred to/from a Profibus-DP slave in a single telegram, as a consistent whole. It is not always required to do so. What I propose is that you disable the call of SFC 15 and SFC 14 (create an Always_false Boolean signal in OB100, and evaluate it so the rung calling the SFCs never becomes true). see the following discussion for example: Always On or OFF bit https://support.industry.siemens.com/tf/ww/en/posts/79179/ Then copy the values at PIW 912, PIW 914... to unused Mwords in your program, such as MW100, MW102; place these in a monitor table and see if there is data to be read from the slave and if there are no diagnostic LEDs active. If this works, then your problem is in the structure of the DB you use for data transfer, as surmised earlier. Hope this helps, Daniel Chartier |
Last edited by: dchartier at: 5/15/2016 12:47:25 AM |
|
5/15/2016 2:46 PM | |
Posts: 24 Rating: (0) |
this Attached 10 |
5/15/2016 3:12 PM | |
Posts: 24 Rating: (0) |
and this is the watch table |
5/15/2016 3:30 PM | |
Joined: 9/27/2006 Last visit: 10/17/2024 Posts: 12289 Rating: (2687) |
Hello Electro Master; The good news is that you have access to the slave's configured communications registers through direct peripheral addressing. So there really should be no impediment in using DPRD_DAT and DPWR_DAT with this CPU. One thing always gnaws at my memory everytime I use a S7-300 with TIA Portal. It seems that the S7-300 is not at ease with the TIA Portal definition of optimized DBs, there have been cases where this has caused problems. I find it hard now to locate specific information on the subject for the S7-300 right now, but there is the following paragraoh from the following document: Configuration of standard telegrams in TIA Portal Is it possible for you to do a quick test, reconfiguring your DB_Unisab_2 with absolute datablock access, and try your SFCs once more? Report back on the results. Hope this helps, Daniel Chartier |
Follow us on