-
Notifications
You must be signed in to change notification settings - Fork 295
GPIO Design Goals
Alden Hart edited this page May 8, 2018
·
2 revisions
This page discusses upcoming functionality being added to the GPIO system.
- GPIO Overview
- GPIO Design Goals
- GPIO Primitives
- GPIO Objects and Bindings
- GPIO Implementation
See also:
In short, we want the GPIO system to be general enough to connect any pin to any machine function as a configuration option. Practically speaking, some pins like motor drive signals will be hard wired, but everything else should be configurable.
We also want different physical machine and board configurations to be more portable and consistent across different UIs, and be able to be driven from the same Gcode and JSON regardless of differences in the underlying hardware or configuration.
- For example, we could have several machines where
in0
is always valid and serves the same function (like a shutdown signal), but on one machine it's attached todi0
but on another it's attached todi5
. - Better yet, create a
shutdown
object and listen to whatever pin or pins invoke that object, regardless of the machine configuration. Another example would be where "heater PWM" for Tool 1 (extruder 1) is usingdo0
whereas Tool 2 usesdo7
. We want to hide these details from the UI. - We also want to be able to create and control arbitrary "tools" like extruders or vacuum nozzles and still be as true to classic Gcode as possible. The GPIO system should provide the ability to drive arbitrary devices using standard Gcode commands.
- Provide a flexible way to expose, configure and control low-level digital and analog IO
- Provide logical-to-physical mapping of IO ports to the objects that use them
- Provide a way to assign (bind) arbitrary functions to arbitrary IOs
- Support concept of "signals" and virtual IO devices
- Allow g2 objects to generate and consume digital and analog values that can be wired to physical pins and IO devices
- Support concept of "events"
- ...which are changes of state of signals
- Make assignment and bindings of pins and signals configurable at runtime (as much as practical). I.e. minimize the number of hard-wired or compile-time choices in favor of making these choices configurable through the interface
- Support the concept of generalized Tools and Toolheads with assignable functions
- Provide a framework for tools and other devices made of composable objects
- Object: We use 'object' loosely. An object is any g2 code that performs some function, like raise an alarm if a limit is hit, or detect if a safety door is open. An object may be complex and expose multiple member functions, like a heater object that may expose functions to detect that a heater has reached a stable set temperature, and the state of a PID loop.
- Host: A host is some processor above the motion controller, such as a single board Linux machine or a desktop computer.
-
Read Physical Input Pins
- Host can read IO pins directly
- Ex: Read an on/off signal from an external device connected to a pin
- Host can display and/or take action on these state changes
- Host can read IO pins directly
-
Write Physical Output Pins
- Host can set IO pins directly.
- Ex: Turn on/off a pin to actuate an annunciator connected to a pin
- Host can monitor these output states to display and/or take action on state changes
- Host can set IO pins directly.
-
Read Objects
- Host can monitor internal g2 objects (i.e. can read output signals from code)
- Ex: Monitor limit and alarm conditions
- Ex: Detect spindle at-speed or temperature at set-point
- Host can display and/or take action on object state changes
- Host can monitor internal g2 objects (i.e. can read output signals from code)
-
Write Objects
- Host can control internal g2 objects (i.e. can send signals to code)
- Ex: Turn on/off coolant - where the object is the coolant control
- Ex: Turn on/off, control direction and speed of spindle
- Ex: Control heaters, fans and other devices
- Host can read back the signal(s) it has sent to an object
- Host can control internal g2 objects (i.e. can send signals to code)
-
Wire Inputs and Outputs to Internal Objects
- An object can use a physical or logical IO as an input
- Ex: Use input pin to trigger limit or alarm - e.g. pin3 is Y-min limit switch
- Ex: Use signal output by another object as an input - e.g. detect heater at set temperature
- An object can produce an output that is "wired" to a pin.
- Ex: A watchdog timer is wired to a SAFE pin that asserts if the timer ever expires
- An object can use a physical or logical IO as an input
-
Multiple IOs to an Object
- Multiple primitives can feed an object
- Ex: A variety of input switches will trigger an alarm or a limit object
- Multiple primitives can feed an object
-
Multiple Objects using an IO
- Multiple objects can read or set a single IO
- One object changes the input, and multiple objects can read and act on this change
- One output "signal" can be applied to multiple pins
- Logically this looks like a very simple publish and subscribe system
- Internally these are chained in a list - so a priority is inherent
- Multiple objects can read or set a single IO
-
IO Addressable through Tools and Toolheads
- Support a machine with a mix of tool types, any or all of:
- Spindle that can accommodate multiple end mills and probes
- Extruder that can have more than 1 color
- Changeable extruders (like an ATC for extruders)
- Support a machine with a mix of tool types, any or all of:
- Classic milling machine with a spindle and manual tool changes
- Classic milling machine with a spindle and automatic tool changer (ATC)
- Classic filament 3d printer with a single extruder
- Filament 3d printer with dual extruders on the same gantry
- 3D filament printer with a manual procedure for changing filament mid-job
- 3D filament printer with multiple, changeable extruders
- Laser cutter with air cooling
- Pick and Place machine with a fixed vacuum pick nozzle
- Pick and Place machine with changeable vacuum pick nozzles
Getting Started Pages
- Home
- What is g2core?
- Who uses g2core?
- Jerk-Controlled Motion
- Getting Started with g2core
- Connecting to g2core
- Configuring g2core
- Flashing g2core
- Troubleshooting
Reference Pages
- Gcodes
- Mcodes
- Text Mode
- JSON Communications
- GPIO Digital IO
- Alarms & Exceptions
- Power Management
- Coordinate Systems
- Status Reports
- Status Codes
- G2 Communications
- Tool Offsets and Selection
- Probing
- Feedhold, Resume, Job Kill
- Marlin Compatibility
- 9 Axis UVW Operation
- gQuintic Specs
Discussion Topics
- Roadmap
- GPIO for 1.X Releases
- Toolheads
- Raster Streaming Prototol
- g2core REST Interface
- Gcode Parsing
- G2 3DP Dialect
- Consensus Gcode
- Digital DRO
- Overview of Motion Processing
Developer Pages
- Development & Contribution
- Branching and Release - DRAFT
- Getting Started with g2core Development
- Project Structure & Motate
- Compiling G2
- OSX w/Xcode
- OSX/Linux Command Line
- Windows10 w/AtmelStudio7
- Debugging G2 on OSX
- Board and Machine Profiles
- Arduino Due Pinout
- Arduino DUE External Interfaces
- Diagnostics
- Debugging w/Motate Pins
- Development Troubleshooting
- g2core Communications
- Git Procedures
- Windows 10 / VMware 8 Issues
- Dual Endpoint USB Internals
- G2core License
- VSCode Setup
- Compatibility Axioms
- Wiki History