synthetos / g2 Goto Github PK

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?

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

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.

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.

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?

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

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.

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.

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

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

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.

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.

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?

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

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.

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?

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?

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

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.

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.

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.

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?

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

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)

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?

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.

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

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.

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?

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.

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.

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.

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.

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.

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

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.

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.

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

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

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;

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 .

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

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.

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

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

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.

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 ==========

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?)