AB7670 multi byte data integrity

Anybus Support Anybus Gateways
, ,
#1

Hi,

We’re working on setting up a AB7670 between a Siemens S7 1500 using TIA Portal, and a vision system that is presenting its data as a Ethernet/IP device.

We have communications working, but the vision system is outputting its data as DINT values (32 bit integers) and the Siemens is reading it as bytes. We appear to be getting data tearing issues when we combine the DINT values again on the PLC.

The test we ran was as follows: we output a series of 32 bit values as DINT which have 4 identical and incrementing bytes, when we get the bytes and reassemble them, the higher number bytes on the PLC occasionally are from a later DINT (as they are higher). (Put another way we output 0x01010101, then 0x02020202, then 0x03030303, and occasionally received 0x02020303, for example).

How can we get synchronized multibyte data through this gateway?

Thanks.

#2

It sounds like there may be an offset of one register, so you are overlapping the next. Try changing the starting register from 0 to 1, or 1 to 0, for example.

#3

I’m pretty sure we are in sync from a bytewise alignment perspective (if i understand you correctly).

Additionally, when we run this test the next DINT (32 bit) over gets a repeated byte value which is 3 values higher (so 0x31313131 to 0x34343434, for example) or 3 values lower (depending on direction) than the one with 4 bytes that have unmatched values. The unmatched byte values are only off by one (so like 0x30313131 in the example above).

#5

I can tell you this, whatever you write to registers in the gateway on one network is what you are going to read from those registers on the other network, or vice versa. The gateway is not changing the data. You may need to do byte swapping for them to align or offset the registers by a byte.

Can you take a screenshot of the diagnostic page where it shows the in and out data as well as the values you are sending and receiving? Also, can you send a copy of the Anybus config file?

#6

Are you filling up the full DINT every time? Is there any way to test with data that is 0x01010202 0x03030404 To see what part of the float is wrong?

#7

Hi,

Yes the full DINT is filled by the vision system each time.

We actually found something fairly interesting though. We changed the Ethernet/IP data rate on the Anybus from 5ms to 10ms (the data sizes are 496 bytes in and 496 bytes out) and this corruption seems to have gone away. What was being seen within 15-30 seconds (at 5ms) instead was not seen overnight (at 10ms).

Is there internal synchronization of the data between the input and output sides on the AB7670 to guarantee that the entire data structure has been updated before it is sent out? Or is there any way that data could be output mid copy? Is 5msec too fast for what is going on in there?

Any other thoughts?

Jay

#8

Yes, 5 ms is too fast. The cyclic data exchange rate is 10 ms.

#10

Hi,

So we set the test setup described above to 10ms, and then left it going for the weekend, but it still eventually detected an incorrect multiple byte value being passed to the profinet side. I’d assume that it was several days into the test when this happened.

What’s the best thing to do next to help diagnose this? I’m assuming that a wireshark trace containing both sides of the anybus traffic when this happens would be helpful. It would at least help confirm the anybus is the issue.

Jay

#11

If you can get pcaps with Wireshark that will definitely help. Maybe try with different speeds. I am going to escalate this case to see if anyone has any other ideas.

#12

Hi @jstavnitzky,

Here is the response that I got from Kris at the Anybus team:

"The GW copies all the data at once to/from the internal DP Ram between the two interfaces.

Have you set to a matching write/reading interval on both sides?

Have you tried to use Consistency in the Siemens config?"

Are you familiar with this Consistency setting in the Siemens configuration? Do you know if it’s enabled or not?

Kyle

#13

The profinet device side doesn’t appear to have any interval that one can set on the anybus. Is there a PLC setting that needs to be set? We do have the ethernet/IP scanner side set to 10ms each way (on the scan list setup web page).

We are using the SCF14 and SFC15 commands to do the read if that is what you mean by consistency settings (we got that from the pdf “How to configure an Anybus PROFINET IO Slave module with a Siemens Step7 PLC “ directions on your site). Is there more that needs to be done to get that functioning?

Jay

#14

Here is how we have the Siemens setup and functioning.

PLC Hardware Setup:

image001.png
image001.png703×120 7.48 KB

Block Call: #VisionDInt is Array (0…127) of DInt

image002.png
image002.png692×234 4.96 KB

#15

Hi,

So attached is a wireshark trace of the corrupt multiple data occurring at packet #209 (byte 97-100) on the profinet side. They are values 0x57,57,58,58 while the packet that was last sent to the ethernet/IP side shows those bytes as 0x58,58,58,58. In fact, it looks like the anybus data copy has “stalled” at byte 99 (it appears to start the copy at the highest byte and works down), with bytes 98 and below being left with stale ethernet/IP values for a while.

wireshark-57575858-event.pcapng (213.4 KB)

Thoughts?
Jay

#16

I’m looking at the pcap now. Here is an article which talks about data consistency:

#17

Hi Jay,

We did find a couple questionable things in the pcap, but need to investigate a little further. For example, the values change once on the CIP side, but twice on the PNIO side. Also, not sure why it’s showing 517 bytes of data instead of 512. Can you create another pcap of when the PNIO connection is opened?

Have you tried 20 ms instead of 10 ms? Do you have the same issue then?

What about with different data sizes?

Kyle

#18

That log is of a 5ms scan time, but has the same failure is seen at 10msec, just a lot less frequently. I haven’t automated the data capture yet so that I can leave it going with longer scan rates.

The fact that data is corrupt ever is a problem.

I can get a connection pcap on the PNIO side when I am back in the office, otherwise I can send you a copy of the PLC code and you could look into duplicating that there. The PNIO PLC seems to be getting the data irrespective of whether it is saying 512/517. We are actually only using 496bytes of that as it is the ENIP limit.

Jay

#19

OK, If you can provide the code we can try to duplicate it. I know my colleague wanted to see what would happen if you remove the use of DPRD_DAT, and rather Move data from IB0 … IB512 to see if you still get any inconsistency.

#20

Hi,

We initially were using a PEEK instruction and when that didn’t have consistent data we went to the DPRD_DAT (which is what we are testing with now).

Attached is the TIA Portal V16 test application.

Jay

VIsionAnybusTesting_20200813_1307.zap16 (775 KB)

#21

Hi, any updates on this? We have 8 gateways that we hope to use shortly on the system here, but need to be able to trust the data going through them. Is there anything that you are waiting on from me at this point?

Thanks,
Jay

#22

I have escalated this case and the developers are working on it. I apologize for the inconvenience and I hope to have a fix soon. When did you need to have this resolved for your project to be successful? I can pass that info on to them as well.