Tuning help?

Sorry it's been a while. I had to go out of town for a while and I'm just not getting back around to working on the machine.

I have upgraded the firmware to 440.18 and SPJS to 1.80. I also rewired the machine so that each Y axis stepper is on it's own driver. I used many of the settings you mentioned above and have been trying to tweak them to work better. I have run into an interesting, and frustrating problem.

I can test the jogs via the cp widget and the machine will move fine. I'll go into the settings and make adjustments, save them, and then the fun begins. I'll go back to the jog setting, and lets say I press the left arrow to move -x. The machine will move in the +x. If I hit it again, it does the same thing. I can then press the right arrow for the +x and it'll move +. Now I can press the -x and it'll move correctly.

If I try it with the Y, it's worse. After changing and saving a setting, I can press the down button for -y. The right motor will move + and the left motor will move -, which racks the machine into a bind. The only way to correct it is the same as before. Jog in the opposite direction once, then both directional keys will then work.

As you can imagine, this is quite frustrating. Once I get the settings correct I shouldn't have to adjust them again and all will be fine. Until the next firmware update and I have to do this all over again.

Here is a video of it in action. Ignore the garage, it's a mess right now.

https://www.youtube.com/watch?v=tqUADy0ijbU&feature=youtu.be

Hi,

I have been having this EXACT same issue. I was originally using JSON 1.80 and 440.18 of TinyG firmware. Whenever I saved new configuration setting, the axes would reverse themselves. For instance when homing right after saving a new setting, the 2 Y-axis motors would suddenly be different polarities and start grinding the belt and twisting the gantry.

To fix I would need to jog back and forth a few times then the direction would correct itself. I have also been having jerky motion as mentioned previously, sometimes the gcode would experience stalls and slowdowns. For example an easy 200mm/min move would move perfectly fine one minute, then all of a sudden slow to 6mm/min velocity like it just hit the brakes. This slowdown also always occurs at the end of every job on the last few 10s of lines of gcode.

I have tried every last combo of every single setting in the gcode options widget to no avail. TinyG settings below:

