-
Notifications
You must be signed in to change notification settings - Fork 295
Dual Endpoint USB Operation
NOTE: This page is currently a discussion about the specification for using two USB serial devices to drive G2 (a specifiction?). At some point it will be edited to become the specification.
This page describes using two USB serial devices with G2 - aka dual endpoint USB.
The basic idea of dual endpoint USB operation is to have 2 independent channels for communication to the board. The first channel is a control channel through which machine commands are sent. The control channel is always active to process commands in near-real time. The second is a data channel through which the Gcode file is queued.
This arrangement greatly simplifies flow control for the UI or host, as the control channel can be viewed as always being available to process incoming commands such as feedholds (stops), whereas the data channel can be heavily buffered, and therefore always have the next Gcode block at the ready.
The following use cases support most configurations.
Please note any other cases that are not covered.
-
UC_1: Two USB serial ports - The USB has two virtual serial ports configured, control and data. This case also encompasses multiple simultaneous control channels.
-
UC_2: One USB virtual serial port, one mass storage device - One virtual serial port is configured as the control channel. Data is made available from a mass storage device. Sub-cases include data channel being from (a) USB mass storage device, (b) SD card or similar off-board, serial accessed storage, (c) on-chip FLASH or EEPROM. Each case may assume read/write or read-only mass storage. This case also encompasses multiple simultaneous control channels.
-
UC_3: One USB serial port - Both control and data are "piggybacked" on the same USB port ("device"). This mode is used to support v8 and earlier boards and cases where 2 endpoints are not available for some reason. Since only one port is used this case assumes only one control channel.
A channel is a logical communications channel such as ctrl or data. Device is a port or other data source that gets mapped to a channel. Right now we are mostly concerned with USB virtual serial port devices but devices may include:
- USB virtual serial ports
- USB mass storage devices
- SD card and other mass storage devices
- SPI channels and SPI connected devices
- Other bulk storage or serial devices
The following are expected on the control and data channels.
- Control channel accepts all non-gcode commands and controls, including:
- Configuration commands (JSON and text mode)
- Single-character controls: !, %, ~
- multi-character controls such as feed rate overrides and other in-cycle commands
- Control channel returns all responses from both channels, including
- JSON response objects
- JSON status reports
- JSON exception reports
- text-mode responses of all kinds
- Gcode echo (if enabled)
- Gcode comment messages
- Multiple control channels may be active at a time. Command input will be processed on a line-by-line basis (no character interleaves), first-come-first-serve, and round-robin. Responses are "broadcast" to all active control channels. This supports multiple control devices such as a desktop and a mobile pendant, or an SPI or USB connected front panel controller.
- Data channel accepts all Gcode input:
- Raw Gcode blocks
- Blocks are read one line at a time
- Lines terminated with LF, CR or both
- All input is interpreted as Gcode (or whatever data protocol is in effect). All else is treated as an error.
- Note: JSON wrapped Gcode is not supported
- Data channel returns:
- No response is provided back on the data channel (no echo, acknowledgements, or errors)
- Only one data channel may be active at any given time.
G2 will implicitly bind channels using the available/connected state of the USB devices.
G2 automatically binds the USB devices to the control and data channels. USB-serial subsystem is able to detect when software on the host side 'connects' to each channel independently. (This is done by a flag in the USB system that is set the the host connects and 'asserts RTS')
-
Initially neither USB device is assigned as control or data, and there is nothing connected to communicate with them anyway.
-
The first usb-serial device connected will be both control and data as long as it's the only device connected. This is to maintain compatibility with UC_3 and not require any additional setup steps for legacy UIs and hosts.
-
If a second usb-serial channel is connected then the first channel becomes control-only and the second channel becomes data-only. This allows simple adoption of UC_1 mode by simply opening the two connections in a controlled order - the first connected will become command and the second connected will become data.
Note: Multiple control ports and the use of other devices such as SD card files is supported using manual binding - more later.
- If the ctrl+data channel disconnects you are simply disconnected. No surprises here.
- If the data channel is disconnected then the ctrl channel reverts to being ctrl+data
- If the ctrl channel disconnects then both teh data and ctrl channels are disconnected
#Notes on the Current Implementation This section describes the current implementation, that may have some differences from the above specifiction.
The current implementation is available as build 048.14 in the alden branch. There are some shortcuts taken, but it should behave more or less according the above description. In short, use it like this:
- System is idle. Nothing is connected.
- Connect to usbserial001. This will become a ctrl+data channel
- Connect to usbserial003. This will become the data channel and usbserial001 will become the control channel.
- Send control messages (JSON) to ctrl (001) and Gcode to data (003). The reader (controller.cpp) will prioritize controls over data and always read and process a control if one is available before attempting to read the next gcode block.
- If data (003) disconnects the ctrl (001) reverts to being a ctrl+data channel. 003 can be re-connected as a data channel. If ctrl (001) disconnects then both channels disconnect.
That's it.
A few observations/questions:
-
There is currently no distinction at the controller/dispatcher between text lines returned by the control channel and lines returned by data (gcode blocks). The controller will happily receive both and execute both. I don't think this is a problem, but people should be aware of this.
-
Any command received on either channel will send its responses to the control channel. Including received data, which will return a response at the current JSON verbosity level (an {R:{... response). This may or may not be a good idea. Depends on use. Also, be aware there is no output sent to the data channel at all. Feedback welcome.
-
One possible enhancement would be to send a connect message back up the channel that was was just connected or changed. So the first connect would send a message indicating ctrl+data, the second would send a message over both ports, one for data, the other for control. SImilar messages would be send for other state transitions. This is more complexity, but if it's useful we should discuss. Part of this might also be the ability to query a channel for it's capabilities and state.
These are notes for future enhancements that will support SD cards, manual binding, and other device-specific functions.
Channels are logical communications channels functions to which physical devices are attached (bound). These include:
-
ctrl0
,ctrl1
, etc. Control channels. See here for details -
data0
,data1
, etc. Data channels See here for details
Devices are described by a fully qualified path. Most physical devices describe a single piece of hardware functionality, but some may be subset using filenames, slave select numbers, or other qualifiers; others may be synthetic devices made of multiple physical devices and/or software devices. The following devices are known or supposed:
-
/dev/usb-serial0
(currently implemented, but not named as such) -
/dev/usb-serial1
(ditto) -
/dev/uart0
,/dev/uart1
, etc. -
/dev/spi0
,/dev/spi1
, etc. Describes entire SPI channel -
/dev/spi0.0
,/dev/spi0.1
, etc. Describes an endpoint (slave select) on an SPI channel -
/dev/sd0
describes an SD card itself -
/dev/sd0/file/filename
describes a file on an SD card -
/dev/flash/addr/0x00000000
depending on the chip this may make sense -
/dev/eeprom/addr/0x00000000
same -
/dev/ram/addr/0x00000000
same
-
R/W
devices are read/write -
R
devices are read-only (plus flow control) -
I
devices are a subset ofRW
devices that are interactive and capable of sending commands (JSON, etc), receiving status reports, and sending GCode -
IC
devices are a subset of interactive devices that cannot transmit GCode such as a front-panel device. - Examples:
- A USB serial device is default
I
. It may becomeRW
when bound to a data channel. Writing to a data channel has the effect of storing or piping the contents, depending on the device. (Is this true? - alden) - An SD card is either
R
orRW
, but neverI
. (Note: You still talk to an SD card to get data, even when the card isR
.)
- A USB serial device is default
- An SPI device may be
R
,RW
,I
, orIC
. There needs to be a mechanism to determine which.
- When an non-
I
device, such as an SD card, is the data channel it's expected to automatically keep the gcode buffer full until there is no more (EOF, etc). - When selecting a data channel the rest of the path beyond that necessary to designate the device itself, if any, will be used to determine a subset of the channel. Example:
- "/sd/file/path" will pass "/file/path" to the sd channel. It might not accept the Data channel designation (file not found, card missing, etc).
- "/spi0/cs1" will pass "/cs1" to the SPI device for determining which sub-channel ("chip select") to use.
- All usable channels must have a sense of "connected/available" ("available" from here on).
- USB-serial gets a signal when the host side has an active connection.
- An SD card socket has a Card-Detect (CD) pin to know when an SD card is present.
- An SPI socket has the !Interrupt pin to detect the presence of an device on a select line.
Note: Need a definition of the state model. To include connected/available, active, etc.
Note 2: Motate will hide the chip-select semantics, so consider their use here as merely example. In the end, it will just appears as a series of SPIn channels.
What about cases where there are multiple logical "control channels?" Example: SPI-connected "front panel" device while there's a USB serial connection and the data channel is an sd card. We would like the front panel to be able to "pause" and "resume" as well as get status reports while the USB serial is is still getting status reports and can control via some UI there as well.
- Possible solution: One channel is Data, and might also be a Control (UC_3 mode) but all other channels that are
I
are also Control. IOW, Control is a broadcast (status reports, etc) and accept-from-anywhere of commands, but will reject GCode from any channel not Data. - The first "available"
I
channel is the default Data. - It's possible that there is no current Data channel, such as when there's an
IC
front panel but no USB serial and no selected SD file to run from.
All filesystem commands will be in the {fs:{...}}
namespace.
- As for all commands in the G2 system, queries/commands and responses are loosely coupled.
- When a query is received, one or more responses are sent out.
- The response format will be dictated by the request. That format will either implicitly indicate that there will be no more responses (such as when only one was expected), or will explicitly indicate which response is the last.
- There might be other information - such as status reports - transmitted by G2 between the request and the response or between responses.
-
UC_SD1: Return card parameters
- Query the device, for device info:
// Query {fs:{info:"/dev/sd"}} // Possible responses: // Card present {fs:{info:{device:"/dev/sd", mount:"/sd", available:true}}} // Card missing/ejected {fs:{info:{device:"/dev/sd", available:false}}}
- Note 1: The string used in the info request must be the string used in the response, even if several possible paths would lead to the same physical device.
- Query the mount for card info:
// Query: {fs:{info:"/sd"}} // Possible responses: // Card present {fs:{info:{mount:"/sd", available:true, volume:"UNAMED_CARD", size:4194304, read:true, write:false}}} // Card missing/ejected {fs:{info:{mount:"/sd", available:false}}}
-
UC_SD2: Retrieve directory listing
// Query (list "/sd", only list the first five items) {fs:{ls:"/sd", first:null, count:5}} // Possible responses: // Files may or may not be sorted. // If unsorted, the order may change on any change to the filesystem. // Reply must use the same string as the request, even if several // paths may lead to the same directory. {fs:{ls:"/sd", item:"test.gc", file:true}} {fs:{ls:"/sd", item:"braid.gcode", file:true}} {fs:{ls:"/sd", item:"image.jpg", file:true}} {fs:{ls:"/sd", item:"test.gc", file:true}} {fs:{ls:"/sd", item:"old_stuff", directory:true}} // A null item indicates that there will be no more responses for // this listing request. 'more' being true means there are more // items to list. 'next' is the token you would provide as "first" // to get the next group of items. It should not be considered // an index into an array. {fs:{ls:"/sd", item:null, more:true, next:1155}} // Query (list "/sd", only list the next five items) {fs:{ls:"/sd", first:1155, count:5}} // The next five (or less) {fs:{ls:...}} responses {fs:{ls:"/sd", item:null, more:false}}
-
UC_SD3: Read a data file from SD card. A file on the SD card is used as a data source (data channel) to deliver a Gcode program. The following behaviors and limitations apply:
- When the SD file is selected the code will start executing automatically (Do we want this behavior or do we want an explicit cycle start?)
- Is there a reason not to? It could be simulated with an M0 as the first item in the file.
- When the program is complete the data channel reverts to the data channel that was in effect at the time the file was selected.
- A program completes when either an M2 or M30 is encountered (Gcode Program End), or an end-of-file is encountered.
- Embedded Stops (M0, M1) will cause the program to halt at that point. Program execution resumes with a Resume (cycle start) being received on any control channel.
- When the SD file is selected the code will start executing automatically (Do we want this behavior or do we want an explicit cycle start?)
-
UC_SD4: Write a data file to an SD card
-
UC_SD5: Stream a data file to an SD card
-
UC_SD6: Read a control file from an SD card
- What would a control file be?
-
UC_SD7: Write a control file to an SD card
- Nested devices:
- How would we describe an sd card that is on a fin at
spi0.1
? - How about an individual websocket on a WiFi fin?
- How would we describe an sd card that is on a fin at
- "Teletype" Channels:
tty0
,tty1
. Do we need these? - Good FAT16 reference http://elm-chan.org/fsw/ff/00index_e.html
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