cmcgrath5035

This sounds like it will be an Alden item (he is traveling) but a couple questions to help him diagnose:

You said:”….The actual speed limit for that axis is above 800 mm/min”,
Do you mean that the physical machine can do this, or there is some other setting that says 800 mm/min is OK?

Does your Z axis seem to be following your 20 mm/min setting when you use a G1 move, e.g. G1Z50 ?
I’ll assume you have an F xxx (xxx> 20) set already.

dataway – You did not say what version of tgFX you have loaded.

If I assume you loaded tgFX build 3256 to run with FW 412.01, your first post, then I am not surprised that things did not work when you installed FW 380.08 into tinyG. tgFX build 3256 requires FW 412.01 (or later) and will attempt to download and install 412.01 it. And, by the way, earlier versions of tgFX (<build 3256) don’t work well with 412.01.

Drift issue- The drift issue highlighted by Flux’s test cases resulted from multiple extremely short segments repeatedly changing direction. Alden has been working the issue and appears to have a code tweak in a Dev build for tinyG, 426.02. I have not seen that build posted yet, most likely still being more thoroughly tested.
When you say “large circle”, how large?
Does Vetric Aspire generate GCode with arcs, or just continuous X,Y short segments?

It is also unclear if you ran your ShapeOko 2 with GRBL, with good results, before migrating to tinyG.

If you can, place a copy of your GCode in a Dropbox (or similar ) and post a link to it here. Additionally, a listing of your tinyG config parameters in a similarly linked file may be helpful.

I believe you want dev branch, where at the moment (could change any time) the version.properties file shows `BUILD=3,256
DATE=2014/04/20 15\:05`

You might also be able to do a similar hack to what I describe in this thread

https://www.synthetos.com/topics/tgfx-linux-experimental/#post-5548

As I said, I don’t run OSx but assume the setup is similar to Linux.

I have found that all you really need is the tgfx.jar file, which itself is an archive.
When a new windows release is posted, I unzip it and copy the tgfx.jar into my established Linux folder structure and run it from there.
That might be easier than setting up the netbeans environment.

I have a v7 which has, I believe, a bit more open area near the driver devices.
I fabricated an interface from 3/8″sq AL stock, with necessary reliefs to avoid non-ground paths and drilled 4 M5 or M8 holes thru the ground PWB area to fasten the board, thru the interface, to a rather large surplus AMD CPU sink.
I have found no need for fans so far, but seldom run jobs longer than 20 mins.
The heat sink gets a little warm, the driver devices with attached dipsinks get to perhaps 105-110F, not bad at all.

Of course none of this is really sanctioned abuse of the tinyG board, but works for me; YRMV.

I can send some pics end of next week, traveling at the moment.

flux – I got the impression that your original short test.gcode was a path extracted from test.7.gcode.
That short path had some very short segments in it, if you want to focus on that path for the evaluation of ‘epsilon’ impact.
In fact, looking at test.7.gcode in my simulator, there seemed to be a lot of discontinuties and “sharp” corners, obviously smoothed out somewhat by the gcode generation process.

flux
Take a look at this Configuration Reference

https://github.com/synthetos/TinyG/wiki/TinyG-Configuration

Specifically, at the end of the document is a section called “Hidden Parameters”.

$ML- Minimum Line Segment

Don’t change this unless you are seriously tweaking TinyG for your application. It can cause many things to break. This value does not appear in system group listings ($sys)

$ml=0.08 – Do not change this value

$MA – Minimum Arc Segment

Don’t change this unless you are seriously tweaking TinyG for your application. It can cause many things to break. This value does not appear in system group listings ($sys)

$ma=0.10 – Do not change this value

What these mean is subject to interpretation, but my assumption on first read a while ago was that linear moves less than 0.08mm ( or arcs with lengths specified less than 0.1mm) would likely fail or cause issues such as your drift.
When I opened your test.7.gcode file, I saw all line segments, no arcs, and numerous line segments <<0.08mm.

I am suspicious that these extremely short segments are at the root of your drift issue.

Interestingly, I cannot get a proper output from my CAM simulator with the test case you just posted, circles.gcode. I may get some time later in the week to try running it on tinyG.

Also, could you clarify what you mean by

I ran it with actual PCB (twice, with identical results), but you could just run it in the air. It takes about 20 minutes to run on my settings.

Are you saying that you actually cut PCB copper, twice, with circles.gcode and the results appear to be A.; cut without drift, yet the final X0 position is offset by -19mm or that the two runs are B.;the same, showing accumulated drift error as the cuts are made? I am assuming your answer is B.

I suspect you chose to draw r=1.0mm circles in circles.gcode since many of the PCB pad features in test.7.gcode appear to be r=1.0mm circles or half circles. But what appears to be a secondary cut path in test.7.gcode, perhaps for additional clearance, has many r=0.5mm circles and arcs; those are the ones yielding line segments as small as 0.012 (quick look), <<< $ml=0.08.

Alden will likely be the key commentator here, I believe he is traveling this week so we may not hear from him for a few days.

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