PDA

View Full Version : Cannot get RS485 to work



heliboy
12-14-2009, 04:59 AM
Hello All: I am new to Propeller and I have used if successfully to build a serial-to-VGA converter. My latest project involves operating a number of Dynamixel servos from the propeller. I chose the Dynamixels because they advertised an object in the prop library. Unfortunatly the object library only supports their AX series while I purchased the RX which communicates over RS485. For the life of me I cannot get·my 485 converter to work from the propeller. I am using a MAX3430 and FullDuplex serial. I have P1 to DI, P2 to RO, and P0 to the Talk/listen pins. No matter what I do, I get byte 00 on the receive even if the A,B lines are disconnected. I have no trouble with a PIC using the max3430 and am now at the frustration stage where I wish I had used the·PIC to begin with.

Any help appreciated.

Leon
12-14-2009, 05:18 AM
I'd try outputting high and low logic levels from the relevant Propeller pins and checking what you get out of the MAX3430 with a DVM or a scope. You should be able to find the problem by checking against the data sheet.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM

T Chap
12-14-2009, 06:09 AM
Can you post the complete schematic and code you are using? I have a Prop and 3430 scheme that I may be able to check it with. I assume you are referring the talk/listen pins a both enable pins.

T Chap
12-14-2009, 06:38 AM
Set your pins to the code below. Hook up a multimeter to outputs A or B. A will always be NOT B. If you can't get this working then you have connection problems or something unrelated to the Prop.




PUB RS485Test
dira[RSTX) := 1 'rstx is MAX3430 DI (DRIVER INPUT)
dira[RSRX] := 0 'rsrx is MAX3430 RO(Receive Output)
dira[RSena] := 1 'MAX3430 RE/DE enable
outa[RSena] := 1 'set enable to TX mode RE/De high tx = 1
repeat
outa[RSTX] := 1
waitcnt(40_000_000+cnt)
outa[RSTX] := 0
waitcnt(40_000_000+cnt)

heliboy
12-14-2009, 08:17 AM
Thanks to all that responded. I have made some progress but not all the way. I can make it work connecting a commercial 232-485 converter to the propeller but not using the max3430. I have tried several chips so it is not a failed chip.

My test program is messy but it basically sends a command to turn the Dynamixel LED on and off periodically. I can read the Dynamixel response and it is correct. With the 3430 I get not LEDresponse and the Dynamixel response is all $FF ...

In the hope that someone will point out an obvious stupidity .. here is the code:

CON
· _clkmode····· = xtal1 + pll16x
· _xinfreq····· = 5_000_000
· DelayMs······ = 2000
· TXPin········ = 1
· RXPin········ = 2
· DirPin······· = 0
· LEDpin······· = 16
· MaxRespStr··· = 20

OBJ
· ser·· :······ "Parallax Serial Terminal"
· ser2· :······ "FullDuplexSerial"··

VAR
· byte INchar
· Byte RESPStr[MaxRespStr]
· byte LEDOn


PUB begin | i,j
· waitcnt(clkfreq*2 +cnt)·
· HIGH(DIRPin)
· HIGH(LEDPin)
· ser2.start(RXPin, TXPin, %0011, 57_600)
· ser.start(115200)
· ser.Str(String("Dynamixel TEST..."))····
· waitcnt(clkfreq*2 +cnt)
· repeat
··· HIGH(LEDPIn)
··· ser2.RxFlush
··· ser.str(String("Sending.."))
··· HIGH(DIRPin)
'··· waitcnt(clkfreq/10+cnt)
··· LED(LEDOn)
··· LOW(DIRPin)
··· LOW(LEDPin)
··· INchar := ser2.rxtime(100)
··· ser.str(String("RCX.."))·
····· if InChar > -1
······· i:=0
······· repeat 10
·········· ser.hex(Inchar,2)
·········· InChar:=ser2.rxtime(100)
·········· i:=1+1
··· waitcnt(clkfreq/1000*DelaymS +cnt)
··· !LEDOn


PUB LED(on)
· If on
··· ser2.tx($FF)
··· ser2.tx($FF)
··· ser2.tx($01)
··· ser2.tx($04)
··· ser2.tx($03)
··· ser2.tx($19)
··· ser2.tx($01)
··· ser2.tx($DD)·
· Else
··· ser2.tx($FF)
··· ser2.tx($FF)
··· ser2.tx($01)
··· ser2.tx($04)
··· ser2.tx($03)
··· ser2.tx($19)
··· ser2.tx($00)
··· ser2.tx($DE)·

·
PUB HIGH(Pin)
··· dira[Pin]~~
··· outa[Pin]~~
········
PUB LOW(Pin)
··· dira[Pin]~~
··· outa[Pin]~

Graham Stabler
12-14-2009, 08:23 AM
Have you done the electrical checks on the converter as suggested?

T Chap
12-14-2009, 09:38 AM
The chip does work with the Prop, you have something not connected right, you may need to check your termination, you should forget serial communication until you can toggle the A/B pins as I provided an easy test for.

Peter Jakacki
12-14-2009, 10:09 AM
heliboy said...
Thanks to all that responded. I have made some progress but not all the way. I can make it work connecting a commercial 232-485 converter to the propeller but not using the max3430. I have tried several chips so it is not a failed chip.

My test program is messy but it basically sends a command to turn the Dynamixel LED on and off periodically. I can read the Dynamixel response and it is correct. With the 3430 I get not LEDresponse and the Dynamixel response is all $FF ...

In the hope that someone will point out an obvious stupidity .. here is the code:

ser2.RxFlush
ser.str(String("Sending.."))
HIGH(DIRPin)
' waitcnt(clkfreq/10+cnt)
LED(LEDOn)
LOW(DIRPin)
LOW(LEDPin)



You have to enable the TE of the RS485 chip before you send and then you only want to turn it back off again after the transmit buffer is empty or a suitable delay. The way you have it there is a timing problem as the the string will start transmitting while the RS485 TE is off.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*

heliboy
12-14-2009, 10:56 AM
Yup. You guys know it all. Just a matter of timing (Isn't that what life is all about!). I added a 2mS delay to hold TE after the TX command and all is well. Once I get the whole Dynamixel RX object done·I will post for posterity.

Thanks to all.

T Chap
12-14-2009, 12:57 PM
I see what was happening to you. Coincidentally today I had just gone out and bought a crimp tool, some connectors, and CAT5e cable to do my own first ever tests with RS485. After getting all the connections dialed in, I started testing with the MAC sending out a querry to the Prop like this MAC>FT232RL>MAX3430 ----------- MAX3430<Prop. The prop was displaying fine what it was receiving from the MAC, however, the MAC was showing that there was an error reading in the response, but it was getting in a partial response.

I remembered what you said about the delay, and now I see the issue. When you launch the serial object in another cog, that cog is operating on it's own when you send if commands to TX something. So when you say ser.str("long string here"), and immediately tell the enable to go back to LOW, the enable is going LOW before the other cog is finished sending the string. So, you set a delay after the TX and wait until there is sufficient time for the serial object to complete sending the string, then turn off the enable pin.

I have had this RS485 on these boards for a year and have never tested it till today. I don't know why this is but for some reason it is still exciting to get some new process working for the first time.