Modbus-serial buffered mode throws exception instead of data about node-modbus-serial HOT 8 CLOSED

Great !
a. can you make a pull request ?
b. can you add this case to the tests ?

from node-modbus-serial.

Hello Yaacov,

before I pull ... and excuse me that I am asking ... I want to understand the current code and what was the initial intention about it in order not destroy your "basic thinking" with my code.

In the buffer examining loop I see the code line
if (unitId !== self._id) continue;
So it loops until it finds the unitid as initial char in the load of the RX buffer ... am I correct that you intended to create a kind of synchronization of where a modbus receive telegram starts in the current load of the RX buffer? Please confirm.

Cause if answer is yes I do have doubts that this will work, cause in my life example you see that also modbus data itself can have the same combo set of unitid and function code. So with this method you will never detect a start of frame securely. Do you agree?

Also I recognized that you are checking for the length of an exception message ... you check for (0x80 | self.cmd) ... this is fine for me ... but don't you agree that the examination of just the unitid and function code | 0x80 you can never be 100% sure that is a real exception message without having also the checksum checked at this point?

from node-modbus-serial.

Hello Yaacov,

i have another dumb question.

Let us suppose I have a "bad working" Modbus RTU slave online that responds instead of an exception or a valid frame with endless chars like e.g. "aaaaaaaa....." forever and forever ... or frames that are anything else than Modbus RTU frames ... in this case the reception "self._buffer" will grow and grow and finally would generate if you wait long enough a "out of memory" error. Do you agree?

So we need also a mechanism to "throw" away frames that are no modbus frames. Do you agree?

from node-modbus-serial.

hi,

a. Yes, we need to deal with modbus frames that start not at the beginning of buffer.
b. Out of memory is something important to fix, maybe in a different pull request ?
c. Make the best you can do, if the tests work, it will be ok, if it start break things that we miss in the test, we will fix it again.

p.s.
Their is always a trade-off between something that we can do and works good, and something that is perfect, but we do not have time to do ... :-)

from node-modbus-serial.

Hi, I finished development but before I am pulling it I want to test it with the test environment

This is why I have extended the rtubufferedport.test.js file locally with my life example above.

But when I start it with "node rtubufferedport.test.js" it runs and exits without any feedback. How do I start this test correctly?

from node-modbus-serial.

run (from root of prject)
npm test

from node-modbus-serial.

p.s.
a. when you do a pull request, tests are run automatically.
b. other people can see what you are doing and comment about it.

from node-modbus-serial.

fixed by #60 and #59

from node-modbus-serial.