Odd Profinet Problem (data corruption?)

[FONT=&quot]Hi all. Fridays a bad day to start anything but here goes. I have an odd problem with a profinet network. All the devices are configured and operating correctly as far as I can take them at this moment in time. We have several 3rd party devices and they appear to be operating correctly also, the plc is happy that they exist, can exchange data etc. Recently I found when checking that some of the data is corrupted when it appears in the plc. I found this because the 3rd party devices use a webserver so you can view the pre-transport data to check it against what you receive. According to the device manual the pre-transport data is what I expect (status bits match device leds, readouts etc), but as soon as the plc gets it, the values are wrong. I will point out that they are not all wrong. The 3rd party device is an anybus abcc-prt from hms controls. When I talked to the vendor of the 3rd party device he said if the webserver shows the correct data then his side is working correctly i.e modbus to the daughter board. If I talk to siemens or hms they say if the plc recognises the device and talks to it then whats the problem. Im struggling to work out which direction to point my finger in.

I have a crude picture of the network arrangement as follows



[/FONT] The devices highlighted in red show the relative position of those devices in the network. The cables to those (and the scalance) are routed far away from the noisy ac side of the panel. The plc is an s7300 cpu315-2pn/dp configured using the step7 v5.5 sp2 and the gsd is obviously correct or the device wouldn't get past the handshaking part of the profinet bootstrapping mechanism.

Hopefully someone will look at this and say "OH NO, you cant wire x,y,z like that", who knows. If anyone can help me figure out where to start looking for this then I would be greatful.

Thanks in advance.

All that your diagram shows, is that you have some devices connected together.

his side is working correctly i.e modbus [?] to the daughter board [?]

Click to expand...

From your description, it seems that it is more complicated than that. You have some devices that talk Modbus (RTU or TCP ?), and then there is a Gateway somewhere or what ?

Is the problem constant or intermittent ? Does the data sometime come OK and only some bad ?
If it is a constant problem, you should investigate if it is because the bytes should be swapped in one side of the system.
State the value(s) shown in both sides, and on the S7 side I would like to see the hexadecimal representation of the value(s).

Hi Sleepy,


Are you the manufacturer of the device where the ABCC-PRT is fitted? If not, contact the manufacturer.
If yes:
I checked with our support dep (I work for HMS) and they say that it is possible that the webpage and Profinet master (PLC) will show differnet values, as it depends on how the application software is written.
For more help, contact our support department at:
http://www.anybus.com/support/support_request.shtml

//Me

It sounds like you may have a couple of Big Endian devices mixed in with all the Little Endians, or vis-versa, which may not be converted properly. In most devices this is a setup parameter.

Jesper, i agree all it shows is that i have a couple of devices connected together. I thought that somehow the topology of the network might have given me some odd issues hence why i posted the diagram incase anyone said "OH! You cant connect the devices because (insert random ethernet sideffect here)" However after i posted the question i disconnected all the devices and ran a direct line to 1 of the faulty devices with only it on the network. The result was the same so i was able to eliminate that idea. After a bit more poking around in the data that is returned i found that it is always the same so unlikely to be corrupted and after comparing the data as binary i noticed that some bytes were where i thought they should be and some werent. After a short period of investigation i found that the order of the bytes versus what i expected was this

Expected Position - Actual Position
0 - 1
1 - 2
2 - 3
3 - 0
4 - 5
5 - 4

Bytes 4 and 5 i would expect to have to reverse because the s7 plc interprets numbers differently from the 3rd party device but the first 4 bytes order i have personally never seen before. It looks like they are just randomly scrambled but the odd thing is that the 6 byte pattern repeats itself throughout the data for the device i examined and then also for the other device i mentioned that wasnt working.

Pudden, we are not the manufacturer of the device only the end user. We explained to them what was happening in a little more detail after my findings detailed above and i believe they are now convinced there is a problem and will be making a support request with you very shortly.

Very odd indeed but at least friday gave me some clarity on the issue. Just need to wait and see what happens.

Modbus comms can be configures to start at 0 or 1 could this have been changed?

Not sure. I think the problem lies in the config of the profinet adapter from hms. The same company supplied us with devicenet and profibus versions of their kit in the past and after setting up the telegrams correctly the data appeared on the bus exactly as we expected it. For this new version they did not change the "host" side of their application and only added some code to configure the profinet adapter and send the same data again. I think they have made a boob in the configuration somewhere.

Not much help, but I will go with a big / little endian issue, as Russ mentioned.

Just thought i would quickly post to poopoo this thread. After extensive investigations via hms (the supplier of the problem unit) and our 3rd party supplier of the kit they have admitted they have found a software problem at their end which is scrambling the data in a nonsensical fashion. Just how it happens they dont know yet but at least we have an admission.

If they report anything back to me that might be of use to others i will post it here later once they get to the bottom of it.

Thanks for all your time/input.