Driving an LTC485 - code check?

xanatos · 2013-09-22 13:32

I think I'm doing this all correctly, but the device I'm trying to communicate with isn't responding at all. I'm wondering if anyone sees anything obviously wrong in my code below...

I'm SEROUTing from a BS2sx through an LTC485, which then connects directly to an ICPCON 7017C.

I have the tx & rx enables all set on my code below and I can see data going out...

I have the ICPCON 7017C in "init" mode, which sets it to 9600 baud, address 00. The command string I am sending is actually a string... $002, where the delimiting character is a $, the 00 is the address, and the 2 is a command telling the ICPCON 7017 to read back its configuration data.

I get not a single byte back on the SERIN line.

Code and datasheets below. Note that a few tried-and-failed versions of my SEROUT string are commented out after the last version in there... grasping at straws

' =========================================================================
'
'   File...... RS485_CommTester.bsx
'   Purpose... Development of RS485 network
'   Author.... David Xanatos, Xanatronics
'   E-mail.... xanatos@xanatos.com
'   Started... 09-22-2013
'   Updated... 09-22-2013
'
'   {$STAMP BS2sx}
'   {$PBASIC 2.5}
'
' =========================================================================
' -----[ Constants ]-------------------------------------------------------

#SELECT $STAMP
  #CASE BS2, BS2E, BS2PE
    T2400       CON     396
    T9600       CON     84
    T19K2       CON     32
  #CASE BS2SX, BS2P
    T2400       CON     1021
    T9600       CON     240
    T19K2       CON     110
  #CASE BS2PX
    T1200       CON     3313
    T2400       CON     1646
    T4800       CON     813
    T9600       CON     396
    T19K2       CON     188
    T38K4       CON     84
#ENDSELECT

' -----[ I/O Definitions ]-------------------------------------------------

  Spin          PIN     0               ' Spinneret SIO
  TXin          PIN     1               ' Transmit Data out to LTC485.4
  RXout         PIN     2               ' Receive Data in from LTC485.1
  TXen          PIN     3               ' High to tx
  RXen          PIN     4               ' Low to rx
' -----[ Variables ]-------------------------------------------------------

  serStr        VAR     Byte(11)

' -----[ Initialization ]--------------------------------------------------

  OUTPUT Spin
  OUTPUT TXin
  INPUT RXout
  OUTPUT TXen
  OUTPUT RXen
  Spin = 0
' -----[ Program Code ]----------------------------------------------------

  Main:

  DO
      'DEBUGIN cmdStr
      LOW RXen   'HIGH = disable rx; LOW = enable rx
      HIGH TXen  'HIGH = enable tx; LOW = disable tx
      DEBUG "Sending....", CR
      SEROUT TXin, T9600, [$24, $0, $0, $2, $0D]  '["$012"]  '[$24, $00, $2, $0D]
      LOW TXen  'HIGH = enable tx; LOW = disable tx
      LOW RXen  'HIGH = disable rx; LOW = enable rx
      DEBUG "Receiving....", CR
      SERIN RXout, T9600, [STR serStr\11]
      PAUSE 2000
      'SERIN Ctx, T9600, [WAIT("10"), SKIP 28, STR serStr\11, SKIP 26, STR serStr2\2]
      DEBUG "Output = ", STR serStr, " ", CR
  LOOP
  STOP

LoopyByteloose · 2013-09-22 14:36

Hi,
Just from my own experience with building RS485 from scratch, I suggest you consider first using an RS232 to RS485 converter with something like Terraterm on a PC to verify your wiring is right.

Then swap to the BS2sx.

You just might be thinking the software is failing you and presumed the wiring is AOKAY.

Nothing is worse than spending a lot of time trying to sort out software code only to find that the hardware was the problem that needed to be sorted first.

++++++++++
Once burned, twice shy.
I now follow careful stepped procedures that include loop back tests to catch problems in wiring.

Of course, you might be more skilled or just luckier than I am. When I skip all this, it generally doesn't work.

Franklin · 2013-09-22 14:49

You could also reduce your pin count by combining the rxen and txen pins since one pin is active low and the other is active high.

Phil Pilgrim (PhiPi) · 2013-09-22 14:50

First impression: there's no need to switch /RXen with a BASIC Stamp, and it just wastes time and a pin. Tie it low. The Stamp will '"receive" everything you transmit, but it makes no difference. It won't be listening anyway.

More importantly, though, $012<CR> is not [$24, $0, $0, $2, $0D] (or even [$24, $0, $1, $2, $0D]), but simply ["$012", $0D]. IOW, the device expects the commands to be in ASCII, not binary. (See page 62 of the datasheet.)

Pursuant to Loopy's suggestion: it might work, or it might not. Many control devices have very short timeouts for their commands. Trying to type a command from a terminal program may be too slow. This has burned me more than once. IOW, I would stick with the way you're doing it.

Finally -- especially if you're driving a long cable -- use termination resistors (120-ohm) across the RS485 leads at both ends. (To save power, you can put the resistors in series with 0.01uF caps.)

-Phil

xanatos · 2013-09-22 16:04

Thanks folks. Regarding wiring, see photo attached. The unit is right here, not out on a network somewhere... yet

Phil, I just tried the SEROUT as here:

SEROUT TXin, T9600, ["$002", $0D]

Still nothing. I have also tried with and without the resistor, no change. I've even tried swapping the two 485 A and B wires to no avail.

