Question about Request-Response issue

[abuech2s]

Hi there,

My aim is to connect via rs232 a control cabinet from an engine of a ferry. The software part was implemented by a java service and jSerialComm library.
To get data from this control cabinet there must be a request defined by the following 8 bytes:

byte[] SEND_DATA = new byte[]{(byte) 0x01, (byte) 0x03, (byte) 0x00, (byte) 0x35, (byte) 0x00, (byte) 0x01, (byte) 0x94, (byte) 0x04};

The response is always of length 7 and has the following structure 01 03 02 XX XX YY YY with XX XX = numeric value and YY YY as a CRC.

Before I have implemented my service I have tested the connection via a standard Serial-Tool. As you can see the request is defined by 8 bytes, the response contains 7 bytes.:

Here are the technical parameters for this connection:

Now, in Java:

My instantiation of the serialPort is done by:

 SerialPort[] serialPorts = SerialPort.getCommPorts();
if  (serialPorts.length == 0) {
   Thread.sleep(5000);
  throw new NoPortException("No ports are found");
}

log.info("Found {} ports:", serialPorts.length);
serialPort = serialPorts[0]; // There should be always just one port -> So take [0]

log.info("Open port: {}", serialPort.getSystemPortName());
serialPort.setComPortParameters(9600, 8, 1, SerialPort.NO_PARITY);
serialPort.openPort();
serialPort.setComPortTimeouts(SerialPort.TIMEOUT_READ_BLOCKING, 50, 0);

and the trigger loop looks like:

while (true) {
  byte[] bytes = new byte[7];

  serialPort.writeBytes(Main.SEND_DATA, Main.SEND_DATA.length);
  log.info("Write bytes ({}): {}", Main.SEND_DATA.length, bytesToHex(Main.SEND_DATA));

  int numRead = serialPort.readBytes(bytes, bytes.length);
  log.info("Read bytes ({}): {}", numRead, bytesToHex(bytes));

  //DO something

  Thread.sleep(1000);
}

If I take a look into my logging file, I can see the following:

The first request and response were fine. Starting from the second request (and all requests afterwards) the response (read bytes) are just random or empty.

Is there anything missing at my code to get instantly the correct response (like any flush at read/write, ...)?

Based on the standard serial tool, I can click "Send" as fast as I can and the responses are fine.

Thanks for any advice.

[akuhtz]

@abuech2s Have you tried without setting the ComPortTimeouts?

[abuech2s]

I am pretty sure, I did. I saw the problem, used Google and then I added the timeouts, because I found this command, but same result.

[Maxwell-lin-TW]

Could you try event-base reading instead of polling serialport.writebytes()/readbytes. (https://github.com/Fazecast/jSerialComm/wiki/Event-Based-Reading-Usage-Example) The difference between using serail-tool and jserialcomm is the interval time. Everytime when you press the button to send out rs232 through serail-tool, the interval is more higher than using a while loop. If you insist in using while-loop, i personally recommand to keep polling serailport.readbytes() until it returns with a non-zero data counts.
while (true) {
byte[] bytes = new byte[7];

serialPort.writeBytes(Main.SEND_DATA, Main.SEND_DATA.length);
log.info("Write bytes ({}): {}", Main.SEND_DATA.length, bytesToHex(Main.SEND_DATA));
//add here
int numRead = 0;
do{
numRead = serialPort.readBytes(bytes, bytes.length);
//place some timeout code here.
}while(numRead == 0);
log.info("Read bytes ({}): {}", numRead, bytesToHex(bytes));
//add ends
//DO something

Thread.sleep(1000);
}
hope it works for you.

[abuech2s]

Thank you. I will try it next time I am on the ferry. What do you recommend for timeout code? 50ms or something like this or even smaller? I mean, I try to trigger it every 1000ms.

Do I understand it correctly, that the serial tool reads as well the "empty" bytes, but just don't show it at the output?

By the way, with my approach above, there are not just empty bytes, sometime there are "random" ones in the response. I have added a screenshot, which shows all responses. The first one is correct, all others are invalid:

I am not an expert of RS communication, so is there any technical reason, why there are sometimes "random" bytes?

[abuech2s]

@Maxwell-lin-TW your approach does not work either. The only approach currently is to reinstantiate the serialPort object for every request again: So moving the init() into the loop and close the serialPort cleanly.

        while (true) {
            try {
                Thread.sleep(Main.TRIGGER_TIME);
                init();

                byte[] bytes = new byte[7];

                log.info("Write bytes ({}): {}", Main.SEND_DATA.length, bytesToHex(Main.SEND_DATA));
                serialPort.writeBytes(Main.SEND_DATA, Main.SEND_DATA.length);
                serialPort.flushDataListener();

                int numRead = serialPort.readBytes(bytes, bytes.length);
                log.info("Read bytes ({}): {}.", numRead, bytesToHex(bytes));

                if (serialPort != null) serialPort.closePort();
            } catch(Exception e) {
                serialPort = null;
                log.warn(e.getMessage());
            }
        }

But I am very sure, that this is programmatically inefficient. The problem is as well, that the device does not like wrong bytes: In case you write any wrong byte, the device does not give you any feedback. So, maybe the question: Are there any "hidden linebreaks" inside of the serialPort.write()-method, such that the request will be wrong after the first request?

[akuhtz]

@abuech2s I would change this to use a data listener in a receiver thread that is running independent from the send data thread.
Your code snippet shows a call to flushDataListner(). Have you tried to move this call before the writeBytes() call?

Can you share your demo project on github?

[abuech2s]

Yes, I have tried without flushDataListener() - same result. It is a private Repository, not hosted by me. I will add the code later.

[mcwolfmm]

Empty bytes are not read. You observe this effect because you are using a pre-allocated buffer of 7 bytes. The data actually read is in the range 0 ... numRead from it.

The random data you are talking about is also not random. The picture you point to shows that it is repeated cyclically. It is clearly a valid answer. The device you are working with must have documentation. Look for a description of its communication protocol in it.

Also, when developing something like this, it is good to monitor the traffic in real time. This is done either with specialized software or with a patch cable. In extreme cases, with an oscilloscope or data analyzer.

[akuhtz]

@abuech2s Create a public repo with your running sample project to allow others to help.

[abuech2s]

I have added the code in a new repository .

This small tool has two tasks:

• One thread triggers the ControlCabinet
• a second one pushes the fuelRate value via UDP a any target ip

For test purposes there are different TriggerX.java classes, that can be used via java -jar *.jar trigger={1,2,3}

For the working impl is java -jar *.jar trigger=3, which initialized the serialPort object every time.

[akuhtz]

@abuech2s I have added a PR with demo that uses a separate thread to read the data. You should be able to test if you get the expected data. It's possible that you get the answer in junks that you have to collect and when the 7 bytes are received you can forward the data to the next processing step.

[abuech2s]

Thanks for the moment. I will try it next time, I am at the device.