XBee serial attachment to TinyG

Started by timnoble2 on Oct 31, 2013 in TinyG Support. 9 replies, last activity Nov 6, 2013.

timnoble2 Oct 31, 2013 #

Hi folks,
I'm using a tinyG to control the action of a large robotic chalkboard for an art piece. After much frustration with older Makerbot Electronics and a very pleasant experience working with a GRBL-shield, I decided to make the jump to TinyG. So far, it's great.

My one unfulfilled desire is to operate this machine wirelessly using a matched pair of xbee radios. As such, I soldered 4 header pins into the RX, TX, 3.3V and GND holes near the USB port and attached my XBee. So far, I haven't been able to get the TinyG to respond to commands sent from a computer attached via USB to the other Xbee. Any ideas about why this may be?

Some more detail: I have done this before with other arduino-based projects. Connecting the RX/TX pins on the GRBL shield to their complements (TX/RX)on an XBee works fine and the connection is essentially seamless. I set the baud rate at 115200 to match the tinyG's setting. For whatever reason, this isn't working. Do the RX and TX mean something different? Has anybody else tried this?

Thanks in advance for your help and advice.
More detail of the project (using older boards) can be seen here:
http://acmespectacle.cc/portfolio-items/semi-automatic-chalkboard/

timnoble2 Oct 31, 2013 #

after a bit more testing, i can report that it does work to attach an XBee to tinyG. However, i am experiencing a few issues with smooth communication. One is that at the high baudrate which tinyG defaults to (115200), I don't seem to receive all of the response from the usual "$$" query. Instead, I get most of it, but lots is lost in the process. I went ahead and reduced the baudrate on both XBees and the tinyG to 38400 and I found that I got more of the expected response, but still experienced choppiness and lost characters. Pasted below is the result.

I'm open to suggestions as to what is causing this. Next step will be to reduce the baudrate further all around and see if that makes the communicaiton more reliable. Can anyone see potential drawbacks to this? Are there perhaps persuasive reasons not to? Was 115200 chosen for a particular reason?

Also, and this is vexing, I cannot seem to retain my changes to tinyG's baudrate. On reset, it reverts to 115200. Is there something I'm missing to "burn" the setting into memory?

Thanks!

