Synthetos Shop

TinyG Doesn't move as intended

From the original Synthetos forum (2011–2025)

Started by TedBlack on in TinyG Support. 13 replies, last activity Jul 1, 2014.

TedBlack #

Hi,
I've been stuffing around for days on end trying to get this TinyG to work!
Can I mention that my first Shapeoko used an Arduino and Polulu steppers and worked flawless straight out the box!

Now I have gone through all your setup and configuration settings for this pile and set it up to be compatible with a shapeoko.
-I'm running a brand new 24V 10Amp power supply (which measures 24V at the outputs)
-There is a decent size 12V computer fan sitting underneath the board with adequate space above and below it.

*Problem 1:
I set up the motor current for nema23 on G0 command with max velocity as 16000 (the 10 o'clock position) works fine when moving fast. However try a G1 move at Feed rates less than 100 and the thing shits itself! If I lower the current right down to almost zero, I can find a spot that sometimes works on slow speeds, sometimes not.

*Problem 2:
With a feed rate of 1000, fairly modest speed, I can do a straight line with G1, 10 O'clock position on potentiometer. However G2, G3 arcs will just give you a diagonal straight line. Then, immediately after a G2 arc (straight line) you perform a G1 X10 straight line, and you get another diagonal straight line! As if there is some buffer holding the movements the last arc forgot to perform.

Now, before I swear and blame you, and only you, what's your excuse?
Kind Regards, :-)

cmcgrath5035Staff #

Ted
Needless to say, something sounds seriously wrong. There are still bugs being worked in tinyG, but basic moves as you describe should be executed OK for sure.

It is unclear how you are now configured. You WERE using an Arduino to directly drive your Polulu drivers, or via a G shield?
And you are NOW driving your motors directly from tinyG, or are you interfacing tinyG to Polulu stepper drivers to drive your motors?
I don't have direct experience with this setup, but wonder if you are aware that tinyG has 3.3V logic swings that may not be compatible with the Polulu drivers. There is a good wiki item on the topic of driving external stepper drivers from tinyG.

You reference pots at 10 o'clock a lot, which seems to imply you are driving motors directly from TinyG (unless Polulu have pots too). If that is the case, sort of have to ask-are you sure the motors are wired correctly?
I run NEMA 17s, and never changed pots from 12 o'clock until I ran into some very speed aggressive GCode. I'd suggest perhaps 1 o'clock as a good starting point for NEMA 23s.
Run fast, but don't run slow is sort a a new one on me; high speed is the usual trouble maker.

If this part of the setup is good, then we'll need some other info to help out:
tinyG hardware (V7, V8, etc) and FW build loaded
How do you interface to tinyG? (Win, MacOS, Linux)?
All three work, but troubleshooting tools are different on each platform.
How do you run GCode? (tgFX, Coolterm, putty, etc)
If tgFX, what build are you running?

TedBlack #

I am running the Stepper Drivers on TinyG.
This is my second Shapeoko and I have 4 x brand new Nema23 connected via 18Gauge wire directly to TinyG. Big 12V fan for cooling.
I communicate via CoolTerm. Standard Baud etc as you recommend in Github.
I've stayed away from all your other "beta" software.

Steppers are wired correctly. Besides if one coil was out of phase, or coil pairs were swapped it would just go in the wrong direction...

Current Setting:
If I increase the current above 10 O'clock then a G0 move will fail mid flight for X axis Motor 1.
I have 10:30am setting for the dual Y-Axis, Motor 2 & 3.
I believe I now have this as good as it gets.

I've tried performing an arc manually:
G2 X0 Y30 I0 J15 (a half circle, diameter 30mm, starting at bottom, end at top)
This draws me a vertical line upwards 30mm long. The Y-axis stepper lights blink away and the machine moves in a vertical straight line, however x-axis light does not come on during the move. Tried turning current up and down during the move and still no action from X-axis motor. Other arcs just give diagonal lines as mentioned and seem to have some moves stored in buffer memory and perform them on the next command.

