struggling with v.6 board – firmware?

[ei8htohms]

I just recently wired up my TinyG v.6 board to my Sherline lathe/mill. This is actually the same rig Nick Manousos sought help with 2 years ago and it turned out rolling back the driver worked for him. He’s a Mac guy and I’m having no luck with Windows 7 or Lubuntu.

I can get CoolTerm (Win7) to deliver gcode, but only about 40 or so lines at a time and even then unreliably (it seems to want to drop the last line and then lock up, forcing me to restart and reset to 0,0,0 etc.). I can’t get tgFX to send code to the TinyG at all although it is eager to update my firmware, something that is presumably stymied by the absence of a bootloader.

Linux is no joy at all with CoolTerm but I haven’t labored through the tgFX installation process yet. I can get screen to get a receiving message from the TinyG but can’t send code.

Seems like I should probably send this board in to get a bootloader installed and some updated firmware, right?

Thanks for your help!

_john

[cmcgrath5035]

Hmmm, I am not 100% familiar with V6 hardware, but some observations and ideas that might help.

Your CoolTerm issues might be caused by a flow control mis-match?
Check the flow control state in tinyG, parameter $ex.
Set same in CoolTerm. The most recent tinyG FW builds use RTS/CTS. I have no idea what your FW might specify.

tgFX might not be of much use to you until you get your FW updated.
The most functional versions of tgFX require FW 412.1 or higher.
I believe you are correct – that tgFX uses the bootloader to do its upgrades so that will not work for you.
And, the tgFX-tinyG interface only works when tinyG is 412.1 or higher.

I have had good luck updating FW using AVRDUDE on Linux.

I never bothered to get Coolterm working on Linux

In this thread I describe using putty and plink for gcode sending

https://www.synthetos.com/topics/tests-with-updated-tinyg-and-tgfx-versions-linux-environment/#post-5701

See if any of this helps.

• This reply was modified 10 years, 6 months ago by cmcgrath5035.

[ei8htohms]

I took a quick look at Putty but have not yet downloaded Plink, I’ll give that a try.

How can I read the flow control state for the TinyG? Is that something a command through CoolTerm should be able to report back to me?

Thanks for your help!

[mcgyvr]

just type $ in the coolterm and hit enter
or $$ to return all settings

[cmcgrath5035]

On openSUSE (I run 13.1/KDE), plink is installed by the putty RPM.
That probably varies by distro.
Check your installed programs.

To add to mvgyvr’s comments,
if you enter $ex and [CR] tinyG will report the current setting for $ex.

To set to something else, enter $ex=(setting you want) [CR]

It is a good idea to keep a list of all the parameters around.
In Coolterm (or putty), $$ [CR] then copy and paste the console output to a text file. Try to make a current copy when you change things.

[ei8htohms]

OK, this looks promising. When I read the settings from the TinyG, enable_xon_xoff was set to 0, so I set it to 1 and turned it on in Cool Term also. Now my settings report:

tinyg[mm] ok> [fb]  firmware_build            338.11
[fv]  firmware_version            0.93
[si]  status_interval           100 ms [0=off]
[gpl] gcode_select_plane          0 [0,1,2]
[gun] gcode_units_mode            1 [0,1]
[gco] gcode_coord_system          1 [1-6]
[gpa] gcode_path_control          2 [0,1,2]
[gdi] gcode_distance_mode         0 [0,1]
[ea]  enable_acceleration         1 [0,1]
[ja]  junction_acceleration  100000 mm
[ml]  min_line_segment            0.080 mm
[ma]  min_arc_segment             0.100 mm
[mt]  min_segment_time         5000 uSec
[ic]  ignore_CR (on RX)           0 [0,1]
[il]  ignore_LF (on RX)           0 [0,1]
[ec]  enable_CR (on TX)           0 [0,1]
[ee]  enable_echo                 0 [0,1]
[ex]  enable_xon_xoff             1 [0,1]

Of course I also enabled XON in CoolTerm and it seems to now be able to run the complete code (well, as far as I had the patience to sit through without cutting anything yet, yea!).

So do I need to do anything with these?

[ic]  ignore_CR (on RX)           0 [0,1]
[il]  ignore_LF (on RX)           0 [0,1]
[ec]  enable_CR (on TX)           0 [0,1]
[ee]  enable_echo                 0 [0,1]

I don’t really understand what these are doing exactly and how they will affect either the gcode I write or the commands I’ll send to the TinyG.

Thanks for the awesome help so far, you guys have made my life vastly better already!

• This reply was modified 10 years, 6 months ago by ei8htohms.
• This reply was modified 10 years, 6 months ago by ei8htohms.

[cmcgrath5035]

So do I need to do anything with these?

