Modbus Master TCP warnings and errors - how to reset to normal state

hubc · 2017-02-04 09:49:01

Hi,

I'm using modbus tcp driver and after some time of RexCore running I receive warnings like this:

Warning	MODBUS MASTER TCP main: invalid response (ignore, TransID=0)
Warning	MODBUS MASTER TCP main: invalid response (ignore, TransID=0)
Warning	MODBUS MASTER TCP main: invalid response (ignore, TransID=19011)
Warning	MODBUS MASTER TCP main: invalid response (ignore, TransID=18176)

many of them, TransID are different numbers, and also errors about modbus items timeouted.
After that, my RexCore device is not reading from modbus slaves and to fix that all I have to do is to pause and restart the execution of RexCore.

First question is how is that happening - but that later.
Second question: can I somehow make my project to restart when it is starting to receive those warnings and errors? It will be a solution for me, because without modbus readings my device is unusable so I don't care if it pauses for a moment.

And getting back to the reason of my issues - I already set 'Max Request' to 1 for my slave devices in case they can't handle multiple commands, but it not changed anything.
I tried to set bigger factor for the MTM driver - didn't helped.

Some advice?

Regards
Hubert

jaroslav_sobota · 2017-02-06 10:49:46

Hi Hubert,
can you please share details about your Modbus slave (manufacturer, type)?

There are special signals in the Modbus driver, which tell you whether the slave station is responding, how many invalid messages were received etc. You can also disable all communication, which will allow your slave to recover from the ill state. See chapter 3.4 of https://www.rexcontrols.com/media/2.50. … rv_ENG.pdf for details.

Kind regards
Jaroslav

hubc · 2017-02-06 16:34:28

Hi Jaroslav,

OK thanks for that. I will try to do that, well I remember I tried that way some time ago, when I had many issues with other Modbus TCP device. But then the 'multiple commands' was the issue, and enabling and disabling communication by special signals was not working as I expected. In case I have some problems again I'll let you know.

And my Modbus slave is Victron Energy CCGX, details here:
https://www.victronenergy.com/live/ccgx:modbustcp_faq
https://www.victronenergy.com/panel-sys … or-control
https://github.com/victronenergy/venus/wiki/sales-pitch

Regards
Hubert

jaroslav_sobota · 2017-02-07 14:54:34

Hi Hubert,
thanks for the information. Do let us know about your progress, we love to hear about your (and everyone else's) projects!

Jaroslav

hubc · 2017-02-14 15:46:59

Hi Jaroslav,

you said:

jaroslav_sobota wrote:

There are special signals in the Modbus driver, which tell you whether the slave station is responding, how many invalid messages were received etc. You can also disable all communication, which will allow your slave to recover from the ill state. See chapter 3.4 of https://www.rexcontrols.com/media/2.50. … rv_ENG.pdf for details.

can you please explain how can I disable all communication?
I see I can disable reading from each item (changing '_ReadEnable' flag) but can I disable reading from slave (every signal) by one flag? Or should I disable every item individually?

Regards
Hubert

jaroslav_sobota · 2017-02-16 11:25:48

Hi Hubert,
in case of Modbus RTU (e.g. via RS485), you can use the following flags:
MBM__3 (Goto block, writable, for disabling all communication with slave device with ID=3, 1 means standard operation, 0 disables all communication)
MBM__3_Connecting (From block, readable, it tells you whether REX is trying to establish connection with device ID=3)
MBM__3_Connected (From block, readable, it tells you whether device ID=3 is alive and responding)

In case of Modbus TCP the principle is the same, you use e.g. MTM__mydevice_Connecting where "mydevice" is the name of the slave station from the Modbus configuration dialog.

Hope this helps.

Best regards
Jaroslav

hubc · 2017-02-16 19:06:01

Hi Jaroslav,

yes that helps, thanks!

I already tried disabling by 'Readable' flag, without success.
It seems that disabling it didn't helped to 'reset' my error.

I will try disabling all communication by MTM__MyDevice flag (set it to 0).

Regards
Hubert

hubc · 2017-02-21 14:04:55

Hi Jaroslav,

small update: I changed from disabling 'Readable' flag to 'MyDevice' general flag and it is working!

So when my program have problems with reading from modbus slave I can fix it by temporary disabling all Modbus communication.

But something is not entirely OK - 'ErrorTimeout' flag, when my issue happened I saw that MTM__ErrorTimeout was showing 1, and that didn't increased at all (and I saw many Timeout errors in logs). Is that normal behavior?
I was counting that it will be increasing as long as there were new errors.

Regards
Hubert

jaroslav_sobota · 2017-02-24 13:00:47

Hi Hubert,
glad I could help. If you disable all communication, the slave gets time to recover from the faulty state. However, you should investigate what brings the slave device into this faulty state.

You are right, in version 2.50.1 the __ErrorTimeout flag is not showing anything useful when using Modbus TCP. When using Modbus RTU (serial communication), it correctly shows how many times the timeout occurred. We'll improve this, thanks for your report.

However, on Modbus TCP you should be OK with the MTM__MyDevice flag. Alternatively, you can also consider using MTM__MySignal_Fresh which gives you number of seconds since the last successful read/write operation.

Kind regards,
Jaroslav

hubc · 2017-03-01 13:29:01

Hi, thanks for info.
And of course one question:
Are MTM__MyDevice input (device status) and MTM__MyDevice output (turning on/off all transmission) possible to use in one project?

I tried and see error:

Error 124: The tag 'errorchck_task.MTM__pac3200' has multiple sources

Regards
Hubert

josar · 2017-03-01 14:04:59

hubc wrote:

Are MTM__MyDevice input (device status) and MTM__MyDevice output (turning on/off all transmission) possible to use in one project?

I guess this was mentioned earlier, see /viewtopic.php?pid=1490#p1490.

BR

REXYGEN Community Forum

Announcement

REXYGEN forum has been moved. This one is closed.
Head over to the new REXYGEN Community Forum at https://forum.rexygen.com.

Looking forward to meeting you there!

#1 2017-02-04 09:49:01