Closed salorob closed 5 years ago
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.
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?
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.
Hello, have you been able to retest with the latest commit?
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.
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.
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:
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:
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?