Project: Teacup Firmware
Posted by Triffid_Hunter
|
Re: Project: FiveD on Arduino September 11, 2010 02:05AM |
Traumflug Wrote:
-------------------------------------------------------
> For example, each movement initially has to expect
> a full stop. There's no guarantee a follow-up
> movement will come in. So you have to rework
> already queued movements. How about movements
> already being processed?
We would have to set end speed and do some of the calculations in dda_start for this to work, or work on previous queue item in enqueue if the math is too big for dda_start. I don't think we can reasonably avoid a ramp down and back up on the first move and occasionally after that, but not doing it every time but still having it happen when appropriate will be awesome.
> Also, each blending unavoidably results in
> geometric errors[*]. How do you estimate
> geometrical error vs. ramp steepness vs. number of
> blended steps?
each move has a definite number of steps. I don't think we need to be precise with speed as long as positional accuracy is maintained. The steppers should handle small disjoints in speed between moves from the inevitably imperfect math. I wasn't foreseeing blending steps, rather simply finishing each move at the start speed of the next move.
> If anybody has seen an implementation, please tell
> me.
The dda code I wrote is a start- it uses the algorithm from that lovely article, but refactored to take a start and end speed and a number of moves and work out the appropriate loop variables. I'll see what I can do when I have some time for it.
I apologise if you felt I was dropping the responsibility for this feature on you, rather my intention was to get a discussion going about how to best do it so we get the best of all worlds regarding acceleration
emt Wrote:
---------------------------
> If any one has this working with a thermistor extruder and thermistor bed I would like to get hold of a copy. I would like to implement this on a mega. My Arduino programming knowledge is such that I should be able to make the required pin changes but not much more at this stage.
there's currently no code for thermistors but I do want to have it in there. I can probably shoehorn some of it from the official firmware and expand the start I've made on an analog input subsystem but you'll have to test it for me as I don't have any thermistors to play with. You could always get your hands dirty if you don't want to wait for me to get around to it
-----------------------------------------------
Wooden Mendel
Teacup Firmware
-------------------------------------------------------
> For example, each movement initially has to expect
> a full stop. There's no guarantee a follow-up
> movement will come in. So you have to rework
> already queued movements. How about movements
> already being processed?
We would have to set end speed and do some of the calculations in dda_start for this to work, or work on previous queue item in enqueue if the math is too big for dda_start. I don't think we can reasonably avoid a ramp down and back up on the first move and occasionally after that, but not doing it every time but still having it happen when appropriate will be awesome.
> Also, each blending unavoidably results in
> geometric errors[*]. How do you estimate
> geometrical error vs. ramp steepness vs. number of
> blended steps?
each move has a definite number of steps. I don't think we need to be precise with speed as long as positional accuracy is maintained. The steppers should handle small disjoints in speed between moves from the inevitably imperfect math. I wasn't foreseeing blending steps, rather simply finishing each move at the start speed of the next move.
> If anybody has seen an implementation, please tell
> me.
The dda code I wrote is a start- it uses the algorithm from that lovely article, but refactored to take a start and end speed and a number of moves and work out the appropriate loop variables. I'll see what I can do when I have some time for it.
I apologise if you felt I was dropping the responsibility for this feature on you, rather my intention was to get a discussion going about how to best do it so we get the best of all worlds regarding acceleration
emt Wrote:
---------------------------
> If any one has this working with a thermistor extruder and thermistor bed I would like to get hold of a copy. I would like to implement this on a mega. My Arduino programming knowledge is such that I should be able to make the required pin changes but not much more at this stage.
there's currently no code for thermistors but I do want to have it in there. I can probably shoehorn some of it from the official firmware and expand the start I've made on an analog input subsystem but you'll have to test it for me as I don't have any thermistors to play with. You could always get your hands dirty if you don't want to wait for me to get around to it
-----------------------------------------------
Wooden Mendel
Teacup Firmware
|
Re: Project: FiveD on Arduino September 11, 2010 01:13PM |
Jakepoz, great to hear that. My electronics is also "stock", but Generation 2, so no secondary board.
If you could merge this thermistor stuff over to the master branch, emt would probably hug you
If you could merge this thermistor stuff over to the master branch, emt would probably hug you
| Generation 7 Electronics | Teacup Firmware | RepRap DIY |
|
Re: Project: FiveD on Arduino September 11, 2010 09:48PM |
Traumflug Wrote:
-------------------------------------------------------
> After drawing even more bizarre figures on paper I
> think I get a clearer view on how this has to
> work:
>
> 1. Even with look ahead, ramping is done for the
> fast axis (the one with the most steps) only. No
> need to take other axes into account here.
>
> 2. While ramping, the bresenham deltas
> (dda->x_delta, dda->y_delta, ...) have to be
> adjusted gradually to match those expected by the
> next move.
>
> 3. The point where the "handshake" is, i.e. where
> calculations get handed over to the next move, is
> the average in terms of fast axis speed and
> deltas. This will offer best geometrical accuracy
> as well as solve the situation where the fast axis
> change between moves.
>
>
> Markus
I was thinking about this last night too- in order for hand-over ramping to work properly, we need to do trigonometry otherwise a move followed by a move in the opposite direction will cause the steppers to slam into reverse and probably skip steps, and while that's a worst case scenario even with a 90 degree turn we're asking one stepper to stop dead while the other goes from zero to full speed, totally missing the point of ramping.
SO, in order to do the smoothing I was envisaging, we need a separate accelerator for each motor while maintaining positional accuracy between them. Personally I think we can shelve that for the time being and work on expanding the number of electrical and mechanical configurations that this firmware supports. We'll leave it to the gcode generator to consolidate similar moves together.
Anyone following this have a mega, and enough knowhow to update arduino.h (and anything else that needs to change) to suit?
ps: I had a chance to play with your changes last night traumflug, the ramping is awesome, as is the xon/xoff flow control. I was able to cat afile.gcode > /dev/arduino and it didn't miss a beat! I also noticed that this firmware /still/ fits onto a '168 with debugging turned off! (although my arduino has been upgraded to a '328 due to a nasty incident involving the combination of a short circuit and the 5vsb and 12v lines of my psu)
I also had to patch the ftdi_sio driver in my kernel. as of 2.6.35 they've redone quite a lot of the driver and it now resets the arduino every time the port is opened regardless of hup setting. patch attached for those affected: ftdi_sio_dtr_hup_fix.patch
-----------------------------------------------
Wooden Mendel
Teacup Firmware
-------------------------------------------------------
> After drawing even more bizarre figures on paper I
> think I get a clearer view on how this has to
> work:
>
> 1. Even with look ahead, ramping is done for the
> fast axis (the one with the most steps) only. No
> need to take other axes into account here.
>
> 2. While ramping, the bresenham deltas
> (dda->x_delta, dda->y_delta, ...) have to be
> adjusted gradually to match those expected by the
> next move.
>
> 3. The point where the "handshake" is, i.e. where
> calculations get handed over to the next move, is
> the average in terms of fast axis speed and
> deltas. This will offer best geometrical accuracy
> as well as solve the situation where the fast axis
> change between moves.
>
>
> Markus
I was thinking about this last night too- in order for hand-over ramping to work properly, we need to do trigonometry otherwise a move followed by a move in the opposite direction will cause the steppers to slam into reverse and probably skip steps, and while that's a worst case scenario even with a 90 degree turn we're asking one stepper to stop dead while the other goes from zero to full speed, totally missing the point of ramping.
SO, in order to do the smoothing I was envisaging, we need a separate accelerator for each motor while maintaining positional accuracy between them. Personally I think we can shelve that for the time being and work on expanding the number of electrical and mechanical configurations that this firmware supports. We'll leave it to the gcode generator to consolidate similar moves together.
Anyone following this have a mega, and enough knowhow to update arduino.h (and anything else that needs to change) to suit?
ps: I had a chance to play with your changes last night traumflug, the ramping is awesome, as is the xon/xoff flow control. I was able to cat afile.gcode > /dev/arduino and it didn't miss a beat!
I also noticed that this firmware /still/ fits onto a '168 with debugging turned off! (although my arduino has been upgraded to a '328 due to a nasty incident involving the combination of a short circuit and the 5vsb and 12v lines of my psu)I also had to patch the ftdi_sio driver in my kernel. as of 2.6.35 they've redone quite a lot of the driver and it now resets the arduino every time the port is opened regardless of hup setting. patch attached for those affected: ftdi_sio_dtr_hup_fix.patch
-----------------------------------------------
Wooden Mendel
Teacup Firmware
|
Re: Project: FiveD on Arduino September 12, 2010 05:29AM |
Quote
I was able to cat afile.gcode > /dev/arduino and it didn't miss a beat!
That's what it's supposed to do
Quote
in order for hand-over ramping to work properly, we need to do trigonometry otherwise a move followed by a move in the opposite direction will cause the steppers to slam into reverse and probably skip steps, and while that's a worst case scenario even with a 90 degree turn we're asking one stepper to stop dead while the other goes from zero to full speed, totally missing the point of ramping.
SO, in order to do the smoothing I was envisaging, we need a separate accelerator for each motor while maintaining positional accuracy between them.
Yes, we should check acceleration for each axis individually. We should also check against maximum speed for each axis individually. Lots of details to do
This "fast axis"/bresenham stuff works within one octant, only. Everything crossing the border of an octant is, well, different.
Quote
Personally I think we can shelve that for the time being and work on expanding the number of electrical and mechanical configurations that this firmware supports.
As I don't have any of this hardware, I can't help much here. However, such developments should nicely go along in parallel.
| Generation 7 Electronics | Teacup Firmware | RepRap DIY |
|
Re: Project: FiveD on Arduino September 12, 2010 06:42PM |
I already pushed a simple check for speeds, only limits to MAX_Z if it's a z axis move and MAX_X otherwise so it ignores Y and E for the time being.
that article looks like a good read- maybe time for a branch to implement that algo in the dda. Would be excellent if it'll still fit on a '168
-----------------------------------------------
Wooden Mendel
Teacup Firmware
that article looks like a good read- maybe time for a branch to implement that algo in the dda. Would be excellent if it'll still fit on a '168
-----------------------------------------------
Wooden Mendel
Teacup Firmware
|
Re: Project: FiveD on Arduino September 14, 2010 06:04AM |
casainho Wrote:
-------------------------------------------------------
> I like your code, it's more easy to me to
> understand and hack.
thanks One of the reasons I wrote this was to understand and improve on the official firmware, and I tried to allow others to do the same without compromising the functionality- good to hear I had some success at this!
> What are the disadvantages of your code when
> compared with "official" one? does the print
> quality is worst or something?
only disadvantages I know of is that it's far less thoroughly tested, and doesn't yet support a diverse range of hardware configurations. I hear that some have done full prints with it, but no concrete posts about it yet.
If the print quality was worse, it wouldn't be following the gcode properly which would be a major bug! With properly tuned PID parameters on the heater it may even be better...
As for advantages, it's smaller, faster, apparently loses less data and is easier to read
I'm sure some of the other contributors have their own stories as to what they like and dislike about this alternative firmware, and why they're contributing what they are!
-----------------------------------------------
Wooden Mendel
Teacup Firmware
-------------------------------------------------------
> I like your code, it's more easy to me to
> understand and hack.
thanks
One of the reasons I wrote this was to understand and improve on the official firmware, and I tried to allow others to do the same without compromising the functionality- good to hear I had some success at this!> What are the disadvantages of your code when
> compared with "official" one? does the print
> quality is worst or something?
only disadvantages I know of is that it's far less thoroughly tested, and doesn't yet support a diverse range of hardware configurations. I hear that some have done full prints with it, but no concrete posts about it yet.
If the print quality was worse, it wouldn't be following the gcode properly which would be a major bug! With properly tuned PID parameters on the heater it may even be better...
As for advantages, it's smaller, faster, apparently loses less data and is easier to read
I'm sure some of the other contributors have their own stories as to what they like and dislike about this alternative firmware, and why they're contributing what they are!
-----------------------------------------------
Wooden Mendel
Teacup Firmware
|
Re: Project: FiveD on Arduino September 14, 2010 06:57AM |
and a third called ad595! (and who knows what else will turn up?)
excuse my descriptional laziness, hopefully the code will be better
-----------------------------------------------
Wooden Mendel
Teacup Firmware
excuse my descriptional laziness, hopefully the code will be better
-----------------------------------------------
Wooden Mendel
Teacup Firmware
|
Re: Project: FiveD on Arduino September 16, 2010 03:18AM |
casainho Wrote:
-------------------------------------------------------
> but mendel.c inclues:
>
> #include stddef.h
> #include stdint.h
> #include string.h
>
> I guess it's header files for a avr-libc, right?
they're generic headers that all C libraries provide, not specific to avr. The avr-specific ones look like #include <avr/blahblah.h> and they're used for architecture-specific things like interrupts and I/O handling.
> My problem is getting a working libc for ARM...
uclibc should work fine on ARM, or maybe klibc if uclibc is too big. No idea about doing I/O or accessing interrupts, you may have to write some of that yourself with datasheet in hand if you can't find it anywhere else.
> What is for the code on "copier.c" and "copier.h"
> files?
that's an idea I've been entertaining whereby the chip can program another similar chip without needing a PC.. just another step towards self-replication
> About PID values, is the RepRap Mendel
> software/firmware using a GCode to save that
> values on hardware/firmware? if not, what others
> softwares do it?
no idea about other firmwares, but this one uses M130-M133 to manipulate PID values and M134 saves them to eeprom. No support for multiple heaters yet, but that's currently being discussed since the heated bed has become so popular.
Traumflug Wrote:
-------------------------------------------------------
> What's "PID"?
PID without a PhD - a critical algorithm for getting fine temperature control
-----------------------------------------------
Wooden Mendel
Teacup Firmware
-------------------------------------------------------
> but mendel.c inclues:
>
> #include stddef.h
> #include stdint.h
> #include string.h
>
> I guess it's header files for a avr-libc, right?
they're generic headers that all C libraries provide, not specific to avr. The avr-specific ones look like #include <avr/blahblah.h> and they're used for architecture-specific things like interrupts and I/O handling.
> My problem is getting a working libc for ARM...
uclibc should work fine on ARM, or maybe klibc if uclibc is too big. No idea about doing I/O or accessing interrupts, you may have to write some of that yourself with datasheet in hand if you can't find it anywhere else.
> What is for the code on "copier.c" and "copier.h"
> files?
that's an idea I've been entertaining whereby the chip can program another similar chip without needing a PC.. just another step towards self-replication
> About PID values, is the RepRap Mendel
> software/firmware using a GCode to save that
> values on hardware/firmware? if not, what others
> softwares do it?
no idea about other firmwares, but this one uses M130-M133 to manipulate PID values and M134 saves them to eeprom. No support for multiple heaters yet, but that's currently being discussed since the heated bed has become so popular.
Traumflug Wrote:
-------------------------------------------------------
> What's "PID"?
PID without a PhD - a critical algorithm for getting fine temperature control
-----------------------------------------------
Wooden Mendel
Teacup Firmware
|
Re: Project: FiveD on Arduino September 16, 2010 03:40AM |
hey all, just pushed a new branch called "temporal_step" in response to this article. On first, second and third reading I simply didn't get what he was doing, so I wrote my own. The perl script is the main part at the moment, but I've had a go at plugging it into dda.c.
As usual, it's totally untested
I'm still baffled as to how to add acceleration/ramping to this algorithm without bucketloads of fancy math that we simply don't have space for, any help would be much appreciated!
At my best guess, we need to grab the timer value from the ramping algorithm and scale it by the result of this one, requiring at least a multiply and divide every step which would violate the design goals of this firmware. Surely there's a better way?
-----------------------------------------------
Wooden Mendel
Teacup Firmware
As usual, it's totally untested
I'm still baffled as to how to add acceleration/ramping to this algorithm without bucketloads of fancy math that we simply don't have space for, any help would be much appreciated!
At my best guess, we need to grab the timer value from the ramping algorithm and scale it by the result of this one, requiring at least a multiply and divide every step which would violate the design goals of this firmware. Surely there's a better way?
-----------------------------------------------
Wooden Mendel
Teacup Firmware
|
Re: Project: FiveD on Arduino September 16, 2010 08:09AM |
Quote
if (dda->x_steps)
dda->x_time_counter += dda->c;
if (dda->y_steps)
dda->y_time_counter += dda->c;
if (dda->z_steps)
dda->z_time_counter += dda->c;
if (dda->e_steps)
dda->e_time_counter += dda->c;
I think you should drop all the if()'s here. If you do a step on the X axis, time passes for the other axes as well ...
... which leads me to the reason why I think this is algorithm is difficult to implement: imagine a movement at an angle of near 45 degrees: X axis should do 1000 steps, Y axis should do 999 steps.
Now you set the timer to 1/1000 = 0.001tu (tu = time units) and do the step. So far so good.
Looking at the Y axis, the first step is to be done at 1/999 = 0.001001001001u. As time passes for all axes the same, you'll have just 0.000001tu available for firing the next timer event after doing the X step, and doing an Y step. Likely, you can't match such a tight timing requirement, and there are situations where it can become arbitrarily tighter.
One solution would be to get hold of four independent timers, one for each axis. Additionally you'd have to make sure each timer interrupt is handled regardless of wether they fire at almost the same time. Currently I don't see how this would work reliably on an AVR chip, but perhaps I'm missing something.
Regarding acceleration, you'd have to calculate the initial parameters for each axis individually and in a manner which leads to synchronized movements. That means, low acceleration for the slow axes and steep acceleration for the fastest axis.
Any loss in algorithmical or numerical accuracy will not only lead to time/speed errors like in our bresenham implementation, but also to geometrical errors.
Have fun
| Generation 7 Electronics | Teacup Firmware | RepRap DIY |
Sorry, only registered users may post in this forum.