Forum Replies Created
-
AuthorPosts
-
cmcgrath5035
Moderatorflux – I can confirm that your shorter test code also drifts on my machine, even with feedrate set to F200. Drift was (1,-1)
I am still running 412.01; Alden seems to have removed 426.06.Alden – to save you a few minutes, I’ll note that this job has an arc made up of 42 sequential 0.028 mm moves, the a few moves later another arc made up of 22 moves, some as short as 0.018mm (both quick looks, not guaranteed worst case).
To me, this is what you were chasing in Z-axis problem.Here is my version of flux’s test case – added lead in and lead out marking with spindle. A Very quick test, you can easily see bad results.
ModeratorI ran a few pot position tests with more or less expected results.
Increased current to the motors did improve my machines performance/ reduce drift.For example, moving the pots from 12 o’clock to 4 o,clock, my test GCode described at the top of this thread ran without drift at F10000, where it had begun to drift with the pots at 12 o’clock.
I did not attempt to go higher in Feedrate, so this is just another data point.I attempted some instrumentation with two DMMs, low cost items from HFT (free, actually). I have no knowledge of their averaging capabilities/characteristics.
One DMM in series using the 10A setting, the other measuring Power Supply output Voltage.
With pots at 4 o’clock, I measured input current = 1.61A while the motors remained ‘locked’ after reset. When released, current dropped to about 0.1A, so roughly 1.5A was feeding the motor windings.
I don’t have a ‘scope and have not dug enough to know what the tinyG drive waveforms look like.
Does anyone have a guesstimate as to the average duty cycle for the winding waveform?I also observed a fairly consistent input voltage of 24.2V when idle, 23.5V when measuring 1.6A. That is about 3% drop, probably within spec for my less than premium 24V 6A power supply.
Moderatorflux – Have you been following this thread?
I reread it today, and note that member grim’s reports from post 5719 (midway thru page 2 of the thread) on sound somewhat similar to what you experienced on 412.01 with test.7.gcode.
If I get a chance, I’ll give 426.06 a try on my machine.
ModeratorAnother brief comment, I used test.7.gcode today as as test case while experimenting with the latest tgFX release, build 3256.
In the course of several runs, I moved my current pots to full on, found that made an incremental improvement in my test case but made no repeatable change in test.7.gcode performance.
In my final run, I set velocity max to 1000 and feed rate max to 200 in both X and Y; extremely slow by your standards. Two runs resulted drifts in the range of 8-10 mm in Y0 final position.
I’ll note that the as-drawn output of tinyG in the tgFX window, captured from the status messages, does not display gross offsets or drift, 10mm would be gross for this job..I believe this says that the servos are not able to properly respond to the tinyG drive signals. Spindle mass is still a possibility, but at these speed settings, plus your good results with 380.08, seem to implicate the servo drive waveforms from 412.01.
Time for Alden to weigh in.
I do note that test.7.gcode has a very large number of relatively short segments(below .1mm), many below .05mm that may not be properly handled, ??Moderatorflux wrote
As you note, it’s different when moving in free air and then milling something. I had some trouble missing steps when milling aluminum, so I decided to just go full throttle in my current pots. (The motors are rated 3A anyway and TinyG can give 2.5A.) So while this approach can give bounds for doing free-air G0 movements, it doesn’t really answer what kind of settings one needs to actually mill hard materials.
Sadly we cannot adjust the current limits in software for different situations (or can we? the edge branch gives some new ‘motor power’ setting ranging from 0.0 to 1.0), I bet that could be useful in using different settings for moving in air, milling PCBs and milling hard materials.
It will be interesting to see if Alden describes the motor power parameter as a ‘software potentiometer’. I believe he said somewhere to leave it at = 1 for now, it is a feature that he is working on in the future.
I have a somewhat different interpretation of drive motor current, that being that the drivers can switch up to 2.5A into an inductive load before they near their dissipation design limit. The pots are available to reduce un-needed torque, which becomes heat, to extend the longevity of the driver and motor components.
Does your tinyG run hot, particularly near the end of test.7.gcode?
I keep finger checking mine – no rise really noticeable, but I have a somewhat unique (I think) implementation with the tinyG pwb bolted to a large heatsink, no fans, plus the small individual driver ‘dip-sinks’.For jolly’s, I am going to put an ammeter in series with my 24V supply just to see what it says during the various phases of my test case and your test cases.
If, as I suspect, the torque required from the motors, with the available current, is inadequate to control the spindle in air while running the test, then clearly they won’t have reserve torque to push the spindle along if the force required to push the spindle thru the material is even moderate. That force is a complex combination of the spindle motor torque, material hardness, bit sharpness, diameter, etc.,
you know all that from dealing with Al.An interesting question then becomes: for a given machine mass (spindle plus X gantry), how does increased velocity in an air test case translate into reserve force available to push the machine at lower feed rate (real work) with the same accuracy.
Sounds like a good Homework and followup lab experiment for ME 305 or perhaps a good Master Thesis!Its probably time to revisit the Spindle pages on the ShapeOko forum, to see if other have test results in this space.
ModeratorI will give your shorter test code a try today.
I also agree that any apparent good set of configs (feedrate, currents, jerk, etc) needs to be repeated multiple times to gain confidence.
Your repeatable success with 380.08 vs 412.01 is a mystery to me so far.
And as you point out, moving between them is somewhat painful with parameter changes and checks.Moderatorflux – After running a longish evaluation of my machine, based on your methodology and documented here
I went back to your test case, test.7.gcode to see what imporvements I could make with my machine,
I started with F2000 feed rate, pots at 12 o’clock, jerk at 5 Billion, and got similar results to yesterday – drift of x +68, y+53.
Next I moved the pots to 2 o’clock for X, Y1 and Y2. Drift for this run was X -5, y 0 , encouraging
Reran a second time, drift was x +15, Y -3, not quite as encouragingI tried reducing jerk by a factor of 10 (xjm and yjm at 500Million), similar results with drift at X +3, y -18.
I went back to jerk of 5000 million, reduced to F800. drift x 0, y +10.
As a final test, I set the pots to 3 o’clock, drift was x -3.5, y 0.
All these results are tinyG build 412.01. While there could be a digital fw issue in these newer builds, I am more suspicious, at least in my case, of the mass of the DW660 being just too much for a NEMA 17 shapeOko to adequately control under the workload presented by test.7.gcode.
I’ll keep an eye out for other suggestions as they come in.
This is a really interesting test case.
ModeratorI understand the time frame comment; it is what I expected.
Would you also say that RTS/CTS, properly configured at both ends, should work as well?
My evidence, using plink with RTS/CTS, would say yes.Again, my objective is to not have to [remember to] change the tinyG config when I move back and forth between tinyG and plink/Coolterm, etc.
Moderatorflux – I generated a pile of data today, will process and post later.
I’ll make a general statement that increasing the current to my NEMA 17s did generally improve the performance (lower offsets).Are you using tinyG to drive the NEMA 23 directly?
How big a difference in current requirement?Another gut observation – using a DW660 spindle on a machine targeted to the pcb application is likely not prudent. Seems way to much mass being moved about in all directions. Do you have a real heavy spindle? You said you are into Alum plate milling, so I am guessing you have something substantial.
Have you tried something with less mass with the PCB code?I did not give a lot of consideration to my choice – I have had a DW660 on the shelf for 10 years, finally getting some use out of it.
But after today’s session, I’ll say that if I get into PCB milling or similar, I’ll find a spindle better matched to the task.I also recall from your config file that your set up has larger travel per rotation on X and Y; larger toothed drive wheel I presume.
Seems that reduces the torque per unit of linear measure, both driving and holding/stopping. Not really what this application needs.Hard data in a few hours.
No answers, but interesting data.Moderatorflux
I highly suspect that, at least for my case, driver current settings on tinyG are at least some of the issue.I have never tweaked the pots, since I have not experienced issues like this with prior jobs; I do tend to run them much more slowly.
It is interesting that when I moved all F2000 directives to F200, my results are the same as yours.
In saying same, I acknowledge that the X=10mm offset is an eyeball and ruler measurement, roughly right.Perhaps there is more than one issue lurking in my setup, such as inadequate current plus what you see as an offset bug (difference between 380.08 and 412.01)
I’ll rerun again, with the G0 speed reduced as well in the config file to see what happens.
Here is a question for Alden or anyone else:
Is there any test Gcode with significant quick motion, that can be run repetitively, to assist in determining if a set of recommended digital settings (in config file) plus motor currents actually performs well?ModeratorGood grief, my ShapeOko is now demanding overtime pay!
That code does moves a lot, quickly!AND, rather randomly.
All my runs are from Linux host.
I grabbed your test.7.gcode file.
I edited in a G1 X0 Y0 line at the bottom to make offset determination easier.This is my tinyG configuration
My jerk settings are higher than yours.
Run 1: I ran test.7.gcode using tgFX build 3009.
Run time 4:20
Offset observed (using my definition) was X +10, Y-4 mmRuns 2,3 and 4
I decided to switch to my GCode dumper script, using plink which is documented in step 5 in this post
Procedure for runs 2,3 and 4:
1. Move spindle to a predetermined (0,0) point
2. Reset tinyG (thereby set a new X0,Y0,Z0 and, maybe clean up some stored garbage in tinyG(?)
3. execute ./CNC_run
note: I do net get job run time from this scriptRun 2
Offset observed X +105, Y -65 mm
During this run, spindle was all over the place (+,+), (+,-), (-,-), (-,+)Run 3 – just hit reset, then rerun again
Offset observed X +10, Y -68 mm
Motion not quite as off the wall as in Run 2.
This is the log of return info from tinyG, captured by the “Tee” in my script. I have the others, if useful to you.Run 4 – I figured speed was in some way introducing issues, so I made the following simple change to the gcode file with vi:
:1,$s/F2000/F200 , replacing the G1 speed by a factor of 10.
Process was slower for sure, and certainly better behaved than Runs 2 and 3.
Offset observed X-10, Y 0.So, yes, there is an issue in here with tinyG build 421.01.
Sidebar question: I assume you edited Z movement out of the Gcode file.
Can PCBs actually be cut this fast?ModeratorHmm, so you tried the G-code on the 412.01 you have?
Nope, I just looked at it. Actually, I loaded it into my CAD simulator just to see what it did.
If I get a chance, I will run this latest code to see what I see.
Is this a correct definition of what you call drift?:
1. Set Start = X0,Y0
2. Run GCode
3. G0 X0 Y0
4. Drift = difference between current position and Start (defined in step 1.)FYI, I re-ran my GCode of diagonals (the long forum thread referenced earlier) with the recommended $xjm = 5,000,000,000 rather than my 5,000,000. It did not affect the cut pattern (where F=200), but the moves between open ends of unconnected parallel lines noticeably faster, per the definition of jerk.
Btw, a related thing I _think_ I noticed when running the test on 380.08: I heard the clicking sound that is fixed in edge. I didn’t hear those in the edge version. It could very well be that the fixes related to eliminating clicking (so the sudden stepper adjustments?) also affect this issue.
When I was running 380.08, I had one vertical 6″ path (the side of a square) that refused to run anywhere near F=200, yet all other paths, vertical, horizontal and diagonal ran consistently at F=200. When that problem path was running, motors sounded weird. Weirdness gone now in 412.01 and path cuts at F=200.
Moderatorflux – I have zero experience with multiple coordinate systems, so have been studying your config file just to see what it looks like. I don’t know what type of machine you have (you mention belt drive). Mine is a ShapeOko. Here is a recent config from my machine
Your motor setups are similar to mine, although you have more travel per rev on X and Y. We both seem to have X-dual Y-Z machines (4 active motors).
What I did notice in your config (from your first post, a run with 421.02)
1. I have not seen prior to this anyone running tinyG at baud=230400. It is a valid option, so I can only assume you are confident it really works well at both ends.
2. Your X jerk, y jerk and z jerk maximums are way larger than I have, which may be part of my problem. For example, your z jerk max is 500 * 1 million, where as mine is only 5 * 1 million. The recommended starting point for my machine is 5000 * 1 million.
I’ll assume you have good reason to be at 500, I appear to have missed 000 in translating my jerks from 380.08 notation to 421.01 notation. I plan to rerun my test again with 5000 *1 million settings.Finally, you say
So it would seem that the edge branch introduces the error – I hope these reproduction images will be helpful in finding the issue.
What did you mean by reproduction images? Did your try to insert an image?
I am off to retest (again…). I’ll let you know if you fixed my problem :).
-
This reply was modified 10 years, 7 months ago by
cmcgrath5035.
ModeratorOK, you are well beyond a boundary I set for myself; I try to work with the releases from Synthetos, rather than Git and build.
Here is what is supposed to be the ‘official’ firmware site
This is the item where 421.06 is revealed – appears I misrepresented it, looks like Alden created it from DEV, not Edge
Good luck
Moderatorflux- I am a bit confused; you say you are running tinyG 412.02. Where did you get that from? I have seen (and use) 412.01 and know that Alden built a 421.06 as a bug-fix experiment, downloadable from a dropbox.
What are you using to run your GCode? I am using tgFX, build 3009.
tgFX seems to have issues running with 412.01, Riley is about to deliver an updated tgFX build to work with tinyG 412.01 (and later).Is the offset/drift you report seen in the milled result, or in a diagnostic window?
You might wish to review a rather long thread here:
My issue with the diagonal line offset is unresolved at this point, but might be related to what you are seeing.
-
This reply was modified 10 years, 7 months ago by
-
AuthorPosts
