2

Solved: dsrdtr=True shouldn't have been used for software, only on the hardware being used

Hi I'm trying to write telegrams to serial port and can send one successfully. If I send more than one nothing happens. The script has to be closed at which point the first telegram is successfully received.

The manufacturer suggests a break of 50ms between telegrams, even with breaks >5s it still fails.

s = serial.Serial(
port='COM3',
baudrate=9600,
parity=serial.PARITY_ODD,
stopbits=serial.STOPBITS_ONE,
timeout=0,
bytesize=serial.SEVENBITS,
dsrdtr=True             
)

buttonUP=b'\x54\x30\x34\x0D'

s.write(buttonUP)
time.sleep(0.05)
s.write(buttonUP)
time.sleep(0.05)
s.write(buttonUP)

If instead I write 

s.write(buttonUP)
s.close()
s.open()
s.write(buttonUP)

This works but the delay caused by closing/opening is too long for our requirements.

Does anyone have any ideas about what could be causing this issue? Thank you very much for your help

QM_42
  • 21
  • 2
  • Did you try to scan the serial port data to see if the data is sent? Your data may have been sent, but the target code on the connected device fails to buffer it or something. (?) – Yotam Salmon Feb 28 '18 at 13:04
  • Is your DSR/DTR state correct? – Stephen Rauch Feb 28 '18 at 13:09
  • I am also doing a project with pyserial right now... I have had a lot of issues with it.. but mainly they boil down to issues with other services (rs485 connection in my case) provided that your interface settings are okay... I would be curious to know what the error is when it fails?? – rustysys-dev Feb 28 '18 at 13:10
  • The data is definitely sent if I send it once. This is confirmed by reading the port and seeing the parts it controls move. – QM_42 Feb 28 '18 at 13:17
  • I am using the DSR/DTR state specified by the manufacturer – QM_42 Feb 28 '18 at 13:17
  • @QM_42 Try setting a write timeout.. since writes are blocking, its possible that your first write never ends. `write_timeout = 1` or whatever suits you for testing – rustysys-dev Feb 28 '18 at 13:24
  • No error actually occurs - the script does nothing and doesn't send anything to the port until I forcibly exit the script, at which point the first message is sent to the port. – QM_42 Feb 28 '18 at 13:25
  • @Procyclinsur I think you might be on to something. I tried what you said using write_timeout=0.1,1,10 and got the same error every time. This is error message: Traceback (most recent call last): File "bla", line 31, in s.write(buttonUP) File "bla", line 323, in write raise writeTimeoutError serial.serialutil.SerialTimeoutException: Write timeout line 31 is the third instance of s.write, though nothing was actually written to the port before – QM_42 Feb 28 '18 at 13:34
  • @QM_42 Try adding the following in between your `write` and `sleep` commands to see what happens. first `print(s.outwaiting)` and then `s.flushOutput()` – rustysys-dev Feb 28 '18 at 13:44
  • @Procyclinsur Thank you so much for your help. This successfully sends once, and prints 0, and then the script fails to do anything as before, but this does at least send the first message successfully – QM_42 Feb 28 '18 at 13:52
  • @QM_42 Okay, I would bet (can't guarantee) that this is an issue with flow control. Is there anyway to share information about the device in question? or if public can you point me to the manufacturers website. I think I need more information on the Manufacturer specifications. PS Sorry for the delay... I was trying to set up a chat room, but you cant join unless you have 20 reputation. – rustysys-dev Feb 28 '18 at 14:13
  • 1
    @Procyclinsur No problem, and thank you again! dsrdtr=True was the problem, and was used by default on the supplied hardware, but should not have been used when using software instead – QM_42 Feb 28 '18 at 14:22
  • ＠QM_42 Glad to hear you found the answer! sounded like a flow control issue since the output buffer cleared on its own as it should have. Time to go home... 11PM (Japan) – rustysys-dev Feb 28 '18 at 14:24

1 Answers1

0

If you are trying to read from the port by using a readline() function, it might be a problem that you don't terminate each message with a newline. Try changing it to 

buttonUP=b'\x54\x30\x34\x0D\n'

You can read more here

mrfred489
  • 80
  • 1
  • 7
  • If the end device requires a new line that might be relevent.. but restarting the script fixes it.. so I don't think its an end device issue. I think he is dealing with a write issue. – rustysys-dev Feb 28 '18 at 13:12
  • Unfortunately changing that hasn't worked - this issue occurs without trying to read from the port. Thank you for your help though, I'll keep in mind how I terminate messages going forward – QM_42 Feb 28 '18 at 13:13
  • I was thinking that closing the connection might send a newline. – mrfred489 Feb 28 '18 at 13:14
  • How do you know that it isn't working if you don't try to read it? – mrfred489 Feb 28 '18 at 13:16
  • Because it controls mechanical parts that move when sent buttonUP successfully. After running the script I do check s.read(9) to see how far it moved – QM_42 Feb 28 '18 at 13:20