Serial Communication Problems
-
- Posts: 13
- Joined: Fri Sep 15, 2017 7:51 am
Serial Communication Problems
Hello,
i have two RoboClaws 2x15A drivers, which are connected via RS485. The Communication works and i got response from the devices. Now i have a interesting Issue.
When i use my CPP class with USB connection directly with one RoboClaw then i receive the following telegram:
Now when i use the same class and switch over to FTDI USB <-> RS485 device i receive the following:
Checksum is missing via serial connection. and it doesn't matter how long i wait i cant receive the last two checksum bytes...
Would it be possible, that you introduce a ETX (0x0D) at the end of a Message or is there another problem of the RoboClaw Firmware while sending via UART?
I tested this under Windows 10 (USB and FTDI USB <-> RS485) and on Raspberry Pi 2 (Raspbian 9.0, with UART <-> MAX491)
Every Time when i didn't use USB Connection i miss the Checksum.
Greetings,
M.
i have two RoboClaws 2x15A drivers, which are connected via RS485. The Communication works and i got response from the devices. Now i have a interesting Issue.
When i use my CPP class with USB connection directly with one RoboClaw then i receive the following telegram:
Code: Select all
Direct USB Connection:
ReadSerial: (HEX) 0x55, 0x53, 0x42, 0x20, 0x52, 0x6F, 0x62, 0x6F, 0x63, 0x6C, 0x61, 0x77, 0x20, 0x32, 0x78, 0x31, 0x35, 0x61, 0x20, 0x76, 0x34, 0x2E, 0x31, 0x2E, 0x32, 0x33, 0x0A, 0x00, 0xC7, 0x4E
ReadSerial: (String) USB Roboclaw 2x15a v4.1.23 + '\n\0' + (0xC7, 0x4E Checksum)
Code: Select all
FTDI USB <-> RS485 Connection
ReadSerial: (HEX) 0x55, 0x53, 0x42, 0x20, 0x52, 0x6F, 0x62, 0x6F, 0x63, 0x6C, 0x61, 0x77, 0x20, 0x32, 0x78, 0x31, 0x35, 0x61, 0x20, 0x76, 0x34, 0x2E, 0x31, 0x2E, 0x32, 0x33, 0x0A, 0x00
ReadSerial: (String) USB Roboclaw 2x15a v4.1.23 + '\n\0'
Would it be possible, that you introduce a ETX (0x0D) at the end of a Message or is there another problem of the RoboClaw Firmware while sending via UART?
I tested this under Windows 10 (USB and FTDI USB <-> RS485) and on Raspberry Pi 2 (Raspbian 9.0, with UART <-> MAX491)
Every Time when i didn't use USB Connection i miss the Checksum.
Greetings,
M.
- Basicmicro Support
- Posts: 1594
- Joined: Thu Feb 26, 2015 9:45 pm
Re: Serial Communication Problems
My guess is the NULL at the end of the string is triggering something in the USB->RS485->TTL connection. Look at the daatsheets for the FTDI RS485 and whatever adapter you are using at the other end to convert from RS485 to TTL serial.
Test with another read command that doesnt(or is unlikely to) return a NULL) like ReadTemp.
There is a setup utility for the FTDI RS485 adapter. You may need to set a mode for passthrough without modification of the data. Same may apply to the adapter the other end of your RS485 cable.
Test with another read command that doesnt(or is unlikely to) return a NULL) like ReadTemp.
There is a setup utility for the FTDI RS485 adapter. You may need to set a mode for passthrough without modification of the data. Same may apply to the adapter the other end of your RS485 cable.
-
- Posts: 13
- Joined: Fri Sep 15, 2017 7:51 am
Re: Serial Communication Problems
Now i found the Problem. Your RS485 Direction Pin is not in Sendmode while you send the Checksum via UART.
So its not due to my serial converters.
I recognized that those short ON / OFF Phases of the direction pin causes problems during send of the message, too.
So it would be much better that you introduce a real protocol. With this you know that you want to send x bytes and within this time the direction pin is always kept high.
A useful protocol could look like this:
So for example:
I would appreciate if you could solve the issue with the RS485_Direction Pin with your next Firmware update. Otherwise i can't use your devices, which i want to avoid.
Best regards,
M.
So its not due to my serial converters.
I recognized that those short ON / OFF Phases of the direction pin causes problems during send of the message, too.
So it would be much better that you introduce a real protocol. With this you know that you want to send x bytes and within this time the direction pin is always kept high.
A useful protocol could look like this:
Code: Select all
STX, FROMADR, TOADR, DATALENGTH, DATA, CHKSUM, ETX
Code: Select all
PC Request:
0x02, 0x01, 0x80, 0x01, 0x15, CHKSM[0], CHKSM[1], ETX
Roboclaw Response:
0x02, 0x80, 0x01, 0x28, 'U','S','B','-','R', ... , CHKSM[0], CHKSM[1], 0x0D
| |
\------------- CRC16 CHECKSUM --------------/
Best regards,
M.
- Attachments
-
- RS485_DIR_FAIL_2.PNG (69.73 KiB) Viewed 10956 times
-
- RS485_DIR_FAIL.PNG (47.29 KiB) Viewed 10956 times
- Basicmicro Support
- Posts: 1594
- Joined: Thu Feb 26, 2015 9:45 pm
Re: Serial Communication Problems
I'll look at the firmware. The RS485 direction pin should be set or cleared depending on the current transmit or receive state of the TTL serial.
-
- Posts: 13
- Joined: Fri Sep 15, 2017 7:51 am
Re: Serial Communication Problems
Hi,
did you already have the chance to check the firmware and what will be the next steps?
Could you post an update when the new and corrected firmware is available?
Best regards,
M.
did you already have the chance to check the firmware and what will be the next steps?
Could you post an update when the new and corrected firmware is available?
Best regards,
M.
- Basicmicro Support
- Posts: 1594
- Joined: Thu Feb 26, 2015 9:45 pm
Re: Serial Communication Problems
No I have not had a chance to look into this yet.
When the update is uploaded to the server Ion Studio will automatically detect it when you run it the next time(after the update) and ask if you want to download/install it.
When the update is uploaded to the server Ion Studio will automatically detect it when you run it the next time(after the update) and ask if you want to download/install it.
-
- Posts: 13
- Joined: Fri Sep 15, 2017 7:51 am
Re: Serial Communication Problems
Hi there,
for my project planning please let me know if you will work on a firmware update with the correction of the direction pin problem in this year.
for my project planning please let me know if you will work on a firmware update with the correction of the direction pin problem in this year.
- Basicmicro Support
- Posts: 1594
- Joined: Thu Feb 26, 2015 9:45 pm
Re: Serial Communication Problems
Our new update got delayed. Please email support. We can get you a pre-release version to test. We already made changes to the RS-485 direction pin control.
-
- Posts: 13
- Joined: Fri Sep 15, 2017 7:51 am
Re: Serial Communication Problems
Hi there,
today i tested the new Firmware v4.1.24 and it looks really good.
The Message disruptions during send are gone and i can even communicate with two modules via RS485, when i ignore the checksum.
The old Problem when the direction Pin is changed before the checksum is send is still there.
I hope this was helpful and you get it work with the next version.
Thanks and i hope to hear from you maybe next year.
Bye.
today i tested the new Firmware v4.1.24 and it looks really good.
The Message disruptions during send are gone and i can even communicate with two modules via RS485, when i ignore the checksum.
The old Problem when the direction Pin is changed before the checksum is send is still there.
I hope this was helpful and you get it work with the next version.
Thanks and i hope to hear from you maybe next year.
Bye.
- Attachments
-
- Now it looks even better, but the Checksum problem is still there
- Firmware_v4.1.24.PNG (102.58 KiB) Viewed 10341 times
- Basicmicro Support
- Posts: 1594
- Joined: Thu Feb 26, 2015 9:45 pm
Re: Serial Communication Problems
I'll look into it further. Glad it is atleast partially workign for you now.