Also, re: enable lines, I originally did have them tied, but in trying various things, I got to wondering if there might be something wrong about that, so i took direct control of them, just in case. That also changed nothing.

I'm certain it's something I'm doing because both units respond identically. Dead silence.....

Open to any other ideas.......

Phil Pilgrim (PhiPi) · 2013-09-22 16:49

Have you connected the ground of the device to the Stamp's ground?

Do you have an oscilloscope that you can use to verify the RS485 output?

You have a very complicated-looking setup there. Why not test first with it stripped to its absolute bare essentials of BASIC Stamp, LTC485, and ICP device, with their needed power supplies -- and with a minimum of wiring jumps?

-Phil

xanatos · 2013-09-22 17:06

That actually is the setup you see. The ICP device does connect into a terminal strip, but that's just a straight pass through. And I do have a Spinneret on the development board, but it isn't connected to anything. What you see there is the stamp, connected directly to the LTC485, which jumps once to the wires for the 485 network because they're a heavier gauge, and I have a few dedicated holes on my PDB that I've ruined by stuffing fat gauge wire in them, so I like to reuse those holes rather than make new ones

That's it. The PDB has a lot of other stuff on it, but unless you wire them in, they're not actually connected to anything. Are you saying I should try wiring it up on another board that is NOT the PDB?

I do have a common ground between the stamp, ltc and ICP device.

Also, I only have a crappy little DS Nano for a scope... but that should change soon. I'm monitoring the outputs with LEDs to check for data, but I disconnect them once I see that data is present, and try the link proper.

Phil Pilgrim (PhiPi) · 2013-09-22 17:24

Are you sure that the ICP device isn't currently configured to require a checksum? Let's see the program that you're testing with now.

-Phil

xanatos · 2013-09-22 17:36

Hi Phil,

The ICP 7017c is in INIT mode, which is accomplished by a switch on the back of the device. When in INIT mode, it forces communications to be 9600 baud, 8N1, at address 00, with NO checksum, and using the DCON protocol. Sending that $002 *should* get a response string of several bytes. I don't even get one.

The test program I'm using is posted up in the first post, but I've edited it slightly to try a few things (and to reflect that the RXen is now hard-wired low):

' =========================================================================
'
'   File...... RS485_CommTester.bsx
'   Purpose... Development of RS485 network
'   Author.... David Xanatos, Xanatronics
'   E-mail.... xanatos@xanatos.com
'   Started... 09-22-2013
'   Updated... 09-22-2013
'
'   {$STAMP BS2sx}
'   {$PBASIC 2.5}
'
' =========================================================================
' -----[ Constants ]-------------------------------------------------------

#SELECT $STAMP
  #CASE BS2, BS2E, BS2PE
    T2400       CON     396
    T9600       CON     84
    T19K2       CON     32
  #CASE BS2SX, BS2P
    T2400       CON     1021
    T9600       CON     240
    T19K2       CON     110
  #CASE BS2PX
    T1200       CON     3313
    T2400       CON     1646
    T4800       CON     813
    T9600       CON     396
    T19K2       CON     188
    T38K4       CON     84
#ENDSELECT

' -----[ I/O Definitions ]-------------------------------------------------

  TXin          PIN     1               ' Transmit Data out to LTC485.4
  RXout         PIN     2               ' Receive Data in from LTC485.1
  TXen          PIN     3               ' High to tx
' -----[ Variables ]-------------------------------------------------------

  serStr        VAR     Byte(11)

' -----[ Initialization ]--------------------------------------------------

  OUTPUT TXin
  INPUT RXout
  OUTPUT TXen

' -----[ Program Code ]----------------------------------------------------

  Main:

  DO
      HIGH TXen  'HIGH = enable tx; LOW = disable tx
      DEBUG "Sending....", CR
      SEROUT TXin, T9600, ["$012", $0D]  
      LOW TXen  'HIGH = enable tx; LOW = disable tx
      DEBUG "Receiving....", CR
      SERIN RXout, T9600, [STR serStr\11]
      PAUSE 2000
      DEBUG "Output = ", STR serStr, " ", CR
  LOOP
  STOP

Phil Pilgrim (PhiPi) · 2013-09-22 19:30

Get rid of your DEBUG "Receiving...." line. It's probably sending stuff while the ICP is transmitting, so you'd miss the entire transmission.

-Phil

T Chap · 2013-09-22 20:30

SERIN RXout, T9600, [STR serStr\11]

Is this code waiting indefinitely for a reply? If so does this specify how many bytes to wait for?

stamptrol · 2013-09-23 05:40

It may be time to set up a test circuit and try to get two stamps to talk over the 485 link. That will confirm that the logic and circuitry is sound.

Once that's done, you'll know that the issue is only talking/listening to the ICPCON.

Cheers,

xanatos · 2013-09-23 08:17

Official notice: I'm an idiot.

Phil... yes, the DEBUG line was probably contributing... but I failed completely to see I had a 100ms PAUSE in there as well.

This is why, no matter how good you are, a second set of eyes is enormously helpful.

Thank you all.... everything is working now. Going to go hang my head in shame...

T Chap · 2013-09-23 08:27

What will also catch you using RS485 is when you send a request from the master to the slave, and the slave is talking over the time it takes for you toggle to receive mode. So your slave needs to have a delay time to account for the master needing to flip modes.

Driving an LTC485 - code check?

Comments