// Response from $$ Command
[fb] firmware build 440.18
[fv] firmware version 0.97
[hp] hardware platform 1.00
[hv] hardware version 8.00
[id] TinyG ID 3X3566-MPF
[ja] junction acceleration 100000 mm
[ct] chordal tolerance 0.0100 mm
[sl] soft limit enable 0
[st] switch type 1 [0=NO,1=NC]
[mt] motor idle timeout 2.00 Sec
[ej] enable json mode 0 [0=text,1=JSON]
[jv] json verbosity 1 [0=silent,1=footer,2=messages,3=configs,4=linenum,5=verbose]
[js] json serialize style 1 [0=relaxed,1=strict]
[tv] text verbosity 1 [0=silent,1=verbose]
[qv] queue report verbosity 1 [0=off,1=single,2=triple]
[sv] status report verbosity 1 [0=off,1=filtered,2=verbose]
[si] status interval 250 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 1 [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 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 1 [0=X,1=Y,2=Z...]
[1sa] m1 step angle 1.800 deg
[1tr] m1 travel per revolution 60.0000 mm
[1mi] m1 microsteps 2 [1,2,4,8]
[1po] m1 polarity 1 [0=normal,1=reverse]
[1pm] m1 power management 2 [0=disabled,1=always on,2=in cycle,3=when moving]
[2ma] m2 map to axis 1 [0=X,1=Y,2=Z...]
[2sa] m2 step angle 1.800 deg
[2tr] m2 travel per revolution 60.0000 mm
[2mi] m2 microsteps 2 [1,2,4,8]
[2po] m2 polarity 0 [0=normal,1=reverse]
[2pm] m2 power management 2 [0=disabled,1=always on,2=in cycle,3=when moving]
[3ma] m3 map to axis 0 [0=X,1=Y,2=Z...]
[3sa] m3 step angle 1.800 deg
[3tr] m3 travel per revolution 60.0000 mm
[3mi] m3 microsteps 2 [1,2,4,8]
[3po] m3 polarity 1 [0=normal,1=reverse]
[3pm] m3 power management 2 [0=disabled,1=always on,2=in cycle,3=when moving]
[4ma] m4 map to axis 2 [0=X,1=Y,2=Z...]
[4sa] m4 step angle 1.800 deg
[4tr] m4 travel per revolution 8.0000 mm
[4mi] m4 microsteps 1 [1,2,4,8]
[4po] m4 polarity 0 [0=normal,1=reverse]
[4pm] m4 power management 2 [0=disabled,1=always on,2=in cycle,3=when moving]
[xam] x axis mode 1 [standard]
[xvm] x velocity maximum 2500 mm/min
[xfr] x feedrate maximum 5000 mm/min
[xtn] x travel minimum 0.000 mm
[xtm] x travel maximum 860.000 mm
[xjm] x jerk maximum 1000 mm/min^3 * 1 million
[xjh] x jerk homing 3000 mm/min^3 * 1 million
[xjd] x junction deviation 0.0200 mm (larger is faster)
[xsn] x switch min 1 [0=off,1=homing,2=limit,3=limit+homing]
[xsx] x switch max 0 [0=off,1=homing,2=limit,3=limit+homing]
[xsv] x search velocity 350 mm/min
[xlv] x latch velocity 100 mm/min
[xlb] x latch backoff 15.000 mm
[xzb] x zero backoff 3.000 mm
[yam] y axis mode 1 [standard]
[yvm] y velocity maximum 2500 mm/min
[yfr] y feedrate maximum 5000 mm/min
[ytn] y travel minimum 0.000 mm
[ytm] y travel maximum 1210.000 mm
[yjm] y jerk maximum 1000 mm/min^3 * 1 million
[yjh] y jerk homing 5000 mm/min^3 * 1 million
[yjd] y junction deviation 0.0200 mm (larger is faster)
[ysn] y switch min 1 [0=off,1=homing,2=limit,3=limit+homing]
[ysx] y switch max 0 [0=off,1=homing,2=limit,3=limit+homing]
[ysv] y search velocity 350 mm/min
[ylv] y latch velocity 100 mm/min
[ylb] y latch backoff 20.000 mm
[yzb] y zero backoff 3.000 mm
[zam] z axis mode 1 [standard]
[zvm] z velocity maximum 1000 mm/min
[zfr] z feedrate maximum 2000 mm/min
[ztn] z travel minimum -75.000 mm
[ztm] z travel maximum 0.000 mm
[zjm] z jerk maximum 250 mm/min^3 * 1 million
[zjh] z jerk homing 1000 mm/min^3 * 1 million
[zjd] z junction deviation 0.0100 mm (larger is faster)
[zsn] z switch min 0 [0=off,1=homing,2=limit,3=limit+homing]
[zsx] z switch max 1 [0=off,1=homing,2=limit,3=limit+homing]
[zsv] z search velocity 200 mm/min
[zlv] z latch velocity 100 mm/min
[zlb] z latch backoff 3.000 mm
[zzb] z zero backoff 2.000 mm
[aam] a axis mode 0 [disabled]
[avm] a velocity maximum 0 deg/min
[afr] a feedrate maximum 0 deg/min
[atn] a travel minimum 0.000 deg
[atm] a travel maximum 0.000 deg
[ajm] a jerk maximum 0 deg/min^3 * 1 million
[ajh] a jerk homing 0 deg/min^3 * 1 million
[ajd] a junction deviation 0.0000 deg (larger is faster)
[ara] a radius value 0.0000 deg
[asn] a switch min 0 [0=off,1=homing,2=limit,3=limit+homing]
[asx] a switch max 0 [0=off,1=homing,2=limit,3=limit+homing]
[asv] a search velocity 0 deg/min
[alv] a latch velocity 0 deg/min
[alb] a latch backoff 0.000 deg
[azb] a zero backoff 0.000 deg
[bam] b axis mode 0 [disabled]
[bvm] b velocity maximum 3600 deg/min
[bfr] b feedrate maximum 3600 deg/min
[btn] b travel minimum -1.000 deg
[btm] b travel maximum -1.000 deg
[bjm] b jerk maximum 20 deg/min^3 * 1 million
[bjd] b junction deviation 0.0500 deg (larger is faster)
[bra] b radius value 1.0000 deg
[cam] c axis mode 0 [disabled]
[cvm] c velocity maximum 3600 deg/min
[cfr] c feedrate maximum 3600 deg/min
[ctn] c travel minimum -1.000 deg
[ctm] c travel maximum -1.000 deg
[cjm] c jerk maximum 20 deg/min^3 * 1 million
[cjd] c junction deviation 0.0500 deg (larger is faster)
[cra] c radius value 1.0000 deg
[p1frq] pwm frequency 100 Hz
[p1csl] pwm cw speed lo 1000 RPM
[p1csh] pwm cw speed hi 2000 RPM
[p1cpl] pwm cw phase lo 0.125 [0..1]
[p1cph] pwm cw phase hi 0.200 [0..1]
[p1wsl] pwm ccw speed lo 1000 RPM
[p1wsh] pwm ccw speed hi 2000 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]

