[Issue#165] Predefined Position commands fail.

#1 – cheton 于 2017-06-10

May I know what TinyG (or g2core) firmware version you are currently using? Below are my test steps running g2core firmware build 100.19 / firmware version 0.99.

!image

#### Steps
1. Go to X10 Y10 in G21 (mm) mode and set predefined position 1 (G28.1).
2. Go to an arbitrary position.
3. Go to predefined position 1 (G28), it shows X 10.000mm and Y 10.000mm.
!image
4. Change to inch mode and run a G-code file in inch mode as well.
5. Go to any arbitrary position.
6. Go predefined position 1 (G28), it shows X 0.3937 in and Y 0.3940 in.
!image

#2 – tomauga 于 2017-06-10

TinyG:
[fb] firmware build 440.20
[fv] firmware version 0.97
[hp] hardware platform 1.00
[hv] hardware version 8.00

#3 – tomauga 于 2017-06-11

I just reconfirmed this and figured out whats happening.

Cycled power on Tiny and restarted CNCJS.

1) Machine/work at 0,0,0. Verified in mm mode.
!! Make sure you have at least 10″ of X+ travel available !!
2) Issue: G0 X10
3) Set Predefined Position 1
4) Issue $g28 to see what the G28.1 is set to:
> $g28
[g28x] g28 x position 10.000 mm
5) Goto Predefined Position 1 – Moves X+ 10″
6) Issue $28 to see what the G28.1 is set to:
> $g28
[g28x] g28 x position 10.000 in

After looking at this closer I believe this is a TinyG bug. Here’s why…When you switch between G20/G21, TinyG converts saved offsets from old to new units. Example:

> $g54
[g54x] g54 x offset 10.000 mm
> G20
> $g54
[g54x] g54 x offset 0.394 in

But it does not convert the G28 values:

> $g28
[g28x] g28 x position 10.000 in
> g21
> $g28
[g28x] g28 x position 10.000 mm

This explains what I was seeing. I started CNCJS and was in mm then set g28. Ran a file that was in inches, when it finished i was in inch mode, then went to g28.1 which was processed as inches not mm. I’ll head over to TinyG and report this.

For now, your fix to restore units after running a file (other post) should get around this issue for now. Its likely to be driving other people nuts though. For me just contributed to a lot of confusion…then again I’m easily confused.

#4 – SirGeekALot 于 2017-06-12

Uh oh. It looks like TinyG firmware development may have stopped entirely.

The most recent checkin to ANY branch looks stale:

master: Latest commit d785510 on Sep 14, 2015
master-449: Latest commit 07ac333 on Jul 17, 2016
edge-0.98: Latest commit 50c8c89 on Aug 26, 2015
edge-0.97: Latest commit c502418 on Oct 23, 2016

I’m starting to kick myself for picking the TinyG board for my OpenBuilds Ox CNC router.

#5 – dirtdiver9 于 2017-06-13

I wonder if they split it off:
https://github.com/synthetos/g2 <https://github.com/synthetos/g2>

I was thinking about a tinyg and appreciate you posting this. I am going to hold off till I can get some more information.

Thanks,
Patrick

> On Jun 12, 2017, at 5:25 PM, SirGeekALot wrote:
>
> Uh oh. It looks like TinyG firmware development may have stopped entirely.
>
> The most recent checkin to ANY branch looks stale:
>
> master: Latest commit d785510 on Sep 14, 2015
> master-449: Latest commit 07ac333 on Jul 17, 2016
> edge-0.98: Latest commit 50c8c89 on Aug 26, 2015
> edge-0.97: Latest commit c502418 on Oct 23, 2016
>
> I’m starting to kick myself for picking the TinyG board for my OpenBuilds Ox CNC router.
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub <https://github.com/cncjs/cncjs/issues/165#issuecomment-307951295>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANeXdSdo7S12JN6wff7X4-Sb7K_70Tx0ks5sDbq8gaJpZM4N1nBG>.
>

