cmcgrath5035

Can you describe how you ran the update (ChiliPeppr/SPJS, CLI avrdude, etc) and how you made changes to the default parameters?
For parameter changes, did you use the configuretinyG widget in CP?
Might be helpful to post your parameter set ($$ dump) to a cloud file and post a URL here.

Here is a typical V8 schematic, this one for a tinyGV8G

https://github.com/synthetos/TinyG/blob/master/hardware/v8schematics/v8g/tinyGv8g%20-%20schematic%20page2.pdf

U8 is the Regulator,
J11 is the fan connector (white)
J12 is the black pin header that selects between Vmot and 12V out of regulator.

with the voltage selection jumper removed from board, do you measure 12V from Regulator( U8, pin 3)?

The fan is the only user of +12V, I believe

Geeze, this is messy.

When you made the following updates

$3tr= 0.079
$xjm= 197
$xjh= 384
$yjm= 197
$yjh= 384

Was the machine in inch mode or mm mode?

I took a look at all your hole_test files.
Just as before, your .dxf file opens and displays for me as I believe you intended.
If I import your .nc file to the QCAD CAM importer(simulator), same bogus arcs as I saw with the control_horn series of files.

From what I see, we might have two issues going on here.
1. Arc errors
2. tinyG Parameter interpretation errors.

Lets try this:
1. With your current Parameter set, rerun a quick test that confirms that commanding Z to move 1 inch moves Z by 1 inch (or, as you reported, 0.9996″)
I assume you are using a 1″ jog?
2. Change the $3mi parameter : $3mi=4 This cuts the number of microsteps per step in half.
3. Resend your 1″ jog command. How far does Z move? I am testing a theory that the $3mi interface is for some reason broken. There has to be an explaination for your needing to set $3tr to a value 4 times as large as it should be.

When you are done with the test, please dump and post another parameter list, IN MM MODE, and give it a clearly identifiable name. We may need that listing in a follow-on test.

One more item I missed

Is there some sort of filtering of the input .nc file prior to sending the code to the machine?

The ChiliPeppr UI has several selectable ‘filters’ that are able to modify Gcode. The auto-level capability, for example, modifies Z position based on pre-determined Z=0 variation across an X,Y workspace. There is also an ability to modify velocity with setting in the Gcode Widget (a static, or whole job modifier) and now in the tinyG widget for dynamic changes while a job is running. Velocity modification is achieved by manipulating F value settings on the fly.
Other custom macros, including your own, can be inserted into the logical path between the Gcode file that is dropped into CP and the input to tinyG.

A default CP set up does not modify Gcode on the fly.
SPJS, in managing the buffer flows into tinyG, inserts control commands as necessary for it to maintain knowledge of the tinyG state, but those are acted upon by the tinyG FW, not passed to the GCode interpreter processes within tinyG.

OOps, $3tr=(2/25.4) = 0.079 inches

(TinyG can’t output a 0-10v analog signal, right? :lol:)

Not directly, but the 3.3V logic PWM signal could be level translated with an open collector buffer to create a “10v logic” PWM signal which could then be filtered to DC in the range 0 to 10V.

I took a quick look at the references and see what they are doing. The first is a classic buck circuit, why bother? you have 12V available (the fan supply) which could easily be used to supply the converter.

My take is this interface does not demand a whole lot of precision; maybe you have an application where the spindle speed needs very precise control. The TI doc gives some good filter designs, perhaps just experiment with them, assuming you have the controller, or just hang a dc voltmeter on the filter output?

If you want to be bleeding edge adventuresome, have a look at tinyG2, a port to the Arduino DUE. The DUE has many available outputs that might better match your needs.
Caveat: some programming required 🙂
Start here:

https://github.com/synthetos/g2/wiki

I suggest to do some Google searching on the SuperPID interface, several folks have shown interest and or have successfully implemented.

mm vs. inch: tinyG saves its internals in mm, converts to/from inch when necessary. Most reference setups are in mm, so it is easier to spot issues with parameters when they are posted in mm.

I forgot to ask an important question, knowing that you use Chilipeppr – how did you enter your new machine parameters? If you used the configuretinyG widget in CP, that may be the issue here – it seems to be corrupting settings.

What I typically look for in parameter settings is wacky precision in values that don’t require precision, for example your $zvm=787 mm/sec, vs the typically suggested 800 mm/sec.
I also wonder about $1tr, $2tr and $4tr, which likely should nominally be 60mm unless you tweaked them (in mm or inch) to ‘tune up’ your machine for precision.
Also, $3tr=8mm looks unusual to me – what sort of lead screw do you have for Z? I am familiar with 8mm diam, 2mm pitch ($3tr=2) and ACME screws with $tr=2.117mm(yes, this particular ACME is an inch based design).
Additionally, your X and Y jerk settings look strange. Recommended starting points are JerkMax=5000, JerkHoming=10000.

Here is another interesting result; I imported the Gcode file your posted above into my CAD program of choice, QCAD.
Here is it’s interpretation:

https://dl.dropboxusercontent.com/u/50261731/banshee_control_horn_3.png

Looks a lot like what you are getting.
Note that QCAD and tinyG have nothing in common, except that the software developers read the same documents specifying how Gcode is supposed to be translated to machine motion.
I also opened your DXF file in QCAD, looks OK to me.

Dragging the same Gcode into CP looks OK. ???

Whatever CamBam is doing, it may be contributing here.

1. Please comment on my parameter comments – perhaps there are reasons you chose those values.
1.5 Was there some guideline document you were following to initially set up your tinyG?
2. Please comment on how you entered parameters after FW upgrade. If you used the configuretinyG widget, I’ll likely walk you thru a parameter reset. Usually fixes issues like this. Underlying cause not well understood.
3. Remember, always enter, manipulate and report tinyG parameters in mm mode; seems to work better. Inch mode Gcode should then run OK.

Sorry, I missed your post.
Lots of good info there, but difficult to dig in to.

Please put your tinyG into mm mode and repost the new parameter set.

Something clearly is wrong somewhere – 440.20 should fix numerous bugs in this area, not create them.

What do you use for sending Gcode? CoolTerm, Chilipeppr, …?

Problem **may** be that Gcode is sending circles as 360 degree arcs.
Try regenerating your Gcode with circles sent as 2 arcs, which is a typical option to fix what appears to be a long standing issue with the definition of arcs and circles in Gcode.
tinyG has, of necessity, become more strict on what it accepts as Gcode and this is an area of great confusion.