netrap object model

map.txt

Object Model for a netrap server, exposed via AJAX

server-server protocol may substitute a server object for TOP so tree-walk can be performed.

listPrintersWithCapabilities() is the major function to be implemented, this should also cause a broadcast amongst any server-server networks where all other functions are server-local

TOP
+-	Printers[]
|	+- Printer
|		+- capabilities
|		|	+- PLA/ABS
|		|	+- color
|		|	+- size
|		|	+- fine or fast
|		|	+- other arbitrary name/value pairs
|		+- listCapabilities() => string_pair capability_pair_list[]
|		+- getCapability(string capability_name) => string capability_value
|		+- setCapability(string capability_name, string new_value)
|		|
|		+- properties
|		|	+- temperature
|		|	|	+- nozzle
|		|	|	+- bed
|		|	+- position
|		|	|	+- X
|		|	|	+- Y
|		|	|	+- Z
|		|	|	+- E
|		|	+- fan speed
|		+- listProperties() => string property_name[]
|		+- getProperty(string property_name) => string property_value
|		+- setProperty(string property_name, string property_value)
|	
+- listPrinters() => string printer_names[]
|
+- getCurrentPrinter() => string printer_name
+- setCurrentPrinter(string printer_name)
|
+- listPrinterCapabilities() => string capability_names[]
+- listPrintersWithCapabilities(string_pair capability_pair_list[])

On Tue, May 29, 2012 at 12:51 PM, Duane Johnson < ***@***.*** > wrote: - Where do printer names come from? Are they GUIDs?

Initially I'll just use the usb serial number or guid or mac address or something, may allow user-specified names in the future. I don't want the name to be tightly bound to anything in particular, and I definitely don't want any of my code needing the names to be anything more specific than unique and persistent text strings- ie the same printer will have the same name every time it connects, and no two printers can have the same name.

- What is the scope of "current printer"? Does each "socket" that communicates with NetRap get a "current printer" context?

any socket that's using the gcode protocol must select a printer before it can do single printer operations HTTP requests must specify a printer in every per-printer operation request since we can't even guarantee that a persistent socket will have the same client talking to the same printer at the far end due to proxies and browser socket sharing and things like that this requirement may relax for netrap implementations that only have one printer, but that will be on the implementation side, the protocol spec will be strict.

- Capabilities as imagined may not have considered the following cases: - Multiple individual colors, and possibly "all colors" i.e. full-color 3D printers

if a print needs CMYKW then it must specify all 5 in the required capability list, then netrap must find a printer with all 5 - ie the capabilities are ANDed when searching for a suitable printer

- Querying for a printer that has "at least this volume" (i.e the most common case. Perhaps just create listPrintersWithVolume(w,h,d)?)

good point, we may have to support minimum/maximum as well as hard values

- Perhaps rename "size" capability to maxPrintVolume

- What does it mean to setCapability on a printer? What is the duration of this setting? i.e. does a printer "learn" about itself in this manner, or is its self-knowledge going to overwrite a capability once set, on reboot for example? I'd like the printers to store the capabilities locally, but for the moment I think netrap itself will maintain a database linked to the printer's name. The capabilities will ideally be as persistent as the printer name itself, but we do need to be able to change them at will- it's pretty common to unload one colour and load in another, possibly of a different type of plastic, or adjust the frame or replace parts in such a way that the total print volume changes... When we start doing server/server stuff or intelligent client/server (ie smoothie on an ethernet link acting as a printer client over network socket) then the "printer client" will be able to have a much greater hand in its own management and can store its capabilities locally. - Can we have a "percent complete" property for when gcode files are sent? when a file is being sent over a socket, the sender alone knows how much of it has been sent. When we're printing from a local file at the request of some client, we'd have to first scan the entire file or look for particular keys in the header or something to find how much -something- 100% corresponds to. Pronterface has a couple of different progress outputs, one is number of layers vs total layers and the other is number of gcode lines vs total lines. I think amount of extrusion vs total volume extruded would be most useful since we spend the majority of our time extruding. this metric would also be most useful for time estimation.

- How do we know if the printer is in an error state? e.g. if the bed is not level, or it's out of plastic, or some other error (overheat?)

