Teacup Auto Bed Leveling
Posted by bethebeer
|
Teacup Auto Bed Leveling June 26, 2012 11:03PM |
Registered: 12 years ago Posts: 25 |
Should have posted this here...
I am trying to add auto bed leveling to Teacup:
I first saw this on nophead's blog(hydraraptor), but, currently, there are several other people doing this.
I started to turn nophead's python code into C.
and
I talked to emaker(he is developing this in Marlin: github ) on the IRC and he explained to me that it is not done in the loop of G-code that is about to be used by the machine, but before that where time is not a constraint. I'm not really sure yet how the firmware buffers commands and such, so I may be describing it incorrectly. If G-code is stored on the printer before being fed into a loop that the machine uses, then g-code can be processed before it is sent to the loop, I'm not sure if this means that a certain amount of G-code must be processed first to fill up the loop. I also do not know if this is specific to Marlin.
I just finished making the methods that will enable input of 3 points(as arrays) and then fill in the variables of the equation that would transform the G-code onto the new plane. By the end of the day I will have learned how to code with strings and I will input fake Z-probe points and a G-code file to make sure it at least appears to be working. And right now I am just using doubles, but I will replace that with uint-type variables once I see it is working in order to be consistent with the "integers only" in Teacup. The only thing I can't figure out is how to tell the motors to move from within the firmware.
I would really like any help with using the firmware to move the motors or with understanding the way in which G-code is stored and processed in the firmware.
I am trying to add auto bed leveling to Teacup:
I first saw this on nophead's blog(hydraraptor), but, currently, there are several other people doing this.
I started to turn nophead's python code into C.
and
I talked to emaker(he is developing this in Marlin: github ) on the IRC and he explained to me that it is not done in the loop of G-code that is about to be used by the machine, but before that where time is not a constraint. I'm not really sure yet how the firmware buffers commands and such, so I may be describing it incorrectly. If G-code is stored on the printer before being fed into a loop that the machine uses, then g-code can be processed before it is sent to the loop, I'm not sure if this means that a certain amount of G-code must be processed first to fill up the loop. I also do not know if this is specific to Marlin.
I just finished making the methods that will enable input of 3 points(as arrays) and then fill in the variables of the equation that would transform the G-code onto the new plane. By the end of the day I will have learned how to code with strings and I will input fake Z-probe points and a G-code file to make sure it at least appears to be working. And right now I am just using doubles, but I will replace that with uint-type variables once I see it is working in order to be consistent with the "integers only" in Teacup. The only thing I can't figure out is how to tell the motors to move from within the firmware.
I would really like any help with using the firmware to move the motors or with understanding the way in which G-code is stored and processed in the firmware.
|
Re: Teacup Auto Bed Leveling June 27, 2012 05:51AM |
Registered: 13 years ago Posts: 7,616 |
Likely it's almost the same in Marlin and Teacup: there's a movement queue. On one side of the queue new movements are added as they come in over the serial line or from the SD card, on the other side the movements are removed after being executed.
The executing side of the queue has to be realtime, as it creates all the step signals making the motors move. The filling side side has more relaxed time constraints. If the queue fills up faster than it can be executed, filling is simply stopped until there is new room. If the filling can't be done as fast as the executing side happens to execute and remove movements, the queue becomes empty. Every piece of software working on the queue has to play nice with both situations.
The filling of the queue is done in enqueue() in dda_queue.c. Pretty simple algorithm, but quite a few measurements to make it reliable even in odd situations (example: what happens if a movement is about to be added, but the CPU interrupts this for removing a movement on the other end in the middle of doing so?)
enqueue() is called by the stuff gcode_process.c. What you likely want is to add your adjusting maths somewhere early in process_gcode_command() or somewhere just before enqueue(). The most meaningful G1 command is handled in line 131ff in gcode_process.c.
The executing side of the queue has to be realtime, as it creates all the step signals making the motors move. The filling side side has more relaxed time constraints. If the queue fills up faster than it can be executed, filling is simply stopped until there is new room. If the filling can't be done as fast as the executing side happens to execute and remove movements, the queue becomes empty. Every piece of software working on the queue has to play nice with both situations.
The filling of the queue is done in enqueue() in dda_queue.c. Pretty simple algorithm, but quite a few measurements to make it reliable even in odd situations (example: what happens if a movement is about to be added, but the CPU interrupts this for removing a movement on the other end in the middle of doing so?)
enqueue() is called by the stuff gcode_process.c. What you likely want is to add your adjusting maths somewhere early in process_gcode_command() or somewhere just before enqueue(). The most meaningful G1 command is handled in line 131ff in gcode_process.c.
| Generation 7 Electronics | Teacup Firmware | RepRap DIY |
Sorry, only registered users may post in this forum.