Feature / New G-code commands M114, M115, M201.3 and M400 (master)

[markmaker]

NOTE: this supersedes PR #257 but is based on master, due to instability of edge-0.98.

Description

This Pull Request implements the common G-code commands M114, M115, M201.3 and M400.

• M115: Get Firmware Version and Capabilities
• M400: Wait for current moves to finish
• M114: Get current position
• M201.3: Set the given axis jerk rates, a 3rd order extension of the common M201, using sub-code .3 for third order.
• G4 P0 was explored as an alternative to M400 (as suggested here) but as G4 is also queued, it is not a solution in TinyG. Instead, a little bug was removed: TinyG should not hang when the P dwell time is zero or negative.

Justification

TinyG is quite common in OpenPnP usage, mostly because it is the stock controller for the Liteplacer and users often adopt OpenPnP.

M115 Get Firmware Version and Capabilities

OpenPnP is being extended to assist users with setting up the Gcode. The first step is automatically identifying the controller/firmware and for many controllers this is done with the M115 code. Discovery is a chicken-and-egg problem: No controller specific commands can be used, before the controller model is known. TinyG having alternative means of identifying itself does not help in this case.

Example:

M115

FIRMWARE_NAME:TinyG, FIRMWARE_URL:https%3A//github.com/synthetos/TinyG, FIRMWARE_VERSION:0.97, FIRMWARE_BUILD:440.21, HARDWARE_PLATFORM:1.00, HARDWARE_VERSION:8.00

M400 Wait for current moves to finish

OpenPnP often needs to interact with the machine. One example: The camera is moved to a location, then Computer Vision is used. Obviously, OpenPnP need to know when the camera is there, before it can take a picture.

In TinyG, there is currently no (known) means to block until moves have finished. OpenPnP is instead polling for status reports, in order to know when a move is done. This only works when status reports are enabled, which generates unsolicited reports in the response stream, which in turn makes it hard to clearly associate responses with commands (race conditions cannot be strictly excluded).

M400 now blocks all further command processing, until the move buffers have drained. This is done with the existing flow-control mechanism: Instead of waiting for the command buffers to not be full, it is waiting for them to be empty.

Example:

G1 X100
M400   ; wait for the move to complete
{sr:n}    ; only then execute the status report

It is important to note that the command only affects processing when it is used.

M114 Get current position

To further unify the Gcode setup, the M114 code is also implemented. It reports the current target position in the common format.

Example:

M114

X:100.0000 Y:0.0000 Z:0.0000 A:0.0000 B:0.0000 C:0.0000

M201.3 Set jerk

Sets the jerk of one or more axes transiently. This is needed for OpenPnP Speed control. Axis jerk rates are given in units per second³ analogous to existing M201 implementations. The jerk rates are internally converted to TinyG's km per minute³ rate. Using $xjm, $yjm etc. on the fly would probably burn out (?) the EEPROM soon and it creates known glitches.

Example:

M201.3 X90000 Z10000

Watch the video:
https://youtu.be/6SBDApObbz0

Testing

The changes have been tested on a TinyG v8.

One testing script is this:

$sv=0
M114   ; report position
G1 X0 F10000 ; go to the start, set feed-rate
M115 ; show the firmware
G4 P0 ; test dwell 0 (hanged before)
G4 P1 ; dwell a second
G1 X10 ; move in pieces, the planner should do them as one.
G1 X20 
G1 X30 
G1 X40 
G1 X50 
M400   ; wait for completion
M114   ; report position
G1 X75  
M114   ; report position
G92 X-25 ; set position
M114   ; report position, must react to G92
G1 X0
M400
M114

See also

• Firmware+avrdude+batch to flash on Windows (you must rename the COM port in the .cmd file).
• Discussion in the OpenPnP user group.