pixelpusher / liveprinter Goto Github PK

It’s hard to understand the printer angle/heading - need graphical display if some sort. Identified in Jan 9 user tests

If not, filament length gets out of syn and can waste lots.
Maybe do an auto-sync? In trials, start() was necessary afterwards. Sometimes retraction gets out of sync to, this needs to be cleared in hardware and software along with queues

It seems that Edge doesn't support the strings.raw being used in lp.run?

Right now the colours have poor contrast and the whole colour scheme needs sanitising. This was identified in one of the January 9 user tests.

use localstorage and/or shareDB!

the updateGUI() function in js/liveprinter.ui.js doesn't always update because it depends on a gcode response callback. Functions like # turn 90 don't generate gcode, hence don't update the GUI display up top. This needs to be done more sensibly.

like in the ajax example: https://github.com/jquery/jquery/blob/master/src/ajax/script.js

It seems that the acornjs version used here doesn't throw complete line/col numbers for syntax highlighting. Probably need to regex the error message manually to highlight wrong code in CodeMirror

Marlin does this...

GCode editor doesn't capture GCode now that the editor is split out.

use ES6 template literals to parse midi and gcode blocks:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals

midi`54 45 65`

Use CodeMirror’s findMatchingBrackets (internal) to automatically highlight all code within brackets and send to globalEval function: https://codemirror.net/addon/edit/matchbrackets.js

See "test" branch for details of development.

Things like move, extrude, etc... map to JS as external functions in the interpreter

Experiment with 3D drawing by getting rid of drawup/drawdown functions and instead using "classic" draw() with 3 optional arguments (each 0 by default) for x,y,z. OR, drawx(x), drawy(y), draw(z) for explicit dimensions setting.

Use a better realtime linter/etc. like what jsbin uses. JS-Interpreter doesn't support ECMA Script 5 or 6

make a proper startup script and add package info, according to pythonic package standards

Sometimes you want to pause the machine and tweak settings like temp, etc. Need to be able to pause and run other commands whilst "paused".

see thread here: https://groups.google.com/forum/#!topic/brython/bdUu5jjwQ3I

var src = "import datetime\n" +
"for i in range(5):\n print(i)\n" +
"print(datetime.datetime.now())"
var js = BRYTHON.python_to_js(src)
js += "console.log('ok')"
eval(js)

brython-dev/brython#937

All print API code should be on the server (move, extrude, stop, etc) and exposed via RPC. The raw GCode sending function can stay for advanced users but it makes sense that the printer driver itself should make decisions about queuing commands, interpreting printer physical extents, and handling errors and actual movements. The web GUI can query printer position and movement status and the size/content of the raw GCode and higher level API command queue.

In the printer serial read thread, create a mapping of printer responses (from commands) to handler functions that can be loaded up when the “driver” is changed (in effect, write a driver for each printer or device firmware instead of hard-coding Marlin). Also create a mapping of printer API functions (move, extrude, etc) to firmware specific GCode.

Should this be in the global namespace? Probably not. See Interpreter.js in the lib folder

Need to fill it out more, using ESDoc currently
https://esdoc.org/manual/tags.html

Right now threading is a mess because code came from two different threading systems and I had to learn tornado's method first. Future code should all be futures/promise-based and use async functions and tornado io loops to handle all threads instead of the hacky sleep/mash-up of python threading library and tornado's that is causing events to get lost. But this is a big change because it could mean getting rid of the printer request/commands queue and replacing it with a proper statefull database of some sort (but lightweight) and then having proper command/responses that can be chained with futures/promises/callbacks so a json-rpc request from the GUI can guarantee a response from the server (although doing that over networks and with multiple people and possible machines is tricky).

It's clunky now updating the GUI separately after each code compilation. It would be nice to have gui fields (like angle, retraction, maybe even position elements like x & y) bound to livePrinter object fields so they update along with the actual data model object.

Like: https://github.com/nijikokun/minami

in USBPrinter.py

it gets out of sync quickly if you restart the server or the browser.

looks like a GUI issue? Have to hard code the baud rate for Marlin printers < 250000

currently very broken...

Use https://github.com/svg/svgo service to better get drawable paths (sorted!) from SVGs.

makes no sense to have it grow forever

Right now, they have to explicitly bind to global lp cope object. But that might be a PITA, especially if they don't want to always re-run their code each time.

it's tiny...

Broken in LivePrinterServer.py - Need to fix it so it sends a proper json-rpc response

a pre-parser for numbers so people can type 3mm or 3in or % and it translates to actual mm units for final function usage

For some reason, they are updating only intermittently and save is also broken -- it saves an older version. Probably to do with the session storage? Seen on FireFox 90.0 on Ubuntu.

Getting this on Firefox, Linux Mint:

[Show/hide message details.] ReferenceError: assignment to undeclared variable event[Learn More] liveprinter.js:68:33
scheduler
http://localhost:8888/static/liveprinter.js:68:33

Fine on Chrome/macOS. Probably a Firefox thing, will investigate.

like with https://github.com/inconvergent/svgsort or https://github.com/RolandJuno/xy/blob/master/xy/planner.py

the periodic callback and ioloop in PrinterServer.py is not working... it's blocking and preventing the WebSockets client from connecting. Likely I've not implemented it correctly, it's more complex than I'd hoped. Perhaps it needs to be a simpler threading model.