aeva / switchprint Goto Github PK

This file https://github.com/Aeva/switchprint/blob/master/switchprint/daemon/monitors/udev.py provides such functionality for Linux.

What on Windows can be used to report when new usb devices are connected as well as provide basic information about said events - and extra credit it it already has a gobject wrapper (wishful thinking)?

This is an easy one:
Currently switchprint is only known to work with a prototype of the Lulzbot Taz running a somewhat recent build of Marlin.

However, that is because thats all I've tested against so far. I also have the direct ability to support an older non-stock Lulzbot running an older version of Marlin, and a janky clonedel running an older version of Sprinter. At my hackerspace is Lulzbot running (I think) repetier, and a makerbot replicator 1 that sometimes works.

I plan on supporting all of those machines, and anything else I can get my hands on.
-Aeva

There needs to be a signal which the printer may push its state to the host software. This should be used both for things like saying the printer is idle or printing, but also for error reporting. This should not be used for things like print progress or temperature reporting.

There needs to be a mechanism to spoof a printer. There should be a general infrastructure for this sort of thing, so its not strictly limited to just one driver, but the driver itself will be responsible for implementing its own fake backends.

What this entails:

• dbus api on the switchboard for creating fake connect and disconnect events for the printer.
• and thus, some generalized interface for faking such commands
• a mechanism in the driver that may be called by the daemon to create this fake device and its access mechanism
• metadata in the driver to report several different fake hardware / emulation profiles to choose from
• a dbus api on the switchboard for querying the possible fake printers to be invoked, so that an external program can provide a handy ui for creating test printers
• spawned subprocess should have an environment variable indicating that this is a virtual printer. this should be used minimally within the driver's actual functionality
• the virtual printer should provide a bus object, and a signal which it emits every time it receives a new command. This is intended so that an additional project may visualize the printer's state, such as print head position, as well as drawing the process of printing the object.

This will also likely result in spinning off another separate project (like printcontrol) which is responsible for hooking into the exposed dbus api for virtual printers.

Fix setup.py or whatever else needs changing so that "sudo python setup.py install" works correctly.

oopse, this was supposed to be a "milestone"

Switchprint should make use of https://pypi.python.org/pypi/python-daemon/

Also, in the event that switchprint is not running and other host software wishes to connect to it, it should be possible for that host software to spawn the daemon in userspace.

To be implemented in these two files: https://github.com/Aeva/switchprint/blob/master/switchprint/_workers/drivers/sprinter_reprap/monitor.py and https://github.com/Aeva/switchprint/blob/master/switchprint/_workers/drivers/sprinter_reprap/protocol.py

The SprinterMonitor class needs to periodically call the request_tool_temp(tool_num) method on the SprinterProtocol class. SprinterProtocol needs to be able to call some kind of event on an associated SprinterMonitor class when there is a reply from the printer, thus allowing it to push the temperature data + context up to the SprinterMonitor so that it may make note.

The SprinterMonitor should do this roughly once a second when the monitor state is either "active" or "hot", and never when the monitor is "idle". If the printer state is printing, this time should be five seconds instead of one. A new request should only be made either when the highest numbered tool is reported for, OR when the monitor state goes from idle to another state, OR when the monitor class is first initialized. Gobject timeouts should be used to keep things simple and avoid concurrent requests.