Sorry to spam even more but recently after upgrading to SPJS 1.83, Chilipeppr will no longer send any commands to TinyG even though it seems to connect perfectly. Coolterm has zero issues connecting though which is very strange.

In short I'm having identical issues to the poster above.

Hi,
Thanks a lot for the reply! Here are some quick updates to this issue as some of it has been resolved. The problems with the gcode stuttering and stalling really began after using the new firmware updater tool to the latest master (440.18). After this update the stalling started, json 1.83 would show a connection at the bottom-right widget of Chillipeppr, no errors would appear in the serial console, but it would not take commands (including resets or any $ command) and would not save any new configurations. The steps I took next are below:

1) re-flashed 380.xx of the firmware using avrdude. (the oldest firmware i could find on the github tinyg page)
2) then flashed 440.19 using avrdude. (added "-e" command to the line in DOS prompt)

This has seemed to fix the stuttering and slow gcode problem. v1.80 of json server runs the gode very speedy now and has no issues saving new configs. The machine takes the jog commands nearly instantly without delay.

v1.83 of json server runs the gcode speedy once it finally buffers. (exact same values in gcode settings widget but buffers much slower than v1.80) Also all jog commands are about 1 secound delayed as well as any other command going to the machine including feedholds, flush, etc.

Both v.180 and v1.83 continue to reverse polarities of all axes after saving a new machine config. The ONLY way that seems to quickly fix this is to jog a short move back and forth a couple times which seems to reset the polarities.

