PM876 profibus master sync messages present for not existing slaves
What is the reason of sync messages ("syncs will show you how many cycles the slaves were not aviable for the master") generated by non-existing slaves on profibus interface of redundant PM876 controllers? Picture below is a part of profitrace network report... does anybody know why "Some types of ABB DCS systems continuously send Sync messages. This does not influence the bus communication. These Syncs can be ignored"?

and second part of question related to profibus interface behavior... when using redundant controllers with redundant profibus A and B lines and termination unit like a TU846 CI840/CI840A. I found out that some slaves are "visible" when profibus analyzer is connected to A-line and other slaves are visible when connected to B-line of the same interface. Why is it so? Is it proper behavior? Are these the right symptoms, and what is the impact of master-slaves communication during redundancy controllers switch over.

and second part of question related to profibus interface behavior... when using redundant controllers with redundant profibus A and B lines and termination unit like a TU846 CI840/CI840A. I found out that some slaves are "visible" when profibus analyzer is connected to A-line and other slaves are visible when connected to B-line of the same interface. Why is it so? Is it proper behavior? Are these the right symptoms, and what is the impact of master-slaves communication during redundancy controllers switch over.
Answers
Hi Mike
Unfortunately, I don't have definitive answers, but I'd at least like to share my related experiences.
ad 1: I've seen similar patterns with Freelance Profibus masters. What's called sync in your software may mean a simple FDL SDA query (IIRC), basically saying "Is someone there at this address", similar to an ICMP ping. AC 800F do this in between cyclic exchanges; they tend to query a contiguous subset of the unassigned address space for unknown slaves every few cycles.
ad 2: It strongly depends on the exact Profibus configuration. We've got a setup that shows the same behaviour: Two redundant AC 800F on the same segment, which is forked using a RLM01 into an A and B line. Slaves are Turck Excom (S900 IO) connected to both lines which occupy two addresses: Active and standby. The active one is visible only on the bus line connected to the active gateway module's line and participates in cyclic exchange, the standby address is on the other line only answers when queried (e.g. by FDL request). Which one is active largely is coincidental (i.e. which GW module was plugged last). The reason for this behaviour is that on one bus only one participant may be active at any given time. If a redundancy link module received two different replies from A and B lines, it'd have a hard time deciding which one to forward.
Best regards
Björn
Unfortunately, I don't have definitive answers, but I'd at least like to share my related experiences.
ad 1: I've seen similar patterns with Freelance Profibus masters. What's called sync in your software may mean a simple FDL SDA query (IIRC), basically saying "Is someone there at this address", similar to an ICMP ping. AC 800F do this in between cyclic exchanges; they tend to query a contiguous subset of the unassigned address space for unknown slaves every few cycles.
ad 2: It strongly depends on the exact Profibus configuration. We've got a setup that shows the same behaviour: Two redundant AC 800F on the same segment, which is forked using a RLM01 into an A and B line. Slaves are Turck Excom (S900 IO) connected to both lines which occupy two addresses: Active and standby. The active one is visible only on the bus line connected to the active gateway module's line and participates in cyclic exchange, the standby address is on the other line only answers when queried (e.g. by FDL request). Which one is active largely is coincidental (i.e. which GW module was plugged last). The reason for this behaviour is that on one bus only one participant may be active at any given time. If a redundancy link module received two different replies from A and B lines, it'd have a hard time deciding which one to forward.
Best regards
Björn
Add new comment