Hello

There is a CP341 working with protocol RTU in our system. it has been working for several years.

Recently,it works for a while and then hangs. For putting it to work we disconnect the power of the module and reconnect it again. The problem goes away for some days and comeback again.

Observations while the problem exists:

- Both RX and TX LEDs are off all the time(When SEND request is activated)

- There are errors in diag.buffer:

      - master: timeout waiting for response frame

      - slave:broadcasting is not permitted with this function

      - processing error of loadable driver

Thanks for your help

Hello,

with this infos it's clear that receive frame doesn't reach Master, Slave doesn't answer. Question can be what type of Code Message is initiated with Slave address 0 - broadcasting. Look to code if some of your mentioned errors not exists on code, like that broadcasting. Also if posssible, connect to your automation some MB simulator SW and check functionality. In case that all Works ok, but for some time, probably I don't think about some line/wire problems, but you can also check this for sure.

1) Lack of Fail-safe biasing

A periodic fault (every so many hours/days) like this can occur if there is no RS-485 failsafe biasing.

I don't know if Siemens modules are fail-safe biased or not, because I'm a Modbus guy, not a Siemens guy.

The section on fail-safe biasing on pages 8 and 9 of the National Semiconductor AN-1057 app note, "10 Ways to Bullet Proof RS-485 Interfaces" has a decent explanation.

Google or download it here:  10 Ways to Bullet Proof RS-485 Interfaces

2)  Intermittent, excessive common mode

Intermittent ground loops, if beyond the common mode limits of the RS-485 drivers can saturate the drivers and fault the 485 network.  

The practical solution is to put an RS-485 isolator in the network, as opposed to trying to find the source of the common mode and trying to eliminate it.   I have had to put in two isolators on multidrop networks, one at the master, another half way down the network, in order to eliminate enough common mode to keep the network running.

3)  Multiple slaves, one slave's driver is flakey

A slave's driver that fails active can lockup the entire network.  Sometimes cycling power will restore the slave's driver temporarily, but eventually it fails.  The effort is in finding which slave has the bad driver.   Logs showing faults like time-outs can be used to see who was the last slave before the time-out happened.

Hi

Thank you Duris_I,Kaulquappe and danw

Dear Kaulquappe the error code is: F1C8:0E60

Dear danw, the cause of problem might be what you have mentioned.Last time the problem occurred the user of the system reported that the problem begins with one of slaves and then the whole network fails.I told them to isolate that node and the run the network again. Till now there was no fail in system and then i saw your note.

What do you mean by "Driver fail" of slave? hardware wise or software wise?