Advice needed

[salorob]

Hi There,

I've got an issue while using SerialPortStream 2.1.2.0, while running dotnet core on Debian (raspberry) 4.14.34-v7+.

I have a application that uses Modbus over UART to query and control some external Modbus devices. It communicates at 19200.

Once every so many days, my responses gets shifted. So; my Modbus request receives a response, but not the one I am expecting. e.g.:

` 2018-11-20T15:09:25.7146782+01:00 [INF] >> 02-03-03-F0-00-01-84-4E (db52bf6a)

2018-11-20T15:09:25.8039295+01:00 [INF] << 00-01-29-FA-03-06-00 (464e81f2) 2018-11-20T15:09:26.2623344+01:00 [INF] >> 03-03-03-F0-00-01-85-9F (eb1f1fcf) 2018-11-20T15:09:26.3486745+01:00 [INF] << 0E-00-01-28-2B-01-03 (cac91b55) 2018-11-20T15:09:26.8100711+01:00 [INF] >> 01-06-00-0E-00-01-29-C9 (5341f43a) 2018-11-20T15:09:26.9065283+01:00 [INF] << 10-38-34-44-84-2E-85-44 (1c3e55a3) 2018-11-20T15:09:27.3696394+01:00 [INF] >> 02-06-00-0E-00-01-29-FA (7ef9716a) 2018-11-20T15:09:27.4563347+01:00 [INF] << 84-46-F0-44-84-13-DC-4C (afec2486) 2018-11-20T15:09:27.9191753+01:00 [INF] >> 03-06-00-0E-00-01-28-2B (d3c1e7b1) 2018-11-20T15:09:28.0066593+01:00 [INF] << F4-CD-8A-02-03-10-8E-88 (f00f6d7a)`

Now; I've tried a few things already:

• Discarding buffer (in and out) before every request
• Flushing the port on every CRC error (my detection of being out-of-sync)
• Lowering speeds
• Temporary closing and re-opening the serial port

Nothing solves the problem of the shifted response traffic. What will help is, if I make my application close the serial port, and I issue a mbpoll command on the linux commandline like so:

mbpoll -m rtu -a 1 -r 1 -c 12 -t 3 /dev/extcomm/0/0 -b 19200 -P none

strangely enough, mbpoll will give me a correct response immediately:

user@device$ mbpoll -m rtu -a 1 -r 1 -c 12 -t 3 /dev/extcomm/0/0 -b 19200 -P none
mbpoll 1.4 - FieldTalk(tm) Modbus(R) Master Simulator
Copyright © 2015-2018 Pascal JEAN, https://github.com/epsilonrt/mbpoll
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions; type 'mbpoll -w' for details.

Protocol configuration: Modbus RTU
Slave configuration...: address = [1]
                        start reference = 1, count = 12
Communication.........: /dev/extcomm/0/0,      19200-8N1 
                        t/o 1.00 s, poll rate 1000 ms
Data type.............: 16-bit register, input register table

-- Polling slave 1... Ctrl-C to stop)
[1]:    1
[2]:    3
[3]:    0
[4]:    0
[5]:    4096
[6]:    4096
[7]:    14701
[8]:    17540
[9]:    12204
[10]:   17540
[11]:   18428
[12]:   17540

More strangely though; when enabling the serial port communication in my own application again (remember; my application has not stopped running, only closed the serial port) my application will get the correct responses again too. All fine!

SO; my question would be; is there something you can think of I can do; to make my response traffic step in line again?

[jcurl]

I'm not familiar with the modbus protocol at all, and cannot see with this problem report how it relates to the SerialPortStream library.

There is a bug in 2.1.2 that is fixed in v2.x HEAD (since only a few days) where a write (depending on the Tx buffer size) might be truncated. You could recompile the .NET library and try again.

You could use a serial port sniffer to analyse the protocol at a byte level, as well as to see how the mbpoll utility is able to recover the sequence even if closing/opening the serial port works.

[salorob]

It might not have anything to do with SerialPortStream. However; it's the only thing in between my application and the linux serial port. I was hoping it might ring a bell.

Well, the mentioned bug is about a Write from dotnet TO a serial device I suppose, not about receiving data from the serial device?

[jcurl]

The bug is about a Write being truncated. That could be enough to kill a protocol that responses are delayed by one (similar to what you describe). However, this is all guessing as I don't know anything about modbus. Only analysing at the protocol level in both directions with timing information from someone who is very familiar with modbus could help.

[jcurl]

Hello, have you been able to retest with the latest commit?

[salorob]

Not just yet. But also I though about it: Modbus is a Request / Answer protocol.

I cant see how a incorrect REQUEST could trigger an incorrect RESPONSE, as the request needs to be (and is validated by CRC) 100% valid, before any RESPONSE occurs.

Groet,

Robert Salomons

Van: Jason Curl notifications@github.com Beantwoorden - Aan: jcurl/SerialPortStream reply@reply.github.com Datum: vrijdag 23 november 2018 om 09:14 Aan: jcurl/SerialPortStream SerialPortStream@noreply.github.com CC: Robert Salomons r.salomons@ropesolutions.nl, Author author@noreply.github.com Onderwerp: Re: [jcurl/SerialPortStream] Advice needed (#79)

Hello, have you been able to retest with the latest commit?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/jcurl/SerialPortStream/issues/79#issuecomment-441176294, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ADulFZ4Go8sxtTj4GS_VtCdTOlY2PdTKks5ux65SgaJpZM4YrRlm.

[jcurl]

There's no indication at this time there is a bug in the SerialPortStream, I'm going to close. If after your analysis you determine something is wrong, please reopen. Have a nice day.