2024-01-15

Last modified: 2024-01-15 21:34:37

• G-code Sender
• Car

G-code Sender

I know this is a distraction from the watch project, but I am kind of interested in working on a replacement for UGS that is less annoying to use. Specifically, I want to be able to drive with keyboard instead of (as well as?) mouse, and I want to be able to jog the axes precisely and quickly and easily. So it needs to be very easy to switch between continuous/incremental, and change the size of the increment.

It definitely wants to be keyboard-focused, but it doesn't need to be unnecesarily difficult, so all the space that is not wasted on buttons can instead be spent on showing you what keys you can press.

But I need to work out how I'm going to implement the GUI. My preferences are Perl, Go, or Javascript/Electron. I don't want to use Electron because it is slow and annoying, but I can't deny that using HTML is ruddy convenient. I've asked ChatGPT for some suggestions. Apparently the good choices for Go are fyne and gioui.

There aren't really any good choices for Perl (probably Gtk, but that sounds annoying before I've even looked at it).

First impression of fyne is that it is pretty heavyweight, I'm having to download an awful lot of go modules to get it to work. And both the ChatGPT example program and the official fyne_demo don't appear to work. No terminal output, no window appears.

So let's look at Gio UI. The example programs on the Gio UI website look more like what I'm going for anyway.

Gio UI doesn't work either:

$ go run gioui.org/example/hello@latest
go build gioui.org/app:
# pkg-config --cflags  -- egl wayland-egl wayland-client wayland-cursor x11 xkbcommon xkbcommon-x11 x11-xcb xcursor xfixes
Package xkbcommon-x11 was not found in the pkg-config search path.
Perhaps you should add the directory containing `xkbcommon-x11.pc'
to the PKG_CONFIG_PATH environment variable
No package 'xkbcommon-x11' found
Package x11-xcb was not found in the pkg-config search path.
Perhaps you should add the directory containing `x11-xcb.pc'
to the PKG_CONFIG_PATH environment variable
No package 'x11-xcb' found
pkg-config: exit status 1

Such fun.

In less than the time it is taking to run apt update on my desktop, I have got it working on the KDE laptop. (Why is apt update being so slow?)

There is a good eggtimer tutorial and a teleprompter tutorial from the same guy. The teleprompter is ideal because it is mostly controlled with keyboard, which is basically what I want for my G-code sender. I am satisfied that Gio UI is going to be the best way to make this.

So probably the place to start is to make a first-pass that I expect to throw away, that has only the absolute barest of essential features. And if it ends up structured sensibly then I can keep it, otherwise I throw it away and at least I've learnt how I don't want it structured.

There are a few things I don't like in the tutorials, for example the egg timer recalculates the egg shape every frame, even though it never changes. That is moronic. But I don't have to make that kind of blunder. For example I'll plot the G-code onto an image and just blit the image every frame. I thought I could have the "G-code from file" and "actual travelled locations" drawn on two separate images, and then composite them together to make the final image, in such a way that it is obvious which lines are:

• travelled but not in G-code
• in G-code but not travelled
• both travelled and in the G-code

So then we need to draw the "movements in G-code" image whenever the G-code is loaded or the screen is resized, and we need to plot a new line on the "movements travelled" image whenever there is an update from Grbl. And then in steady-state, for a single frame, we're doing either nothing, or just drawing a single line. Also maybe rapid movements in G-code-to-run should be a different colour.

For testing I can hook it up to an Arduino running Grbl but not connected to any actual hardware.

I kind of like the idea of being able to drag around and resize parts of the UI, but maybe that's too much trouble for a first pass.

Key bindings in normal mode:

 A[expr] - set A coordinate
 B       - reserved for potential B axis
 C       - reserved for porential C axis
 F       - open a g-code file
 G       - [every mode] start typing in MDI, beginning with "G"
 H       - reserved for homing
 J       - jog mode (see below)
 L[expr] - jump to line in g-code view
 M       - [every mode] start typing in MDI, beginning with "M"
 O       - overrides mode (see below)
 P       - pause
 R       - run
 X[expr] - set X coordinate
 Y[expr] - set Y coordinate
 Z[expr] - set Z coordinate
 Ctrl-C  - clear MDI input; if MDI is empty then stop current incremental jog, or current job
 Ctrl-R  - search MDI (see below)
 ?       - [every mode] show current key assignments
 Esc     - [every mode] return to normal mode

Override key bindings:

 F[expr] - feed rate % override
 R[expr] - rapid feed rate % override
 S[expr] - spindle speed % override

Jog mode key bindings:

 A       - jog A axis
 I[expr] - jog increment
 F[expr] - jog feed rate
 P       - toggle whether probe contact makes it stop (default on?)
 shift   - 10x increment
 arrow keys - X/Y movement
 PgUp/PgDn - Z movement

In jog mode if a key is held down then it turns into continuous mode.

I'd really like to keep access to the MDI open as much as possible, possibly even during G-code sending, for example to let you send an "M3 S24000" in the middle of random other lines. And if you type something that crashes the machine then it's your own fault.

Allow MDI commands to be chained with semicolon, for example "G0 Z5; G0X0Y0; G1 Z0 F100; G1 X10 F1000; G0 Z5" so there's no dwelling while typing.

Allow MDI commands to be pipelined, so it lets you type while it's still busy.

Remember work offset when disconnecting, so that next time you start it up you keep your coordinate system.

Auto-connect to serial devices and check if they're Grbl.

Make it very clear when it's connected and when it's not.

It should be very clear in the G-code view which line is about to be sent and which one has just been sent.

Working name: "pugs" for "Power-Users' G-code Sender", can have some pugs for a mascot.

Car

I did some long-overdue maintenance on the car today:

• new fuel filler tube (because of the rust problem with the old one)
• oil+filter change
• new spark plugs
• new piece of windscreen washer hose

The fuel filler tube was Martin's idea, I hadn't considered that it would be an independent part and easy to fit, I kind of assumed it was welded to either the fuel tank or the bodywork. Easy to do though, just 2 bolts and 2 hose clamps.

Oil and filter change was straightforward, didn't spill too much oil on the drive.

Replacing the spark plugs requires removing the airbox which is bolted to the top of the engine, but of course some of the bolts were rusted in place, so I sheared a couple of them off. I don't think it's too much of a problem, might just confuse the airflow sensor if there's a substantial air leak after the sensor. It seems fine though, I don't think it leaks very much if at all.

And while I was in there I noticed that a short piece of windscreen washer hose had a hole worn in it from rubbing against something, so I fished out a similar diameter piece of rubber hose and replaced it.

Also got the car washed.

Also I read online that if you disconnect a misbehaving lambda sensor then the car will actually run better. So I have disconnected the lambda sensor to see if it is any improvement. So far it doesn't appear to be worse, not obvious where the stuttering problem is gone or not. Apparently having no lambda sensor means it runs slightly rich all the time, which eventually damages the catalytic converter. I'm also not sure whether it will mean the check engine light is permanently on, and whether that is an MOT fail. So we may have more work to do come MOT time. (Or a new car to buy).

All seems golden for now though.