cmcgrath5035

I would suggest a place to start would be to dig deep into the Chilipeppr (CP) code, particularly the Serial Port JSON Server(SPJS). SPJS runs on many machines, including RasPI, is written in GO for speed and is web centric.

CP is Open Source and well documented. It was developed by reverse engineering the tinyG Serial interface and uses low level status messaging to optimize buffer fill as its flow control mechanism. It evolved to also work with other motion control sub-systems such as GRBl and the G2core Line Mode protocol.

I’d also suggest you have a look at these links
https://github.com/synthetos/TinyG/issues
https://github.com/synthetos/g2/issues
where developers like yourself probe issues with the developers.

Start there, this topic could head in many different directions .

OK, pyserial is a good solution for parameter loading, AFAIK

Just to baseline our communication,
Hard Reset == the tinyG reset button or a power cycle
Soft Reset == ^x (ctrl-X) from a CLI

command ## == long list of the current EEPROM parameter values
command $gdi == show current value of parameter $gdi
command $gdi=1 == set value of parameter to 1
command $defa=1 == load ‘factory defaults’ into EEPROM
‘factory defaults’ are set at compile time

As far as I know (can’t verify at the moment) a Hard Reset or a Soft Reset should leave tinyG in the following state

Position = (0,0,0) where at the machine position when reset occurred
Parameters = values from EEPROM
Motion is idle

So $$ reports what the full parameter set would be if you were to Hard or Soft Reset tinyG, it does not report their current working values

In your most recent post, what I see is your ## parameter set, but your position shows X=30, so modifications to the working parameter set have been made.
I have to assume that in addition to x position not being 0, the working value of $gdi had been set to 0, perhaps by a G90 command in a Gcode file?

Does this help?

Please describe how you do the “.. issue 64 settings”.

Dumping a file to tinyG with minicom will likely not work.

There is a hardware bug in the controller device, which forces tinyG to block serial reads for the duration of an EEPROM write operation. Bits arriving overrun the input serial buffers and get lost and/or mangled.

What I mean by torque reduction is I observe that while it is stepping, it is easy to stop the x carriage with the slow g1 command. with the fast g0, the movement nearly takes my finger off. Not very scientific but that’s how I did it…

OK, understand your methodology.
Are you using microstepping? If so, do you need it for precision?
Typical stepper motors are ‘native’ 200 steps per rotation (some are 400).
By native, I mean that the pole/winding structure of the motor has 200 combinations of the two poles that will result in discrete movement.
Microstepping is achieved by having the driver modify the phases of the winding pulses to divide each of the 200 steps into 2,4,8,16,etc pseudo steps. These pseudo steps do not exhibit the same holding torque (force to hold position) as native steps.
When you run at very low speeds, e.g. f40, an increased percentage of time is actually holding torque, not moving torque.

This is a very readable reference for the TI 8825 drivers that are native to tinyG http://www.ti.com/lit/ds/symlink/drv8825.pdf.
The discussion on microstepping can be informative, if interested.

Looking back at your posted pictures, I have to wonder if the .2 mm offset you were seeing is the result of a long standing tinyG computation precision bug. The best released version of tinyG FW is $fb=440.20. If that is not what you are running, update.
What your pictures depict is often referred to as ‘drift’, i.e. after running a Gcode job, the physical location of (0,0,0) is not the same as logical (0,0,0).
tinyG (and therefore cnc.js) report logical position, not physical. If step pulses issued by tinyG do not result in proper movement, due perhaps to inadequate torque or binding mechanics, or if tinyG skips a move due to a computational error (the bug), drift can occur.

drift is almost always the result of G2 or G3 arc commands.
Testing first with G1 commands is good to get started, but running a job such as depicted in your pictures, which I’ll assume uses G2 and G3 moves, is also necessary.

I am a bit confused by your comment ” I did notice the torque was much reduced at this slow rate. so I am suspecting my stepper controller.”

Are you using an external stepper driver (controller)?
What observation makes you say torque is reduced?

As you observe, the G0 version of your program runs at whatever you have set for max velocities in X,Y and Z, where as G1 f40 runs at 40mm/minute.
The torque applied to the discrete rotations of the stepper is nearly the same at Vmax and F40, in a real world the effective torque would be slightly less at Vmax.
On each step pulse, the stepper controller dumps a pulse of current into each winding, at the correct timing, to create movement. The current level is controlled by the POT. At higher speed, I would expect the motor core to heat up a little, as the stepper heats up a given pulse of current will generate slightly less effective torque, but that should be trivial.

Keep in mind the following as well:
The first two lines of your program are
G0 x10.0 y10.0
g0 x10.0 y50.0

tinyG implements continuous motion from the starting point(I’ll assume (0,0)). When the motion gets close to the (10,10) point,a third order polynomial track is computed to keep the the spindle in motion as it changes X velocity to zero and continues on to (10,50). The actual path of the spindle will not pass thru (10,10). The amount of ’rounding” at each corner is a function of the velocity of the spindle and it’s mass, with the mass represented by the jerk parameter ($xjm, $yjm, $zjm).
When the program runs with f40, the momentum of the moving spindle will be lower and the computed third order polynomial will more closely match the path over (10,10).

It might be useful to dump your parameter set ($$ command) and copy it to a cloud drive, then provide a URL.

Also, just to clarify what I think Zootlaws is suggesting “Always start from a factory reset. ”
I believe he is saying move you spindle to what you want to be the (0,0,0),
then do a hard reset of the tinyG board with the pushbutton or a software reset from the CLI (^x Reset (control x) )

For tinyG, a “Factory reset” is a $defa=1 command from the CLI, probably not what you want
https://github.com/synthetos/TinyG/wiki/TinyG-Configuration-for-Firmware-Version-0.97#defa—reset-default-profile-settings

Perhaps I am reading this differently, Zootalaws.

@richl, are you wanting to connect the TinyG Spindle PWM output to the input of a Stepper Driver device as the step input?
The stepper driver device converts a step pulse (probably the rising edge) into properly phased drives for the two windings so that proper rotation is achieved and manages the max current in the windings.

The number of pulses per full rotation is a function of the winding design of the motor.
The driver takes inputs to decide if microstepping is to be implemented, which changes the winding phases.

You don’t really need tinyG for that…….

I don’t see user parameters listed here
https://github.com/synthetos/TinyG/wiki/Gcode-Support,
so likely not supported

I don’t see a workaround in tinyG, you of course could develop a Gcode stream preprocessor., but not clear how that would help.

You are generating your own Gcode?

I agree with Zootlaws observations on an 80W ‘spindle’.
Maybe OK for precision engraving, not for medium or heavy duty milling.

If you decide to purse vfd based spindles, be aware that tinyG does not directly support them, but can with an interface circuit. Zootalaws can provide some guidance.

tinyG’s native spindle output is a 3.3v logic PWM signal, compatible with several spindle systems and controllers in the 400W range.
Here is an example, not necessarily a recommendation

Given a quick look at the BE3030, something in the 200-400W range should be adequate, if they will fit.