8327 questions

9795 answers

15581 comments

13944 members

0 votes
14 views 0 comments
by

Hello, 

I have an situation written here. I still don´t have a solution. But now I open CLI and run command: "modbus_tcp_master" and now i can see this: 

root@Teltonika:~# modbus_tcp_master

Daemon starting

got ctx

got ctx

Uci init done

modbus_data table already exists

SENT_ID_TABLE already exists

Create DB done

Getting configuration for alarms

found alarm for slave device,alarm_config_name:alarm_ca08583ab875735b3cc50d820e8b0d82, section->e.name:cfg014d1e

SMS alarm (nr:[0]) config is full and enabled

slave request nr:[0] config is full and enabled

slave request nr:[1] config is full and enabled

have full slave config with 2 rules configured, can start thread

pthread_created:0

Freeing UCI structures

Checking DB size

Current entries to db count: 52 of 20000

request paramms: function=2, first_reg=2, reg_count=1, enabled=1

adding data for function 2 request

chars writen to socket[12]

Before reading - expected_response_length:10

total_bytes_read[[10]]

response->data_count:1

10 chars read: trans id:0, prot id:0, len:4, uid:10 f_code:2, data_count:1, resp0:0, resp1:0, resp2:4, resp3:0, resp4:152

Checking if the response is valid

saving response to DB

Response succcessfully writen to db

Checking alarms configuration

Found configured alarms, checking conditions

Not checking alarm conditions (not an alarm request)

closing socket

connect to socket error

Thread sleeping 30 s, before next check

Checking DB size

Current entries to db count: 53 of 20000

Could be helping for somebody who can help. I think row with: 
Checking alarms configuration
Found configured alarms, checking conditions
Not checking alarm conditions (not an alarm request)
look wierd. Why is there "not checking alarm conditions...?" 
Don´t anybody know? 
Thank you

1 Answer

0 votes
ago by
Hello,

Our RnD team is already working on this. Currently it seems that this type of behavior is caused, because our devices do not have timeout between connections to same device, while some serial devices do expect a timeout between connection.

What happens is: RUT sends request for first alarm, and almost instantly sends second one, serial device replies to first request, but discards second, because it cane in too fast after connection for first request was terminated.

Currently work is being done on continuous connection, which would mean that RUT as TCP master will not be establishing it separately for separate requests, but have it active all the time, which should solve alarms after first one not getting a response, and in turn not sending SMS.

This reworking of TCP Master and Slave communication should be done for RutOS 7.2 release, but I do not have exact time frame for that.

Best regards,
VidasKac.