synthetos / g2

g2core - The Next Generation

What it is

g2core is a 9 axes (XYZABC+UVW) motion control system designed for high-performance on small to mid-sized machines.

• CNC
• 3D printing
• Laser cutting
• Robotics

Our default target is the Arduino Due, though it can also be used with other boards.

Some features:

• 9 axis motion (XYZABC+UVW).
  • Note - UVW is only in the edge branch for now.
• Jerk controlled motion for acceleration planning (3rd order motion planning)
• Status displays ('?' character)
• XON/XOFF and RTS/CTS protocol over USB serial
• RESTful interface using JSON

Mailing List

For both user and developer discussions of g2core, we recently created a mailing list:

• https://lists.links.org/mailman/listinfo/g2core

Please feel welcome to join in. 😄

g2core - Edge Branch

G2 Edge is the branch for beta testing new features under development. New features are developed in feature branches and merged into the edge branch. Periodically edge is promoted to (stable) master.

Edge is for the adventurous. It is not guaranteed to be stable, but we do our best to achieve this. For production uses we recommend using the Master branch.

Firmware Build 101 {fb:101.xx}

Feature Enhancements

New features added. See linked issues and pull requests for details

• Added UVW axes for 9 axis control. See also: Issue 304
• Added Enhanced Feedhold Functions
• Added explicit Job Kill ^d - has the effect of an M30 (program end)
• Documented Communications Startup Tests

Internal Changes and Bug Fixes

Many things have changed in the internals for this very large pull request. The following list highlights some of these changes but is not meant to be comprehensive.

• Added explicit typing and type testing to JSON variables.
• As part of the above, 32bit integers are not float casts, and therefore retain full accuracy. Line numbers may now reliably go to 2,000,000,000
• Movement towards getters and setters as initial stage of refactoring the Big Table :)
• Bugfix: Fixed root finding problem in feedhold exit velocity calculation
• Bugfix: fixed bug in B and C axis assignment in coordinate rotation code
• PR #334 A, B, C axes radius defaults to use motors 4, 5, & 6
• PR #336, Issue #336 partial solution to coolant initialization
• PR #299, Issue #298 fix for reading nested JSON value errors

Feature Enhancements

Firmware Build 101 {fb:101.xx}

The fb:101 release is a mostly internal change from the fb:100 branches. Here are the highlights, more detailed on each item are further below:

• Updated motion execution at the segment (smallest) level to be linear velocity instead of constant velocity, resulting in notably smoother motion and more faithful execution of the jerk limitations. (Incidentally, the sound of the motors is also slightly quieter and more "natural.")
• Updated JT (Junction integration Time, a.k.a. "cornering") handling to be more optimized, and to treat the last move as a corner to a move with no active axes. This allows a non-zero stopping velocity based on the allowed jerk and active JT value.
• Probing enhancements.
• Added support for gQuintic (rev B) and fixed issues with gQuadratic board support. (This mostly happened in Motate.)
• Temperature control enhancements
  • Temperature inputs are configured differently at compile time. (Ongoing.)
  • PID control has been adjusted to PID+FF (Proportional, Integral, and Derivative, with Feed Forward). In this case, the feed forward is a multiplier of the difference between the current temperature and the ambient temperature. Since there is no temperature sensor for ambient temperature at the moment, it uses an idealized room temperature of 21ºC.
• More complete support for TMC2130 by adding more JSON controls for live feedback and configuration.
• Initial support for Core XY kinematics.
• Boards are in more control of the planner settings.
• Experimental setting to have traverse (G0) use the 'high jerk' axis settings.
• Outputs are now configured at board initialization (and later) to honor the settings more faithfully. This includes setting the pin high or low as soon as possible.

Firmware Build 100 {fb:100.xx}

The fb:100 release is a major change from the fb:089 and earlier branches. It represents about a year of development and has many major feature enhancements summarized below. These are described in more detail in the rest of this readme and the linked wiki pages.

• New Gcode and CNC features
• 3d printing support, including Marlin Compatibility
• GPIO system enhancements
• Planner enhancements and other operating improvements for high-speed operation
• Initial support for new processors, including the ARM M7

Project Changes

The project is now called g2core (even if the repo remains g2). As of this release the g2core code base is split from the TinyG code base. TinyG will continue to be supported for the Xmega 8-bit platform, and new features will be added, specifically as related to continued support for CNC milling applications. The g2core project will focus on various ARM platforms, as it currently does, and add functions that are not possible in the 8-bit platform.

In this release the Motate hardware abstraction layer has been split into a separate project and is included in g2core as a git submodule. This release also provides better support for cross platform / cross target compilation. A summary of project changes is provided below, with details in this readme and linked wiki pages.

• Motate submodule
• Cross platform / cross target support
• Multiple processor support - ARM M3, M4, M7 cores
• Device tree / multiple motor types
• Simplified host-to-board communication protocol (line mode)
• NodeJS host module for host-to-board communications

More To Come

The fb:100 release is the base for number of other enhancements in the works and planned, including:

• Further enhancements to GPIO system
• Additional JSON processing and UI support
• Enhancements to 3d printer support, including a simplified g2 printer dialect

Changelog for Edge Branch

Edge branch, Build 101.xx

This build is primarily focused on support for the new boards based on the Atmel SamS70 family, as well as refining the motion control and long awaited feature enhancements. This list will be added to as development proceed.s

Edge branch, Build 100.xx

Build 100.xx has a number of changes, mostly related to extending Gcode support and supporting 3D printing using g2core. These include temperature controls, auto-bed leveling, planner performance improvements and active JSON comments in Gcode.

Communications has advanced to support a linemode protocol to greatly simplify host communications and flow control for very rapid Gcode streams. Please read the Communications pages for details. Also see the NodeJS communications module docs if you are building a UI or host controller.

Build 100.xx also significantly advances the project structure to support multiple processor architectures, hardware configurations and machine configurations in the same code base. Motate has been cleaved off into its own subproject. We recommend carefully reading the Dev pages if you are coding or compiling.

Functional Changes:

Note: Click the header next to the arrow to expand and display the details.

Linear-Velocity Segment Execution

• The overall motion is still jerk-controlled and the computation of motion remains largely the same (although slightly simplified). At the smallest level above raw steps (what we call "segments," which are nominally 0.25ms to 1ms in duration) we previously executed the steps at a constant velocity. We now execute them with a linear change from a start velocity to an end velocity. This results in smoother motion that is more faithful to the planned jerk constraints.
• This changed the way the forward differences are used to compute the segment speeds as well. Previously, we were computing the curve at the midpoint (time-wise) of each segment in order to get the median velocity. Now that we want the start and end velocity of each segment we only compute the end (time-wise) of each segment, and use that again later as the start-point of the next segment.

Probing enhancements

• Added {"prbs":true} to store the current position as if it were to position of a succesful probe.
• Added {"prbr":true} to enable and {"prbr":false} to enable and disable (respectively) the JSON {prb:{...}} report after a probe.

gQuintic support

• Support for the gQuintic rev B was added. Support for rev D will come shortly.

Temperature control enhancements

• Added the following settings defines:
  • HAS_TEMPERATURE_SENSOR_1, HAS_TEMPERATURE_SENSOR_2, and HAS_TEMPERATURE_SENSOR_3
  • EXTRUDER_1_OUTPUT_PIN, EXTRUDER_2_OUTPUT_PIN, and BED_OUTPUT_PIN
  • Added BED_OUTPUT_INIT in order to control configuration of the Bed output pin settings.
  • Defaults to {kNormal, fet_pin3_freq}.
  • EXTRUDER_1_FAN_PIN for control of the temperature-enabled fan on extruder 1. (Only available on extruder 1 at the moment.)
• (Experimental) Analog input is now interpreted through one of various ADCCircuit objects.
  • Three are provided currently: ADCCircuitSimplePullup, ADCCircuitDifferentialPullup, ADCCircuitRawResistance
  • Thermistor and PT100 objects no longer take the pullup value in their constructor, but instead take a pointer to an ADCCircuit object.
