Function block ImplicitRead

0x7000 for Siemens blocks usually means the block is "ready" and not busy.

Check page 34 for the details for status 0x8702.

My guess - without seeing the data record request details - is the data is not available, or the values provided are not valid or correct for the data being requested.

Do any of the PN record requests work, or just this one?  Try reading simple stuff, like PN name or PN IP.

There is also the assumption you are using an S7-1500 PLC - at least per the provided documentation for that Entry ID.

Did you follow the project example code to make sure you can do verify similar requests to the example project?

Does ConnectionEstablished output turn on after enabling the block?

smcuser

Hello,

I'm looking for clarification on how to decode Output values from the Function block ImplicitRead.

The FB performs implict read requests for Profinet records, see Siemens entry ID: 109810980

The 1st Output of interest is called 'Status'.

It's shown as 'No1' in the attachment

In my case it's returning a value of 0x7000

The FB documentation doesn't mention how to decode values at this Output.

The 2nd Output of interest is called 'Diagnostics -> subFunctionStatus'

It's shown as 'No2' in the attachment

In my case 'Diagnostics' is returning a value of

'Diagnostics -> Status': 0x8702

'Diagnostics -> subFunctionStatus': 0x00B0 80DE

The FB documentation makes no mention on how to decode this value when 'Status' = 0x8702

Anyone got an idea on how I could find out what these values mean?  (other than submitting a support request)

Look in page 8 of the library's PDF.  It shows what instructions are being called - and presumably the diagnostics (status) data is passed up to the library block's and then tweaked and moved to the block diag outputs.

TU* blocks (and many other Siemens comms instructions) have a fairly common set of status codes for routine situations.

Check TCON instructions for STATUS values for example:

0x7000 = No job active
0x7001 = Starting to establish connection
0x7002 = Establishing connection 

Page 21 tells you where the 2 diag status outputs gather their values and how to use them.

Once a connection is established, the 0x7000..0x7002 then mean there is or is not a send or receive currently happening - depending on what internal state the implicitread block has made it to.

For example, the flow chart on page 10 describes the internal state so you can better interpret the diagnostics data at the 2 outputs.  Collectively, you can infer the reason for a given set of diag values.

smcuser

 Yes, FB is fully functional when known Index values are specified.

It's been tried with 2 different IO-Devices.

In this case a customer application is accessing an invalid index ()  eventually resulting in device lock-up.

I've replicated the setup and everything works OK (sure, error codes are returned but  everything remains working).

So the RD access is probably not the culprit although somehow it's involved.

Yes, it's a S7-1500 PLC.

Could you point me in the direction of the documentation for the 0x7000 value? 

I assumed this FB Status value (2 bytes) was in some way related to the 'Parameter STATUS (S7-1200, S7-1500)' value which has 4 bytes.

What index value are they attempting to read?  I ask because some years ago I posted a rather lengthy list of PN index values available for reading in these forums.  I have that info saved in a document on my PC desktop for ready reference - for when I need to research a given piece of data, or to know whether it is possible to get it using this method.

smcuser

 Yes, FB is fully functional when known Index values are specified.

It's been tried with 2 different IO-Devices.

In this case a customer application is accessing an invalid index ()  eventually resulting in device lock-up.

I've replicated the setup and everything works OK (sure, error codes are returned but  everything remains working).

So the RD access is probably not the culprit although somehow it's involved.

Yes, it's a S7-1500 PLC.

Could you point me in the direction of the documentation for the 0x7000 value? 

I assumed this FB Status value (2 bytes) was in some way related to the 'Parameter STATUS (S7-1200, S7-1500)' value which has 4 bytes.

Searching this specific Siemens document: S7 System Standard Functions S7-300/400 
page 151 shows 80DE (part of subFunctionStatus) which states: 80D5 The data record is static. [Restriction]only with SFC 55 "WR_PARM" 

It sounds like the record attempting to be read is only available for writing - if I am interpreting the PDF correctly.  In other words, that particular INDEX IS WRITE-ONLY.

smcuser

...

I'm looking for clarification on how to decode Output values from the Function block ImplicitRead.

The FB performs implict read requests for Profinet records, see Siemens entry ID: 109810980

...

'Diagnostics -> Status': 0x8702

'Diagnostics -> subFunctionStatus': 0x00B0 80DE

The FB documentation makes no mention on how to decode this value when 'Status' = 0x8702
...

You may need to get details from each vendor for what data is available at index 16#8001.  If no data is available, do not waste PLC time trying to read or use it.

If the request returns data successfully, it should tell you the size of the data.  If it returns a length less than 16#008F, do not attempt to read and use data beyond the length returned.

My RDREC LIST

16#8001 LEN=4176 Actual configuration at subslot level

smcuser

Thanks 0_Einstein, that's useful information 

The application consists of multiple IO-Devices from multiple manufacturers

The PLC program is accessing subslot 0x8001, Index 0x8F.

It could be this Index is supported by another manufacturers IO-Device on the same network and the program is checking certain devices for something (i.e. RD operation)

There's no information available on what/how the program is constructed or what it's trying to do 

When it comes to the IO-Device being investigated, the IO-Controller knows it is accessing an invalid index (the PNIO spec permits it and the wireshark trace backs this up).

The IO-Device response is correct and continues functional operation.

At some point after many, many RD requests it is assumed the IO-Device is busy doing something else and does not respond to the IO-Controller (within an expected timeframe?). This seems to be the point at which things go wrong.

The customer has agreed to modify the PLC program to check for an invalid Index and act accordingly. Hopefully this will solve the issue but not explain why.