I'm having issues communicating with my down stream serial device. Enabling DTR and RTS fixes the problem in MAC but not in windows. Does anyone know how I can replicate in windows the success I've had using MAC?
I also had success with a program called CoolTerm by enabling CTS and DTR, and disabling "Software Supported Flow Control".
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2019-06-06
Still have not found a work around for this yet. It appears to have something to do with the way that scriptcommunicator interacts with windows USB driver (seems to possibly be usbser.sys?).
This is not an issue in Mac or Linux.
Monitoring and checking the USB serial port settings in the windows terminal using the command "mode com[:]" to check and change serial port parameters, it seems that scriptcommunicator interacts with these differently than other programs that work in my specific situation (such as realTerm or coolTerm). Checking these settings in the windows terminal before and after connecting, scriptcommunicator seems to not overwrite these values while the programs that work do overwrite them.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
ScriptCommunicator use the QT class QSerialPort for the serial communication. Maybe this class has a problem on windows.
Last edit: Stefan Zieker 2019-06-06
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2019-06-27
I was able to solve my problem by chance recently. I attached a picture of my code with a working code block and a non-working code block.
When I create my own serial port using the example in the manual I get my issue that I was having (Extra bytes being added to received message replies or messages initiated by the device I'm talking to repeating the last message I sent).
What I did by chance was removed the .setDTR and .setRTS lines of code which happened to fix my issue.
thx for your feedback. That's weired because ScriptCommunicator just directly calls the corresponding functions from the QSerial class. I will have a look at it when I have more time.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm having issues communicating with my down stream serial device. Enabling DTR and RTS fixes the problem in MAC but not in windows. Does anyone know how I can replicate in windows the success I've had using MAC?
I also had success with a program called CoolTerm by enabling CTS and DTR, and disabling "Software Supported Flow Control".
Still have not found a work around for this yet. It appears to have something to do with the way that scriptcommunicator interacts with windows USB driver (seems to possibly be usbser.sys?).
This is not an issue in Mac or Linux.
Monitoring and checking the USB serial port settings in the windows terminal using the command "mode com[:]" to check and change serial port parameters, it seems that scriptcommunicator interacts with these differently than other programs that work in my specific situation (such as realTerm or coolTerm). Checking these settings in the windows terminal before and after connecting, scriptcommunicator seems to not overwrite these values while the programs that work do overwrite them.
Hi,
ScriptCommunicator use the QT class QSerialPort for the serial communication. Maybe this class has a problem on windows.
Last edit: Stefan Zieker 2019-06-06
I was able to solve my problem by chance recently. I attached a picture of my code with a working code block and a non-working code block.
When I create my own serial port using the example in the manual I get my issue that I was having (Extra bytes being added to received message replies or messages initiated by the device I'm talking to repeating the last message I sent).
What I did by chance was removed the .setDTR and .setRTS lines of code which happened to fix my issue.
Hi,
thx for your feedback. That's weired because ScriptCommunicator just directly calls the corresponding functions from the QSerial class. I will have a look at it when I have more time.