We Keep Coding

Serial connection problem with Pyserial after reboot

I have a Python script to communicate with a measuring instrument over a RS232 serial port.
Everything works fine, but every time I turn on the PC (Windows 10) the communication doesn't work in the beginning. I have to open a serial terminal (for example hterm) press the "connect" and "disconnect" button. After that the Python script works as expected, reading and writing to and from the instrument is no problem.
Here is a short example of the code:
import serial, time
ser = serial.Serial(port='COM6', baudrate=19200, bytesize=8, parity=serial.PARITY_NONE, stopbits=1, timeout=0, xonxoff=False, rtscts=False, dsrdtr=False)
time.sleep(1)
print(ser.isOpen()) #output: true
ser.write(b'READ:CH1\r\n')
time.sleep(1)
print("read:" + ser.read(18).decode('utf-8'))
ser.close()
print(ser.isOpen()) #output: false
The instrument doesn't receive the data "READ:CH1" or any other command. Because of this there isn't any transmitted data to the PC via ser.read().
I tried every possibility with hardware handshakes and very long sleep times. I guess there's a problem between Windows and Pyserial. In Python the port is open, but Windows doesn't send the data. Do you have any ideas what I could do?
Thanks for your help.
Best regards
Edit with solution:
Instead of or additional to "Serial.flushInput()" and "Serial.flushOutput()" you need "Serial.reset_input_buffer()" and "Serial.reset_output_buffer()".

If you are using a third-party tool and then the script works fine, then I think there is some garbage data present in the buffers of either side, flushing the serial port on the hardware device and on the python script too might work and verify the data being received on the hardware device it is possible garbage is being appended on the commands, also try to use some header bits which keep errors at bay in this kind of communication.
Use some serial port sniffer to verify what is being sent, like this

Look at https://github.com/pyserial/pyserial/issues/329
https://github.com/pyserial/pyserial/issues/329#issuecomment-400852426
https://github.com/pyserial/pyserial/issues/329#issuecomment-503059537
Do you see this?
Another issue that might be related:
https://github.com/pyserial/pyserial/issues/485
Another thing you could try is to open and close the port first.
That's the same thing you are doing with hterm for
ser = serial.Serial()
time.sleep(1)
print(ser.isOpen()) #output: true
ser.close()
ser = serial.Serial()
time.sleep(1)
print(ser.isOpen()) #output: true
...
Does this work?

