BUG on RepRap firmware V. 20100628

There is a BUG on firmware that make long pauses while printing, if we use Hop on Skeinforge. I took a few days to try understand the RepRap firmware and debug the problem... in the end I couldn't resolve it but I found that Hop functionality does this bug happen.

The interrupt code where the DEBUG LED blinks, were just giving a blink every few seconds (I verified with oscilloscope):

// Our interrupt function
ISR(TIMER1_COMPA_vect)
{
(...)

This interrupt code does the step signal for stepper drivers, and so it's frequency change accordantly the distance and velocity, on this piece of code:

// wait for next step.
// Use milli- or micro-seconds, as appropriate
// If the only thing that changed was f keep looping  
if(real_move)
{
    timestep = t_scale*current_steps.f;
    timestep = calculate_feedrate_delay((float) timestep);
    setTimer(timestep);
}

I made a test and did "setTimer(200);" and I got prints without pauses and always at same velocity (no acceleration).

For sure the problem is a bad "timestep" calculation... and I found that I got a big pause always on this piece of gcode:

11:11:06 Echo >>Echo: N1902 G1 X6.64 Y2.45 Z1.96 F720.0 *51
11:11:06 Send >>SendData: N1904 G1 X6.62 Y2.64 Z1.8 F801.882 *9
11:11:06 Echo >>Echo: command done
11:11:06 Echo >>Echo: N1903 G1 X6.65 Y2.63 Z1.85 F1433.813 *15
11:11:06 Send >>SendData: N1905 G1 F15000.0 *89
11:11:06 Echo >>Echo: command done
11:11:06 Echo >>Echo: N1904 G1 X6.62 Y2.64 Z1.8 F801.882 *9  <--- LONG PAUSE!!!
11:11:50 Send >>SendData: N1906 G1 E20.09 *86
11:11:50 Echo >>Echo: command done
11:11:50 Echo >>Echo: N1905 G1 F15000.0 *89
11:11:50 Send >>SendData: N1907 G1 F801.882 *84
11:11:51 Echo >>Echo: command done

I added another echo string at the end of command when it is executed, on that way I could know the time the firmware/AVR took to execute it -- it begins when it's does echo the gcode line and ends when echoes "command done".
As you can see, it took a pause of 44 seconds to execute the gcode "G1 X6.62 Y2.64 Z1.8 F801.882"!! And why?? If we see the line before, we can see that Z value have the maximum change:

11:11:06 Echo >>Echo: N1903 G1 X6.65 Y2.63 Z1.85  F1433.813 *15
11:11:06 Echo >>Echo: N1904 G1 X6.62 Y2.64 Z1.8   F801.882 *9  <--- LONG PAUSE!!! 
                               -0.03 +0.01 -0.05

There is a piece of firmware that find the dominant axis:

// find the dominant axis.
// NB we ignore the f values here, as it takes no time to take a step in time :-)

total_steps = max(delta_steps.x, delta_steps.y);
total_steps = max(total_steps, delta_steps.z);
total_steps = max(total_steps, delta_steps.e);

And the "total_steps" value is used on "timestep" calculation, that is used for setting the timer interrupt frequency!!! I am sure the problem is here, however I can't understand where.

This is the price to pay for using Arduino, which do not have an OpenSource and cheap debugger :-( -- on the other side, ARM have the OpenSource and cheap debugger!

Edited 4 time(s). Last edit at 07/02/2010 07:45AM by casainho.

---

---
New cutting edge RepRap electronics, ARM 32 bits @ 100MHz runs RepRap @ 725mm/s:

[www.3dprinting-r2c2.com]

At first glance, the issue is perhaps related to the fact that all 3 axes are changing at once. I think the usual layered approach to printing on a RepRap would never do that; we print one layer, then adjust Z, then print the next layer. A quick check on a sample complex gcode file (one created from tray-1.rfo by the reprap host code) shows no such G0 or G1 moves in X, Y and Z at once, at all, in over 865000 moves. In addition, all the Z movements present in the file are positive, moving up layer by layer.

The GCode you are using does not match that model. Why not? While there may indeed be a bug in the firmware, it could be one that is never triggered when the RepRap is instructed to move in the usual and expected way. As a practical matter, you might want to investigate what is causing your host software to generate such unusual Gcode.

---

---

Jonathan

That's why I want to go for a OpenSource and DIY fast ARM9 @ 454MHz and with JTAG debug, so I can at least see the variables values and find the problem.

---

---
New cutting edge RepRap electronics, ARM 32 bits @ 100MHz runs RepRap @ 725mm/s:

[www.3dprinting-r2c2.com]

Quote
jmarsden
As a practical matter, you might want to investigate what is causing your host software to generate such unusual Gcode.

Hmm. Moving all three axes at the same time is pretty standard with carthesian robots. Pointing the finger to the host software when the firmware fails might be a working short term solution, but doesn't solve the problem.

There's FiveD on Arduino, which was re-worked in big parts and should work on later boards as well. Does this firmware have the pausing bug as well? If not, could you send me a G-code sequence which doesn't?

Quote
casainho
That's why I want to go for a OpenSource and DIY fast ARM9 @ 454MHz and with JTAG debug, so I can at least see the variables values and find the problem.

Sure, go ahead. There's nobody stopping you from using more powerful controller hardware. As soon as you solution works, others will chime in.

However, I'm not sure wether a debugger helps debugging the stepping algorithms. These are mostly calculated at interrupt time, so you can't just stop the program to look at variables. Outside interrupt space printf-type debugging in combination with a serial terminal (minicom, GtkTerm, ...) works fairly well, so the pressure to get a "real" debugger isn't that big.

The only solution to find bugs in interrupt code I've found so far is to copy the code to a non-interrupt place and exercise it with a while() loop there. This often gives you many insights on where variables contain something different from what you'd expect. Recently, I've even fired up a spreadsheet to get a few insights on the algorithms used :-)

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Traumflug Wrote:
> However, I'm not sure wether a debugger helps
> debugging the stepping algorithms. These are
> mostly calculated at interrupt time, so you can't
> just stop the program to look at variables.

No, I can stop when I have that long pauses and see all the variable values (even inside interrupts)! I am sure at least one variable get's a wrong value (to big?). I can stop the program and get the value of all variables, that will let me understand where is the problem.

Being able to stop the program and see/change on all variables values is much more powerful than using printfs.

Here is one video I did recorded while debugging an ARM Cortex M3 LPC1768:



Edited 3 time(s). Last edit at 07/08/2010 07:22AM by casainho.

---

---
New cutting edge RepRap electronics, ARM 32 bits @ 100MHz runs RepRap @ 725mm/s:

[www.3dprinting-r2c2.com]

Quote

Here is one video I did recorded while debugging an ARM Cortex M3 LPC1768:

So, please go ahead and build that ARM based controller. Until you're done, I'll continue fixing problems on FiveD for Arduino.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Traumflug Wrote:
-------------------------------------------------------
> Here is one video I did recorded while debugging
> an ARM Cortex M3 LPC1768:
>
> So, please go ahead and build that ARM based
> controller. Until you're done, I'll continue
> fixing problems on FiveD for Arduino.

I am looking to commercialize that board, the main board + "shield" dedicated for RepRap Mendel. I think it's a need, as actual Arduino is slow to make the circles...

Even that board can be a bit more expensive and have SDRAM, on that way it can have Linux... let's see later what people will be able to do with it (for RepRap) :-)

---

---
New cutting edge RepRap electronics, ARM 32 bits @ 100MHz runs RepRap @ 725mm/s:

[www.3dprinting-r2c2.com]

Please be informed I'm not responsible if RepRappers continue to ATmega solutions when an ARM based solution arrives.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Traumflug Wrote:
-------------------------------------------------------
> Please be informed I'm not responsible if
> RepRappers continue to ATmega solutions when an
> ARM based solution arrives.

Ok, no prob. I believe that we need to sell a complete solution, and that means all boards tested and well documented. We will need to port the code (which is C and C++ I think) and we use the ARM GCC, so it should be relative easy.

I think community must/can have better solutions, like the RepSnapper which I prefer over official RepRap host software. Like your work also. If you sell boards with your firmware, more people would use it, even if it's not the official.

See Makerbot, they have their own boards, firmware and software, RepRap uses Makerbot boards. I think a company have much more power in getting the things in the hands of users. Well, I really like RepRap and I believe it can be better, at least in what I can help: board + firmware.

---

---
New cutting edge RepRap electronics, ARM 32 bits @ 100MHz runs RepRap @ 725mm/s:

[www.3dprinting-r2c2.com]

Quote

RepRap uses Makerbot boards

It's the other way around. MakerBot picked up RepRap electronics.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Traumflug Wrote:
-------------------------------------------------------
> RepRap uses Makerbot boards
>
> It's the other way around. MakerBot picked up
> RepRap electronics.

Right, but Makerbot can put (produce, sell and distribute) that boards on users hands, while RepRap don't. But RepRap put other important things...

---

---
New cutting edge RepRap electronics, ARM 32 bits @ 100MHz runs RepRap @ 725mm/s:

[www.3dprinting-r2c2.com]

Right, but Makerbot can put (produce, sell and distribute) that boards on users hands, while RepRap don't. But RepRap put other important things...

RepRap can and does. We sell the:
http://reprap.org/wiki/Generation_3_Electronics/Tech_Zone_Remix
which are the current version of the reprap generation 3 boards.

---

-Sebastien, RepRap.org library gnome.

---

Remember, you're all RepRap developers (once you've joined the super-secret developer mailing list), and the wiki, RepRap.org, [reprap.org] is for everyone and everything!

I tried to replicate this bug so far have not managed to do it. (Doing by sending the G-Codes manual). However as the printer is not fully working yet and I was just using the electronics I have set up at the moment there may be some testing issues

(Using the very latest release of the firmware from the SVN)

David

SebastienBailard Wrote:
-------------------------------------------------------
> Right, but Makerbot can put (produce, sell and
> distribute) that boards on users hands, while
> RepRap don't. But RepRap put other important
> things...
>
> RepRap can and does. We sell the:
> [reprap.org]
> ch_Zone_Remix
> which are the current version of the reprap
> generation 3 boards.

NO! The one that produce and sells that electronics is TechZone is short for Tech Zone Communications (llc)!! and not RepRap! -- it's clearly explained on that page.

---

---
New cutting edge RepRap electronics, ARM 32 bits @ 100MHz runs RepRap @ 725mm/s:

[www.3dprinting-r2c2.com]

I think the response came across badly, it was more any one can produce and sell electronics specifically for the Mendel based on the electronics design found on the reprap pages. They don't need to use the electronics specifically from Makerbot. As it stands I don't believe that the core RepRap project sells anything itself these days.