Circle in MakerCam:
I have since drawn a 50mm circle in Makercam.com and it draws 7/8ths of a circle (yay) and then stops :-(
Drew a bigger circle and generated new code, stops in exactly the same spot on the circle :-P every time. Visually, code seems fine around the spot it stops! I checked the co-ordinates of the stop position and compared to G-code. I stops after a certain line of G-code. No errors found in the code before or after this spot!

Tried the Hello World from Shapeoko
Got through one letter I'm guessing ( I was drawing up in the air ) before the thing went spastic. It shot off real fast 100mm/4in (G0) in the Y direction and motors failed mid flight. So without the controlled deceleration it was one nasty stop when it failed. This move doesn't appear in the G-Code, so not sure why it did it. :-/

Here are my settings:

Line number: 0
X position: 0.000 mm
Y position: 0.000 mm
Z position: 0.000 mm
A position: 0.000 deg
Feed rate: 0.000 mm/min
Velocity: 0.000 mm/min
Units: G21 - millimeter mode
Coordinate system: G53 - machine coordinate system
Distance mode: G91 - incremental distance mode
Feed rate mode: G94 - units-per-minute mode (i.e. feedrate mode)
Motion mode: G80 - cancel motion mode (none active)
Machine state: Ready
[fb] firmware build 412.01
[fv] firmware version 0.97
[hp] hardware platform 1.00
[hv] hardware version 8.00
[id] TinyG ID 2X2660-FYX
[ja] junction acceleration 2000000 mm
[ct] chordal tolerance nan mm
[sl] soft limit enable 0
[st] switch type 0 [0=NO,1=NC]
[mt] motor idle timeout 10.00 Sec
[ej] enable json mode 0 [0=text,1=JSON]
[jv] json verbosity 0 [0=silent,1=footer,2=messages,3=configs,4=linenum,5=verbose]
[js] json serialize style 0 [0=relaxed,1=strict]
[tv] text verbosity 0 [0=silent,1=verbose]
[qv] queue report verbosity 0 [0=off,1=single,2=triple]
[sv] status report verbosity 0 [0=off,1=filtered,2=verbose]
[si] status interval 0 ms
[ec] expand LF to CRLF on TX 0 [0=off,1=on]
[ee] enable echo 0 [0=off,1=on]
[ex] enable flow control 0 [0=off,1=XON/XOFF, 2=RTS/CTS]
[baud] USB baud rate 5 [1=9600,2=19200,3=38400,4=57600,5=115200,6=230400]
[net] network mode 0 [0=master]
[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 0 [1-6 (G54-G59)]
[gpa] default gcode path control 0 [0=G61,1=G61.1,2=G64]
[gdi] default gcode distance mode 1 [0=G90,1=G91]

TedBlack #

Another thing:
After the Y-Axis stall, I tried reducing the Velocity_Max and Feedrate_Max to 1000 for Motor 1,2,3.

It said on Cool Term that the $xvm =1000 and $xfr = 1000.
However a G0 still went at a speed of about 16,000 as before, and the Feedrate could be increased to 10,000.
I then performed a G1 X100 and it indeed did move at 10,000.

So changing these speed limit settings in memory did nothing.

cmcgrath5035Staff #

Hmmm, the only thing I see on quick look is that Flow control,$ex, is set to off. Probably OK for line by line cli entry, probably not for sending Gcode files such as hello world.
Set $ex=2 (for RTS/CTS) and set Coolterm as well.

Can you dump all the tinyG parameters with a $$ command and put the results in a text file, post a link to it (dropbox or similar)?

Direct posting to the forum is hard to read. Result should look like this

https://dl.dropboxusercontent.com/u/50261731/2014-05-31_18.28.12-tinyg.conf

Your configuration is this (?)
Motor 1 - X axis
Motor 2 - Y axis
Motor 3 - Y axis reverse
Motor 4 - Z axis

jlauer #

Hi Ted,

I'd suggest trying the ChiliPeppr app to send. I put a lot of flow control into the app by watching the planner buffer on the TinyG. I also use the RTS/CTS flow control as another layer. Just go to http://chilipeppr.com/tinyg to run the app in your browser. You will have to download the Serial Port JSON server to your local box with the serial port, but can run the web app on any machine remotely.

Curious if this will solve your problem.
-John

TedBlack #

My motor config is as you mentioned above.

I still have three problems.

Can't do a single arc using G2 X0 Y30 I0 J15
Gives a straight line 30mm along X-axis left to right.

Motor timeout not working on files:
I tried the flow control and my full circle generated by makercam works. :-)
However, I have a 10 second inactivity timeout on my motors which normally works after a single command, but after sending a file some motors stay activated. (one time just the z-axis, another time all four motors)
I have even tried changing this to power down when idle on Motor1-4:
[1pm] m1 power management 1 [0=remain powered,1=power down when idle]
The thing still keeps all motors powered after sending a file
( but they now power down immediately after a single command).
The end of my file has an M5 and M30 command straight after the G-codes.
Problem still remains after removing these two commands....

Max_Velocity problem
I still have the problem of the max-velocity setting not working.
If I reduce max velocity on all motors to 1000 then I can still drive them at speeds of 16000!

Here is my $$ dump:
http://www.gerardscientific.com.au/Download/DoubleDollarDump.pdf
(Note this was before setting $ex = 2, $1pm =2 etc.)

This is my cool term settings: (is is correct?)
http://www.gerardscientific.com.au/images/Screenshot.png

John, I will try the chillipepper app when I have time

cmcgrath5035Staff #

TedB
1. Something is very wrong with your confgs - compare yours to this

https://dl.dropboxusercontent.com/u/50261731/2014-05-31_18.28.12-tinyg.conf

Those values may not be correct for you, but your file has numerous 'nan' entries that are bogus.
2. Try this: Reset tinyG (reset button) then in Coolterm enter $defa=1. This will reset the tinyG to factory defaults. Likely it will reset some values that you entered for your machine, they will have to be reentered. But should you continue to see 'nan' when you do a $$ dump, then you likely have a defective unit.
Reference

https://github.com/synthetos/TinyG/wiki/TinyG-Configuration-for-Firmware-Version-0.97

Assuming 2. works OK, read on:
3. Are your Limit switches really NO? NO is susceptible to noise. Try running your job with Limit switches disabled.
4. I assume you reversed the wiring on one of your Y motors, because the config says both motors 2 and 3 are set to the same polarity.
5. Your Coolterm settings "look" correct to me, but I am not a Coolterm user.
6. I would leave $?pm=0 for all motors. Should work, dissipates a little more power but that isn't you issue at the moment.

Good Luck

aldenStaff #

Thanks for the detailed information. Many points to cover, so bear with me. (this message overlapped Carl's - above - so there is some duplication)

First, your $$ settings are messed up, somehow. You should not be seeing the word 'nan' anywhere, and way too many things are set to 0. I recommend resetting them to defaults by issuing $defa=1. This will wipe all your settings and you will need to reset, but I think it's necessary.

Next, I recommend that you update your firmware to the latest edge build - currently 435.10. It can be found here: http://synthetos.github.io/

Third, the Coolterm settings look OK, as far as I'm familiar with windows. You do, however need flow control updated to XON. You currently have it turned as RTS/CTS and turned off on the board (may be a settings problem). I have updated this page with (hopefully) clearer instructions:
https://github.com/synthetos/TinyG/wiki/Connecting-TinyG#establish-usb-connection

Fourth, some other points on the settings:
- Try dropping junction acceleration [ja] down from 2M to 200,000, then crank it back up again once things are working.
- Set JSON verbosity [jv] to 3 (default). THis will allow you to see startup messages
- Set Text verbosity [tv] to 1 (default). Otherwise it's silent.
- Set flow control to XON [$ex=1]
- Note that on the new build the power management settings are different, as are some others. See here for reference:
https://github.com/synthetos/TinyG/wiki/TinyG-Configuration-for-Firmware-Version-0.97

Once you have done these things try your tests again.

Separately, Should I assume that you have previously entered a feed rate (e.g. F500) before the G2 X0 Y30 I0 J15 command?

The motor timeout should be working on the 435.xx builds - it does not work in 412.01

I have not had a chance to look at the max velocity issue but will check that out as well. I believe this is not a problem in the edge builds, but would like to verify.

aldenStaff #

Just confirmed that setting the max velocity does indeed work (e.g. $xvm=1000), so I suspect that is also related to the problems in the settings.

TedBlack #

Thanks for the continued replies :)
I have only changed the settings according to your setup for Shapeoko and Config instructions so I'm not sure why my factory shipped board has all these bogus nan settings... :(

I will reset the factory defaults and reprogram for my motors / shapeoko as the first step.

after that I'm thinking....

There are many bugs in this firmware I have, not just the settings.
I notice the last master firmware (meant to be 99.9% stable) seems way back: 380.08.
Will the latest "Edge" 435.10 be more stable than my 412.01? assuming my 410.01 is an older "Edge" firmware which probably isn't the best....?
Which Firmware should I go for?

My personal feedback:
I just want this thing to do simple machining. Not crazy rotational a,b,c axis and the likes.
When I purchased I imagined this board to have higher power stepper drivers for my Nema 23's and maybe a more advanced acceleration / jerk control added to the standard Grbl code.

If it were my project I would offer only simple benefits such as above to users over standard Grbl and provide very stable firmware with all the bugs ironed out to keep customers happy / provide high volume of sales.
Then if people with a major boner for all the crazy bells and whistles nobody needs then they can download the latest experimental Firmware and screw their shit up...?

aldenStaff #

I appreciate the feedback and agree with you. Our main focus now is stability. We are now in the process of hammering out the remaining bugs. We have made a lot of changes since the 380 builds and need them to be validated. Expect to see a series of edge releases that address issues from our own testing as well as feedback we get from users. This will lead to another master push.

As for the settings - is it possible that the board was partially powered at some point? The brown-out detection on the board is supposed to address this, but it's not perfect. One way this can happen is if the motors are moved when the power is off. This causes a current to be generated that can bring up the CPU momentarily, and can damage the EEPROM settings. Could this have happened on your board?

TedBlack #

I have reset the settings as you recommended.

Then I reprogrammed the Shapeoko settings.
I typed up a Notepad txt file to copy them over.
They are at the bottom of this post if anyone wants to shortcut and copy / paste straight into coolterm.

Source of Communication Error:
When I copied and pasted all four of the motor settings there was an error half way through communication with the TinyG. An error message come up because it received $2.r instead of $2tr. This happened a few times in random spots.
I have $ex=RTS/CTS and RTS/CTS selected in coolterm, however it didn't seem enough. Then I enabled 'DTR' and 'DTR ON' in Coolterm and I could send large chunks of the settings below without any errors.
See Screenshot here:
http://www.gerardscientific.com.au/images/CoolTermSettings.png

This might explain why I had some erratic behavior when drawing arcs or sending large files. As I suspected the buffer in the AVR filled up and my Laptop just kept sending anyway as it can send much faster than the AVR can receive and process the G-code.

Settings:
The nan settings are now gone.
I'm getting feedback from the machine of it's position as it moves around during a command.
The velocity_max now works. I can still change the feedrate to a value above the max, however it will only traverse at the velocity_max I have set for the axis.
Motor timeout doesn't work after sending a file, however you said it would only work for 435.xx builds.
As for my settings buggering up from moving an axis manually. I doubt it. Find me someone who hasn't done that. The output of the stepper drivers should be well isolated from the power supply and I wouldn't suspect that. Even if the power was off the stepper driver would have a very high internal impedance and wouldn't allow stepper EMF to feedback to the power supply to then power the atmel.

System Settings

$ja=2000000
$st=1
$mt=10

Motor Settings
Motor1,2,3,4

$1ma=0
$1sa=1.8
$1tr=40.00
$1mi=8
$1po=0
$1pm=0

$2ma=1
$2sa=1.8
$2tr=40.00
$2mi=8
$2po=0
$2pm=0

$3ma=1
$3sa=1.8
$3tr=40.00
$3mi=8
$3po=0
$3pm=0

$4ma=2
$4sa=1.8
$4tr=1.25
$4mi=4
$4po=0
$4pm=0

Axis Settings

X,y,z axis

$xam=1
$xvm=5000
$xfr=5000
$xtn=0
$xtm=220
$xjm=5000
$xjh=10000
$xjd=0.01
$xsn=1
$xsx=0
$xsv=3000
$xlv=100
$xlb=20
$xzb=3

$yam=1
$yvm=5000
$yfr=5000
$ytn=0
$ytm=220
$yjm=5000
$yjh=10000
$yjd=0.01
$ysn=1
$ysx=0
$ysv=3000
$ylv=100
$ylb=20
$yzb=3

$zam=1
$zvm=800
$zfr=800
$ztn=0
$ztm=100
$zjm=50
$zjh=1000
$zjd=0.01
$zsn=0
$zsx=1
$zsv=3000
$zlv=100
$zlb=20
$zzb=3

aldenStaff #

Good progress. Some points:

- Thanks for the pointers to add DTR to the RTS/CTS setup. We will make that change in the wiki documentation.

- As for flow control, we've found the AVR can process things as fast as the host can send it, but the Gcode execution occurs in real-time and is what sets the pace that Gcode blocks can be received.

- If you are blasting down sequences of $ commands (configs) it's advised to delay about 30ms - 50ms between each one. This is because each config item (that changes) causes an EEPROM write which takes about 20-30ms, during which time the AVR cannot receive any serial input. So communications errors can occur in this interval. Coolterm has a setting to do an end-of-line delay.

- We have seen settings get corrupted in extreme cases where motors are moved rapidly while the board is unpowered. There was enough back EMF to get back into the switching power supply and power up the MCU. By setting the MCU config fuses to the correct brownout level any ill effects were prevented. We made this change initial chip setup about 2 years ago. We have not seen this error since then, but are now sensitized to it. That doesn't explain why you had a corrupted config, so I'd consider that issue still open.

This topic is from the original forum (July 2014). Your reply starts a new discussion linked to it.

Reply

Different problem? Ask a new question

Back to TinyG Support or latest activity.