cmcgrath5035

I have no experience with GRBL-GRU and very limited with UGCS. Most of my work has been with Chilipeppr or CoolTerm, and occasionally via a Linux putty terminal. I have over time had folks attempt variou bulk loading schemes for setting parameters that resulted in erratic behavior. defa=1 was a recovery mechanism. The root of the issue in those cases is a hardware bug in the tinyG micro controller-EEPROM interface, which is patched by shutting down the serial reader interface while an EEPROM write is being performed. Manually entering parameters one at a time via a CLI is OK, bulk loading needs to be properly implemented to ensure all data is properly written.

In Chilipeppr, code in the SPJS properly handles this.

In this item https://github.com/synthetos/TinyG/wiki/scripting-settings
a 40ms delay is suggested. I have seen delays as much as 100ms. Up to you

What you are engaged in is beyond my level of expertise, here are some hints and ideas to pursue.
You report that your Gcode runs mostly fine using Chilipeppr. Buffer management in a Chilipeppr implementation is the role of SPJS, among other tasks. My gut impression is that “..leaving 10 slots free all the time..” does not match the SPJS methodology. I am making the assumption, by the way, that your Python3 session is communicating directly with TinyG, not via SPJS.
If you buffer management is not achieving the same fill rate dynamics, you may be forcing the motion planner to compute different motion paths.

This sort of topic is much lower level than typically found in this forum. You should give a look at the issues area here https://github.com/synthetos/TinyG/issues here most developers are their thoughts and ideas. The G2 issues at https://github.com/synthetos/g2/issues might also provide some hints, although G2 code is now well beyond tinyG Master

Good luck with your project

I’ll assume you have looked thru the wiki information at https://github.com/synthetos/TinyG/wiki . I have not seen anyone try this, either using onboard flash or On-board EEPROM.
If there is help the be had, it would be available at https://github.com/synthetos/TinyG/issues where you can ask your questions and hope a developer or customizer like yourself stops by and shares ideas.

Good luck with your project

It could be an issue with your setup parameters.
If you are using Chilippr or CoolTerm, head to the console and enter $$ and return to dump your parameters. Copy and paste them to a text file on you favorite Cloud drive (Gdrive, OneDrive, etc) and post a link to them back here.

One item that looks strange in the above is that Homing Z should find the maximum, not minimum

Also be sure to review this wiki item:https://github.com/synthetos/TinyG/wiki/Homing-and-Limits-Description-and-Operation

Nope, maybe I would need to be logged in to that forum?

Chilipeppr uses the information on tinyG buffer fill to manage flow..

I am making the assumption the 2D motion is ‘snappy’ , i.e. not slowed.
Are you using arcs to define the cut, or very short segments (linear interpolation)? Are you seeing any error messages in the console?

There are of course a zillion parameters to ask about. Do normal 2D jobs run ‘snappy’?

Here is a forum where a lot of laser active folks hang out
https://forum.makerforums.info/

You ask good questions, all lack specific details on your knowledge base and require some interpretation on my part.
I’ll assume you are familiar with the tinyG wiki found here
https://github.com/synthetos/TinyG/wiki
I’ll assume you have found and understand the tinyG schematics found here
https://github.com/synthetos/TinyG/tree/master/hardware/v8schematics/v8h

For my own education, are the broken-out stepper signals on the Tiny G PNP or open-collector (looking at page 4 in https://www.omc-stepperonline.com/download/CL42T.pdf)?

Review https://github.com/synthetos/TinyG/wiki/TinyG-Using-External-Drivers
It addresses some of your questions, I am assuming you are calling J17 – J20 the breakout signals. These are simply bridge points on the internal connections between the microcontroller and the 4 driver devises on tinyG.
they are 3.3V logic levels and you should assume limited drive capability.
I would not recommend you assume these logic points meet the Logic Signal Current spec on the CL42T sheet, you will need a buffer.

I know of no breakout boards easily adaptable to tinyG.
You should review https://github.com/synthetos/g2/wiki/G2core-on-DUE—External-Interfaces the suggested circuits for interfacing G2 boards are a good guide. You should fully understand the G2 environment, it may be more adaptable to your project. There are breakout boards available for a Duo running G2core.

You could simple invert the enable lead, but you must then analyse you built up system to ensure that steppers will not be enabled during power up and power down transitions.

tinyG has been successfully interfaced to more generic opt-isolated step-dir=enable stepper drivers. The CLT42T is aimed at a more complex stepper. In fact I am not sure exactly what a

r 2-phase NEMA11, 14
and 17 stepper motors with incremental encoders(Encoder resolution must be 1000-line).

is.

It is also unclear how you would deal with the fault signal returned by the CLT42T. tinyG would not know what to do to recover from such a fault, in general.

Sorry for delay, away for the holiday.
Directions are somewhat a matter of preference on how you wish to use your workspace.
TinyG commands for homing assume homing to Xmin, Ymin and Zmax.

My best guess id you need to reverse the Y polarity.

What sort of machine do you have?