#6 – tomauga 于 2017-06-13

@SirGeekALot I wish I had seen all this when I bought my TinyG. Certainly speaks volumes.

@dirtdiver9 A note from Synthetos: “The original plan was to eventually retire the TinyG code base and run g2core on the Xmega hardware. But g2 core has evolved past the point that the 8-bit Xmega can run it. So we will continue support the v8 TinyG hardware and will be adding new features, but it will not run the g2core firmware. ” See: https://github.com/synthetos/g2/wiki/What-is-g2core

I will eventually move to a GRBL controller (thinking the xPRO v3 http://www.spark-concepts.com/cnc-xpro-controller-v3/). Based on the specs, the xPRO does what the TinyG will do from a hardware point of view. There appear to be far more g-code sender apps available for GRBL compliant controllers and GRBL is actively being developed/supported (https://github.com/grbl/grbl). I have not yet determined if all GRBL based controllers can be used in any GRBL sender. I did note that ESTLCAM now supports the vPRO which leads me to believe that he must have had to make some change to “support” it. So I dont know which sender app will support which GRBL controllers. Still learning.

There are many people successfully using the TinyG. I’ve learned that not many people use inch units which eliminates some issues. Also not many people use the GUI buttons for jogging & zeroing out workspace. Some use g-code to jog and zero your workspace and some use a probe which I have but have not yet tried.

At a minimum, if you go with the TinyG, I recommend you install limit switches and dont buy just 1 mill out of the gate. I have had numerous crashes and 1 broken bit as I’ve tried to navigate the TinyG quirks.

Hope this helps.

-Tom

#7 – SirGeekALot 于 2017-06-13

Uh on (again). It looks like the board I have (TinyG v8) is based on the Atmel ATmega 192, which is 8-bit and is likely the one they are referring to below:

“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 other words, technically it appears to be “supported” but not really; more like a “legacy” board that will only get high priority fixes, with “high priority” likely being a subjective assessment. That is to say, all the coding love is going to go into the new ARM based boards. TinyG v8? Not so much.

EDIT: Sorry, I didn’t see the previous comment from tomauga until after I posted this one. Pretty much the same conclusion though.

#8 – SirGeekALot 于 2017-06-13

@tomauga I just looked at the grbl project: https://github.com/grbl/grbl

Of note: “Grbl v1.1 has been released here! Notice: This site will be phased out and moved to the new one!”

The new site for v1.1 is here: https://github.com/gnea/grbl

Regarding the CNC xPro you linked to, its grbl compatibility is currently old:
“100% GRBL version 0.9j (& GRBL version 0.8c) compatible”

I don’t know if that means it will not be upgraded/upgradeable to support grbl v1.1, but beware getting caught with a deprecated board (like I did). I think I’m just going to stick with something modular that is more likely to stay supported.

Probably a nice cheap Arduino UNO and a CNC shield that supports grbl v1.1 (although I’m having a hard time searching for a shield that explicitly says it supports grbl v1.1, but perhaps that is just because they haven’t updated their page yet? I could be wrong, but I think the stepper driver shield is fairly ubiquitous and unlikely to require changes, since it is likely just a “dumb shield” and all the new stuff is really just logic/perf tweaks that reside in the UNO’s sketch (firmware).

Anyway…good luck!

#9 – tomauga 于 2017-06-13

@SirGeekALot I emailed Spark Concepts and asked if the xPRO V3 supports the latest GRBL (1.1). The “fast” response:

“Sure does. Latest boards ship with 1.1f preloaded. I believe version 1.1e had some bugs – just heads up.”

Tom

#10 – cheton 于 2017-06-14

Forgot telling you there is a workaround solution to change the units. You can create an event trigger with G-code: Stop event and G-code trigger selected, then you can specify G-code commands to be sent after finishing a job.

!image