ah yes, this is important! specifically that one of the "error" states I intend to implement is 'print complete, bed need clearing'. I want to add a button to the printers that clears this state and causes it to ask netrap for the next job from the spool that's suitable for that printer. This will be the killer feature for printer farms when coupled with some indicator lights :D We will of course have to have some method of reporting entry into/exit from various error states, I'll ponder on this, feel free to provide suggestions :)

- Capabilities as imagined may not have considered the following cases: > \* Multiple individual colors, and possibly "all colors" i.e. full-color 3D > printers > if a print needs CMYKW then it must specify all 5 in the required capability list, then netrap must find a printer with all 5 - ie the capabilities are ANDed when searching for a suitable printer

I think there's a difference between discrete capabilities and continuous capabilities. The "all colors" I was referring to is supposed to indicate that the printer is capable of printing colored voxels--continuous variations of any color at any location in space. On the other hand, we will have "dual extruders" in our near-term printers that will have two (discrete) colors to choose from. How do you tell the difference between a printer that can print continuous variations and blends of any color (CMYKW) and one that prints five discrete colors, Cyan, Magenta, Yellow, Black and White (CMYKW)?

On Tue, May 29, 2012 at 2:25 PM, Duane Johnson < ***@***.*** > wrote: I think there's a difference between discrete capabilities and continuous capabilities. The "all colors" I was referring to is supposed to indicate that the printer is capable of printing colored voxels--continuous variations of any color at any location in space. On the other hand, we will have "dual extruders" in our near-term printers that will have two (discrete) colors to choose from. How do you tell the difference between a printer that can print continuous variations and blends of any color (CMYKW) and one that prints five discrete colors, Cyan, Magenta, Yellow, Black and White (CMYKW)?

ah I get your point now, this would have to be a separate capability- colour mixing, or perhaps something even more specific Do you have any ideas for a system that's better than a list of arbitrary capabilities that we could sensibly implement on smoothie or maybe even integrate into sprinter or marlin?

What if we integrate sqlite into netrap? I.e. store the capabilities of any connected printer in a table. Then let sockets send SQL as queries? On Mon, May 28, 2012 at 11:33 PM, triffid < [email protected]

…

wrote: On Tue, May 29, 2012 at 2:25 PM, Duane Johnson < ***@***.*** > wrote: > > I think there's a difference between discrete capabilities and continuous > capabilities. The "all colors" I was referring to is supposed to indicate > that the printer is capable of printing colored voxels--continuous > variations of any color at any location in space. On the other hand, we > will have "dual extruders" in our near-term printers that will have two > (discrete) colors to choose from. How do you tell the difference between > a > printer that can print continuous variations and blends of any color > (CMYKW) and one that prints five discrete colors, Cyan, Magenta, Yellow, > Black and White (CMYKW)? ah I get your point now, this would have to be a separate capability- colour mixing, or perhaps something even more specific Do you have any ideas for a system that's better than a list of arbitrary capabilities that we could sensibly implement on smoothie or maybe even integrate into sprinter or marlin? --- Reply to this email directly or view it on GitHub: https://gist.github.com/2780735

On Wed, May 30, 2012 at 12:44 AM, Duane Johnson < ***@***.*** > wrote: What if we integrate sqlite into netrap? I.e. store the capabilities of any connected printer in a table. Then let sockets send SQL as queries?

remember that we want smoothie to act as a netrap server, don't want to make it too complex! smoothie already has code set up for it to access a flat file database (its config) and that's all we need at this level I think we can do SQL queries as a protocol upgrade which smoothie won't support, so let's get the low tech method working before replacing it with amazing high level stuff :)

Agreed On Tue, May 29, 2012 at 10:38 AM, triffid < [email protected]

…

wrote: On Wed, May 30, 2012 at 12:44 AM, Duane Johnson < ***@***.*** > wrote: > > What if we integrate sqlite into netrap? I.e. store the capabilities of > any > connected printer in a table. Then let sockets send SQL as queries? remember that we want smoothie to act as a netrap server, don't want to make it too complex! smoothie already has code set up for it to access a flat file database (its config) and that's all we need at this level I think we can do SQL queries as a protocol upgrade which smoothie won't support, so let's get the low tech method working before replacing it with amazing high level stuff :) --- Reply to this email directly or view it on GitHub: https://gist.github.com/2780735