Hey Folks - let’s revive this beast!
Made some headway reading machine state by listening on the websocket endpoint.
ws://xxx.xxx.xxx.xxx/websocket
That returns a JSON string per state update. The first reply contains all state variables; subsequent replies contain only updated variables. Here’s an example of the output: websocket-trimmed.json This file contains output from homing, jogging, running gcode, pausing, unpausing, and emergency stopping. Have a peek!
I’m using Node-RED to string this all together. Here’s a basic flow to get you started:
It starts a websocket listener, parses the returned JSON string into a JavaScript object, and passes the object to this function:
var machineState = flow.get("machineState");
if ('xx' in msg.payload) {
machineState = msg.payload.xx;
flow.set("machineState", machineState);
msg.payload = machineState;
return msg;
};
Which places the value of “xx” from the JSON packet into a persistent variable, and passes just it on to the next node.
This will drive dust collection and router power, and already controls my timelapse capture rig. Getting data out of the Onefinity controller is now the least complicated part of my automation setup.
As for the other direction - I’ve sent HTTP PUT requests to pause/unpause/estop, and they worked just as expected. But alas, read on for a mystery.
api/override/speed
api/override/feed
These seem like juicy endpoints - adjusting speeds/feeds on the fly could be pretty flippin’ sweet.
When I send a PUT request to IP/override/speed/* or IP/override/feed/* while running a file:
Always:
- the API sends back a string containing “ok” (like a generic http 200 response)
- the output of IP/api/log shows that the value of “so” or “fo” has changed
- no state change is reported by the websocket listener (though “so” and “fo” are sent in the first response, so I think they’re hard-set at 1000 - er - 1 - right now).
Either:
- nothing happens physically, i.e. no movement speed change (we have a Makita, so not concerned about spindle speed)
- or, the UI throws an error message and stops the job. Seems to happen with values larger than four digits, but I haven’t tested that rigorously enough to define a range.
I have a couple of suspicions.
-
I suspect the “ok” response may be a default baked into the Tornado package Buildbotics chose to handle API requests.
-
Since there’s no updated value reported to the websocket (from bbctl firmware on AVR), but the updated value does appear in the log (from the Python/rpi side of bbctl), I suspect that the “so” and “fo” set commands aren’t yet implemented in firmware, so they get chucked by the command processor.
Diving into the command processor headers in the AVR code, there’s no command for speed or feed override. It’s a red-herring in the UI. For now. We can cross our fingers that BB is working to implement it, or one of us can buck up and do it ourselves. Yay FOSS!
Thank you to anyone who takes the time to read this. Please let me know if I can be helpful in your quest to automate around your Onefinity or Buildbotics controller!