2024-02-18

Last modified: 2024-02-18 15:30:46

Pugsender

I want to fix some more data races in Pugsender by having it send a GrblStatus struct or something over the status update channel, instead of having the UI thread read directly out of the active Grbl object.

https://github.com/jes/pugsender/commit/d7b3d6321443468172558e1892a622f21238a33e

I'm really dissatisfied with the jog control. I don't see why it can't work as well as I want. There should be no problem jogging one axis continuously while another jogs incrementally. I should be able to get them to act independently of each other. The 2 problems are:

1. cancelling a jog command cancels all axes simultaneously
2. there is only one planner buffer, but I want to move the axes independently

I found an improvement by sending a jog cancel after every incremental jog command, so that we reduce the planner buffer size during incremental jogs, makes it feel more responsive.

I need to read http://usingcsp.com/cspbook.pdf

And I think I want to fix the architecture of pugsender so that each "component" has an interface with functions that you use to control that component, and channels you can read/write as appropriate, and an implementation which has functions that are only called "internally" to that component, and communicates with everything else via channels.

Each component would ideally only have one goroutine, but I could tolerate short-lived ones for special purposes. They should act externally like they only have one goroutine.

Obvious components would include:

• GUI
• gcode loader
• gcode runner
• grbl connection
• jog controller
• auto-connector
• toolpath renderer

And each of these components would have potentially 2 source files: one that implements the component's internal operations, and one that exposes an external interface.

Loading a gcode file would have the GUI component select a filename and hand it off to the gcode loader, which would read from the file and parse its movements (for rendering in the toolpath view) and work out the cycle time (per line), and then hand this back to the GUI, which would then give it to the toolpath renderer and to the gcode runner. Then when you click play in the GUI it would tell the gcode runner to start playing, which would result in commands going to the grbl connection to actually talk to the device.

But first I need to read the CSP book.