As for the machine, it is a custom built OpenBuilds OX, with 262oz-in steppers, dual-y, gt3 pulleys and 2.2kw water cooled spindle. (hence the need for the half microstepping, needed the extra torque to make sure the heavier X/Z gantry does not miss steps. An aside, during the deceleration/stuttering/stalling issue, I did try other microstep levels and manually adjusted the current to each motor and the effect was absolutely nil, the issue persisted at all levels of motor current. Machine pic below.

https://www.dropbox.com/s/u3j0jry7llccypr/2015-08-08%2021.29.54.jpg?dl=0

The main reason I'm using TinyG is the individual constant jerk acceleration customization as this feature puts this motion control in competition with other heavy hitters for an absolute fraction of the price, however these weird issues sometimes pop up that are borderline machine breaking if not caught right away(polarity reversals, etc.)

Thx for the help!

Hi, I'm not sure if I filtered this right but here is the serial output below. Jogged the y back and forth 1 mm before and after a new save. I'm in json v1.80

G91 G0 Y1
G90
G91 G0 Y-1
G90
G91 G0 Y1
G90
{"x":{"am":1,"sn":3,"vm":5000,"sx":0,"fr":5000,"sv":350,"tm":860,"lv":100,"tn":0,"lb":15,"jd":0.05,"zb":3,"jm":1000,"jh":4000}}
{"y":{"am":1,"sn":3,"vm":5000,"sx":0,"fr":5000,"sv":350,"tm":1210,"lv":100,"tn":0,"lb":15,"jd":0.05,"zb":3,"jm":1000,"jh":5000}}
{"z":{"am":1,"sn":0,"vm":2000,"sx":3,"fr":2000,"sv":250,"tm":0,"lv":100,"tn":-75,"lb":3,"jd":0.05,"zb":3,"jm":2000,"jh":7000}}
{"a":{"am":0,"sn":1,"vm":25920,"sx":0,"fr":12960,"sv":2000,"tm":-1,"lv":2000,"tn":-1,"lb":5,"jd":0.1,"zb":2,"jm":324000,"jh":324000,"ra":5.305}}
{"1":{"ma":1,"pm":2,"po":1,"tr":60,"mi":2,"sa":1.8}}
{"2":{"ma":1,"pm":2,"po":0,"tr":60,"mi":2,"sa":1.8}}
{"3":{"ma":0,"pm":2,"po":1,"tr":60,"mi":2,"sa":1.8}}
{"4":{"ma":2,"pm":2,"po":0,"tr":8,"mi":2,"sa":1.8}}
G91 G0 Y1 <-------------goes backwards in(-) direction
G90
G91 G0 Y-1 <-------------goes backwards in(-) direction AGAIN
G90
G91 G0 Y1 <-------------goes forwards in(+) direction
G90

This has to be repeated for every axis otherwise any positive move in Z, for example, will plunge into the table. If this action is not cleared, by
the back and forth jog, any gcode run will keep the screwed up setting and get up to all sorts of shenanigans as soon as I press 'play'. The dual y motors on the first jog after a new save will twist the gantry until the 2nd jog command is sent. Another thing I noticed is that the gantry will continue to twist until a reversed jog command is sent, if I sent the same jog command over and over again, it will continue the incorrect movement.

Hope this info helps. Thx!

A little update from me. I flashed to 440.19 and updated the parameters via the console instead of the widget and the jogs are correct. I tried via the widget and half the time the setting wouldn't even save at all. It was very hit and miss, and when it did, the jogs were backwards.

I did some playing with my velocities and jogs and stumbled across something interesting. I've been working in mm since everything I've read says TinyG works better that way. Any xvm/yvm value greater than 1200 mm/min and jogs on the machine jump and stumble...until you put Chilipeppr in Inch mode. I've ran the velocities to 5000 mm/min, changed over to Inch mode and it jogs smooth as glass. I'm using the jog widget at 1.

I got to thinking, maybe there was a change in the way Chilipeppr buffers the jog commands? I changed back to MM and changed to the Custom jog to 10 and it works smooth on MM mode now. It's weird, prior to the update to 440.16 I didn't have to put it on custom 10 to get smooth jogs.

I still need to adjust my travel values as they're a bit off. I tried to cut a 1" circle and it came out to .97". Similar values with a .25" pocket cut. They came out about .22". Should I drop my 1tr/2tr/3tr values down a hair? They're at 40 right now.

The only other thing I've noticed is it is still having problems with some curves. Some jump and stall while others are smooth.

Well son of a b. I just tried changing my 1tr/2tr/3tr values via the console, same way I've been changing everything today. Wouldn't you know, I jogged the machine right before changing the tr values. I changed the tr, then went back to the jog and it inverted the polarity on one of my y motors, racking the machine yet again. I've tried in in both the X & Y. Same as before, I can clear it by jogging in the opposite direction. This last time, I sent the tr commands again, but didn't change anything. Here are the lines:

[1tr] m1 travel per revolution 40.0000 mm
tinyg [mm] ok>
$2tr=40
{"ej":""}
[2tr] m2 travel per revolution 40.0000 mm
tinyg [mm] ok>
$3tr=40
{"ej":""}
[3tr] m3 travel per revolution 40.0000 mm
tinyg [mm] ok>
G91 G0 X10
G90
G91 G0 X10
G90
G91 G0 X10
G90
G91 G0 X10
G90
G91 G0 X10
G90
G91 G0 X10
G90
G91 G0 X10
G90
G91 G0 X10
G90
G91 G0 X10
G90
G91 G0 X10
G90
G91 G0 X10
G90
G91 G0 X10
G90
G91 G0 X10
G90
G91 G0 X10
G90
!
%

{"qr":""}
!
%

{"qr":""}
G91 G0 X-10
G90
{"qr":""}
G91 G0 X-10
G90
G91 G0 X-10
G90
G91 G0 X-10
G90
G91 G0 X-10
G90
G91 G0 X-10
G90
G91 G0 X-10
G90
G91 G0 X-10
G90
G91 G0 X-10
G90
!
%

{"qr":""}
!
%

{"qr":""}
G91 G0 X10
G90
{"qr":""}
G91 G0 X10
G90
G91 G0 X10
G90
G91 G0 X10
G90
G91 G0 X10
G90
G91 G0 X10
G90
G91 G0 X10
G90
G91 G0 X10
G90
G91 G0 X10
G90
G91 G0 X10
G90
G91 G0 X10
G90
!
%

{"qr":""}
!
%

{"qr":""}
{"qr":""}

The commands show the correct orientation. First was a +X move, then -X, then +X again. The problem is the machine moved - the first and second time, and finally + again the third time.

This is driving me crazy. It worked fine all day, I take a break to grab a drink and it goes crazy.

I went through and rechecked all motor connections. They're good. The problem is the direction isn't random. I can repeat the behavior with the same parameters.