- This topic has 8 replies, 2 voices, and was last updated 7 years, 1 month ago by
.
-
TinyG is running on an OX machine (OpenBuilds), NEMA23 Stepper motors and 24V@14.6Amp power supply.
the machine has been running fine for a while, but lately I noticed that a portion of my cut was not accurate. I narrowed it down to a section that has a figure of a SPIRAL on it SVG File (Inkscape)
I’m running CHILIPEPPR.
At this moment, my machine is running with no load and I am using a pen to draw the output (after ruining some material). The speed is just 300 mm/min, but regardless of speed the result is always the same.
FIRST:
I generated the code with JSCUT which generates just G1 codes (small lines).
Here’s the G-Code GCode-JSCUT Original
Here’s the Output Output-JSCUT-Original
From the image, the machine made some strange and uneven movements, I expected to have a constant distance between cuts, but it varied from 2.5mm to 5mm.I verified the paths on CAMOTICS and CHILIPEPPR and all looks good and constant.
What am I doing wrong??
SECOND:
I took all the code generated on the previous stage and flipped it, meaning the first position is now last and the last is now first. The direction of the path now is INVERTED. But all coordinates are exactly the same as previously
Here’s the new G-Code GCode-JSCUT Inverted
Here’s the Output Output-JSCUT Inverted
From the image, the machine made some strange and uneven movements, and more surprising is that the drawing is not the same as the original; where I used to have a gap of 2.5mm now is 5mm and where I used to have a gap of 5mm now is 2.5mm.
This is the same coordinates on a series of very small straight lines, did not generate the same results. I get to the conclusion that it might not be an issue with my original drawing on Inkscape but something with the machine.Why is it that using the same set of coordinates, I’m getting a different result? Both wrong by the way.
What has to be done in order to get the right output?
THIRD:
I switched from JSCUT to MAKERCAM, and generated a new G-Code. This time MAKERCAM generated the code with G2/G3 codes as opposed to just G1 from JSCUT.
Here’s the 3rd G-Code G-Code-MAKERCAM Original
Here’s the Output Output-MAKERCAM Original
As can be seen from the drawing it is exactly the same result I’m getting from the FIRST case, Meaning the gap of 5mm is where the original gap of 5mm was and the gap of 2.5mm is where the original gap of 2.5mm was. The figure is almost identical.This time – sound wise – the stepper motors were producing “music”.
Two instruction’s set completely different are generating the exact same wrong output. One limited to G1 codes while the second using G2/G3 codes.
FORTH:
I went to TinyG’s configuration and moved the JERK MAXIMUM at (million) 2, 10, 250, 5,000 and 10,000 and the problem is still there. The drawings are almost identical (at lower level the edges are a bit rounder, and a higher values the edges are sharper).
Here’s the configuration file TiniG Configuration file that I’m currently using.I also moved the potentiometers to higher values with no change.
After spending too many hours trying to figure this out, here I’m requesting support to solve this issue and better understand what’s happening and more important the limitations on TinyG.
Thanks in advanced for your help!
I am not an Ox owner, but there do seem to be many happy with their machines over at the Ox Forum
.
Let’s not kid ourselves, even the big industrial machines need good maintenance. It would appear you have discovered the critical areas to keep track of.There is no easy answer to the screw vs belt question. Screw machines are costly to scale(in size) but perhaps more rugged.
Generally speaking, the lower the value of $_tr, the more usable holding torque from your motor spec you get.The torque/pulley issue.
AFAIK, Ox specifies the smallest pulley that is generally available for GT2 belts, which are more rugged than MXL belts used in ShapeOko designs.
Smaller pulley diameter is better, from a torque load perspective.
It is perhaps easiest to think of the issue in terms of holding torque.
If you energize your motors to hold a position, then try to push the gantry manually in X or Y direction, your pushing force is translated into a rotational load on the stepper shaft, the stepper pushes back with the torque available determined by how much current you dump into the stepper, which at rest is acting like a stationary electro-magnet.
In this mode, the pulley diameter acts to amplify the amount of torque on the shaft you are creating by pushing on the belt. That torque amplification scales, I believe, as radius-squared, radius of the pulley.
A long while back I did the math and came to the informal conclusion that an Ox with ‘good’ quality NEMA23 motors and ShapeOko with ‘good’ quality NEMA 17 motors had about the same gantry holding properties out-of-the box.
The Ox design wins here for heavy duty users because there are a lot more stepper options above ‘good’ level in terms of available holding torque. And some folks have even gone to NEMA 34 motors.
Alas, high torque motors, high current drivers, cooling systems and power supplies drive costs up quickly.I hope that helps, the math gets complex and there are way too many variables to get super specific.
3DPtr: I am not a player yet, searching like your for alternatives. If you dig into G2core
you will see that a lot of the recent work is targeted at 3DPtr enabling enhancements. G2Core is the motion engine for several evolving 3DPrinters.
My take is that the bigger question in that space is around the CAM layer software features, functionality and the entire 3dPtr tool chain.A lot more complexity, and a lot more opportunity in 3D space, depending on what you want the end result to be.
- You must be logged in to reply to this topic.