Lastly, when this infromation is reported and cleaned, it needs to be packaged up as a dictionary and pushed to the host via the on_report signal (see the docstring here https://github.com/Aeva/switchprint/blob/master/switchprint/_workers/server.py#L45 for expected structure), and printcontrol then may be updated to report tool temperatures.

Likely one for one of my lulzbot compatriots.
Dependant on issue #6, however.

Ideally, for Windows, we should provide a nice installer executable that takes care of installing the necessary dependencies for using switchprint and other software that interfaces with switchprint.

This includes dbus!

Notes.org both contains resources for dbus development in python, and other useful reading, as well as some lingering tasks, and a few huge braindumps on how to approach the architecture of switchprint.

The architectural braindumps are most certainly out of date, and need to be split into documentation of what has actually been implemented so far, and some kind of upcoming feature roadmap.

This traceback is occasionally produced when sprinter_driver attempts to write to it's serial port.

Traceback (most recent call last):
  File "/home/aeva/science/switchprint/switchprint/workers/drivers/sprinter_reprap/monitor.py", line 33, in __trigger
    self.__callback()
  File "/home/aeva/science/switchprint/switchprint/workers/drivers/sprinter_reprap/monitor.py", line 197, in monitor_event_loop
    self.proto.execute_requests()
  File "/home/aeva/science/switchprint/switchprint/workers/drivers/sprinter_reprap/protocol.py", line 194, in execute_requests
    state = packet.send()
  File "/home/aeva/science/switchprint/switchprint/workers/drivers/sprinter_reprap/protocol.py", line 50, in send
    self.__serial.write(line+"\n")
  File "/home/aeva/science/switchprint/switchprint/workers/drivers/sprinter_reprap/connection.py", line 87, in write
    return self.__s.write(data)
  File "/usr/lib/python2.7/dist-packages/serial/serialposix.py", line 489, in write
    raise SerialException('write failed: %s' % (v,))
serial.serialutil.SerialException: write failed: [Errno 5] Input/output error

This exception should be caught (and likely ignored), but also the driver's internal event loop should be totally halted when the subprocess containing it receives the disconnect event.

From a practical standpoint, the bug as it is doesn't really hurt anything since the event loop is killed and restarted when the device is reconnected.

This will probably be done on the SerialConnection class. When the device connects, the temperature should be queried (no need for tool change?). When the result returns, if the bed temperature is exactly zero, assume no bed is installed, and note this in the device's capabilities.

Traceback (most recent call last):
File "/home/aeva/science/switchprint/switchprint/workers/on_disconnect.py", line 39, in
on_disconnect(*sys.argv[1:])
File "/home/aeva/science/switchprint/switchprint/workers/on_disconnect.py", line 31, in on_disconnect
for name in list_printers(bus):
TypeError: list_printers() takes no arguments (1 given)

This is used for pausing / canceling print jobs, and also for clearing an error. For machines with no means of clearing their build platform automatically, the printer should raise an error when it finishes a job - upon clearing the error state, the printer will accept new jobs again.

Good luck.

Currently, the group id for dialout is hardcoded at "20", which makes sense for Debian, but not Fedora. Also, the fail message should be updated to mention that you need to log out and back in again for the command to add yourself to the proper group to take affect.

This file https://github.com/Aeva/switchprint/blob/master/switchprint/daemon/monitors/udev.py provides such functionality for Linux.

What on OSX can be used to report when new usb devices are connected as well as provide basic information about said events - and extra credit it it already has a gobject wrapper (wishful thinking).

This bug depends on issue #3.
Additionally, this is worthless unless switchprint can use the dbus system bus instead of the session bus.

Ok, changed my mind on how I wanted to implement this. Originally to be done with threads, turns out its much easier to just use all of the gobject event stuff thats already there!

This commit 2dcf46b accomplishes most of the initial functionality and scaffolding needed, but a few things are missing:

• There ought to be a buffer of checksumed commands to be sent (which should be the bulk of the 'active' state) http://reprap.org/wiki/G-code#Checking
• I don't know how to check for multiple extruders, and I don't have any machines configured for it to debug against
• There should be a signal that is hit every time the temperature readings are updated, to push the results to host software.

I've been testing this with Marlin. I have a nice old repstrap running sprinter that lacks a print bed. It'll be interesting to see if or how it barfs.

In particular, it needs to be verified if the resend notifications from the printer are the same in marlin.

The sprinter reprap uses the temperature reading for the bed to guess if there is an installed bed or not. If the temperature read is exactly zero degrees, it is assumed that there is no heated bed.

I'm marking this as wontfix, because there is no other way to infer that information from the driver, but I'm filing the bug because this should be documented somewhere. Someone might be confused if they're using their printer in a really cold space, but realistically, I doubt anyone is going to notice.

on_report is a signal that pushes updates about the state of the printer. The update is in the form of a dictionary, that will be encoded as a json string when sent over dbus. It will contain information including things like temperature readings for the different tools, as well as updates on the print progress.

This may be signaled by several components independently from one another, and the information does not need to be aggregate. For example, one such push might be information on tool 0, another might be tool 1, and another might send the progress on slicing a model, and another might indicate the amount of data that has been sent to the printer so far, and so on.

Thus when a host first opens, it should call this to determine things like how many tools are available, and if there is a hot plate or not.

Later on, when we have the ability to store persistent settings, some of that information might also be returned through this call.

This issue depends on Issue #29

When the pdq print mechanism is used on the current sprinter driver, there are noticeable pauses which disrupt the overall flow and extend the length of the print job unnecessary.

This is most likely due to the fact that each command is sent one at a time, and the server waits for the ok before sending the next command. The serial port being set to timeout at 0.25 seconds combined with .readlines() being used to check for new data is probably the main culprit.

The project readme needs to be updated to correct for two things:

1. The dependencies list is incomplete.
2. Remove "sudo python setup.py install" all together and replace it with "sudo python setup.py develop", and note that moving the project's directory will break the install.

There is a plethora of (necessary) boilerplate code. To provide a clean base for things to build on, python's abstract base class module (abc) should be utilized to provide base classes for different types of device classes, as well as for core printer functionality. Then once this is in place, all boilerplate code should implement the relevant interfaces, and a number of driver base classes should be created that implement these interfaces and which will provide the dbus functionality, thus replacing the worker server class. Additionally, virtual hardware should have a collection classes that can be instanced or subclassed to provide the dbus bus object.

I'm thinking the new library structure should look something like so:

api/
--switchboard.py
--generic_printer.py
--fff_printer.py
--sla_printer.py
--dlp_printer.py
--base/
----printer_base.py
----hw_base.py
----fff_base.py
----sla_base.py
----dlp_base.py

daemon/
...

workers/
...

drivers/
--driver_base.py
--fff_driver.py
--sla_driver.py
--dlp_driver.py
--virtual_base.py
--virtual_fff.py
--virtual_sla.py
--virtual_dlp.py
--sprinter_reprap/
----...

The current readme doesn't describe all of the dependencies actually needed to install and run switchprint.

Additionally, in its current state, "python setup.py install" should never be called. Rather, everyone should use the "develop" variant.

The get_max_temp_state method has a comment which explains what needs to be done:
'''python
# FIXME rather than an arbitrary definition of room
# temperature or whatever '30' is supposed to represent, None
# should be returned only after the change in temperature over
# the last three minutes was less than a degree or something
# like that AND its low enough that it won't likely start your
# house on fire or cause burns to anyone who touches the hot
# bits.
'''

I have a repstrap running sprinter, and lacks a heated bed. Printcontrol should only show a singular gauge, but this behavior is somewhat dependent on temperature reporting support. Dependent on issue #6 being completed.

On the wiki for this project, there needs to be docs explaining using nose to run tests, where to find documentation on nose, a handy cheat sheet of commands, where to put your tests in the project, and so on.

Also, research this coverage reports thing.

Arguments should be a file and a mime type.
If the mime type does not match the type expected by the printer (this should be defined in the driver's metadata), then an exception should be raised indicating that a slicing pipeline is not currently present.
If the mime type matches, then it should copy the file to a temporary location, and then invoke functionality upon the driver to stream the contents of that file to the printer.

Things like, "why do drivers run in subprocesses?", "how should the api ought to work?", and "why does printcontrol import switchprint - isn't switchprint a stand-alone program?"

In tandem with the related Printcontrol project, this milestone is accomplished when the driver api is fleshed out enough, and the demonstrational sprinter_driver implements all of the features needed to build a host program that is able to manually control the printer, report its state automatically, and provide a rudimentary print-from-file feature, and a visualization of print progress.

What is not necessary for this milestone:

• gcode visualization
• print bed visualization
• persistent printer configurations
• slicing integration
• unit testing

Replace the debug script in the sprinter_repraps with actual unit tests using nose.

Rather than using python-dbus, move to the dbus functionality provided in gi.repository. Given that this will likely need some research for how to do correctly, and my cursory search for documentation returned nothing, how this is done should probably also be documented in the wiki, and probably followed up with a blogpost somewhere.