i haven't been able to find where the hex files are for g2core.

i haven’t been able to find where the hex files are for g2core.
does anyone know where to find these or whether I can use arduino IDE to flash a Due with g2core?

I compiled the firmware from source. If you send me your settings.h file, I can make the bin for you.

literally no experience with g2core. do settings need to be pre-compiled rather than set at runtime?

I experienced that at least limit switches type has to be defined in the settings.h. Do you have NO or NC limit switches in your setup?

neither. no limit switches.

I am looking through the settings file now. I’m not sure what to add for the travel per revolution. Do you know what the units are? I assume that this is just an equation to convert from steps to mm

travel = (360/1.8) / (steps per mm/step multiple)

In this case I think it’s better to disable limit switches (except Zmin which is used for the probe) and compile.

I use Linux VM, get g2 source from github, edit settings.h and compile. If you want I can go online (Skype or Hangouts or WhatsApp) and explain details.

thanks - i think i can compile ok if the toolchain is there. i am now working through what the settings mean.

@Justin_Adie did you go Due + g2core? If so take note that probing doesn’t work, it hangs randomly and CP also adds an unneeded 2-3sec delay at each probe point, unneeded as in grbl doesn’t have it and works. I’ve raised an issue with the developers but got nowhere and gave up since it was eating too much time. If you want my modified grbl 0.9 buffer with no lookups here it is: https://pastebin.com/9AghLRXL

I was going to try a due with g2core as i realised that over the last four months i have spent perhaps ten times the amount of time fixing, debugging and enhancing the software than i ha e successfully using the tool. I just cannot afford that time in my life and i need to rationalise either to a working mill, 100% of the time or just go back to using fab houses and waiting a few weeks.

If the due is not going to work well for autolevelling then i will give up now. I don’t want another day thrown away.

This is the ‘official’ G2 release interface, but seems rather out of date
As suggested above, learn to build your own, here is the how-to

Thanks. No need to learn. I know how to build but didn’t have the tool chain. I tried and saw that it autodownloaded. So all fine.

A bit worrying that there has been so many months since the last stable release but that there are still significant flaws reported. Suggests of either major architectural issues hindering resolution or inadequate investment.

1 Like

@Justin_Adie besides lacking some really basic config options like what pin do we have the probe on, invert dir/step signals for drivers, etc g2core is a big mess partially due to the abstraction layer (motate) it should make things simpler and more portable but instead makes debugging a nightmare for a newbie to the project.
The probing code has some deadlocks (to make you feel at home coming from grbl buffer) and the probe pin sometimes gets locked as triggered when is not.

Also the Due is 3.3V and you need some level shifters for it to work with 5v drivers, txb0108 doesn’t cut it so I made my own 3.3v mosfet based and commanded the tb6560 ok, but probing doesn’t work, neither interfacing the optocoupler from the jp-382a (original parallel port controller) or directly wiring the probe to the due, tried different pull-up values and even caps to debounce.

After about two weeks of designing shields for the Due (which if it’s a clone has a reset bug by the way) I gave up, that’s when I talked to you about the grbl 1.1 buffer but had all sort of errors with it and resorted to adding those delays in the classic grbl buffer. At first I had them at 1ms but at 1400mm/sec I was still getting 1-2 hangs per project so I increased them to 2ms and I’ve been milling a few dozen boards since then without any hiccup. Just make sure you enable CP to buffer the max lines of gcode to the spjs, you get a start delay but otherwise you get jerky movement.

Best of luck whichever path you take. Mircea


I’m not seeing any problems with the grbl probing. Completed fine every time after i fixed a bug in the code (now also fixed in the tinyg workspace).

The latest runs i did used CP to do the board to gcode conversion and apply the autolevelling. And then export the gcode (export function now included in the gcode list widget in my workspace) and then use universal gcode sender to send the project. But i am getting lots of null pointer exceptions in ugs and the project hangs. Far further in than with CP (which would disconnect very rapidly) but still annoying. I may try with a nano tomorrow but i am not sure i have enough jumper wires to connect into the gshield.

I’m surprised that you need a level shifter with the gshield and a due. The driver chips should measure highs against the ttl voltage and there are no regulators on board. Or maybe you don’t use a gshield?

@Justin_Adie I use my jp-382a which is an opto isolated tb6560 driver board, it’s meant to be run via parallel port and Mach 3 but runs flawless driven directly by a Nano. Due to the optocouplers and the low Due sink current ability I went the mosfet route.

I have never ever had probing issues with grbl. My toolchain is Altiun Designer->Flatcam->CP->SPJS. I only had the annoying SPJS hangs with grbl 0.9j solved by my buffer pasted above. So if you need a machine working NOW that’s my solution.

I got excited by all the features in the tinyg workspace and tried to make myself one (too expensive to buy the original) via the Due and g2core but afterall I don’t really need all the fancy stuff, all I need is a reliable PCB router and I have one now, I just hope nobody kills the grbl CP workspace, as you can never trust these online services.

@Mircea_Russu ​ the whole cp code is open source. And none of it is server side. So if you are worried about longevity you can always take a snapshot of everything loaded and use it as you like.

I didnt recognise the reference in your earlier post to jp-382a. The gshield chips are 6euros each so not a very expensive option if you want to build your own tinyg. I got a due (genuine) for 10usd so again not expensive even if you were just harvesting components for the tinyg clone! And with the likes of elecrow and seeedstudio you can get boards made up for a dollar. I can’t even buy blanks at that price!

@Justin_Adie I didn’t want to use different drivers since I’m tired of all the fuss with my A4988 in my Prusa, DRV8825 in my laser, TMC2100 in my delta printer. I couldn’t find any drivers able to deliver 2-3A easily enough and I need one machine to “just work” and it does after replacing the spindle with a 60.000rpm water cooled one (400GBP including the VFD, cheap upgrades by the way). It seems I have developed some form of FTOBTCC syndrome (f**k the original buy the cheap clone).

struggling to programme the due if I am honest…

i am following the ./DuefromOSX script but it doesn’t like receiving .elf files (No such file or directory) and if I comment out the regex to prevent the string replacement (.elf -> .bin) I get a file operation exceeds flash size.

any thoughts on this?

Device found on cu.usbmodem411
Atmel SMART device 0x285e0a60 found
Erase flash
done in 0.033 seconds

file operation exceeds flash size

WARNING: You may need to hit the RESET button on the device at this point.

@Justin_Adie ​ Due has 2 ports. Use the programming one. Use stty to set it at 1200baud then 9600 baud then use bossac. I have the commands at home, now on the phone.

@Mircea_Russu - thanks! I am using the programming port, and using the script supplied by the authors.

the script sets the port to 1200. but then does not upgrade it to 9600bps. Is that a requirement? the upload command uses bossac of course.