I've had another go at the Z-axis gib adjustments, it's now running with
a backlash of 0.015um and a slop of about 0.035um. That's about as good
as it's likely to get on the current setup. If you need better than that
then there's work that could be done on the boxford to make it better
but we've already got the low-hanging fruit and further improvements
will need increasing amounts of time and effort spent. If you need
better than we currently have then we could have a talk about how you
could try making those improvements.
As for writing G-code manually, I normally discourage that because it's
a very error prone process but if there's a specific reason that you
need it then it's an option. As you say, go very carefully indeed, use
lots of break-points in your program and pay attention to air-passes and
being ready on the E-stop but there's no fundamental reason why you
can't do it. You'll probably want to take a copy of the post-processor
from the boxford and study it so you can understand what it's doing and
how it's customizing the g-code for the boxford.
I understand there's g-code language modules available for notepad++ and
for Visual Studio but I've not used either of them for that so can't
comment on their merits.
On 05/09/2021 19:07, Andrew Carson wrote:
> Awesome, thanks Steve.
> On a slightly different note, I want to try writing my own g-code for
> simple operations. Obviously, I'll go (very) carefully, but is there any
> reason that this is a terrible idea?
> If it's not, does anyone have recommendations for a good g-code editor?
> On Sat, 4 Sept 2021 at 16:12, 'Steve Rodway' via rLab / Reading's
> Hackspace <reading-...@googlegroups.com
> > <mailto:reading-hacksp...@googlegroups.com
> To view this discussion on the web, visit
> You received this message because you are subscribed to the Google
> Groups "rLab / Reading's Hackspace" group.
> To unsubscribe from this group and stop receiving emails from it, send