Incorrect Arc Movement

Small arc movements were fixed in newer firmware. Are you sure you have the latest firmware? I too have seen issues in the past with small arcs, but my understanding is those got fixed. I have not personally tested that though.

Hcamp
Two parmeters

[ja]  junction acceleration50800000 mm
[ct]  chordal tolerance           0.0000 mm

Look to be way off, here are the default values

[ja]  junction acceleration  100000 mm
[ct]  chordal tolerance           0.0100 mm

$ct=0 could be causing havoc.

You might try just changing these.

But to be honest, a number of other parameters look strange, such as

[xtm] x travel maximum          300.228 mm
[xjm] x jerk maximum           5004 mm/min^3 * 1 million
[xjh] x jerk homing           10008 mm/min^3 * 1 million

I am not sure why you would have 5004 vs just 5000.
Did you enter these manually? Do you recall how?

Hmmm. I am a bit suspicious that your parameters were borked a while ago by tgFX.
I think I have to recommend a factory reset procedure to get a clean set of 440.14 parameters, after which you will need to reset your motor and axis parameters again.

But first – what are you using on PC to run your machine:
OS – Win__, Linux, MACOS ?
Interface SW – Chilipeppr, CoolTerm, other? You can no longer use tgFX.

To reset parameters, I would suggest you send a $defa=1 command from the CP Serial Port Console. This resets parameters in EEPROM to ‘factory setting’, a set of parameters compiled into the firmware

Reflashing the tinyG with FW 440.14 would have the same effect.

In both cases, the tinyG parameters will then need to be manually restored to match your machine. Use either the Serial Port Console command window or the configuretinyG widget.

Running Windows, your could do the same process using CoolTerm, the choice is up to you.

TinyG runs based on parameter values stored in EEPROM. The initial values in EEPROM are loaded as part of the FW install process. Subsequent changes to parameters make from the command line or by programs such as CP change values in EEPROM, not flash.

The problem of corrupt parameters we are chasing are most likely with the values in EEPROM, not flash

I highly recommend you NOT try tgFX anymore. While some basic functionality may still work properly, there are know issues between the final release of tgFX almost a year ago, and FW440.14. Work on tgFX has been terminated.

Good luck – let us know how you make out.

Julian
We never heard back from HCamp, so have no update on if his resetting tinyG to defaults and entering correct parameter values helped.
Note that the value of $ct in his parameter list was just an indicator of something very wrong. It might help if you added your full parameter dump to the Dropbox record.

I downloaded your Gcode file. Way to big for any manual review and detection of issues, but will be useful to debug none the less.

I first loaded your Gcode into the CAM generator/simulator I use, which is a backend to CAD program QCAD. That simulation displayed some bizarre results, including numerous large circles and small, including the one shown in your picture. Here is a screenshot :

https://dl.dropboxusercontent.com/u/50261731/Selection_277.jpg

I then loaded the Gcode into my CP (Linux, Chrome) It took quite a while for the simulation to render, but it finally did and appears to be correct, no large circles. I will note that the CP browser seems seriously loaded down by the Gcode file – any attempt to zoom or make a 3D perspective change trashed the entire browser window. That might be a 3Dviewer issue, or ??

So, nothing definitive in this so far. I could guess that tinyG is making the same error that my QCAD simulator is making, but have no idea why that would be.

• This reply was modified 9 years, 7 months ago by cmcgrath5035.

my tinyg has never worked right it starts to follow the gcode but then veers off and crashes. help would be appreciated.
thanks,
matt

Not sure if a similar problem,

But when I use Sheetcam to create my gcode, if I use outside or no contour, it works fine on the tinyg. The moment I use inside contour, it no longer follows arcs as normal and will instead use a series of very course straight lines, or skip circles all together.

I will try to refine the problem, and start a new thread with it.

This is with Vr8.