cmcgrath5035

chmr – You know the Ox design well. Thanks for comments. I’ll agree with your characterization “nifty idea with unwanted side effects”.

Rhino – When I play with CLI moves, I keep these in my head:
G0 moves are at max velocity
G1 moves are at F velocity
G2 and G3 moves are arcs, I don’t try them from CLI

So, from a tiny G reset with the Z above the work surface, which sets current position at (0,0,0) , you could do
G1 Z10 F20
G1 Z0
G1 Z10 F40
G1 Z0
etc., incrementing velocity (Fxx) until it starts to misbehave.

From where do you get the 50mm/min slow start velocity value? From tgFX? That velocity display is tgFX diplaying the status messages returning from tinyG, which are the results of the 3rd order calculation tinyG is doing. Not clear why this would be happening, your parameters seem reasonable (jerk, Vmax). If this persists, perhaps cut your $[xyz]vm and rerun, as an experiment.

Electro-mechanical considerations:
Z motor making any strange noises? Have you tried a run with current pots maxed out? You’ll need more torque from Z motor to move spindle up down with 8mm/rev speed.

Are the Z motor to lead screw coupling set screws good and tight?

I don’t have any other great debug ideas. Perhaps Alden will.

Do you have a Atmel programmer?
You could try re flashing tinyG, to see if that function works.
There no obvious reason that should help in this case, but if the re flash does not verify, that might be another indicator of failure.

You could level shift the Due to 5V, or you could fiddle with the tinyG level shifting resistors per post 6801.

BTW, should you get up and running again, I would expect XonXoff flow control to work with the serial interface. Running with no flow control likely not good for Gcode runs.

Good hunting

Thanks for the comments, chmr. Hopefully Rhino will be able to report better results after a couple tweaks to parameters.

Chmr has more experience than do I, so I use this set of good information (in Rhino’s dropbox set) to pose a somewhat philosophical question:
Why compromise the torque gain one gets by using NEMA23 motors with large pulley diameters? There seems to be a bias toward speed of movement, rather than using the available torque to better control the spindle mass. And if precision is important to the end user, this 60mm/revolution machine is about half as accurate as a Shapeoko, at 36.54mm/revolution. There is no right or wrong here, and for light duty jobs (laser, 3D printer) these might be more optimal choice.
Likewise, the use of a “fast” lead screw on Z significantly reduces torque available to control the up/down motion of the spindle. Of course, choice of spindle is a free parameter in this situation.
There is not right or wrong answer here, more philosophy.

Rhino: How did you create the Dropbox URL that you posted? Specifically, how does one get the ‘skin’ that allows switching between ‘list’ view and ‘thumbnail’ view? This is a very effective way to share information on issues such as this, given the limitations of the forum tool we have.

Cheers

An additional suggestion, since you use tgFX.
Only one application; Coolterm, tgFX, avrdude can be attached to your USB port connecting to tinyG.

Earlier versions of tgFX had an issue of not exiting cleanly if you did not first disconnect from the USB port. The GUI would terminate but a tgFX process would remain running (as seen in Task Manager). If you get a ‘can’t connect to port’ error from avrdude (or CoolTerm), check Task Manager and kill the tgFX process, or just pull out the USB cable and reinsert it.

I’m actually a bit surprised that a set screw being that loose resulted in such a small, therefor hard to detect, error. Perhaps it was on one of the Y motors, leaving the other to do most of the work?
Anyway, good find.

Your use of the term ‘pocket’ leads me to think you are milling a 2.5D job of some sort.
Perhaps now is the time to upgrade your machine to the latest tinyG FW, 438.02 if not already, I have lost track of where you are at.
While the differences between 435.10 and 438.02 are minor, they were changes to fix machine dynamics when Gcode calls for very short moves. Many 2.5D code generators seem to be outputting code with move increments at or below the minimum capability of the machine. TinyG seeks to accumulate such short moves until a physical move can be made, there were some bugs up thru 438.02.
BEWARE- Loading new FW will reset all your configs, you will have to re-enter. Make sure you have a copy of where you are at.

This forum tool is tough on images and long files. What we suggest is to set up a dropbox or equivalent clould sharing account. put images, configuration files and Gcode examples in files, and post here a URL.

And, very long threads become difficult to look back into as well.
Since you seem to be more or less up and running now , with all your screws tight ( 🙂 ), I suggest start a new topic, with new Subject that refocuses on more specific issues.

And now perhaps an opportunity to address your CAMBAM post processor question. I don’t use CAMBAM, so don’t have specific suggestions, but here are some fundamentals that the post processor might address.
1. Configure to use arcs – Gcode G2 and G3 commands. Work well with tinyG.
2. Use reasonable precision – tinyG will keep track of line segment requests down to 0.08mm and arc segments down to 0.10mm. not much point in requesting a 1.0001 mm move.
3. Do the math and understand the fundamentals of your setup, specifically the minimum moves that it can make in the X,Y and Z directions. The minimum move a stepper can make is a microstep. The number of steps per revolution is a physical parameter of you motor. The number of microsteps is programmable, [1,2,4,8]. Pulley diameter and belt pitch determine the travel per revolution. From all those parameters, compute travel per microstep in each direction. You will find these to be larger than the tinyG minimums for a typical NEMA23 machine. It is then a personal preference how precise you have your Gcode generated. Maybe 2x, meaning that if a microstep is 0.2 mm, generate Gcode with 0.1mm accuracy. Super accurate Gcode will run, but it will be a much larger file, will take longer for tinyG to interpret (i.e. slow the machine sometimes) and won’t deliver any additional accuracy in the final job, because of the machine fundamentals.

Enjoy

Alex
The number of bytes written , 117,552, seems reasonable

Do you have vi adding the line numbers?
They should not be part of the file.

Here are the last four lines of the file as I see it (Linux, kate editor)

:10CB04002E31660025302E32660025302E33660025
:10CB140025302E34660025302E35660025302E361D
:0CCB2400660025302E37660025660000F4
:00000001FF

Same hex, no line numbers

Flow Control – Pick one, both work.

You should not have to reset.

Do you have limit switches enabled?
Disable them for now.

Is $ej still = 0 (text mode) ?