• Thermistor and PT100 objects no longer assume an ADCPin is used, but now take the type that conforms to the ADCPin interface as a template argument.
• TODO: Make more of these configurable at runtime. Separate the ADC input from the consumer, and allow other things than temperature to read it.
• PID+FF control adds feed-forward (FF) to adjust the output to a reasonable minimum based on heat loss dues to room temperature.
  • This can be effectively disabled, making the controller a PID controller, by setting the F value to 0.0.
  • Warning setting this value too high can cause thermal runaway. Set this value conservatively (low), since there's currently no ambient temperature, and the actual heat loss may be less than computed. This will be magnified by another heater (such as that on a heat bed of a 3D printer) in close proximity.

TMC2130 JSON controls

• Added the following setting keys to the motors (1 - 6):
  • ts - (R) get the value of the TSTEP register
  • pth - (R/W) get/set the value of the TPWMTHRS register
  • cth - (R/W) get/set the value of the TCOOLTHRS register
  • hth - (R/W) get/set the value of the THIGH register
  • sgt - (R/W) get/set the value of the sgt value of the COOLCONF register
  • sgr - (R) get the SG_RESULT value of the DRV_STATUS register
  • csa - (R) get the CS_ACTUAL value of the DRV_STATUS register
  • sgs - (R) get the stallGuard value of the DRV_STATUS register
  • tbl - (R/W) get/set the TBL value of the CHOPCONF register
  • pgrd - (R/W) get/set the PWM_GRAD value of the PWMCONF register
  • pamp - (R/W) get/set the PWM_AMPL value of the PWMCONF register
  • hend - (R/W) get/set the HEND_OFFSET value of the CHOPCONF register
  • hsrt - (R/W) get/set the HSTRT/TFD012 value of the CHOPCONF register
  • smin - (R/W) get/set the semin value of the COOLCONF register
  • smax - (R/W) get/set the semax value of the COOLCONF register
  • sup - (R/W) get/set the seup value of the COOLCONF register
  • sdn - (R/W) get/set the sedn value of the COOLCONF register
• Note that all gets retrieve the last cached value.

Core XY Kinematics Support

• Enabled at compile-time by setting the KINEMATICS define to KINE_CORE_XY
  • The default (and only other valid value) for KINEMATICS is KINE_CARTESIAN
• Note that the X and Y axes must have the same settings, or the behavior is undefined.
• For the sake of motor mapping, the values AXIS_COREXY_A and AXIS_COREXY_B have been created.
• Example usage:

#define M1_MOTOR_MAP                AXIS_COREXY_A           // 1ma
#define M2_MOTOR_MAP                AXIS_COREXY_B           // 2ma

Planner settings control from board files

