Home › Forums › TinyG › TinyG Support › XBee serial attachment to TinyG
- This topic has 10 replies, 5 voices, and was last updated 11 years, 1 month ago by
timnoble2.
-
AuthorPosts
-
October 31, 2013 at 12:26 pm #4902
timnoble2
MemberHi 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/October 31, 2013 at 6:18 pm #4903Memberafter 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>November 1, 2013 at 8:00 am #4904cmcgrath5035
ModeratorJust 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 luckNovember 1, 2013 at 11:49 am #4905alden
MemberIn 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.
November 3, 2013 at 9:51 am #4909Riley
KeymasterYah 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
November 3, 2013 at 10:03 am #4910MemberSlight 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.
November 3, 2013 at 11:16 am #4911MemberSlight 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.
November 3, 2013 at 1:02 pm #4912MemberThanks 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!
November 3, 2013 at 3:33 pm #4913KeymasterGood 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
November 6, 2013 at 10:26 am #4917tomking505
Member>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?
November 6, 2013 at 1:37 pm #4919MemberI 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!
-
AuthorPosts
- You must be logged in to reply to this topic.