[ic] ignore_CR (on RX) 0 [0,1]
[il] ignore_LF (on RX) 0 [0,1]
[ec] enable_CR (on TX) 0 [0,1]
[ee] enable_echo 0 [0,1]

I don’t really understand what these are doing exactly and how they will affect either the gcode I write or the commands I’ll send to the TinyG.

I don’t think so; I believe they are there to tweak legacy issues interfacing with terminal emulator programs.
Perhaps someone else will comment.

Keep on chugging!

[ei8htohms]

Well, looks like I spoke too soon. At least with the spindle running, it can still only get through maybe 50 lines of code. The fact that it seems to be able to get farther with the spindle off has me curious if I’m having EMI issues also, so I may try to reduce some of the possible sources of interference before sending the board in. Two steps forward, one step back I reckon.

[cmcgrath5035]

Difficult to say where to go next.
EMI/interference is of course possible and shielding might help.

Try running the job in air, spindle on several times.
Always stop in the same place?
Then probably not EMI.

You could try to slow down the velocities.
The most recent FWs have transitioned to RTS/CTS flow control, which may not be available with your Ver 0.93 FW

[mcgyvr]

Run it with the spindle off/out of the way ( a few times)..
If it makes it through.. then you have a noise problem caused by the spindle.

If it doesn’t it could be noise from stepper motor cabling or other sources still..
Do you have limit/homing switches wired? (disconnect them and try running the file)

Are you stepper cables shielded?
Are your limit switch cables shielded?
I had bad noise issues with a V7 board and had to redo all wiring to shielded and add capacitors across the switch inputs for some additional filtering.

http://www.cnccookbook.com/CCCNCNoise.html

[ei8htohms]

Yeah, I’ve definitely got an EMI problem. I switched all the stepper wires to shielded cables, put ferrite beads on the power cable and USB cable and it still can’t run the code all the way through with the spindle running and often with some weird anomalous behavior before it just stops.

I’m not using end stops at all, so I’m thinking my next step may be to ground the shielding on the stepper cables. Can I ground those to the TinyG board or do I need to ground them to the PSU somehow?

Perhaps I need a metal enclosure for the board to act as a Faraday cage?

Thanks!

[cmcgrath5035]

I ground all shields at the tinyG end – do NOT ground both ends of the shield; the shield becomes a long antenna (a.k.a. ground loop).

Do you have the microswich (home,max switches) disabled?

I run a v7 tinyG, shielded cables to steppers but no other exotic shielding.
What sort of spindle are you using?
The Gcode seems to run OK with spindle off, correct?

[ei8htohms]

OK, I grounded the shielding for the steppers (on the TinyG side only) to the chassis of PSU and disabled all switches (xsm, ysm zsm and asm; they were all set to 1 previously, so I don’t think that should have made a difference). I also took out the transmit delays.

The spindle I’m using it the Sherline motor with a 10,000 RPM pulley upgrade.

http://www.sherline.com/33050pg.htm

Yes, the code runs fine with the spindle off.

I even tried moving the board a few feet further from the motors and still no luck.

I’m really starting to suspect the janky wiring in my apartment building may be part of the problem. It’s a pre-war, Art Deco building and almost all of the outlets are only two prong. I’m running both the board and the spindle off of separate extension cords to two of our only outlets that are grounded however and still having the same problem. My next step may be purchase a power conditioner and/or put the board in a metal enclosure in the hopes of getting some Faraday cage protection.

As a point of interest, when it froze up this time, I uplugged the USB so that CoolTerm would unfreeze and when I plugged the USB back in and told CoolTerm to reconnect (the spindle was off, but I did not reset the TinyG) and sent a G28 command it ran several more lines of the original text file before executing the G28. Weird. Don’t know what to make of that.

• This reply was modified 10 years, 6 months ago by ei8htohms.

[cmcgrath5035]

Interesting. Are you sure that the frame of the power supply is actually connected to anything? I think normally it would be the third wire of the AC inlet, which your don’t have.

I have the shields connected to DC- at tinyG, but there is no guarantee that is the best solution.

Conducted (powerline) emissions can be real tough to diagnose, even in a three wire world., Power supplies, to meet FCC rules, should have reasonable outgoing (conducted back on the input mains) emissions, but those mitigation techniques may be compromised in your two wire environment.

Most all power supplies are now electronic AC to DC converters. Might be interesting to try an old linear (transformer) supply,if you have one or could borrow. Know anyone into Ham radio? Those folks frequently have power filters in their experimental bag of tricks.

• This reply was modified 10 years, 6 months ago by cmcgrath5035.

[ei8htohms]

This is a good question. I have no idea if the frame of the PSU is connected to anything. I tried connecting the ground for the shields to the body of the mill also (the bed of the lathe actually in this instance), but I don’t think that’s connected to anything either. I guess I’ll try the DC- on the TinyG next. Thanks!

[Author]

Posts