According to the RepRap protocol we should actually not ever get anything other than those anyways, as the protocol is defined as ASCII-only. In the future there might be a way to somehow handle such files too, for the time being this fixes issues though where non-ascii files on the SD made the whole SD file handling not work.
Closes#381
Evaluate active flag on gcode analyzer AFTER fetching an item from the work queue, otherwise it will always start working once it finds something if the active flag was true once but then switched to false while the queue was still empty.
Thanks to @Salandora for spotting this.
Fixes#357
- also recognize such temperature reports that do not contain a "T:" but a "T0:" (should help with parts of #345)
- properly parse temperature commands to track target temp during slow heatup
- for the former point, also keep track of the currently selected tool
- simulate heatup and replies without "T:" in virtual printer (to test all this)
- also auto-caps T commands in terminal
- confirmation dialog when trying to visualize large files (different threshold for mobile and "regular" devices, configurable of course, although only via config file right now) - should also help a bit with issues leading to #215
- proper clearing of the viewer area when reconnecting to the backend (e.g. after server restart)
Also all of this plus previous commits closes#35
- GCODE viewer now supports multiple extruders and configurable bed sizes
- GCODE viewer also now based on callbacks and config injection instead of dependence on elements in the embedding website
- Switched GCODE viewer to bootstrap-slider for the layer/command sliders, patched bootstrap-slider a bit up (TODO: PR to upstream)
- GCODE interpreter in backend also calculates filament usage for all extruders
- More consequent use of LESS, switched bootstrap to LESS source to have access to variables and mixins, introduced config setting to switch between usage of compiled CSS (checked in as well) or LESS, defaults to CSS
I'm still not happy with that circular import stuff I'm currently doing... there must be a better way to better split stuff built with flask? To investigate...
Changed some endpoints again (removed "/control" path element) and made API spit out only raw data (e.g. seconds, millimeters, unix timestamps etc) instead of formatted versions. Modified frontend to take care of formatting this data itself.
This WILL break existing API clients and probably some event handlers too. I'm sorry for the disruptive changes, but I needed to rectify some decisions before they went too far utilized elsewhere to still be corrected.
Basically this change completely removes the old API and switches it (same endpoint) with the new one, that's basically the existing AJAX API that the client uses, but way more RESTful and based on JSON (exception being the file upload).
The event system has been revamped to carry more payload data (and in an extensible form as dictionary, to allow for later addition of attributes to single events), with the existing event listeners adjusted to also allow users to make use of this data in their consumers.
Documentation has been greatly enhanced for the REST API (and is still being added to), the events will be documented here as well.
Payload data can now be properly injected into event handlers such as command triggers. Added a couple of new events to use for update triggers to the frontend instead of custom code, further decoupling the application. Movie rendering now also causes a frontend notification.
directory to everybody.
This was probably considered appropriate for the case of octoprint
running on a single-user device, but given that Unix has groups
support, it is not necessary, and can be very harmful.
