Kinen Device Model

This page describes a model for organizing complex devices. Many devices don't need to level of specification but some do - so it's offered as a starting point. The Kinen specification and use is not bound to this model.

##Kinen Device Model Kinen devices are modules that provide some high-level functionality such as stepper controllers, extruder controllers, LED controllers, etc. Kinen doesn't care where the device actually lives - it could be on the motherboard, on a Kinen fin connected via a Kinen socket, or off-board attached to some communications channel like Ethernet or RS-485.

Here's some vocabulary that describes the device model.

• Motherboard - anything with one or more Kinen female sockets on it and/or one or more Kinen devices. A motherboard usually has a processor of some sort on on it, but "dumb" motherboards are also possible that are driven by some upstream device such as a parallel port provided by LinuxCNC or a Raspberry Pi.

• Fin - a daughterboard adhering to Kinen socket conventions, and to communication conventions as applicable. A fin may have one or more devices on the board. Typically there is only one communications channel on the board which is shared by all the devices on the fin.

• Fin Types

  • Dumb - uses the dumb header and does not have processor on it (may also physically overlap the smart header in some cases)
  • Smart - uses the smart header and has a processor
  • Dual - uses both headers and has a processor

• Device Hierarchy

  • Device - a top-level useful object such as a heater controller
    • Programs (users) talk to devices (i.e. devices are exposed as APIs)
    • Devices are made of functions
    • Devices can be "operated"
    • Devices can be configured
  • Function - a logical sub-system such as a temperature sensor
    • Programs do not generaly talk directly to functions (i.e. functions are not exposed except for configuration)
    • Functions are made of resources and/or other functions; i.e. can encapsulate other functions
    • Functions can be configured via a configuration interface
  • Resource - a low-level system resource such as a timer (on chip) or a digital sensor (off chip) (Note that this naming collides with the REST use of the term "Resource". So be it.)
    • Functions encapsulate resources, usually with static bindings
    • Resources are always leaf nodes
    • Resources may be hardware, software or a mix
    • Resources may be on-board, off-board, on-chip or off-chip
    • Resources may have underlying comm protocols of their own (e.g. I2C to digipots, SD cards, RTC...)
    • Programs do not talk to resources (i.e. resources are not exposed except for configuration)
    • Resources can be configured via a configuration interface

  For example - Here's a hierarchy for a multi-channel temperature controller fin. It has multiple Kinen devices on the fin. Devices have one or more function, and functions use one or more resources.

  • Temperature Controller Fin

    • Heater 1 (extruder thermocouple controller w/on-board DC power)

      • thermocouple sensor function
        • thermocouple amplifier resource (say it's digital and requires setup and SPI communication)
        • ADC resource (on chip analog to digital converter)
      • PID function
        • PWM resource (example of a resource that is configurable)
        • Power resource (the FET and the phase outputs) (example that is not configurable)

    • Heater 2 (extruder thermocouple controller w/off-board DC power)

      • thermocouple sensor function
        • thermocouple amplifier resource (also digital)
        • ADC resource (on chip)
      • PID function
        • PWM resource (talks to off-board power unit)

    • Heater 3 (heated bed thermistor controller w/off board AC power)

      • thermistor sensor function (including linearization code)
        • ADC resource (on chip)
      • Bang-bang temp controller function
        • Digital IO resource (talks to off-board SS relay as power unit)