Forum Replies Created
-
AuthorPosts
-
cmcgrath5035
ModeratorHere is a good place to start the discussion
ModeratorMissing something – no, you are not.
tinyG is predominately used for 4 motor (X, Y, Yr,Z) setups so each motor gets a driver.
Some folks move to using external drivers.
Most NEMA23s generate good torque at 1A or less(each).
But if you want your setup to have max drive capability, individual drivers and good thermal handling (heat sinks, fans) highly recommended.ModeratorThanks, good to know different ones out there.
When Pitch is provided, $_tr = PitchOne has to do math when TPI provided
ModeratorI believe the pitch on 8MM rod is 1.25mm.
Most folks use
$4tr=1.25
and
$4mi=4ModeratorIf you play with CP at all, you see CP/SPJS sending $ej=1 after every command, as a means of keeping tinyG in JSON mode.
I suspect that JohnL found, by experience, that some commands left tinyG in text.
I am not sure what correct answer to your question is, but would suggest $ej=0 after each command gets sent would be advisable.
ModeratorMake sure $tv=1
Sending $ej=0 should put tinyG in text mode.
Are your wanting tinyG automatic status reports in text mode?
Are you running Chilipeppr?
Since CP makes extensive use of JSON , it is unlikely you can get text mode status, since CP is aggressive about keeping tinyG in JSON mode.ModeratorThis item may help
Lots of info spread around other wiki sections
ModeratorGood news!
Do you have Soft Limits enabled?
That might explain the stop half wayModeratorOK, I think we may need to try this:
I’ll suggest you upgrade your FW to the current Edge Build, $fb=440.20.
The changes 440.18 to 440.20 are focused on handling some difficult arcs, so that is not directly affecting you at the moment, but I believe what you really need is likely a complete reset of the EEPROM stored parameters. We could do that with a $defa=1 command and then restore all your motor and axis parameters, but moving to the most current FW makes good sense and is only incremental effort.The good news is you already have the current value settings for your Ox in a file to use as reference..
I recommend you stay away from the configuretinyG widget. It worked well back in May when released, but significant churn in tinyG fw and in CP seems to have caused the widget to corrupt EEPROM parameters.
Your best options are the CP Serial Sport console, one parameter at a time, or CoolTerm (or equivalent).It should go without saying that caution is advised with your forked version of configuretinyG. Writing parameters reliably in batch to tinyG is a non-trivial task. Perhaps more important, future tinyG FW will migrate to a significantly enhanced, but changed, parameter set. To get an idea where it is headed, review
FV 0.98 represents the merger of the tinyG and tinyG2 code and feature bases. It will likely impact any GUI interface you are designing by reverse engineering the current parameter set.
Also, set up and use a cloud drive to share your parameters – this forum interface is difficult to manage with long text dumps. See:
ModeratorAt first read, your parameters look OK with the exception of the Z axis. Those setting should not affect X and Y homing.
I do suggest your read this wiki item a couple of times (lots of meat in there)
For your Z axis, your settings do not follow the tinyG guideleines for homing.
The Zmax switch should be set as the Homing switch, with the Zmin switch disabled.
Typically Z travel Max ($ztm) is set to 0 if you plan to home Z axis.
$ ztn would in your case then be -75mm, but that is in reality only important if you turn on soft limits. Because a real $ztn is a function of your tool and how you mount it in the chuck, $ztn is difficult to use.I would suggest these parameter changes
$tv=1
$xjh=10000
$yjh=10000These are more in line with ShapeOko/Synthetos recommendations.
Are you following some recommended setup settings from somehwere?
I have seen these numbers before and don’t fully agree with them.Nothing on what I have recommended so far gets to the root of your issue.
If changing the Y axis polarities results in a homing cycle that goes in the same direction irrespective if polarity setting, something is fundamentally wrong.
What are you using to send homing commands?
CoolTerm, Chilipeppr, something else?What homing command are you sending?
Are you confident that X, Y and Z movement is generally working?
Either by jogging or by issuing CLI commands?What are you using to make parameter changes?
Cool Term, CP Serial COnsole, ??The CP configuretinyG widget has been producing some strange results of late, please respond if that is what you have been using.
ModeratorPlease keep in mind that for readers, like me, who don’t work with the Ox, front and back are sort of meaningless. Also be aware that most tinyG documentation was developed in the context of ShapeOko machines, which have a different model for where (0,0) is.
When you say you reverse polarity in Firmware, I assume you mean you flipped the polarity setting for the Y1 and Y2 motors in the setup parameters.
Are you saying that from an arbitrary location (0,0), issuing a “Y +10 units” jog moves the same direction, irrespective of Y motor polarity setting?
That is just not right.What FW build are you running?
Perhaps post your entire parameter set ($$ dump) for a look?
Is this a new machine that has never worked ‘correctly’, or is this behavior a recent phenomenon?
ModeratorHere are results of a quick test on my tinyGV9, next gen platform but the fan drive same, however the regulator device is physically smaller.
I have an older ultra thermoflow 80 mm 2500 rpm fan blowing up on the bottom of the board. Spec is I believe 2.16W max.
I can hold my index finger on the regulator for “1001-1002-1003” before my brain says ‘hot, ouch coming’.
ModeratorThe drivers are in a “Power Pad” smt package, you can read about them here:
So what you see on the bottom of tinyG are the recommended connection points from the package to the ground plane, which acts as a heat sink
You could also fashin a heatsing and attach to that pad as well.
Blowing air on the board is usually adequate.
U8’s thermal tab also connects to the board for heat sinking.Seems a rather inefficient fan, a quick look into my junk box sees a couple 80mm fans in the .16-.19A range. Maybe just try a different one?
I don’t think blowing on top vs. bottom would make all that much difference, actually bottom might be better
I have one of each, fan mounted approx 0.75″ from the tinyG surfaceModeratorHow big a fan are you running?
I use a 92mm TT9025A 2.64w (rating .22A max) fan that blows down directly on top of tinyG, so the LM7812 benefits from the airflow as well as the driver devices.
Since it is 24 V to 12V , the regulator will be dissipating about 2.64W as well.I honestly can’t say I have touched around that area, I am sure it is warm but yours sounds much worse.
ModeratorAre all your G2 and G3 full circles?
Mine were. It turns out there is a long standing disconnect in Gcode space with the formal definition of a full 360 degree arc.The common, longstanding resolution is to send full arcs as two half arcs, most Gcode generators do that by default or provide an option.
Full arc Gcode that does not meet the Linux CNC formal syntax criteria is skipped.
-
AuthorPosts
