TIA portal - modbus RTU intermitent fault

rQx

Lifetime Supporting Member
Join Date
Oct 2010
Location
Trelleborg
Posts
1,051
Hi!

I communicate with an onboard communications board modbus RTU. I communicate with 5 VFDs (Parker AC10) and each has 4 calls of MB_Master. So 20 in total.

Everything is working fine with no error for 99% of the time, but sometimes I get a errorStatus 80C8 on the MB_master block wich indicates "slave timeout".

I get this error on ONE of my 4 blocks for the slave and then it just keep running the sequence and next time it is OK again. It can run for a couple of hours and then it triggers on another VFD and another block. It seems random to me.

I guess that maybe the comm gets corrupted somehow and respond with an error, is there anything I can set to make this "better". Or has anyone encountered smiliar findings?

I have terminated both ends with 120Ohm resistor

/Tim
 
Hi Tim,
It sounds like you could have some noise on the communication line. I would try dropping the speed of the network to see if the communications improve. If you are running 19200 baud then drop to 9600 baud.
Regards,
 
Hi Tim,
It sounds like you could have some noise on the communication line. I would try dropping the speed of the network to see if the communications improve. If you are running 19200 baud then drop to 9600 baud.
Regards,

Thanks for the suggestion! We are running 9600 now, when Im on site again I can try a lower setting
 
How you enable next query?


There should be only one query at time. 9600baud should not be problem
120ohms resistors on both side of wiring?
 
The comm manual for Siemens ET200SP CM PtP says error 80C8 is "the slave does not respond within the set time". The associated suggestions are to check the data transfer speed, parity, and the wiring of the slave.

I think the suggestions miss the point. It's somewhat speculative because I only have a Siemens manual an no Siemens experience, but I do have other Modbus experience and other Modbus masters 'time-out' when the slave does not respond because there's a time-out setting. If a complete and valid message has not been received by the end of the designated time period, the master 'times-out'. I think this a more likely cause than than parity or wiring. If the slave never responded, then yes, check the parity, wiring and baud rate, but in this case those factors must be correct because this is an intermittent, occasional error, not a dead slave than never responds.

Modbus is NOT deterministic. If a slave's micro gets tied up doing whatever, it's likely to do the Modbus thing last, because it's just a comm option added way after the main functions were coded. It is not at all unusual for one slave device to be slower than another in replying.

Yes, you can play around with the baud rate, but given how a time-out error is normally generated by other (most, if not all) Modbus masters, I think the better bet is to find the setting that tells the master how it waits for a slave to reply and to increase that value slightly. Then track the incidence of errors at the extended 'time-out' period to see if and how much it improves.
 
How you enable next query?


There should be only one query at time. 9600baud should not be problem
120ohms resistors on both side of wiring?

I have a signal at REQ (contantly, the manual says I can use LEVEL signal)
when I get done or error from that block it moves on to the next block.

Yes, 120ohm resistor externally on the VFD side and internally in the CB1241 module on my s7-1200.
 
The comm manual for Siemens ET200SP CM PtP says error 80C8 is "the slave does not respond within the set time". The associated suggestions are to check the data transfer speed, parity, and the wiring of the slave.

I think the suggestions miss the point. It's somewhat speculative because I only have a Siemens manual an no Siemens experience, but I do have other Modbus experience and other Modbus masters 'time-out' when the slave does not respond because there's a time-out setting. If a complete and valid message has not been received by the end of the designated time period, the master 'times-out'. I think this a more likely cause than than parity or wiring. If the slave never responded, then yes, check the parity, wiring and baud rate, but in this case those factors must be correct because this is an intermittent, occasional error, not a dead slave than never responds.

Modbus is NOT deterministic. If a slave's micro gets tied up doing whatever, it's likely to do the Modbus thing last, because it's just a comm option added way after the main functions were coded. It is not at all unusual for one slave device to be slower than another in replying.

Yes, you can play around with the baud rate, but given how a time-out error is normally generated by other (most, if not all) Modbus masters, I think the better bet is to find the setting that tells the master how it waits for a slave to reply and to increase that value slightly. Then track the incidence of errors at the extended 'time-out' period to see if and how much it improves.

I'll check where I can change that value and try. Thanks!
 
Ok so I have implemented some timers to see how long the fault is active etc. I have implemented it on one of the 20 MB_Master block so still waiting for a fault. But I have some more information:

A normal response to a block from REQ to DONE is 35ms, some block have 25 read register so I guess this takes longer so I think about 1 second it takes to go through all blocks.

I have seen the VFD trip that is active from 271ms to 1,5seconds. But I haven't been able to see how long it takes for the actual block to get ERROR but it seems to take less then the 1000ms timeout, at least sometimes.

However I have encountered another fault, "data length to long". It seems very strange, this block is communicating whole the time and getting DONE signal. Can the whole "send message" or " the recieved data get corrupted somehow?

Should I add time between the MB_Master REQ signals?

/Tim
 
Last edited:
Ok, so now I have some more time values.

One MB_master got ERROR after 187ms and another got 1sec and 65ms. So it's not just a internal timeout it seems.
 
Should I add time between the MB_Master REQ signals?

/Tim


It is at least good practise, since you can have collision on data otherwise.
Send next query only when query before have Done or Error signal.


For jamming if done or error bit is not setted for some reason, you can reset all querys if nothing is sended like 5 or 10second interval.
 
Last edited:
It is at least good practise, since you can have collision on data otherwise.
Send next query only when query before have Done or Error signal.


For jamming if done or error bit is setted, you can reset all querys if nothing is sended like 5 or 10second interval.

Yes, that is what I do. Wait for DONE or ERROR signal and then move on. I wonder if I should have more time after this so be 100% sure the previous block is inactive.
 

Similar Topics

Hello gentlemen, Im working on a small project on TIA Portal, about establishing a Modbus TCP connection between my ET200SP plc and a socomec...
Replies
11
Views
244
Hi! Science we don’t get any ready-to-go modbus functions from my Siemens I wanted to ask you TIA users: In your experience, what’s the best...
Replies
5
Views
2,338
I'm trying to communicate with a heating controller over Modbus RTU (RS485) but I'm running into the common issue of having no Rx light. S7-1200...
Replies
8
Views
3,981
I have a system with an ET200SP controlling a Profinet network already pre-established. Am I correct in that I can add a Modbus TCP/IP node and...
Replies
2
Views
1,880
I am beatin gmy head against the wall trying to get my modbus comms working. I have a s7-1200 running tia v14, a cm-1241 comm card. I have...
Replies
22
Views
7,384
Back
Top Bottom