cmcgrath5035

From your description, I assume your work flow is to design and generate Gcode in Aspire, then use CNCJS as CAM to manage delivery of the Gcode to tinyG.
I am not fluent in Aspire or CNCJS.

Perhaps for starters, leave your Aspire Gcode out of the picture.
Start up your machne with CNCJS connected as CAM.From the Serial console, execute a probe cycle from the command line.
Here is an old Forum reference https://www.synthetos.com/topics/how-to-locate-workpiece/#post-10934

See also https://github.com/synthetos/TinyG/wiki/Automatic-Z-Homing-When-Milling-PCBs

My initial guess would be you are experiencing a variation of what is usually referred to as the “arc issue”. Is the hole coded as a 360 degree arc (aka circle) or multiple segments that total 360 degrees?

The easiest solution is often to regenerate your gcode in MM, rather than inch. Another option is to have your gcode generated without arcs, so circles will be all short segments.

I am assuming your tinyG $fb is 440.20

That is a Ripple Filter circuit

Part ID is on Schematic Murata 1255AY-150+P3
https://www.digikey.com/product-detail/en/murata-electronics-north-america/1255AY-150M=P3/490-10802-1-ND/5271544

See reference design here
http://www.ti.com/lit/ds/symlink/lm25011.pdf

It will be a challenge to remove the old unit from pwb, the ground plane layer beneath is a great heatsink

A quick scan of known places I find nothing either.
I don’t recall ever seeing it enumerated

Suggest you post this over at https://github.com/synthetos/TinyG/issues, where the developers drop by.

I believe I have seen information that says one needs to read
1.000 mm as Logical 1, yes, the axis is homed.

Need to dig a bit.

Json – I don’t believe there is, more dig

Give that URL a read and a try. I developed it a while back for exactly the purpose you describe, as well as a way for CP users to generate a text file that would be helpful in Forum discussions. It seeks to automate a CLI interaction via coolterm or the like.

It may not work, be sure to switch to mm mode before trying to run it.
Access to the sub-widget was broken by the move of CP to the new host platform, but that is now fixed.

If you are not a Chilipeppr user, there are some ad-hoc Python scripts around that implemented the same function.

What may not be obvious, depending on how deep you read the description: there is a hardware bug in the microcontroller on tinyG that requires a wait between each parameter write. The script sends a parameter, then waits for a response from tinyG before sending the next one.

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

Based on what I see, particularly ” If I back the feeds and speeds off, the programs will complete “, my guess would be one or more of the stepper drivers (not the steppers) are shutting down due to thermal overload.

Do you have a fan blowing on tinyG?

Another good test would be to run the job “in-air” above the work piece by setting a high Z=0. If job completes at your desired speed settings, then it is likely thermal overload.

For tinyG, the most effective heat sink is the PCB, so good volume of air movement helps.
What voltage are you running your motors at?