I decided to go for it and compile 1.1 and flash the “Stepoko” controller. As background for folks Sparkfun sold a V3 unit with their own controller. Its stuck at V0.9 and they only sell the Carbide version these days.
I compiled using all the defaults and aside from a “Low Memory” warning on the upload the flash was successful. Jogging more or less works it seems to be in a mode where it does a bunch of tiny steps instead of one big movement for say 1 inch.
Goes downhill from there. Homing always fails and only moves in Z. Carbide motion V4 puts up a bunch of warnings (see attached). UGS also seems unhappy with what it sees coming back over the wire. I also attached the config/console output from UGS.
So Dr. Will – what were those compile settings that you guys used when you build V1.1 for the native controller???!
The compile settings should be defined in comments in the header files — my understanding is it’s just a matter of editing them to comment out the defaults and uncomment the Carbide 3D settings.
May I ask why you compiled GRBL yourself? I managed to upgrade my Stepoko board to 1.1 using the Carbide 3D provided GRBL 1.1 image and the Upgrade tool. I described my upgrade here: Upgrading a Sparkfun SO3 to GRBL 1.1
I thought about trying the updater, but its a little unclear from your write-up whether you ended up with a working V1.1 system. The update failed but after standard configuration you concluded that it is working(?)
The real answer to your question though is that I use the Arduino IDE quite a bit so I naturally gravitated to that method. I successfully restored 0.9 years ago using the IDE when I buggered the Stepoko.
@johnelle Update your grbl settings and I think you’ll be ok. The upgrade resets them to generic defaults unless you changed that compile time.
EDIT:
Alternatively, in config.h change DEFAULTS_GENERIC to DEFAULTS_SHAPEOKO_3
See my edit above…
I do think C3D had their own, modified slice though. I believe parking is enabled in theirs, but it’s not a default. I just run grbl and edit the config options and cpu_map to suit what I want.
The updater does “work” on the Stepoko although not as described. It charges ahead without any switch presses, does two firmware update passes and then disappears from the screen without any notice. The resulting flash seems to satisfy both Motion and UGS. This last time it appears that it left my configuration alone (which is good).
Still can’t get the compile option to totally work. I set the defaults as mentioned in this thread and the result is better than before but Motion keeps complaining GRBL ERROR: Unsupported or Invalid g-code command found in block No specifics (log file somewhere?). I don’t see any config issues. On UGS I don’t get the same errors. I would prefer this method but not at the expense of a working system.
One final question. After all this I still have one question. Things are “working” but I can’t get the system to behave exactly as before. When I jog it takes these tiny little steps no matter what I specify for the increment. So if say I want it to go an inch left, it takes a bunch of tiny steps to the left instead of jumping to the left as it used to. Is this a config option that I missed? I see Motion has a bunch more jog settings than UGS nightly. What do I need to set in the client and/or configuration?
I have attached the config, but after fiddling around a little I think its just that there are more control(s) with jogging in V1.1. I noticed a new field called “Feed Rate.” If I set feed rate=100 and XY Step Size=1 it behaves in familar ways. I have to set Z Step =0.01 to do the manual zeroing (I prefer manual as mentioned earlier).