January 5, 2022 at 2:42 pm #29706
I’m having a hard time issuing commands to the a5 using python and an FTDI friend.
For example, this code should make the clock read HELLO:
ser = serial.Serial(‘<USB DEVICE>’, 19200)
header = chr(0xFF)
I have to run it three times in order for it to have any affect on the clock, and the the display changes to something more like HELlA, not HELLO.
I’m fairly certain this is an encoding problem at play, but it has stumped me. I’m on a M1 macbook, using python2.7.
Any suggestions would be much appreciated!January 5, 2022 at 3:00 pm #29709
If it’s working *sometimes* or partially, then I’d suspect an electronics or reset issue first.
Are things acting stable and reliable otherwise?
If you have auto-reset enabled, you may be resetting the device when you open communication– I don’t see a delay there, so make sure that you’re waiting a moment for reset to complete before trying to send data.January 5, 2022 at 3:49 pm #29710
Thanks for the reply.
Things are perfectly stable otherwise. In fact, I’m able to interface with the clock exactly as expected using processing. It’s only once I tried to port my work over to python that I encountered this problem.
There’s no reset happening from what I can tell, and I’ve tried adding in a delay, but this hasn’t had any affect.
I’m running the code using the pycharm IDE in a virtual python2.7 environment (because I was having a hard time getting pyserial to play nice with my local python3 runtime). Do you think my environment could somehow be to blame?January 5, 2022 at 4:01 pm #29711
Actually scratch that, once I added more 500ms delays between each .write() method, I am able to get it to work reliably as expected.
Do you understand why the timing is so much more touchy in python than it is in processing?
Cheers, and thanks for your help!January 5, 2022 at 4:19 pm #29712
On an M1, I would say (to start with) that any pyserial version less than 3.5 is absolutely, positively unreliable, and I personally would not even try on 2.7. The IDE and virtual environment shouldn’t cause any issues so far as I know off hand.
That you are able to communicate on Processing does very much suggest that this is a software-specific issue.
In Python3, the following works reliably for me:
ser = serial.Serial("/dev/cu.usbserial-FTE55RTK", baudrate=19200)
header = b'\xFF'
command = b'A0'
data = b'ABCDE'
space = b' '
ser.write(header + command + data + space)
January 5, 2022 at 4:22 pm #29713
I don’t think that you need time between individual writes — my example doesn’t have them — but my script has time added for the reset after starting communication, a different word (so that HELLO WORLD isn’t confusable with the word I’m writing) and a “display” delay time after writing the text before the restart.January 6, 2022 at 10:48 am #29716
Following up for closure. After a sleeping on it, I realized my code was occasionally sending over a 3 or 4 letter word without whitespace padding to equal it all up to five characters. This meant that I was not sending over the complete 13 byte command that the clock was expecting, and thus my subsequent command was appended to the previous command. As I hadn’t been resetting the clock, this truncation was being compounded and even my simple debug code was being affected by it.
Thanks for your help (I also took your advice and got python 3.9 and pyserial2.5 running.)
Sample code to recreate the problem:
import serial import time ser = serial.Serial('/dev/cu.usbserial-AC013VIR', baudrate=19200) time.sleep(3) theseWordsWork = ["TRUSS", "SPIED", "WHACK", "BOGUS", "METER", "SLIDE"] theseWordsDontWork = ["TRUSS", "SPIE", "WHAC", "BGUS", "METER", "SLIDE"] for word in theseWordsDontWork: header = b'\xFF' command = b'A0' data = word.encode() space = b' ' ser.write(header + command + data + space) time.sleep(1) ser.close()
- You must be logged in to reply to this topic.