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.
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.
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.
$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).
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 CapabilitiesM400: Wait for current moves to finishM114: Get current positionM201.3: Set the given axis jerk rates, a 3rd order extension of the commonM201, using sub-code.3for third order.G4 P0was explored as an alternative toM400(as suggested here) but asG4is also queued, it is not a solution in TinyG. Instead, a little bug was removed: TinyG should not hang when thePdwell 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:
M115FIRMWARE_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.00M400 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:
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:
M114X:100.0000 Y:0.0000 Z:0.0000 A:0.0000 B:0.0000 C:0.0000M201.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
M201implementations. 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 Z10000Watch the video: https://youtu.be/6SBDApObbz0
Testing
The changes have been tested on a TinyG v8.
One testing script is this:
See also