JS module based machine definitions

[docprofsky]

This is an issue to discuss using JS modules for handling machine definitions and adding more extensibility to CNC Server.

I see the scope of CNC Server as being

• Provide a REST API for easy control of a machine
• Manage queuing of commands sent to said machine

  JS modules to be added

• Controller module (what can the controller do)
  • Handles all of the communication with the bot controller
  • Defines the controller capabilities
  • Inputs and outputs
  • Motor drivers and type (DC, stepper)
• Machine module (what can the machine do)
  • Defines the machine capabilities
  • Anything constant across all of the machine variations
  • Axes information
  • Number of Axes
  • Absolute Maximum and minimum speed of axes
  • Additional information about Axes (continuous rotation for EggBot egg rotation axis)
  • Endstops
  • Encoders
  • Carriage information
  • Configuration for anything on the carriage
  • Pen motor on EggBot and WCB
    • Upper and lower bounds on travel
    • Any additional motor information
• Tool module (what tool is attached to the machine)
  • Available tools
  • Can modify the Machine and controller modules
  • Enable the engraver output to add the EggBot engraver
  • Disable the servo for the engraver
  • Define tool change procedures
  • This would be implemented as a function called to issue a tool change command
    • This will be implemented as a function to get and release the tool (pens), and/or a function to just change tools (paints).
  • This could also handle color changing and reinking or they could be separate tools for water as they are currently implemented.
  • This would change the API most significantly for a different tool, but would make it really easy to add support for something like the EggBot engraver or some other custom made tool.

[techninja]

Words. We're going to need some slightly different vocabulary to describe what all these parts mean and in what context.

Modules:

These are basically complete projects, packaged in a certain way following the CommonJS standard for node. The neat thing is that they're clean and can provide almost anything to their parents that require('them'). The Grunt task runner project has done a great job utilizing this to make their own "plugin" model.

Plugin:

A plugin in this instance is really just a node module, but with some extra requirements. Possibly some additional package.json fields, but most likely it's all about some expected structure or API around its instantiation and use. Cncserver might require a module plugin like this:

require('cncserver-watercolorbot')(cncserver); // Note we don't have to assign output to a variable

Basically passing in the "global" cncserver object over to an instantiation function (as is done all over the place, including with grunt), and then "the plugin API" will be operated entirely through that object.

Machine definitions could be passed in to cncserver.defineMachine([object]), and the object would easily be enough to define everything currently setup in the ini files. Callbacks for events and additional control surfaces for tool changes (to add wiggle, etc.) could easily be added as well and passed along.

Anyways... any additional functionality would likely have to be a module plugin of some kind, I suspect if we add enough API, the addition of plugins that technically can provide communication methods, API endpoints, machines, tools, and anything else imaginable, is certainly possible.

Of course all of this is a bit moot if we still have customers left in the lurch trying to get basic systems working, and all we seem to be doing is trying to over-engineer things. This is not my current priority, but it seems to be a great idea and may become a future priority. Without active contributors beyond myself (or funds to make up for my lost time), it would take years for something like this to really happen.