• The defines PLANNER_QUEUE_SIZE and MIN_SEGMENT_MS are now set in the board/*/hardware.h files.
• PLANNER_QUEUE_SIZE sets the size of the planner buffer array.
  • Default value if not defined: 48
• MIN_SEGMENT_MS sets the minimum segment time (in milliseconds) and several other settings that are comuted based on it.
  • Default values if not defined: 0.75
  • A few of the computed values are shown:

  #define NOM_SEGMENT_MS              ((float)MIN_SEGMENT_MS*2.0)        // nominal segment ms (at LEAST MIN_SEGMENT_MS * 2)
  #define MIN_BLOCK_MS                ((float)MIN_SEGMENT_MS*2.0)        // minimum block (whole move) milliseconds

Experimental traverse at high jerk

• The new define TRAVERSE_AT_HIGH_JERK can be set to true, making traverse (G0) moves (including E-only moves in Marlin-flavored gcode mode) will use the jerk-high (jh) settings.
  • If set to false or undefined G0 moves will continue to use the jerk-max (jm) settings that feed (G1) moves use.

PID+FF - added feed forward

• There is a new JSON value f in each pidn object (read-only, for reporting) as well as an f setting in the hen objects (for control).
  • This is controlled in the settings file via Hn_DEFAULT_F, such as H1_DEFAULT_F. Default value is 0.0.
  • This is a value that is multiplied to by current temp - 21 and added to the current computed output.
  • Warning! Setting this value too high can result in thermal runaway. Set it conservatively (low) or disable it completely if in doubt.
  • Set the henf value to 0.0 to effectively disable feed-forward.

Output setting as soon as possible

• At board initialization, the output value on each of the out objects is set to whatever the pin is configured to be "inactive." This is based on the settings file DOn_MODE setting.
• For example, if DO10_MODE == IO_ACTIVE_LOW then the pin at DO10 is initialized as HIGH at board setup. This happen even before the main() function starts, shortly after the GPIO clocks are enabled for each port.

g2's Issues

Feedhold response slower than expected

The response of the feedhold command when received on the control port is still slow, even thought he g-code port is now separate. Easy to reproduce with a complex file, and low traffic on the control port.

Feedhold-Flush Workflow Broken

Bringing the system to a halt with feedhold (!) and then issuing a flush (%) does not work in the current edge build.

The FabMo fork is part of the way there:

https://github.com/ShopBotTools/FabMo-G2-Core/tree/edge

It successfully executes the feedhold (!) and the receipt of the flush (%) character triggers the system to go into alarm, which is the expected behavior. However, when in the alarm state, it appears that not all of the data from the G-Code port is continued to be consumed and ignored (as described here: https://github.com/synthetos/g2/wiki/Job-Exception-Handling) By installing breakpoints and inspecting as the system is passed through the feedhold/flush workflow, it seems as though the data is not being read in quite as expected.

To reproduce:

1. Load edge of the FabMo fork: https://github.com/ShopBotTools/FabMo-G2-Core/tree/edge
2. Open two terminals, one for control [C] and one for data [D]
3. [C] {clear:n} (Currently the system is initially in alarm, and must be cleared.)
4. [D] G1X100F30
5. [C] !
6. Wait for the system to enter the hold state (stat=6)
7. [C] %

Now, at this stage, any g-codes that come in on the data port should be consumed and ignored, but this doesn't appear to be the case. Continuing the debug procedure:

1. Pause the running FW and place a breakpoint on line 312 of controller.cpp
2. Resume the FW
3. Send some g-codes on the data port, for instance: G1X10F30
4. Observe that the breakpoint is not apparently hit. (This behavior seems to vary, though. Try sending several g-code lines. The expected behavior is that the breakpoint would be hit once for each line)
5. Send a gcode down the control port. This appears to trigger the breakpoint every time, and in cases where the data port has several g-codes queued, one breakpoint is hit for every queued code, as if data coming down the control port provokes a flush of the data port.

In this fork, I have added ignored_gcodes to the canonical machine singleton, which counts every g-code that is ignored due to an alarm. This can help for debugging.

Setting the switch type causes cortex halt

System is locked up when setting the st variable (global homing switch type) via JSON.

To reproduce:

1. Connect with coolterm
2. {st:0}
3. Observe cortex halt.

I came upon this error in attempting to get homing working properly. Homing routines that worked in edge now behave erratically. I thought it might be because i never set the switch type and perhaps the new build works differently with unspecified. When specifying the switch type (doesn't matter what value) the SAM locks up, and cannot be recovered.

G2 gShield/DUE pin mapping seems to be incorrect

I checked out the latest g2 edge branch did a build (which defaults to gShield) and flashed my Arduino DUE (I'm using linux so I also needed PR #55).

I hooked my logic analyzer to pins D2 thru D8 on the DUE (according to the gShield schematics this should be the XYZ step/dir pins + enable).

I'm not seeing any steps on D2 at all.
I'm seeing steps on D3 when I ask to move the Z-axis (D3 is the Y axis)
I'm seeing steps on D4 when I ask to move the Y axis (D4 is the Z axis)

The Y&Z direction seem to be swapped as well (and I see no changes on x-dir)

Anybody have any idea what's going on?

Flush queue does not work as documented

I have observed that the 'Flush Queue' command ('%') appears not to actually flush the queue in instances when G2 is still moving. This is easy to observe by initiating a move, and then issuing a '!%' in a single serial write.

Instances where the '!%' are sent in rapid succession (such as in a single write) cause the tool to enter the feed hold condition (the machine state changes appropriately) but not actually flush the buffer. A second '%' character is required after the system has physically come to a halt. Issuing the queue flush 10ms after the status reports 'vel': 0 appears to do the trick in the test cases I have observed.

To reproduce, configure the dynamic properties of the motion system to have a sufficient ramp time to observe (1-2 seconds of ramp for a typical move is more than sufficient) - Then initiate a long move, and when the move is at top speed, issue a '!%' in a single serial write. The system plans down and stops moving, but another g-code is not accepted until a second '%' is sent once the system has stopped moving.

Makefile not working.

g2-Master biuld failed. What I done wrong?
Help please!

------ Build started: Project: TinyG2, Configuration: Debug ARM ------
Build started.
Project "TinyG2.cppproj" (default targets):
Target "PreBuildEvent" skipped, due to false condition; ('$(PreBuildEvent)'!='') was evaluated as (''!='').
Target "CoreBuild" in file "C:\Program Files (x86)\Atmel\Atmel Studio 6.2\Vs\Compiler.targets" from project "R:\Firmware\g2-master\TinyG2\TinyG2.cppproj" (target "Build" depends on it):
Using "RunCompilerTask" task from assembly "C:\Program Files (x86)\Atmel\Atmel Studio 6.2\Extensions\Application\AvrGCC.dll".
Task "RunCompilerTask"
Shell Utils Path C:\Program Files (x86)\Atmel\Atmel Studio 6.2\shellUtils
C:\Program Files (x86)\Atmel\Atmel Studio 6.2\shellUtils\make.exe -C "R:\Firmware\g2-master\TinyG2" -f "Makefile" TinyG2.elf COLOR=0 VERBOSE=1 OPTIMIZATION=s
d was unexpected at this time.
d was unexpected at this time.
d was unexpected at this time.
The system cannot find the path specified.
d was unexpected at this time.
d was unexpected at this time.
d was unexpected at this time.
The system cannot find the path specified.
make: Entering directory R:/Firmware/g2-master/TinyG2' if [[ ! -ddirname build/SAM3X8E/flash/./canonical_machine.o]]; then mkdir -pdirname build/SAM3X8E/flash/./canonical_machine.o; fi ! was unexpected at this time. make: *** [build/SAM3X8E/flash/./canonical_machine.o] Error 255 make: Leaving directoryR:/Firmware/g2-master/TinyG2'
Done executing task "RunCompilerTask" -- FAILED.
Done building target "CoreBuild" in project "TinyG2.cppproj" -- FAILED.
Done building project "TinyG2.cppproj" -- FAILED.

Build FAILED.
========== Build: 0 succeeded or up-to-date, 1 failed, 0 skipped ==========

Porting Motate

I'm trying to port motate to the STM32F407VG platform,
alas my C++ templates are far from fluent.

Is there a guide or a short summary as to porting motate?

I've obviously started with the pin handlers, and am wondering
what the PinHolder classes do? Are they even in use by Tinyg2?

Thanks so much,
Tyberius Prime

EDGE behavior $DEFA=1

Is $defa=1 command expected to work for this FW build?

Running Edge build 71.04 on tinyGv9k.
I compiled with a custom settings file with initial settings for my ShapeOko2-ish machine.
Host is Linux, connected to /dev/ACM0 with Coolterm at 115200baud.
Experimenting with changing a parameter, then resetting to defaults.
Executing $xvm=8000 changed the setting correctly, able to display changed value with $xvm
Then executed $defa=1, expecting xvm to be reset to 16000, my default.
After the DEFA=1, Coolterm not communicating wiith tinyG2.
Disconnect then reconnect coolterm via Coolterm console did not help.
Pulling and re-inserting USB cable did not help, but did restart both ACM0 and ACM1 with new date/time stamps at Linux end.
A manual (reset button) reset cleared the issue, Coolterm would reconnect.
Then, of course, parameter xvm was back to it's default, =16000.

Thank you and some initial questions

First, let me just say G2 on the Due sounds awesome! Thank you! I realize this is early, but I'm curious about a few things--

1. Is G2 intended to only work with the TinyG? Or is this the next big step on a GRBL path?
2. What approaches are anticipated to address the lack of EEPROM on the Due?
3. Do any GUI's currently work with G2?

G2/Edge won't talk to linux host, usb errors suspected

I'm trying G2 on an arduino Due, and the ports ACM0 and ACM1 get created, however, if I picocom -b 115200 /dev/ttyACM0 ( or 1 ) there's nothing, no output, no echo. Chillipeppr also fails to do anything with these ports.
One thing that looks interesting is that the kernel (3.16) complains about:
usb 1-3: config 1 interface 1 altsetting 0 bulk endpoint 0x2 has invalid maxpacket 256
usb 1-3: config 1 interface 1 altsetting 0 bulk endpoint 0x83 has invalid maxpacket 256
usb 1-3: config 1 interface 3 altsetting 0 bulk endpoint 0x5 has invalid maxpacket 256
usb 1-3: config 1 interface 3 altsetting 0 bulk endpoint 0x86 has invalid maxpacket 256

AFAIK, maxpackets are fixed, and should be 512 on bulk packets, can this explain why I can't talk to my board?

Shapeoko + TinyG2 cannot send commands

I have a semi working build with a simple setup with Arduino Uno + gshield (v4); everything works except I haven't fully calibrated for my scaled up setup.

but since I have the Due, I wanted to make use of it.
I successfully flashed the Due and used the latest .inf for Windows from alden's branch

When I plug in my Due and power up my PSU for the gshield (v4), I can hear my motors automatically whirring as if they were trying to move but can't.

I'm thinking that the problem is in the settings
but none of the gcode senders I tried are allowing me to send the gcode.
I tried:

• gcodesender for windows
• universalgcodesender by john lauer
• tgfx

Could it be possible to compile a new bin to flash with the settings for shapeokos already built in? I am pretty new at this, so if anyone would care to compile one for me or direct me to how to do it myself; that would be very helpful.

thanks

Unexpected machine state behavior.

Per this:

https://github.com/synthetos/TinyG/wiki/TinyG-Status-Codes#status-report-enumerations

state 6 = "motion is holding" which is the state entered either when a feedhold command is issued, a limit switch is hit, or the system exhausts itself of g-codes (but does not encounter an M2 or an M30)

State 6 appears to be entered immediately when a feedhold ('!') command is received. This is OK, but unexpected, and perhaps unintended, because 'Motion is Holding' implies that the motion system is stationary, which it does not appear to be guaranteed when entering machine state 6.

To observe, configure the dynamic parameters for a multi-second ramp (1 or 2 seconds will do) and set automatic status reports. Initiate a move that accelerates to full speed, and then issue a feed hold (while at full speed) - Observe the 'stat' member of the status report, and you can see that state 6 is entered essentially immediately after the '!' but, several status reports follow before the end of motion.

I would assert that this is unintended, or at least undesirable behavior, especially in light of #16 ... if a flush queue doesn't work when the tool is not in motion, the only solution is to wait for the tool to become stationary, and then issue the flush queue before starting a new program. If you can't reliably tell when the tool is stationary, then this becomes a challenge. The end of motion should always be accompanied by a system state change, so I would suggest one of the following:

1. Bifurcate that state and make it two states: the "limit or feedhold hit but still in motion" state and the "motion has now completely stopped due to limit or feedhold" state. These could stand alone from the "motion stopped for reasons that are not a limit or feedhold" state.
2. Move the state transition to the end of motion so that the "motion hold" state means just that. The system is in holding and nothing is in a dynamic state.

G-code arc planning broken in edge

Planning for g-code arcs appears to be broken in edge.

Two files are linked below. The first is a simple circle, drawn as four g-code arcs. The second is the same circle, done as an interpolated polyline.

The polyline works fine, but the one composed of the arcs does not work. This file previews and runs correctly in other tools, and looks to be valid.

This is the file with the arcs: https://gist.github.com/ryansturmer/3d240a58203675bef997

This is the file with the segments: https://gist.github.com/ryansturmer/7d9d0e487f9fac3a0ace

The arc file appears to only draw a portion of the complete circle. The image below details the behavior:

The dotted lines are drawn in by hand after the job had completed. The solid lines were drawn by the tool.

Where Is the COM port ? impossible to open serial monitor

Hello, please see the image file attached.

I'm confused, i'm able to compile, send the program, and use the serial monitor on Mac OSX. But when i plug the Due on native USB port on Windows (tried Windows 7, and Windows8) impossible to get the serial monitor. no COM port on serial manager but 2 "TinyG V2" lines in "Other devices" Chapter.

Please How can i do ?

Thank's for your work

Machine position not reporting correctly?

mpox/mpoy/mpoz appear not to report the correct machine positions.

To reproduce:

1. Issue a G28.3 Z0 (to set the machine position of the z to zero)
2. Request an mpoz using the JSON interface. {mpoz:null}

On my machine, the value reported for mpoz = -0.579 mm when according to the docs, the position should be zero?

Edge or Master?

I had a git clone of Edge from 12/24/2014.
Today I did a git-pull, wanting to build 74.03 to see if I could figure out why I crashed the Cloudv9 that was just opened up at Chilipeppr.
The Edge-pull made 1/24/2015 won't build on my machine. Is that my problem or is Edge now WIP?
In looking a bit deeper, it would appear that Master has been significantly updated, should that be used rather than Edge?

Edge chokes on dwell (G4)

In the same way described in #44, the G4 command appears to cause G2 to crash irrevocably. A simple file such as what follows is all it takes:

G1X1F120.0
G4P3.0
G1X0F120.0

Sending this down all in one packet (on the data channel) actually causes the program to hang before the tool is even set in motion. On an older build g2@3b00ffad the hang occurs in the trapezoid planner on the check for a non-NULL motion buffer. On the tip of edge, the program proceeds, but there is no motion, and subsequent commands are replied to with er:9 "File not open"

This feels related to #45

GCode Sending issues

Not sure if this is the place for this, I was directed to post this here from the synthetos forums.

I’m running G2 on an Arduino Due, attached to a Gecko G540 stepper driver on a ballscrew driven 3d printer.

[fb] firmware build 37.03
[fv] firmware version 0.80
[hp] hardware platform 3.00
[hv] hardware version 0.00

I got this firmware from the github downloads page. I’m currently running my own gcode sending application since I couldn't get tgFX to connect.

When I run this chunk of gcode:

G1 X49.312 Y40.709 F4200.000
G1 X50.630 Y40.777
G1 X51.260 Y40.832
G1 X52.626 Y41.050
G1 X54.320 Y41.817
G1 X55.530 Y42.489
G1 X56.858 Y43.788
G1 X57.765 Y44.834
G1 X58.572 Y46.516
G1 X58.699 Y46.827
G1 X58.989 Y47.750
G1 X59.035 Y47.746
G1 X59.189 Y49.014
G1 X59.247 Y49.659
G1 X59.259 Y49.994

I get an error:

ALINE() line0 0.000011
tinyg [mm] err: Move less than minimum time: G1 X59.035 Y47.746
posx:53.071,posy:44.088,vel:3487.864,stat:5
posx:49.487,posy:40.649,vel:338.393
posx:55.670,posy:42.493,vel:1295.647
posx:59.043,posy:47.639,vel:245.400
posx:59.035,posy:47.746,vel:0.000,stat:3

What does this mean, and is it safe to ignore? I assume this means that the move time is so tiny, that it makes no sense to make this move, so I should just continue on with the next line and ignore it? If I ignore the error and continue, it seems to move just fine

I also get periodic “######## LOADER – SEGMENT NOT READY” messages, what do these mean? They seem to come randomly, and interrupt the text causing parsing pretty difficult.

Motion runaway while running a file

I had motion control run away on me today, in a not-spectacular but not-ideal fashion. This was a g-code file generated by v-carve pro, and consisted only of G1 segments, plus a few G0 jogs and some setup. The file failed in the vicinity of line 29743 (of 31164) - this was the last line number reported by G2 when it stopped, but the line that tripped it up, if that was the cause, may have occurred before that. This was the expected behaivor:

And this was the outcome (See the departure from the intended toolpath towards the bottom right):

AT the point of the deviation the tool appeared to stop moving, but on closer inspection, it was seen to be moving very slowly in the direction of the slash (you can tell it was moving slowly by the burning of the wood in that area) It eventually did stop, though it did not escape the run state, and the line number has ceased to advance, with the position of the tool remaining fixed.

FWIW, the move appears to be tangent to the move it was intending to make at that time. There are no arcs in the file, just coordinated moves and jogs.

One last thing, the engine (which is the process managing the communication with G2) spit this up, the only error message since the start of the file:

Feb 03 06:48:29 FabMo_dev_006 node[138]: info: Running file /opt/fabmo/files/catplex.nc [machine]
Feb 03 06:48:29 FabMo_dev_006 node[138]: info: Got a machine state change: running [machine]
Feb 03 06:57:29 FabMo_dev_006 node[138]: error: -1,JSON_PARSE_ERROR,Could not parse response: '
Feb 03 06:57:29 FabMo_dev_006 node[138]: error: -1,JSON_PARSE_ERROR,Could not parse response: '
Feb 03 06:57:29 FabMo_dev_006 node[138]: [62B blob data]
Feb 03 06:57:29 FabMo_dev_006 node[138]: [62B blob data]
Feb 03 06:57:29 FabMo_dev_006 node[138]: [58B blob data]
Feb 03 06:57:29 FabMo_dev_006 node[138]: [58B blob data]
Feb 03 06:57:29 FabMo_dev_006 node[138]: error: -1,JSON_PARSE_ERROR,Could not parse response: '
Feb 03 06:57:29 FabMo_dev_006 node[138]: error: -1,JSON_PARSE_ERROR,Could not parse response: '

The JSON_PARSE_ERROR is emitted whenever the g2 module doesn't unerstand a message that came from the board. Looks like the board crashed and was sending out some garbage? I am re-running this file in a less EMI-laden environment to see if the system fails in the same place.

Dual Endpoint USB

This issue is for discussion of the dual endpoint USB function that is documented here:
https://github.com/synthetos/g2/wiki/Dual-Endpoint-USB-Operation

Atmel Studio 6.2 Issues - README

A recent disaster bricked my tinyGv9 (see #47 for gory details).
So I went to the shelf and dusted off my new, still in box, Atmel-ICE.
Prior to this , BOSSAC ver 1.3 worked so well I had not needed ICE.

Following the Wiki instructions, I set off to load and run Atmel Studio 6, the prescribed interface to Atmel-ICE. If you head to Atmel today, it will offer for download Atmel Studio 6.2 build 1548 Service Pack 2. As suggested, grab the version that includes .Net updates, just in case.

Just a note - I am a Linux user, run Windows only when absolutely necessary and then in Virtual Box VMs. So almost by definition, my Windows machines are not ready for heavy duty development work (.Net., etc, etc.) If your are an experienced Windows developer, you are likely accustomed to this abuse.

AS6.2 is Windows only. I tried a Win 8.1 Virtual Box VM, then a Win7 Virtual Box VM, then a native boot into Win7. After install, none would connect to my Atmel-ICE.
Being new to AS6, I flounder a bit not knowing what to expect from the interface.

For now, assume there is a fatal bug in this version of the AS6.2 package.

If you just want to move forward, review this POST : http://www.avrfreaks.net/comment/1456731#comment-1456731 then proceed to download http://distribute.atmel.no/tools/AS6/driver-atmel-bundle-7.0.666.exe. Just run the .exe, it will update/overwrite the batch of USB drivers distributed with AS6.2.
FYI, I ran these installs by right click and Run As Administrator. I cannot say if that is necessary or not, but it did work for me.
If you are lucky, as I was, you can now connect to Atmel-ICE from AS6.2.

Compared to this AS install fiasco, flashing tinyGv9 or DUE with ICE is trivial. Follow the Wiki.

I will update this as I triage where I am at.
So far, I can only guarantee that this now works on native Win7.
I'll test the VMs tomorrow, or soon.

g2 in Win7 64

Hi,

I can see no forums for TinyG2 issues so am asking here.

Not having a mac, and I dislike Atmel Studio, I decided to try to get g2 compiling using Eclipse with just the makefile. This, from past experience, would allow a quick conversion to compile in Linux as well.

Looking through the github repo and the issues I decided that the Alden branch would be most suitable, as that seemed to have had some windows USB fixes.

After slight modifications to the makefile I have a bin file compiled.
As this is windows I have a gnu utils dir which can be added to the path with gnu make lifted from the arduino toolchain. As the note in the makefile I used gmkdir for MKDIR.

Also I found I had to add -D__SAM3X8E__ -DF_CPU=84000000L to the CFLAGS as presumably these are added by AS6 through a gui mechanism.

The suggested yagarto distribution however failed on missing --specs=nano.specs. Grepping this on the web, I found that the yagarto toolchain is and will be no more and that a recommended toolchain was gcc-arm. So I downloaded that and everything compiled. (gcc 4.8.3).

I flashed this to the due, 'Write 104360 bytes to flash' and referenced the TinyG2.inf and windows shows TinyG v2(COM10) in device manager. However, I can get nothing at all to connect to com10. Eclipse terminal hangs eclipse, putty will not launch. So I downloaded tgFX edge and that at least says it connects but hangs on 'Getting TinyG Firmware Build Version....', tgFX now frozen until I kill it or pull the plug on the due.

What is interesting is the tx light on the usb looks like it is doing a pwm up and down cycle. Now it must have connected at slow speed for windows to query the VID/PID, name etc but after that the USB will not talk to anything, does not show in command line with a mode command and cycles the tx line from almost off to ~ half brightness as though it was trying to talk to something that is not there.

I then tried the image that rob provided a while back for the windows USB issue. This has the same behaviour. As the machine I am compiling with is AMD based and some issues have been reported on USB on AMD systems I tried the above on my Intel powered box, again Win 7 64, with the same result.

ATM I do not have any hardware debugging, so I am about to get the logic analyser to the usb stream. Any suggestions anyone?

Make finding G2 Wiki easier

github.com/Synthetos/tinyG has a reference to the tinyG wiki right at the top.
"Affordable Industrial Grade Motion Control https://github.com/synthetos/TinyG/wiki"

Can you add similar reference to the G2 Wiki on github.com/Synthetos/G2; will make it easier for new git-ers to find the wiki
I think it reasonable to expect an uptick in traffic now that v9 (and soon Due) are accessible for test via Chilipeppr

Connecting Windows to TinyG2

This issue is to track the connection of Windows to G2. Currently, with Due/G2 connected via Native USB, Windows doesn't see it in the COM ports.

Arduino 1.6.0

I am trying to flash my due using arduino 1.6.0 and getting:

Arduino version is too old and does not include support for the due. Get a newer version!
Download a newer ARM version here: http://arduino.cc/en/main/software
Exiting......

I know 1.6 does support the due, but it looks like bossac is not in the same spot, anyone know where it went in 1.6?

Progress on persistence?

Any guesstimates on when persistence will be available for the v9 platform?

Also, when it arrives, what sort of flash device will be desired for Due? The sort of widely available SPI connected SD card?

Reject string values for numeric fields

Numeric inputs such as {xvm:1000} will incorrectly accept string values and set the numeric value to zero.

Example: {xvm:"spaghetti"} will return {xvm:0}. This should reject the command and return an error.

Homing switch issues

I'm using the TinyG2_Due_rob_usbtest.bin binary from http://synthetos.github.io/g2/ on a Due with a stepper shield using A4988 stepstick clones to drive a large laser cutter mechanism I've designed. It works well with a minor problem revolving around homing switches.

Everything seems to be wired and configured correctly, and indeed it drives the motors perfectly, so I can drop a gcode file in and it will execute it quite happily. Issuing a G28 command will make it home to it's 0,0 origin correctly as well. But if I give the G28.2 X0 command, for example, I get an error:

"*** WARNING *** Homing error: X axis settings misconfigured

The same error occurs for any axis or set of axes, for the first one given. I have gone over every scrap of documentation I can find with no result, I can't find any setting I have missed. Either I'm still missing something (entirely possible), or there is a real problem, which as far as I can see must be a bug of some sort.

I notice that the $ST command to set switch type as NC or NO gives an unrecognised command error, as does $BSN and $BSN, although all the other switch commands seem to work. Is this binary broken in some subtle manner?

Any help on resolving this would be much appreciated.

My complete configuration is as follows (note that only the X and Y axes are in use):

[fb] firmware build 25.01
[fv] firmware version 0.80
[hp] hardware platform 2.00
[hv] hardware version 0.00
[ja] junction acceleration 100000 mm
[ct] chordal tolerance 0.001 mm
[mt] motor idle timeout 2.00 Sec
[ej] enable json mode 0 [0=text,1=JSON]
[jv] json verbosity 5 [0=silent,1=footer,2=messages,3=configs,4=linenum,5=verbose]
[tv] text verbosity 1 [0=silent,1=verbose]
[qv] queue report verbosity 0 [0=off,1=single,2=triple]
[sv] status report verbosity 1 [0=off,1=filtered,2=verbose]
[si] status interval 250 ms
[gpl] default gcode plane 0 [0=G17,1=G18,2=G19]
[gun] default gcode units mode 1 [0=G20,1=G21]
[gco] default gcode coord system 1 [1-6 (G54-G59)]
[gpa] default gcode path control 2 [0=G61,1=G61.1,2=G64]
[gdi] default gcode distance mode 0 [0=G90,1=G91]
[1ma] m1 map to axis 0 [0=X,1=Y,2=Z...]
[1sa] m1 step angle 1.800 deg
[1tr] m1 travel per revolution 160.000 mm
[1mi] m1 microsteps 8 [1,2,4,8]
[1po] m1 polarity 0 [0=normal,1=reverse]
[1pm] m1 power management 1 [0=disable,1=power in cycle,2=power when moving]
[1pl] m1 power level 25.00 [0-100]
[2ma] m2 map to axis 1 [0=X,1=Y,2=Z...]
[2sa] m2 step angle 1.800 deg
[2tr] m2 travel per revolution 60.000 mm
[2mi] m2 microsteps 8 [1,2,4,8]
[2po] m2 polarity 0 [0=normal,1=reverse]
[2pm] m2 power management 1 [0=disable,1=power in cycle,2=power when moving]
[2pl] m2 power level 25.00 [0-100]
[3ma] m3 map to axis 2 [0=X,1=Y,2=Z...]
[3sa] m3 step angle 1.800 deg
[3tr] m3 travel per revolution 1.250 mm
[3mi] m3 microsteps 8 [1,2,4,8]
[3po] m3 polarity 0 [0=normal,1=reverse]
[3pm] m3 power management 1 [0=disable,1=power in cycle,2=power when moving]
[3pl] m3 power level 25.00 [0-100]
[4ma] m4 map to axis 3 [0=X,1=Y,2=Z...]
[4sa] m4 step angle 1.800 deg
[4tr] m4 travel per revolution 360.000 mm
[4mi] m4 microsteps 8 [1,2,4,8]
[4po] m4 polarity 0 [0=normal,1=reverse]
[4pm] m4 power management 1 [0=disable,1=power in cycle,2=power when moving]
[4pl] m4 power level 25.00 [0-100]
[5ma] m5 map to axis 4 [0=X,1=Y,2=Z...]
[5sa] m5 step angle 1.800 deg
[5tr] m5 travel per revolution 360.000 mm
[5mi] m5 microsteps 8 [1,2,4,8]
[5po] m5 polarity 0 [0=normal,1=reverse]
[5pm] m5 power management 1 [0=disable,1=power in cycle,2=power when moving]
[5pl] m5 power level 25.00 [0-100]
[6ma] m6 map to axis 5 [0=X,1=Y,2=Z...]
[6sa] m6 step angle 1.800 deg
[6tr] m6 travel per revolution 360.000 mm
[6mi] m6 microsteps 8 [1,2,4,8]
[6po] m6 polarity 0 [0=normal,1=reverse]
[6pm] m6 power management 1 [0=disable,1=power in cycle,2=power when moving]
[6pl] m6 power level 25.00 [0-100]
[xam] x axis mode 1 [standard]
[xvm] x velocity maximum 20000.000 mm/min
[xfr] x feedrate maximum 20000.000 mm/min
[xtm] x travel maximum 1210.000 mm
[xtn] x travel minimum 0.000 mm
[xjm] x jerk maximum 5000 mm/min^3 * 1 million
[xjh] x jerk homing 5000 mm/min^3 * 1 million
[xjd] x junction deviation 0.0500 mm (larger is faster)
[xsn] x switch min 3 [0=off,1=homing,2=limit,3=limit+homing]
[xsx] x switch max 0 [0=off,1=homing,2=limit,3=limit+homing]
[xsv] x search velocity 500.000 mm/min
[xlv] x latch velocity 100.000 mm/min
[xlb] x latch backoff 2.000 mm
[xzb] x zero backoff 1.000 mm
[yam] y axis mode 1 [standard]
[yvm] y velocity maximum 20000.000 mm/min
[yfr] y feedrate maximum 20000.000 mm/min
[ytm] y travel maximum 500.000 mm
[ytn] y travel minimum 0.000 mm
[yjm] y jerk maximum 5000 mm/min^3 * 1 million
[yjh] y jerk homing 5000 mm/min^3 * 1 million
[yjd] y junction deviation 0.0500 mm (larger is faster)
[ysn] y switch min 3 [0=off,1=homing,2=limit,3=limit+homing]
[ysx] y switch max 0 [0=off,1=homing,2=limit,3=limit+homing]
[ysv] y search velocity 500.000 mm/min
[ylv] y latch velocity 100.000 mm/min
[ylb] y latch backoff 2.000 mm
[yzb] y zero backoff 1.000 mm
[zam] z axis mode 1 [standard]
[zvm] z velocity maximum 600.000 mm/min
[zfr] z feedrate maximum 600.000 mm/min
[ztm] z travel maximum 75.000 mm
[ztn] z travel minimum 0.000 mm
[zjm] z jerk maximum 20 mm/min^3 * 1 million
[zjh] z jerk homing 20 mm/min^3 * 1 million
[zjd] z junction deviation 0.0500 mm (larger is faster)
[zsn] z switch min 0 [0=off,1=homing,2=limit,3=limit+homing]
[zsx] z switch max 0 [0=off,1=homing,2=limit,3=limit+homing]
[zsv] z search velocity 400.000 mm/min
[zlv] z latch velocity 100.000 mm/min
[zlb] z latch backoff 2.000 mm
[zzb] z zero backoff 1.000 mm
[aam] a axis mode 3 [radius]
[avm] a velocity maximum 172800.000 deg/min
[afr] a feedrate maximum 172800.000 deg/min
[atm] a travel maximum -1.000 deg
[atn] a travel minimum -1.000 deg
[ajm] a jerk maximum 5760 deg/min^3 * 1 million
[ajh] a jerk homing 5760 deg/min^3 * 1 million
[ajd] a junction deviation 0.0500 deg (larger is faster)
[ara] a radius value 0.1989 deg
[asn] a switch min 0 [0=off,1=homing,2=limit,3=limit+homing]
[asx] a switch max 0 [0=off,1=homing,2=limit,3=limit+homing]
[asv] a search velocity 600.000 deg/min
[alv] a latch velocity 100.000 deg/min
[alb] a latch backoff 5.000 deg
[azb] a zero backoff 2.000 deg
[bam] b axis mode 3 [radius]
[bvm] b velocity maximum 172800.000 deg/min
[bfr] b feedrate maximum 172800.000 deg/min
[btm] b travel maximum -1.000 deg
[btn] b travel minimum -1.000 deg
[bjm] b jerk maximum 5760 deg/min^3 * 1 million
[bjd] b junction deviation 0.0500 deg (larger is faster)
[bra] b radius value 0.1989 deg
[bsn] b switch min 1 [0=off,1=homing,2=limit,3=limit+homing]
[bsx] b switch max 0 [0=off,1=homing,2=limit,3=limit+homing]
[bsv] b search velocity 600.000 deg/min
[blv] b latch velocity 100.000 deg/min
[blb] b latch backoff 5.000 deg
[bzb] b zero backoff 2.000 deg
[bjh] b jerk homing 5760 deg/min^3 * 1 million
[cam] c axis mode 3 [radius]
[cvm] c velocity maximum 172800.000 deg/min
[cfr] c feedrate maximum 172800.000 deg/min
[ctm] c travel maximum -1.000 deg
[cjm] c jerk maximum 5760 deg/min^3 * 1 million
[ctn] c travel minimum -1.000 deg
[cjd] c junction deviation 0.0500 deg (larger is faster)
[cra] c radius value 0.1989 deg
[csn] c switch min 0 [0=off,1=homing,2=limit,3=limit+homing]
[csx] c switch max 0 [0=off,1=homing,2=limit,3=limit+homing]
[csv] c search velocity 600.000 deg/min
[clv] c latch velocity 100.000 deg/min
[clb] c latch backoff 5.000 deg
[czb] c zero backoff 2.000 deg
[cjh] c jerk homing 5760 deg/min^3 * 1 million
[cam] c axis mode 3 [radius]
[cvm] c velocity maximum 172800.000 deg/min
[cfr] c feedrate maximum 172800.000 deg/min
[ctm] c travel maximum -1.000 deg
[cjm] c jerk maximum 5760 deg/min^3 * 1 million
[ctn] c travel minimum -1.000 deg
[cjd] c junction deviation 0.0500 deg (larger is faster)
[cra] c radius value 0.1989 deg
[csn] c switch min 0 [0=off,1=homing,2=limit,3=limit+homing]
[csx] c switch max 0 [0=off,1=homing,2=limit,3=limit+homing]
[csv] c search velocity 600.000 deg/min
[clv] c latch velocity 100.000 deg/min
[clb] c latch backoff 5.000 deg
[czb] c zero backoff 2.000 deg
[cjh] c jerk homing 5760 deg/min^3 * 1 million
[g54x] g54 x offset 0.000 mm
[g54y] g54 y offset 0.000 mm
[g54z] g54 z offset 0.000 mm
[g54a] g54 a offset 0.000 deg
[g54b] g54 b offset 0.000 deg
[g54c] g54 c offset 0.000 deg
[g55x] g55 x offset 75.000 mm
[g55y] g55 y offset 75.000 mm
[g55z] g55 z offset 0.000 mm
[g55a] g55 a offset 0.000 deg
[g55b] g55 b offset 0.000 deg
[g55c] g55 c offset 0.000 deg
[g56x] g56 x offset 0.000 mm
[g56y] g56 y offset 0.000 mm
[g56z] g56 z offset 0.000 mm
[g56a] g56 a offset 0.000 deg
[g56b] g56 b offset 0.000 deg
[g56c] g56 c offset 0.000 deg
[g57x] g57 x offset 0.000 mm
[g57y] g57 y offset 0.000 mm
[g57z] g57 z offset 0.000 mm
[g57a] g57 a offset 0.000 deg
[g57b] g57 b offset 0.000 deg
[g57c] g57 c offset 0.000 deg
[g58x] g58 x offset 0.000 mm
[g58y] g58 y offset 0.000 mm
[g58z] g58 z offset 0.000 mm
[g58a] g58 a offset 0.000 deg
[g58b] g58 b offset 0.000 deg
[g58c] g58 c offset 0.000 deg
[g59x] g59 x offset 0.000 mm
[g59y] g59 y offset 0.000 mm
[g59z] g59 z offset 0.000 mm
[g59a] g59 a offset 0.000 deg
[g59b] g59 b offset 0.000 deg
[g59c] g59 c offset 0.000 deg
[g92x] g92 x offset 0.000 mm
[g92y] g92 y offset 0.000 mm
[g92z] g92 z offset 0.000 mm
[g92a] g92 a offset 0.000 deg
[g92b] g92 b offset 0.000 deg
[g92c] g92 c offset 0.000 deg
[g28x] g28 x position 0.000 mm
[g28y] g28 y position 0.000 mm
[g28z] g28 z position 0.000 mm
[g28a] g28 a position 0.000 deg
[g28b] g28 b position 0.000 deg
[g28c] g28 c position 0.000 deg
[g30x] g30 x position 0.000 mm
[g30y] g30 y position 0.000 mm
[g30z] g30 z position 0.000 mm
[g30a] g30 a position 0.000 deg
[g30b] g30 b position 0.000 deg
[g30c] g30 c position 0.000 deg

pca

Board ID

Add a function to return a unique board ID. The calling format is {id:n}

Bug in $$ Parameter Listing

I just noticed that with build 71.04(current master), the parameters [csv] - [csh] are output twice, once with the other c axis parameters, then again later in the output.
It does not affect anything, so is really cosmetic but probably should be corrected.

I searched a bit on github, could not find where the contents of the $$ report are constructed.

May be fixed in current Edge - my compile ate my tinyGv9 and I have not fixed that yet
(Issue #47)

How fast is the step rate, can it speed up to Mega grade?

porting to other cortex hardware

What areas need to be looked at in porting g2 to other cortex hardware platforms?

I have some cortex M4 boards that I've been working with that I'd like to use for CNC.

It seems that most of the hardware specific stuff is contained in Motate and that Pins* and Timers* would need porting. Some detailed digging into the manufacturers datasheets should allow that.

Also the *ld file voodoo for the new h/w can be pulled out of the CMSIS code provided by ARM

Are there any other major hurdles to anticipate?

Thanks.

Build issues under linux (order of object files on linker command line)

I was helping @buserror investigate why his firmware wasn't working properly.

Right now, I've reached the point in the investigation that it seems to be triggered by some differences between make 4.0 and make 3.81, specifically related to the order of the object files produced by $(wildcard).

On my local machine (ubuntu 14.04) if I build with make-3.81, I get the following linker line:

arm-none-eabi-g++ -T"/home/dhylands/g2/g2/TinyG2/platform/atmel_sam/gcc_flash.ld" -Wl,-Map,"bin/gShield/gShield.map" -o bin/gShield/gShield.elf -lgcc -lc -Wl,--cref -Wl,--check-sections -Wl,--gc-sections -Wl,--entry=Reset_Handler -Wl,--unresolved-symbols=report-all -Wl,--warn-common -Wl,--warn-section-align -Wl,--warn-unresolved-symbols -nostartfiles -mcpu=cortex-m3 --specs=nano.specs -u _printf_float -mthumb -lgcc -lc -Wl,--start-group build/gShield/motate/SamTimers.o build/gShield/motate/SamUSB.o build/gShield/motate/SamPins.o build/gShield/platform/atmel_sam/syscalls_sam3.o build/gShield/CMSIS/Device/ATMEL/sam3xa/source/system_sam3xa.o build/gShield/CMSIS/Device/ATMEL/sam3xa/source/gcc/startup_sam3xa.o build/gShield/platform/atmel_sam/cortex_handlers.o build/gShield/platform/atmel_sam/hooks.o build/gShield/motate/AvrUSB.o build/gShield/motate/SamSPI.o build/gShield/./canonical_machine.o build/gShield/./config_app.o build/gShield/./config.o build/gShield/./controller.o build/gShield/./cycle_homing.o build/gShield/./cycle_jogging.o build/gShield/./cycle_probing.o build/gShield/./encoder.o build/gShield/./gcode_parser.o build/gShield/./hardware.o build/gShield/./help.o build/gShield/./json_parser.o build/gShield/./kinematics.o build/gShield/./main.o build/gShield/./persistence.o build/gShield/./plan_arc.o build/gShield/./plan_exec.o build/gShield/./plan_line.o build/gShield/./planner.o build/gShield/./plan_zoid.o build/gShield/./pwm.o build/gShield/./report.o build/gShield/./spindle.o build/gShield/./stepper.o build/gShield/./switch.o build/gShield/./test.o build/gShield/./text_parser.o build/gShield/./util.o build/gShield/./xio.o build/gShield/platform/atmel_sam/Reset.o build/gShield/platform/atmel_sam/UniqueId.o -Wl,--end-group

This produces working firmware.

Using make 4.0, I get the following linker line:

arm-none-eabi-g++ -T"/home/dhylands/g2/g2/TinyG2/platform/atmel_sam/gcc_flash.ld" -Wl,-Map,"bin/gShield/gShield.map" -o bin/gShield/gShield.elf -lgcc -lc -Wl,--cref -Wl,--check-sections -Wl,--gc-sections -Wl,--entry=Reset_Handler -Wl,--unresolved-symbols=report-all -Wl,--warn-common -Wl,--warn-section-align -Wl,--warn-unresolved-symbols -nostartfiles -mcpu=cortex-m3 --specs=nano.specs -u _printf_float -mthumb -lgcc -lc -Wl,--start-group build/gShield/motate/SamTimers.o build/gShield/motate/SamUSB.o build/gShield/motate/SamPins.o build/gShield/platform/atmel_sam/syscalls_sam3.o build/gShield/CMSIS/Device/ATMEL/sam3xa/source/system_sam3xa.o build/gShield/CMSIS/Device/ATMEL/sam3xa/source/gcc/startup_sam3xa.o build/gShield/platform/atmel_sam/hooks.o build/gShield/platform/atmel_sam/cortex_handlers.o build/gShield/motate/AvrUSB.o build/gShield/motate/SamSPI.o build/gShield/./help.o build/gShield/./cycle_homing.o build/gShield/./text_parser.o build/gShield/./controller.o build/gShield/./switch.o build/gShield/./planner.o build/gShield/./plan_arc.o build/gShield/./hardware.o build/gShield/./kinematics.o build/gShield/./cycle_probing.o build/gShield/./pwm.o build/gShield/./plan_zoid.o build/gShield/./stepper.o build/gShield/./plan_line.o build/gShield/./json_parser.o build/gShield/./config_app.o build/gShield/./xio.o build/gShield/./cycle_jogging.o build/gShield/./report.o build/gShield/./config.o build/gShield/./canonical_machine.o build/gShield/./encoder.o build/gShield/./persistence.o build/gShield/./gcode_parser.o build/gShield/./main.o build/gShield/./plan_exec.o build/gShield/./test.o build/gShield/./spindle.o build/gShield/./util.o build/gShield/platform/atmel_sam/UniqueId.o build/gShield/platform/atmel_sam/Reset.o -Wl,--end-group

and this produces non-working firmware.

The only difference between these 2 lines is the order of the .o files.

I need to investigate further to determine if this is a problem with the code (depending on things being in a particular order) or a toolchain issue.

So I figured I'd open this issue to at least make others aware of the issue, in case they're also experiencing similar problems, and I'll add to this as I discover more.

Introduction to code base

This is an open issue to create a wiki page(s) for a developer's introduction to the G2 code base.

Edge won't compile on Linux

Continuation from bottom of #44
I am following https://github.com/synthetos/g2/wiki/Compiling-G2-on-Linux-and-OS-X-%28using-the-command-line%29

From cli, I went to my /synthetos directory, ran -> [I don't know why I am so big :) ]

git clone https://github.com/synthetos/g2 new_g2
Cloning into 'new_g2'...
remote: Counting objects: 16398, done.
remote: Total 16398 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (16398/16398), 94.70 MiB | 13.06 MiB/s, done.
Resolving deltas: 100% (9971/9971), done.
Checking connectivity... done.
----------- looks OK so far, so ran
/synthetos/new_g2> git checkout edge
Branch edge set up to track remote branch edge from origin.
Switched to a new branch 'edge'
----------- still looks OK, so ran
/synthetos/new_g2/TinyG2> make PLATFORM=gShield SETTINGS_FILE=settings_default.h
Compiling c CMSIS/Device/ATMEL/sam3xa/source/system_sam3xa.c
-> build/gShield/CMSIS/Device/ATMEL/sam3xa/source/system_sam3xa.o
bash: arm-none-eabi-gcc: command not found
Makefile:455: recipe for target 'build/gShield/CMSIS/Device/ATMEL/sam3xa/source/system_sam3xa.o' failed
make: *** [build/gShield/CMSIS/Device/ATMEL/sam3xa/source/system_sam3xa.o] Error 127
----------------- Error, obviously.
Interestingly, the /synthetos/new_g2/Tools directory did not download anything:
.. /synthetos/new_g2> ll Tools
total 4
-rw-r--r-- 1 carl users 1759 Feb 4 15:41 Makefile

I can't call this a compiler error, the compiler did not get loaded into the Tools directory.....?

My prior clone looks like this
.../synthetos/g2_edge_old> ll Tools
total 60044
lrwxrwxrwx 1 carl users 28 Dec 22 23:08 gcc-arm-none-eabi -> gcc-arm-none-eabi-4_8-2014q1
drwxr-xr-x 6 carl users 4096 Dec 22 23:08 gcc-arm-none-eabi-4_8-2014q1
-rw-r--r-- 1 carl users 61469091 Mar 27 2014 gcc-arm-none-eabi-4_8-2014q1-20140314-linux.tar.bz2
-rw-r--r-- 1 carl users 1759 Dec 22 20:10 Makefile

History:

1. I cloned and checked out Edge on Dec 28, procedure worked as written, Edge Make built 72.01
2. I checked out Master on Jan 26. Make again caused the compile tarball to download and populate the /Tools directory and unpack itself there. Edge had been moved to Master, Make in Master built 72.01 again.

I'm open to suggestions - no rush, not top priority my end

Missing status report on feedhold in bernstein-bears branch

In prior builds, a status report was sent when the tool came to a halt after a feedhold is issued. In the latest bernstein-bears branch (latest) 6cd11f9 this does not appear to happen. A state change is reported immediately at the time of the feedhold request, but no following report is issued when the tool actually stops. This makes it impossible to know when the feedhold has actually been completely executed. An example output follows:

info: Stopping jog. [manual]
debug: stopJog() [g2]
g2: --C-1419728349346----> ! [g2]
g2: <-C--1419728349352---- {"r":{},"f":[1,0,17]} [g2]
g2: <-C--1419728349353---- {"qr":18,"qi":1,"qo":0} [g2]
g2: <-C--1419728349381---- {"qr":19,"qi":0,"qo":1} [g2]
g2: <-C--1419728349391---- {"sr":{"posx":-1.509,"vel":50.57,"stat":6,"hold":3}} [g2]
g2: <-C--1419728349446---- {"qr":20,"qi":0,"qo":1} [g2]
g2: <-C--1419728349553---- {"qr":21,"qi":0,"qo":1} [g2]
g2: <-C--1419728349642---- {"sr":{"posx":-1.628,"vel":16.89}} [g2]

The last status report above is the last one actually issued by G2. No further reports were made, even though the system is clearly moving, and at least should issue a status report containing the position once the tool stops moving, (and ideally also changes the "hold" value, if this value still applies with the reworked feedhold system.)

Note that in the example above, the feedhold appears to execute correctly, and the system is still working at this point, I just find myself missing the status report that gives a full tool update when it reaches its resting state, as it did in prior builds.

Accessory axes don't scale properly

I have only tested this with the B axis, but in our system, I do not get sensible results for the scaling on the B axis.

Setting the axis up with bam=1 (linear mode) and sensible defaults for tr,mi, and sa, I get unexpected movement distances, which I expect is the axis behaving in a rotational fashion, rather than in a linear fashion as expected. For instance a G0B10 which I expect to jog the axis to 10 inches, jogs to 0.394 inches. All moves on this axis move with a similar scaling factor.

Cycle resume does not work in dual USB mode

After a feedhold, tool is unresponsive to resume character sent over the control port.

edge

Ask about stepper.cpp

Why use double check at 364 line:
if (st_cfg.mot[motor].power_mode == MOTOR_DISABLED) {
_deenergize_motor(motor);
return;
}
and 117 line:
if (st_cfg.mot[motor].power_mode != MOTOR_DISABLED) {

And why double change power_state at 119 line:
st_run.mot[motor].power_state = MOTOR_POWER_TIMEOUT_START;
and 388 line:
st_run.mot[motor].power_state = MOTOR_POWER_TIMEOUT_COUNTDOWN;

Makefile Question

I cloned the G2 build environment from Git on 12/22/2014.

Is there a reason why at line 168, when setting up to build Platform=gshield, we have this line
DEVICE_DEFINES += MOTATE_BOARD="gShield"
and not this line
DEVICE_DEFINES += MOTATE_BOARD="gShield" SETTINGS_FILE=${SETTINGS_FILE}

All other platform builds include the option of the different settings file.

New status report behavior for "non-moves" (status report idempotency)

We would like Gcode blocks that do not actually move the tool to report back a full status line. This is so that moves that are deliberately issued just to ensure that the tool is at zero will in-fact report back stopped status {stat:3}

More generally, this issue addresses idempotent behaviors for status reporting - i.e. the same command issued twice should return values in a report - even if no state change occurred.

xlb,xzb Reported in incorrect units

The units for xlb/xzb are reported incorrectly (latest alden branch) (I assume ylb,zlb, etc)

To reproduce:
Set units: {gun:0}
Set xlb: {xlb:5.0}
Read xlb: {xlb: null}
Set units: {gun:1}
Read xlb: {xlb:null} - Value is unchanged.

-R

Psuedo EEPROM support?

Does it make sense to use a flash page to save what normally gets stored iin EEPROM?

Rather than rewriting flash for every value change, we could introduce some commands to do that.

Marlin has the following G-codes:
5.1 M500: store parameters in EEPROM
5.2 M501: read parameters from EEPROM
5.3 M502: revert to the default "factory settings."
5.4 M503: Print settings

If we replace the words EEPROM with FLASH, then we could at least have persistent settings. I wouldn't use M-codes, I' just talking about the concept.

Anyways, I figured I'd throw it out as an idea. If there is traction, I'd be happy to work on it (I'm a total noob to the TinyG code base, but an experienced embedded programmer otherwise).

Or maybe the right solution is just to add an external EEPROM. What are the plans for the v9? I haven't seen much information published about it yet (maybe I'm not looking in the right places?)

Spindle Speed Control Alternative

If I could figure out how to label this an enhancement, I would

From what I see in low cost PWM drivers for spindle motors, an analog voltage (normally POT) control is almost always supported, PWM signal sometime but not always.

An nice enhancement would be for the Spindle speed (now known as Spindle PWM) to be either PWM or a D/A converted analog output. Range would be up to the user to implement .

Compiling working code?

Do any of the branches produce code that works? I can compile all the branches except master and edge correctly (using mint 16 linux), but the binaries they produce all have the same problem, which is that the stepper motors then run in little random lumps, as if there was something else taking most of the processing power.

The edge and master branches don't compile, the makefiles appear to be badly broken. With some fiddling around I managed to produce a hybrid of the alden branch and the master branch, a horribly ugly thing to do, which involved moving the 'platform' and 'motate' directories from alden to master, along with the makefile and also editing the hardware.h file slightly. It builds, then produced exactly the same result, ie little random lumps of stepping.

I'd like to find the working source to whatever produced the http://synthetos.github.io/g2/binaries/TinyG2_Due_rob_usbtest.bin binary, which does at least work except for the homing switch issue, so I could hard code my machine settings into it.

Build with -Werror

We should enable -Werror option and fail on any linker or compiler warning. This way, the issues like #11 won't happen or at least they would be very visible.

Right now, there's three kinds of warnings:

1. Unused variable. The code should be fixed.
2. Inline instruction ineffective. It's fine to ignore these warnings.
3. Linker complains about three undefined symbols: SMC_Handler, USART3_Handler, EMAC_Handler. This should be fixed.

Makefile: support parallel build (-j)

Currently, make with -j option will produce incorrect results.

Let's compare:

$ make clean
$ make
...
$ ls -l ./bin/gShield/gShield_flash.bin
-rwxr-xr-x 1 krasin krasin 117704 Jun 14 22:14 ./bin/gShield/gShield_flash.bin

And now with -j4:

$ make clean
$ make -j4
...
$ ls -l ./bin/gShield/gShield_flash.bin
-rwxr-xr-x 1 krasin krasin 30608 Jun 14 22:15 ./bin/gShield/gShield_flash.bin

In fact, with -j4, the size is different with each invocation!

-rwxr-xr-x 1 krasin krasin 12816 Jun 14 22:16 ./bin/gShield/gShield_flash.bin

This issue is to fix a race condition in the Makefile. My semi-blind guess is that some targets incorrectly list dependencies.

Homing backs off longer than expected?

System appears to back off for a really long time when running the homing cycle:

xlb = 5
xzb = 1
xsv = 60
xlv = 100

https://www.youtube.com/watch?v=AFiD36STgvA

Persistence Functions

This issue is for discussion of persistence functions documented here:
https://github.com/synthetos/g2/wiki/Persistence-Functions