Flush not working

[FliegenKLATSCH]

Flush doesn't clear the buffer?

• port.pause(); port.flush(); port.resume();
• data event is emitted for every message received during the paused period / before the flush.

Code to Reproduce the Issue

const SerialPort = require("serialport");
const Readline = require('@serialport/parser-readline');

const port = new SerialPort("/dev/ttyUSB1", {
    baudRate: 9600, databits: 7, stopbits: 1, parity: 'even', lock: false
});
const parser = port.pipe(new Readline({delimiter: "!", encoding: 'ascii'}));


parser.on("data", function(data) {
    console.log(new Date() + ': ', data);
});

setTimeout(() => {
    console.log('pause...');
    port.pause();

    setTimeout(() => {
        console.log('flush...');
        port.flush(function(err) {
            console.log(err);
            console.log('resume...');
            port.resume();
        });
    }, 10000);

}, 10000);

Versions, Operating System and Hardware

• [email protected]
• Node.js v10.13.0
• Raspberry Pi 3

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in a week no further activity occurs. Feel free continue the discussion or ask for a never-stale label to keep it open. If this is a support issue, consider sharing it on stack overflow to get more eyes on your problem.

[thedayofcondor]

V7.1.5 I can confirm.

On Windows - flush callback is called but the buffers are never flushed.
On Linux - works maybe 30% of the times

As a test, I am connected to a serial device that sends a packet every second.

const SerialPort = require('serialport')
const Readline = require('@serialport/parser-readline')

const port = new SerialPort(process.argv[2], {
    baudRate: 57600,
    autoOpen: true,
    rtscts: true
})

port.on('open', () => {
    console.log("port opened");
    port.flush((error) => {
        console.log("port flushed")       
        const parser = port.pipe(new Readline({ delimiter: '\r' }))
        parser.on('data', line => {
            console.log(line)
        })
    })
});

Upon launching (passing the serial port name as first parameter), the code above prints all the packed that have been received since the last launch notwithstanding the flush.

[reconbot]

What behavior are you expecting?

[reconbot]

Parsers and streams have their own buffers which are not flushed by this command. It only flushes the os level buffers.

[thedayofcondor]

The behaviour I am expecting Is to only see the data sent after the flush.
Also, I am initialising the parser after the flush - so I do not expect it to be able to buffer anything.

But, if this is the case, should I flush the stream as well?

[reconbot]

How do you know when the data was sent? Open => flush => read might not miss any data, no data is buffered when the port is closed.

[thedayofcondor]

The device I am using outputs one line per second to the serial. It is an USB device based on a FTDI chip.

Just starting the above code should only print new data, one per second - it prints about a dozen of lines straight away.

If I kill the process, wait 5 seconds, relaunch it - it prints 5 lines immediately, then one line every second.

If I understand what you are saying, the device itself, and not windows, could be the one doing the buffering - but then I would get exactly the same behaviour on Linux

[reconbot]

Maybe, it might be paying attention to the line state when the port is closed and they’re might be different behavior between systems. Can you tell me more about the device?

[thedayofcondor]

This is the device. I am implementing sl-can for a project
http://www.vscom.de/usb-can-plus-iso.html

As an additional note, (may help with troubleshooting)

port.on('open', () => {
  const old = port.read(65536);
  if (old!=null) {
    debug("Discarded", old.length, "bytes")
  }
});

doesn't work either - immediately after an open port.read returns null, and later my "data" event is flooded with stale packets.

As a note, my device requires rtscts - which may be broken on windows.
#1809 which could explain the odd behaviours I am getting (a port.read doesn't return any data at first)

[thedayofcondor]

Hi,
I had a chat with VSCOM support - they immediately pointed the finger at probable issues with HW handshaking - necessary because the VSCOM communicates over serial at 3Mbps.

Not sure how it plays out, but it looks like on startup port.flush does not see any data because there is no data to see (buffering is done by the device), so this is not an issue with port.flush in the first place

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in a week no further activity occurs. Feel free continue the discussion or ask for a never-stale label to keep it open. If this is a support issue, consider sharing it on stack overflow to get more eyes on your problem.