So, excuse my ignorance, but doesn’t the current stock setup use GRBL? I ask this because I noticed in a post earlier today that in the connection information he captured, GRBL 1.0 is listed:
I think of it this way. Grbl is a firmware and a language. The Maslow firmware speaks grbl (sends gcode and settings in a grbl compliant format) but the Maslow firmware is different than the official grbl firmware because the grbl firmware doesnt have the code needed to work with Maslow (grbl code is based on corexy, not the triangular Maslow configuration)… Until @ldocull did this that is…
Thanks @madgrizzle.
If I am understanding, GC doesn’t have any acceleration management. This being true, what is the acceleration mechanism at work for the initial movement and stopping of the sled?
I don’t really know the answer, but perhaps this thread will help? I don’t think there is anything special that is managed at start and stops.
See this thread:
No, we aim to have the stock firmware support grbl senders, and to support grbl
in the future (once it’s modified the way this thread has done), but stock is
not running grbl.
Ground Control looks for GRBL 1.0, so it will not support GRBL 0.9 based stuff,
but if we port these changes over to GRBL 1.x we should be able to still use
Ground Control
David Lang
the firmware notices that the sled isn’t where it is supposed to be according to
the position and the PID loop ramps up the speed. It attemps to go from 0 to
$feedrate instantly and initially falls behind (thus the problems with the
‘cannot keep up’ message appearing)
David Lang
ok, good to know
Updated the Due-code to GRBL 1.1g. Tested and posted today.
If I understand things well enough, the current firmware uses Timer0 and Timer1… is there a particular reason more timers are needed for GRBL? Is it just because that’s how they wrote it or is there a technical reason it’s needed? Does each motor need its own timer?
I needed a timer for the position loop. GRBL needs timers for the path generation (that’s how they get accel/decel and control the speed though corners, etc.). The stock-Maslow solution is more of a velocity-loop type system, calculating a speed for each motor to the target and stopping when the target is reached.
The Due-version is a classic position loop system. GRBL generates steps at a pace all along the tool path, and Due-PID loop moves the motors to resolve those steps keeping the error as small as possible – like a horse following a carrot.
Timers are also required for communication management and PWM (motor speed and spindle control).
I am confused does this work with the tle5206 motor controllers? If not what would be needed to make it compatible?
It does not work just plugging the shield on-top.
I did not look at the pin settings for the Due yet and how ‘L298P-specific’ the firmware is, thinking of attempting a ‘in-between-board’ for the TLE-shield with the required logic converters, the additional capacitors, resistors, the eeprom and cross-wiring for the pins on the TLE.
Edit, if you build it i pre-order 6pc.
There’s differences in pin functionality between the two controllers. I believe the L298 uses one PWM pin and two other (digital) pins to control direction whereas the TLE uses just two pins (a the third pin is an error flag that doesn’t seem to be used in reality). So there’s code that needs to be added to detect the type of controller, some pin assignment changes that need to be added, how PWM speed and direction is set needs to be updated, and attach/detach of motors updated… But that’s really about the extent of it.
Thanks allot for the detailed info @madgrizzle
It does somehow bury my hope to test this soon, but i can focus on other stuff and wait Do you know if the FAKE_SERVER mode is kept, to at least play with the software side (bCNC, chilipeppr etc.)?
I doubt fakeservo is there, but I haven’t really looked. It’s grbl with new code / existing code from the maslow firmware, not the other way around. I’ve been busy working on other projects to really dive to deep in the code.
“Neither 3D printing or CNC woodworking are for the impatient.” - @theHipNerd
so the physical board and components can theoretically work with the TLE 5206, BUT the firmware/software needs to be updated is the current status?
I believe this was discussed further up the thread?
but that is mostly a matter of copying code from the maslow firmware. They have
compatible licenses.
David Lang
rather than making an in-between board, just make a new TLE shield with the logic converters/eeprom and the MOSFETs on it. Given that you would save the pins needed to interface with the TLE shield, It’s very possible that the price would be the same or lower than the ‘in-between board’