[fb]  firmware build            380.08
[fv]  firmware version            0.96
[hv]  hardware version            8.00
[id]  TinyG ID                    1H4973-DSU
[ja]  junction acceleration  100000 mm
[ct]  chordal tolerance           0.001 mm
[st]  switch type                 0 [0=NO,1=NC]
[mt]  motor disble timeout       60 Sec
[ej]  enable json mode            0 [0=text,1=JSON]
[jv]  json verbosity              4 [0=silent,1=footer,2=messages,3=configs,4=linenum,5=verbose]
[tv]  text verbosity              1 [0=silent,1=verbose]
[qv]  queue report verbosity      0 [0=off,1=filtered,2=verbose]
[sv]  status report verbosity     1 [0=off,1=filtered,2=verbose]
[si]  status interval           250 ms
[ic]  ignore CR or LF on RX       0 [0=off,1=CR,2=LF]
[ec]  expand LF to CRLF on TX     0 [0=off,1=on]
[ee]  enable echo                 0 [0=off,1=on]
[ex]  enable flow control         1 [0=off,1=XON/XOFF, 2=RTS/CTS]
[baud] USB baud rate              3 [1=9600,2=19200,3=38400,4=57600,5=115200,6=230400]
[gpl] default gcode plane         0 [0=G17,1=G18,2=G19]
[gun] default gcode units mode    1 [0=G20,1=G21]
[gco] default gcode coord system  1 [1-6 (G54-G59)]
[gpa] default gcode path control  2 [0=G61,1=G61.1,2=G64]
[gdi] default gcode distance mode 0 [0=G90,1=G91]
[1ma] m1 map to axis              0 [0=X,1=Y,2=Z...]
[1sa] m1 step angle               1.800 deg
[1tr] m1 travel per revolution   40.900 mm
[1mi] m1 microsteps               8 [1,2,4,8]
[1po] m1 polarity                 1 [0=normal,1=reverse]
[1pm] m1 power management         1 [0=remain powered,1=shut off when idle]
[2ma] m2 map to axis              0 [0=X,1=Y,2=Z...]
[2sa] m2 step angle               1.800 deg
[2tr] m2 travel per revolution   40.900 mm
[2mi] m2 microsteps               8 [1,2,4,8]
[2po] m2 polarity                 1 [0=normal,1=reverse]
[2pm] m2 power management         1 [0=remain powered,1=shut off when idle]
[3ma] m3 map to axis              1 [0=X,1=Y,2=Z...]
[3sa] m3 step angle               1.800 deg
[3tr] m3 travel per revolution   11.000 mm
[3mi] m3 microsteps               8 [1,2,4,8]
[3po] m3 polarity                 0 [0=normal,1=reverse]
[3pm] m3 power management         1 [0=remain powered,1=shut off when idle]
[4ma] m4 map to axis              2 [0=X,1=Y,2=Z...]
[4sa] m4 step angle               1.800 deg
[4tr] m4 travel per revolution    2.000 mm
[4mi] m4 microsteps               8 [1,2,4,8]
[4po] m4 polarity                 0 [0=normal,1=reverse]
[4pm] m4 power management         1 [0=remain powered,1=shut off when idle]
[xam] x axis mode                 1 [standard]
[xvm] x velocity maximum        600.000 mm/min
[xfr] x feedrate maximum        600.000 mm/min
[xtm] x travel maximum          150.000 mm
[xjm] x jerk maximum       20000000 mm/min^3
[xjh] x jerkhoming        20000000 mm/min^3
[xjd] x junction deviation        0.0500 mm (larger 
[xsn] x switch min                1 [0=off,1=homing,2=limit,3=limit+homing]
[xsx] xx                0 [0=off,1=homing,2=limit,3=limit+homing]
[xsv] x search velocity  .000 mm/min
[xlv] x latch velocity          100.000 mm/min
[xlb] x latch backoff       2.000 mm
[xzb] x zero backoff              1.000 mm
[yam] y axis mode            andard]
[yvm] y velocity maximum        600.000 mm/min
[yfr] y feedrate maximum     m/min
[ytm] y travel maximum          150.000 mm
[yjm] y jerk maximum       200000003
[yjh] y jerk homing        20000000 mm/min^3
[yjd] y junction deviation        0.0500 mm (larger is faster)
[ysn] y switch min                1 [0=off,1=homing,2=limi+homing]
[ysx] y switch max                0 [0=off,1=homing,2=limit,3=limit+homing] search velocity         500.000 mm/min
[ylv] y latch velocity          100.000 mm/m[ylb] y latch backoff             2.000 mm
[yzb] y zero backoff              1.000 mm
[zam] z axis mode                 1 [standard]
[zvm] z velocity maximum        600m/min
[zfr] z feedrate maximum        600.000 mm/min
[ztm] z travel maximum         00 mm
[zjm] z jerk maximum       20000000 mm/min^3
[zjh] z jerk homing        200000in^3
[zjd] z junction deviation        0.0500 mm (larger is faster)
[zsn] z switch m        0 [0=off,1=homing,2=limit,3=limit+homing]
[zsx] z switch max                ,1=homing,2=limit,3=limit+homing]
[zsv] z search velocity         400.000 mm/min
[zlatch velocity          100.000 mm/min
[zlb] z latch backoff             2.000 mm
[zzz zero backoff              1.000 mm
[aam] a axis mode                 3 [radius]
[alocity maximum     172800.000 deg/min
[afr] a feedrate maximum     172800.000 deg/mitravel maximum           -1.000 deg
[ajm] a jerk maximum     5760000000 deg/min^3
[a jerk homing      5760000000 mm/min^3
[ajd] a junction deviation        0.0500 deg ( faster)
[ara] a radius value              0.1989 deg
[asn] a switch min            [0=off,1=homing,2=limit,3=limit+homing]
[asx] a switch max                0 [0=off,1=limit,3=limit+homing]
[asv] a search velocity         600.000 deg/min
[alv] a latchocity          100.000 deg/min
[alb] a latch backoff             5.000 deg
[azb] a zckoff              2.000 deg
[bam] b axis mode                 0 [disabled]
[bvm] b city maximum       3600.000 deg/min
[bfr] b feedrate maximum       3600.000 deg/min
 b travel maximum           -1.000 deg
[bjm] b jerk maximum       20000000 deg/min^3 junction deviation        0.0500 deg (larger is faster)
[bra] b radius value            1.0000 deg
[cam] c axis mode                 0 [disabled]
[cvm] c velocity maxi  3600.000 deg/min
[cfr] c feedrate maximum       3600.000 deg/min
[ctm] c travel ma     -1.000 deg
[cjm] c jerk maximum       20000000 deg/min^3
[cjd] c junction devian        0.0500 deg (larger is faster)
[cra] c radius value              1.0000 deg
[p1frq] pwm frequency           100.000 Hz
[p1csl] pwm cw speed lo        1000.000 R[p1csh] pwm cw speed hi        2000.000 RPM
[p1cpl] pwm cw phase lo           0.125 1]
[p1cph] pwm cw phase hi           0.200 [0..1]
[p1wsl] pwm ccw speed lo       100M
[p1wsh] pwm ccw speed hi       2000.000 RPM
[p1wpl] pwm ccw phase lo          0.125 [0..1]
[p1wph] pwm ccw phase hi          0.200 [0..1]
[p1pof] pwm phase off        0.100 [0..1]
[g54x] g54 x offset               0.000 mm
[g54y] g54 y offset           0.000 mm
[g54z] g54 z offset               0.000 mm
[g54a] g54 a offset             0.000 deg
[g54b] g54 b offset               0.000 deg
[g54c] g54 c offset        0.000 deg
[g55x] g55 x offset              75.000 mm
[g55y] g55 y offset             75.000 mm
[g55z] g55 z offset               0.000 mm
[g55a] g55 a offset           g
[g55b] g55 b offset               0.000 deg
[g55c] g55 c offset               0.00g
[g56x] g56 x offset               0.000 mm
[g56y] g56 y offset               0.000 mm
[g56z] g56 z offset               0.000 mm
[g56a] g56 a offset               0.0] g56 b offset               0.000 deg
[g56c] g56 c offset               0.000 deg
[g57x] g57 x offset               0.000 mm
[g57y] g57 y offset               0.000 mm g57 z offset               0.000 mm
[g57a] g57 a offset               0.000 deg
[g5g57 b offset               0.000 deg
[g57c] g57 c offset               0.000 deg
[g5 offset               0.000 mm
[g58y] g58 y offset               0.000 mm
[g58z] g58ffset               0.000 mm
[g58a] g58 a offset               0.000 deg
[g58b] g58 offset               0.000 deg
[g58c] g58 c offset               0.000 deg
[g59x] g5x offset               0.000 mm
[g59y] g59 y offset               0.000 mm
[g59z] g5               0.000 mm
[g59a] g59 a offset               0.000 deg
[g59b] g59 b off              0.000 deg
[g59c] g59 c offset               0.000 deg
[g92x] g92 x off           0.000 mm
[g92y] g92 y offset               0.000 mm
[g92z] g92 z offset               0.000 mm
[g92a] g92 a offset               0.000 deg
[g92b] g92 b offse            0.000 deg
[g92c] g92 c offset               0.000 deg
[g28x] g28 x location             0.000 mm
[g28y] g28 y location             0.000 mm
[g28z] g28 z location             0.000 mm
[g28a] g28 a location             0.000 deg
[g28b] g28 b ion             0.000 deg
[g28c] g28 c location             0.000 deg
[g30x] g30 x lion             0.000 mm
[g30y] g30 y location             0.000 mm
[g30z] g30 z loc            0.000 mm
[g30a] g30 a location             0.000 deg
[g30b] g30 b locati       0.000 deg
[g30c] g30 c location             0.000 deg
tinyg [mm] ok>

cmcgrath5035Staff Nov 1, 2013 #

Just a thought for you to contemplate until Riley or Alden pop in.

In fixing something in the most recent build of tgFX, Riley had to change flow control to RTS/CTS, away from Xon/Xoff. Since your problem sounds like buffer over run, perhaps you can experiment on that path?
That would be $ex=2.
Good luck

aldenStaff Nov 1, 2013 #

In your $$ dump flow control is set to Xon/Xoff. Is your host observing this? I don't think RTS/CTS ($ex=2) is an option as the RX/TX/GND/3.3 wifi connection bypasses the FTDI USB chip, which emulates the RTS/CTS signals over USB.

RileyStaff Nov 3, 2013 #

Yah you are skipping the FTDI so flow control via $ex=1 or 2 is out. However, What you are experiencing is not flow control issues. I suspect this is noise on the 2.4ghz spectrum (900mhz? depending on your xbees). I am not sure if you have a logic analyzer but I am willing to bet if you tapped the tx lines on your tinyg you would see 100% complete commands going out... If you looked at your RX lines on your other recv hardware then you would see that its "dropping packets"

Just my guess. Try changing freq's or channels.

Riley

aldenStaff Nov 3, 2013 #

Slight correction. XON/XOFF ($ex=1) will work as the protocol is run entirely from the tinyg firmware and does not involve the FTDI. The The FTDI passes XON and XOFF characters through as it does any other serial character. Obviously the host needs to know handle XON/XOFF for this to be effective.

RTS/CTS ($ex=2) does involve the FTDI. The RTS and CTS signals are connected to the xmega pins, and the FTDI acts as a "translator" performing the USB flow control corresponding to the RTS/CTS transitions.

So in bypassing the FTDI by using the RX/TX directly XON/XOFF is available, whereas RTS/CTS is not.

timnoble2 Nov 3, 2013 #

Thanks for your help and advice. This certainly helps me narrow the causes of my communication issues. One variable that I just realized may be in play is copious electromagnetic interference from the massive power substation across the street from my studio. There's an ever-present audio hum in the air, so it stands to reason that the RF spectrum is a mess too.

Another possible cause for the weirdness with XBee is a mismatch of clock rates according to this post at Digi (makers of the XBee):
http://www.digi.com/support/forum/4787/using-the-xbee-at-115-200-baud-updated-16-march-2010

A baudrate of 9600 is pretty standard for a lot of xbee projects. If I were to change over to 9600, are there any concerns that this brings up for tinyG? is it perhaps too slow? For the purposes of my machine, I don't expect to be passing data back and forth very quickly or all that often, but I'd be interested in hearing about any unintended consequences this may create.

Thanks again!

RileyStaff Nov 3, 2013 #

Good point alden.

@tim,

Wow that really sucks that the 115200 is not "reliable". I would suggest you play with the baudrates. I for one have not tried other rates really. If you experience something "off" or "weird" let us know. I would also say to try to set your $si=250 or so to test it out.

ril3y

tomking505 Nov 6, 2013 #

>massive power substation across the street
>ever-present audio hum in the air
>it stands to reason that the RF spectrum is a mess too.

If the substation is close enough to be heard, what is the chance that your xbees aren't hearing it, too?

Have you taken your radios and TinyG home to try them without having a wideband radio transmitter across the street?

timnoble2 Nov 6, 2013 #

I haven't had a chance to remove the wireless radios and TinyG and test them elsewhere. Due to the deadlines I'm under with this piece, all the rewiring involved will have to wait until I'm at the museum and setting it up for real. At that point, however, I will give Xbee serial control another try and report back. In the meantime, I'm fighting with controlling the machine from a linux computer, which may end up in another forum thread soon too, since it's not going as smoothly as I'd like. Thanks for the interest and helpful suggestions, all!