Modbus Slave don`t respond

I am trying to use a Raspberry Pi 3B (run Ubuntu Mate 16.04 operating system)as a Master to read values from an electric energy meter which supports Modbus-RTU protocol.
I used a RS232/USB adapter and a RS485/RS232 adapter to link the meter and the USB port on the Raspberry Pi. I have tried the modbus_tk 0.5.7 and MinimalModbus to implement the communication under Modbus-RTU protocol.
When I use modbus_tk 0.5.7 and run the following code：
import sys import serial
#add logging capability import logging import modbus_tk import modbus_tk.defines as cst import modbus_tk.modbus_rtu as modbus_rtu
logger = modbus_tk.utils.create_logger("console")
if __name__ == "__main__":
try:
#Connect to the slave
master = modbus_rtu.RtuMaster(serial.Serial(port="/dev/ttyUSB0", baudrate=9600, bytesize=8, parity='N', stopbits=1, xonxoff=0))
master.set_timeout(5.0) #Change the timeout value/Defines a timeout on the MAC layer
master.set_verbose(True) #print some more log prints for debug purpose
logger.info("connected")
logger.info(master.execute(1, cst.READ_HOLDING_REGISTERS, 0, 49))
except modbus_tk.modbus.ModbusError, e:
logger.error("%s- Code=%d" % (e, e.get_exception_code()))
The parameters such as port, baudrate, bytesize,parity,and stopbits were set correctly, but it always returns this:
2017-08-10 19:24:34,282 INFO modbus_rtu.__init__ MainThread RtuMaster /dev/ttyUSB0 is opened
2017-08-10 19:24:34,283 INFO rtumaster_example.<module> MainThread connected
2017-08-10 19:24:34,284 DEBUG modbus.execute MainThread -> 1-3-0-0-0-49-132-30
2017-08-10 19:24:39,291 DEBUG modbus.execute MainThread <-
Traceback (most recent call last):
File "rtumaster_example.py", line 34, in <module>
logger.info(master.execute(1, cst.READ_HOLDING_REGISTERS, 0, 49))
File "build/bdist.linux-x86_64/egg/modbus_tk/utils.py", line 39, in new
modbus_tk.exceptions.ModbusInvalidResponseError: Response length is invalid 0
When I use MinimalModbus and run the following code：
#!/usr/bin/env python
import minimalmodbus
instrument.serial.port='/dev/ttyUSB0' # this is the serial port name
instrument.serial.baudrate = 9600 # Baud
instrument.serial.bytesize = 8
instrument.serial.parity = serial.PARITY_NONE
instrument.serial.stopbits = 1
instrument.serial.timeout = 0.05 # seconds
#instrument.address # this is the slave address number
instrument.mode = minimalmodbus.MODE_RTU # rtu or ascii mode
instrument = minimalmodbus.Instrument('/dev/ttyUSB0', 1) # port name, slave address (in decimal)
energy = instrument.read_register(10, 1) # Registernumber, number of decimals
print energy
It always returns this:
raise IOError('No communication with the instrument (no answer)')
IOError: No communication with the instrument (no answer)
And then I use the same serial transmission line to link the meter and the laptop, and use a debugging tool running on Windows XP, which was developed by the manufacturer of the meter. The debugging tool sends the same Request (1-3-0-0-0-49-132-30) as before, but the debugging tool can get correct Responses. (Maybe it's because it ignored some incorrect Responses and keep on send Requests regularly) And it can represent that the Request message is correct and the connection of serial transmission has no problem.
I also used the CuteCom(a graphical serial terminal) and the RS232/USB adapter to confirm that the USB port can send and receive correctly. It is also useless to add a resistor between two RS485 lines
I have tried many times, but the Raspberry Pi never gets a Response, and always returns the same error information. I also try to run the same code on a Ubuntu virtual machine, it returned the same message as above and never get a Respond.
I am new to Modbus and serial communication, so any help would be appreciated.

I have solved my problem by using a more expensive USBtoRS485 connector.
The problem took me a lot of time to try different library and different code.
It turns out that the adapter "QinHeng Electronics HL-340 usb-serial" that I bought works well on windows but does not work with Linux. It can achieve send and receive message on Linux, but it just can`t support Modbus communication.
So I suggest you buy a more expensive connector, and it may save your a lot of time and energy.
That`s all, thank you!

I was having the same problem. After use mbpoll tool I have realized the parity was wrong. Just updated to parity.EVEN and it is ok now.

Try connecting RS232-end of a cable into PC with serial port (if you have it ofc) to ensure usb/rs232 works
If you have oscilloscope (like fluke), you can observe RS485 line (it is not difficult in fact) to understand where is the issue.
It happened to me to find out that serial parameters (like baud rate) can be configured it 2 places for Windows - when you open the port and in driver configuration.
Try equalize the potential for all devices. I know rs485 is supposed to be immune to it but rs232 not

You have a too short time out on your Pi, try increasing it to 100 ms and it should work.
EDIT: As requested in the comment below I'm giving some more details on my suggestion. Based on the details given on the question and subsequent answers and comments the hardware setup seemed to be correct. I've seen this happen from time to time: when you set a very short timeout on one side the link suddenly stops working (it makes sense too, a timeout error occurs when you have not received an answer within the timespan you determine with the timeout parameter), and it goes back alive as soon as you increase it again. I've also noticed this effect is hardware dependent, some devices are able to answer faster than others

Program execution stopping on atml atmega16 microcontroller upon terminal connection

I am attempting to receive data from the qu-bot at http://www.qu-bot.com. The robot has an ATML atmega16 microcontroller. I have written a program that runs on the robot which outputs data to its serial port. The program however stops whenever I connect to the controller. I tested this by adding a beep statement. The robot beeps as long as the program is running. The beeping stops when I connect to the robot. I tried qu-bo support and they suggested disabling the dtr flag on the serial port. I did that but no joy.
Is there anything else I can try?
[start of code running on the qu-bot]
Note:
This is written in some kind of proprietary variant of C which they call quick c.
// This code displays the uart functions.
int main(void)
{
INIT();
UART_INIT(57600);
UART_PRINT("HELLO!!\n");
DELAYS(1);
UART_PRINT("MY NAME IS QU-BOT.\n");
DELAYS(1);
UART_PRINT("HELLO!!\n");
UART_PRINT("YOU ARE USING UART SAMPLE CODES.\n");
while(1)
{
UART_PRINT("test\n");
BEEP();
DELAYS(60);
}
}
now for my python serial port reading program. I have tried this program both on raspbian and on windows 7 64bit. I am pasting the windows version. The raspbian version has a different name for the linux.
import serial
import time
ser=serial.Serial()
ser.port=8
ser.baudrate=57600
ser.setDsrDtr(False)
print 'initialized'
flag = ser.isOpen()
if flag:
print 'port already open.'
pass
else:
ser.open() # opening the port 'ser' that was just created to receive data
time.sleep(0.5)
print 'ready to read'
print ser
ser.write('a')
s=ser.read(4)
print s
ser.close()
Pranav
P.S. I have consulted the following links amongst others.
<https://learn.sparkfun.com/tutorials/terminal-basics/all>
<http://www.plainlystated.com/2013/06/raspberry-pi-serial-console/>
<http://elinux.org/RPi_Serial_Connection>
<https://learn.sparkfun.com/tutorials/terminal-basics/all>

Based on my experience in serial communications with microcontrollers the most likely cause of this problem is that when you connect the serial cable to the robot it causes a phantom byte (due to electrical noise that happens when you make the connection) to look like it's coming from the controller - either this or the controller is sending a legitimate byte to the robot. In either case it is likely that the arrival of a byte at the robot's serial port (even if it was only electrical noise mistaken to be a data byte - this is a very common occurrence) caused the robot's microcontroller to invoke the UART receive interrupt. If you don't have an appropriate UART receive handler (ISR - Interrupt Service Routine) written and linked into the correct interrupt vector then your robot's microcontroller can go off into "deep space" upon the detection of the first incoming serial data byte - and make your robot appear to "hang". If you intend to do "polled" serial communications (your code manually checks for received bytes in its main loop) instead of interrupt-driven (hardware detection of an incoming byte causes your UART Rx ISR to be invoked) then all you have to do is to disable UART interrupts and your problem should go away.

Script is not blocking

This is a timelapse script for moving a camera along a dolly. The problem is that when I run the code, sometimes (at iteration 7 exactly, for example) the dolly is moving and the camera snaps a photo at the same time. It's as if the commands aren't blocking before the next one gets executed. As you can see, I've tried scattering sleep's in the code to no avail.
Here is the workflow:
Raspberry Pi sends commands to camera (snap photo) and Arduino (move dolly)
The Arduino talks to EasyDriver Stepper Motor Driver, which talks to the stepper and causes dolly to move.
Repeat.
Here is my Python script.
import os, commands, string, gps
from subprocess import Popen, PIPE
from time import sleep
import serial
ser = serial.Serial('/dev/ttyACM0', 9600)
sleep (5)
for i in range(0, 20):
#To write information
steps = 1000*(i+1)
ser.write('1,'+str( steps )+'/n')
sleep (4)
bashCommand = "sudo /home/mh00h/Timelapse/camerareset.sh"
os.system(bashCommand)
sleep (2)
bashCommand = "sudo gphoto2 --capture-image"
os.system(bashCommand)
sleep (1)

There are (potentially) two reasons why this doesn't block as required:
Serial communication is buffered, so as long as the length of the data passed to Serial.write() is smaller than the buffer this call can return before the data is read by the Arduino sketch. In fact, depending on the length of the data and the size of the buffer, several calls to Serial.write() could complete before the Arduino completes any reads.
The Arduino sketch may not block until the stepper motor has completed its movement. It would be useful to see the sketch to determine whether this is the case.
Sleeping between calls can help but even if you can get this to work you'll likely experience odd, non-reproducible behavior.
The solution to both the problems above is to synchronize the actions in your code. For the serial communication this can be achieved by sending a 'finished' message back from the Arduino sketch to the python script which will read from the serial port until it receives this message. How to synchronize the stepper motor with the Arduino sketch (if needed) will depend on how the Arduino to stepper motor communication is coded.

Pyserial problem with Arduino - works with the Python shell but not in a program

All right, so I am positive my Arduino circuit is correct and the code for it. I know this because when I use the serial monitor built into the Arduino IDE and send 'H' an LED lights up, when I send 'L' that LED turns off.
Now I made a Python program
import serial
ser = serial.Serial("COM4",9600)
ser.write("H")
When I run the code the LED blinks on for a second then goes back off.
However when I do each of these lines separately in the shell it works just like it is supposed to.
Any ideas?

When you open the serial port, this causes the Arduino to reset. Since the Arduino takes some time to bootup, all the input goes to the bitbucket (or probably to the bootloader which does god knows what with it). If you insert a sleep, you wait for the Arduino to come up so your serial code. This is why it works interactively; you were waiting the 1.5 seconds needed for the software to come up.
I confirmed that opening the serial port resets my Arduino Uno; I flashed a program which will blink the LED from the setup() routine -- calling open("/dev/ttyACM0") was sufficient to trigger the reset. This is IMHO a confusing and undocumented wrinkle in the serial support.

I had the same problem and it works if I add a delay of about 2 seconds from opening the serial connection to writing on it, 1 second was not enough.

Just to make it a bit more clear I'll modify the code so everyone can see what needs to be added!
import serial
import time
ser = serial.Serial("COM4",9600)
time.sleep(3)
ser.write("H")
Adding in a sleep statment helps to let the serial open up without any problems!

Assuming you are using an Arduino Uno
The USB port and the Uno serial bus exposed on pins 1 and 0 share the same RX/TX lines. I suggest getting a USB to TTL adapter like the one here so that you can communicate to the Arduino without using the USB port. The Arduino IDE has its own method for disengaging from the USB driver such that a virtual serial port can be created. Have your Ardunio use SoftwareSerial instead.
Here is an example I found on the internet where somebody had clashing bus issues.