Home › Forums › TinyG › TinyG Support › Changing settings on G2/due
- This topic has 7 replies, 2 voices, and was last updated 8 years, 9 months ago by troisieme_type.
-
AuthorPosts
-
March 8, 2016 at 4:19 am #9413troisieme_typeMember
Hello,
New day, new problem to solve!
I can’t succeed in changing settings of my G2/due board. I’ve created a settings_laserK40.h file by duplicating the setting_default.h. Then I’ve tried to include this file in settings.h, but if I understand well the behavior of this include, it only includes the file if it is not set by the makefile.
So I’ve tried to change the makefile on line 60 (is “?=” a conditional assignment?), and on line 73 to 79, commenting the “settings_shapeoko2.h” line, and adding a line for my settings file.
Once the build done and the bin sent to the board, the setting are the same than before.
I’ve also tried to build the files by usingmake -B
to force the compiler to re-evaluate all files, but no difference.
Last, I’ve tried to usemake PLATFORM=gShield SETTINGS_FILE=settings_laserK40.h
, but it doesn’t work neither…There is probably something I don’t get, but I can’t see what.
Also, a question that is not linked with that problem: forgetting to change the plug the USB was plugged on, I’ve flashed the board using the native usb. It seems it works well, but above all, it’s maybe ten times faster than with the program port! What is the reason to use the other one instead?
Thank you for your answers!
March 8, 2016 at 6:39 am #9414cmcgrath5035ModeratorI have not done any G2 builds in a while, but will say you should not have to muck with the makefile. Stay away (treat as RO) from makefiles unless you are a make_guru.
Your third try form, with SETTINGS_FILE= , should do the trick.Did you ‘make clean’ first?
IIRC, make will place your binaries (.bin and .elf) in the …/src/github.com/synthetos/g2/TinyG2/bin/gshield/ directory.
If that directory already exists, a new bin will not be built, even if all the .o files do build.
My personal method is to rename the directory there with something like gshield_mybuildxxx/. If it flashed OK, I would determine what build it was (the $fb parameter) and reedit the directory name to add that. Otherwise, you have no way to know what version you have except to run it.Give that a try.
Yes, once tinyG2’s bootloader is installed, the native port will reflash as well..
I believe the process using the programming port is there for first time programming of tinyG2 into DUE. The programming port is implemented with a small microcoded device that emulates a USB port but has a hard coded boot interface to support the generic Arduino sketch loading process.
Footnote: Be sure to watch the build process for errors. G2 frequently makes changes or adds parameters as newer versions are created. I got burned by simply copying my_settings.h from an old version to the new settings directory in the new version tree. Make displayed a number of errors, streaming quickly across the console, when my_settings.h did not supply some expected (and required) new parameters. I use ‘diff’ to compare settings files.
March 8, 2016 at 10:47 am #9415troisieme_typeMemberHi,
Your answers have helped a lot! After suppressing the gShield bin folder it was ok. And I’ve been able to send new settings to the board. And your advice to carefully select the setting file used to create the new one was important too: till today I used the settings_defaults.h file, that have too lines missing (MANUAL_FEEDRATE_* defines), generating an error when compiling config_app.cpp… So I’ve used settings_hapeoko2.h instead, since it’s the one used in the makefile, that compile well.
My machine is now well tuned, i just need to setup the hardware that’s left.
I’ve got a question about homing: on my machine there’s just one swith per axe. On X it’s Xmin, on Y it’s Ymax. I’ve set it well in the setting file, and also set the DI*_MODE, DI*_ACTION, DI*_FUNCTION, even if I don’t know if they are used on the due, or only on the v9 board.
But, when homing Y, I end with an axe that go from -225 to 0. Is there a way to do that make it be 0-225 instead? I would like that Ymin equals $ytn and Ymax equals $ytm. Maybe this question is or should be an issue in github?March 8, 2016 at 11:08 pm #9417cmcgrath5035ModeratorYou are running G2, so a good place to raise such isues as you have would be here:
Read thru a few of the items there to get a feel for how the list works.
Not much experience here in you area of need – my impression has been that current homing processes are fairly hard wired to Xmin, Ymin and Zmax and not easily modified.
March 9, 2016 at 3:11 am #9418troisieme_typeMemberOk, that’s what I thought. On my router run by TinyG, the Z axis as the same behavior: as you said, it’s homed on Zmax, and then set to zero. But it’s not a big issue as it’s rehomed at each new job to be at zero on the part top face.
I suppose the right solution here is to set a coordinate system (like G56) with a negative offset for that axe, and choose it once the machine has been homed.
I’m going to look at it in the G2 issues on github.Thank you!
March 15, 2016 at 7:03 am #9429troisieme_typeMemberHello,
I don’t realy have an answer for the “problem” of homing, but I have a nice solution: instead of homing by calling
G28.2 X0 Y0
, I simply home with this G-code file:G28.2 X0 Y0 G0 Y-225 G28.3 Y0
And it’s ok. 😉
March 16, 2016 at 12:17 pm #9439cmcgrath5035ModeratorIf it works, it works.
Be Careful when upgrading FW, if it is actually a bug, it may get fixed and this workaround may then break somethingMarch 17, 2016 at 6:14 am #9442troisieme_typeMemberYou’re right, I’ll have to pay attention to it. For now it’s ok, but I’ll be careful when upgrading.
-
AuthorPosts
- You must be logged in to reply to this topic.