How fast can a Gen 3 Electronics Print?

What's the fasted feed rate that the Gen 3 electronics can support? And what limits it?

By entering G-code into repsnapper and using a stopwatch, I found that I can't move my x and y faster than about 52 mm/s and at about 1.4 mm/s regardless on how high a feed rate I enter. I checked the firmware and found a limit in the configuration.h file of 3000 mm/s for x and y and 50 mm/s for z. I doubled them and reloaded the firmware and it had no effect.

Can this be changed? Is it a good idea?

Thanks.

Are you using acceleration? Acceleration rates will slow down the average speed because it ramps up .

here are some possible suggestions.

change digitalWrites to fastDigitalWrites. If looking for the best of the best for speed try the teacup firmware. I think that is the old 5d on arduino firmware.


What is your divisor speed set at for your stepper driver 1/8 1/2? lowering divisor would speed things up a bit.


you could also disable acceleration in firmware. that would make your speed at full from start.


would i recommend any of the above, i don't know. how much faster do you need?

also measuring lines is only part of the equation. Speed of communication and amount of data that can be sent relates to speed as well.

I do have acceleration off. I have the Pololu set for 1/16 steps and this might be too much for the processor to handle above 52 mm/s. I also noticed that the extruder motor doesn't retract as fast as I used to get with the old controller (1/2 step) until I set the Pololu to 1/4 step. I might have to back them down to 1/8 for the x and y axis to speed it up.

As you pointed out, communication is another problem. At 50 or 60 mm/s, large circles (r=25 mm) doesn't come out right. The movement is not smooth and there's a lot of stops and starts such that the filament breaks into short segments. I'm guessing that the motherboard is not getting the G-codes fast enough so it has to stop and wait. So it seems that with this firmware/motherboard combination, I can only go up to 40 mm/s. And with that speed, there's a lot of vibrations when doing circles.

Edited 1 time(s). Last edit at 03/22/2011 11:47PM by brnrd.

To send g-code much faster you really have to read off of an SD card.

---

Help improve the RepRap wiki! Just click "Edit" in the top-right corner of the page and start typing. Anyone can edit the wiki!

If you use repsnapper you could increase your send queue and allow more commands in transit, or you could follow a few steps. If using skein forge disable absolute positioning. This allows smaller numbers and less byte data to send your positioning. But you will need to test it, and if there is an error it will cause your entire print to fail. So be sure to have a firmware that has check-sum or use sd card


Another thing is to disable fillet settings, or set to arc settings. This allows your rounded corners to be simple, or to be done by a single arc gcode. Then also turn off ooze bane if you do not need it. That adds a lot of steps.

If you want the voodoo magic kick ass method:::: Dare I say it, setup your system to use emc2. You’ll be in love... but you'll want to 'keep it secret'. emc2 allows over 500mm/s at 16x divisor. it uses the awful parallel port and a power hungry 700mhz 2g ram computer though..... that will set you back at least a 100$

Here is another possibility.
[forums.reprap.org]

IMHO of course.

Edited 4 time(s). Last edit at 03/23/2011 06:44AM by jamesdanielv.

The limiting factor here is the firmware sending step pulses. The official firmware uses floating point in interrupt context which limits the step pulse rate. With alternatives firmware like Teacup you get more step pulses but Teacup is still in an alpha/beta stage.

With 1/16 stepping and 52mm/s results in around 4000 steps/second, which looks about right for the limit of the official firmware. With Teacup firmware I was able to get over 10000steps/second (I'm not sure about the upper limit, it might be quite a bit higher).

Hi Brnrd,

Your question reads much like an information request we got on our website last night.

We use generation 3 electronics on all of our Mendel's. According to Skeinforge the machine below is running at 72mm/s, 54mm/s broaders with a travel speed of 120mm/s.



If you want you could try using a stop watch on the video

Mike

Mike,

OK. You caught me.

How are you able to run so much faster than me? I have a Techzone remix motherboard. I thought this is equivalent to the gen 3 electronics just in a smaller package.

Is it the firmware? I use reprap host 20100719 that I modified to support Techzone thermocouple AD so that I can control a heated bed also.

Is it the PC/host? I'm running on a Mac OS and sending the g-codes from SF 040 with repsnapper. But I timed the axis speed by manually sending commands using repsnapper so this should not be an issue. But it might be while printing.

Are you using 1/16 steps on the X and Y? That's what I have. I also have the extruder on 1/4 steps.

My measurements indicate a limit of 52mm/s but you're obviously going faster and you're getting it while printing. When I try to print at that feed rate, I get a lot of checksum error presumable because the Sanguino is too busy and it's not always able to respond to commands from the computer. Even at 40 mm/s, the Mendel can't get the g-code fast enough when going around small (around 10 mm) circles and vibrates as it pauses after each segment.

BTW, I've found that my X, Y and extruder motors are running a lot cooler with microstepping.

Hi brnrd,

Ok, that's a lot of questions, let's see how I can do.

"How are you able to run so much faster than me? I have a Techzone remix motherboard. I thought this is equivalent to the gen 3 electronics just in a smaller package."

Actually, we use a techzone remix MB on one of our machines here with pololu steppers. It's capable of the 72mm/s pace that the machine in the video was running, but currently runs our thick fill prints, so it runs at 66mm/s. So, theoretically, your techzone MB should be capable of the same.

"Is it the firmware? I use reprap host 20100719 that I modified to support Techzone thermocouple AD so that I can control a heated bed also.

Is it the PC/host? I'm running on a Mac OS and sending the g-codes from SF 040 with repsnapper. But I timed the axis speed by manually sending commands using repsnapper so this should not be an issue. But it might be while printing"

We are currently using the firmware from 20100930 that we got from the nightly build server. But we were using the 20100719 firmware that you have up until we switched. So I doubt that the firmware is your issue. We have run on ubuntu, win xp, win vista, and win 7, 32 and 64 bit versions (most of our machines are win 7 64 bit right now). We also use SF 039 and the reprap host software. We don't have much experience with repsnapper, so perhaps there is something there, I'd try looking at the full debug of your communications to see if there are any idicators in there.


"Are you using 1/16 steps on the X and Y? That's what I have. I also have the extruder on 1/4 steps. "

Yup and ditto

"My measurements indicate a limit of 52mm/s but you're obviously going faster and you're getting it while printing. When I try to print at that feed rate, I get a lot of checksum error presumable because the Sanguino is too busy and it's not always able to respond to commands from the computer. Even at 40 mm/s, the Mendel can't get the g-code fast enough when going around small (around 10 mm) circles and vibrates as it pauses after each segment. "

This is probably the crux of your issue, and it's 2 fold. Number 1, the 20100719 firmware uses a default baud rate of 19200. We found that things run much smoother running at 57600 believe it or not. Number 2, make sure that your circles aren't circles. A good general rule of thumb that we use here is that any circle should be drawn as a polygon with with an outer diameter of (desired diameter + 0.4mm) and with a side count equaling no more than (desired diameter*2 + 2) sides. Therefore, if we want a 4mm diameter hole, the model will sport a 4.4mm diameter 10 sided polygon. The reason being, when your solid is converted to an stl, the converting program reduces the circles to polygons with many many sides, depending on the program, it can be hundreds of sides. This causes so many calculations in such a small space that your sanguino will want to shoot itself in the face, but lacking a gun, will settle for barfing checksums all over your interface.

Jeremy

Thanks for the detailed response! This one, along with everyone else's input helps a lot.

This afternoon, I actually tried increasing the baud rate in the firmware and I found that it improved things a lot at higher than 20 mm/s feed rate. I saw an improvement up to 57600 and complete failure at 115200. Then when I did more tests, the machine started freezing at random times. Usually, there were checksum errors just before it got stuck. I went back down to 19200 and the problem still remained. I've always been suspicious of the push down ribbon cable connectors that techzone suplied to connect the FTDI USB-serial adapter and the motherboard. I remember reading somewhere that it's a good idea to solder the them together after pushing the ribbon cable in. So, I did and I made sure that enough solder made it to where each wire made contact with the pin. When I tried again, the checksum errors were gone! But it was still slow when printing circles and it moved incrementally (not smooth). Then I changed the firmware to 57600 again. This not only sped up extruding the circles but it also made it smooth. For this test, I was only extruding at 20 mm/s. Tomorrow, I'll try going to higher speeds again after it finished printing a 120 mm tall piece that I desperately need.

I did change the Pololu settings as follows: x and y at 1/8 steps, z and extruder at 1/2 steps. It sounds like I should try going up to 1/16 again on the x and y and perhaps 1/4 on the extruder.

you will want the latest firmware to use for 57600baud, the older firmware had interrupt issues conflicting with the interrupt generated for the i/o of the serial, and the timer interrupt .Basically the serial data was becoming corrupt. there are some hacks out there, but the latest firmware seems stable at 57600. the latest firmware has traffic control over the interrupts.

the latest firmware can be found here [sourceforge.net]

After printing for about 9 hrs, it's still running and no errors have been reported by repsnapper. But the SF calculated a build time of less than 7 hrs. I don't know if this is a sign of a problem of just SF underestimating the build time. Perhaps the firmware issues are for releases earlier than the one I'm using?

The latest firmware is loaded with bugs in the Gen 3 code relating to extruder temperature control. Somehow, it includes extruder codes in the Gen 3 section although it's on a separate board and has a separate sketch. Following instructions from this forum, I debugged the code and the tried it a while back but it didn't work.

Do you have the Hop plugin activated?

I think he calculates this using X/Y speed instead of Z speed meaning your build times will always be longer than calculated when Hop is activated.

---

Bob Morrison
Wörth am Rhein, Germany
"Luke, use the source!"
BLOG - PHOTOS - Thingiverse

No. Hop is disabled. I didn't think it was a good idea since I was concerned about lag in the lead screws for the z.

I was able successfully printing for over 12 hours without any errors overnight. But there were some layers showing signs of not getting the commands fast enough and the extruder pausing between moves in some layers. So I ran a quick test by printing only the layers that showed the problem to see if I can reproduce it. I couldn't. The parts came out good without any smooth stepper motion. But while printing, the machine froze again. I got it unstuck by sending an M105 command.

So, it seems that jamesdanielv might be right about a bug in the firmware with serial communication. I tried running other firmwares (20100806 and the latest one) and I couldn't get either to talk to the reprap host or to repsnapper. Yes, I did set the right baud rate to match the firmware at 57600.

Does anyone have a firmware suggestion? Jereme suggested the 20100930 but I couldn't find it in the repository.

I'm back to using the reprap host to send g-codes to the printer. But to make it work, I had to set the baud rate back to 19200. I just started a print which will take about 12 hrs.

Edited 1 time(s). Last edit at 03/25/2011 07:26PM by brnrd.

According to reprap gcode site the following codes are implemented in the latest gcode firmware

G-Codes
G0 - Rapid Motion

Implemented - only supports X, Y, and Z axes.

G1 - Coordinated Motion

Implemented - only supports X, Y, and Z axes.

G2 - Arc - Clockwise

Implemented

G3 - Arc - Counter Clockwise

Implemented

G4 - Dwell

Implemented.


Have you tried to change fillet module settings to beveled corners as arc ? It will take less gcode around corners during parts of process. Also switch from absolute distant mode to Relative Distance. This will make less data sent for gcodes, especially short ones. Perhaps this will allow a 33% speed improvement. Not much, but it will help some. If possible up your queue send buffer in repsnapper. This will allow commands in transit, while waiting for acknowledge to be sent. This will help if the software pauses often. Buffer 3-4 commands to see how it works. Here is some old but helpful skienforge settings [wiki.bitsfrombytes.com]

as for faster speeds for long travels and for jogging speeds you may want to modify the code a little.
lower the delays between steps, and change digitalwrites to digitalwritefast [code.google.com]

I have fillet set to off. How do you tell SF to use G2 and G3 commands instead of G1 when drawing circles? Anyway, I have been able to compile and load the latest reprap firmware for Gen 3 but it doesn't work. So, this is not really an option for now.

As far as repsnapper, on the Mac with Leopard OS, I can't get to the options for the send and receive buffer since it's out of the window. I tried to compile the code myself but the dev tool from Apple.com only works on the latest OS. But I'm not sure if this will help since the problem seems to be the reprap motherboard not being fast enough. It gets worse the smaller I make the steps on the X and Y from 1/2 to 1/16. It also has comm errors during retract and restart when the extruder stepper is being run at a fast rate with small step size (<1/2).

I'll take a look at the delays between steps.

So far, the reprap host hasn't gotten stuck on a print yet after running overnight everyday since my last message. But I have to run at only 20 mm/s with 19200 baud. I saw it pause and start once and the log showed checksum error during that time so it probably still has problems.

BTW, with the Pololu, I've also noticed that I have to set the steps per mm to twice what I calculate in order for the extruded feed to come out right. Is there something special about how the firmware is sending pulses to the extruder stepper through the SDA/SCL lines?

Edited 1 time(s). Last edit at 03/29/2011 08:05AM by brnrd.

It looks like I can go as fast as 40 mm/s reliably at 1/16 steps on x and y and 1/2 steps on z and e with the reprap host (20100719 64-bit) sending g-code from Skeinforge 40 to the Mendel with my and modified firmware. 60 mm/s is too fast for this combination.

Looking at the firmware, I noticed that for a Gen 3 Mendel electronics, the loop still makes calls to manage the extruders (and bed) even though the motherboard doesn't support it. So I removed it with a conditional #if as follows:

Quote


void loop()
{
#if MOTHERBOARD != 2      // brnrd 20110330
  manageAllExtruders();
#endif
   get_and_do_command(); 
#if MOTHERBOARD == 2
   talker.tick();
#endif
}

It works. I haven't measured a speed difference yet, but it has to save some processing time. Also, the call does eventually read and write to io ports as far as I can tell.

Edited 1 time(s). Last edit at 03/30/2011 02:16PM by brnrd.

This is really disappointing. The Mendel got stuck 78 minutes into an 8 hr print job at 40 mm/s. The machine was fine. It looks like the host didn't get an acknowldegement from the machine that it received the last command. So it just sat there.

i know this is frustrating. have you looked at the repsnapper.xml file.


change ReceivingBufferSize="4" or ReceivingBufferSize="1" to test different speeds, if issues. faster baud rate may not be working with repsnapper because at 57600 the speed of data is greater. lower the receive buffer to 1 or 2, if at 19200 increase your receive buffer to test it out.


I think the file stores in the same directory as repsnapper.

if you are able to look at repsnapper menu, tab to print options. reduce distance used to read full speed.
maybe also disable acceleration settings.

if editing with xml file for repsnapper.


EnableAcceleration="1" enables acceleration
EnableAcceleration="0" disables acceleration

default
DistanceToReachFullSpeed="3.000000"

change to
DistanceToReachFullSpeed="0.800000"


the default settings for acceleration are 3mm to max speed, which may explain why your circles are so slow. IMHO, you will figure it out.

Thanks. But I gave up on using repsnapper to generate g-codes a while ago since it didn't produce good tool paths with the objects that have complicated features beyond straight and circular edges. I thought that those options would only affect g-codes that it generates itself except for the receive buffer which probably won't help since the problem seems to be with the firmware not responding to commands.

A few days ago, I stopped using repsnapper to send g-codes because of more frequent freeze after I started using microstepping. Using the reprap host was definitely more stable and it worked well at 20 mm/s. So I decided to try 40 mm/s. It was printing fine with smooth motion and no communication errors until it froze without any errors reported. So, today I tried 30 mm/s. This time something else started happening. The extruder controller seems to be turning off the heat to the extruder and the bed at random points in a couple of tries for 5 hr print. There were no error messages or commands to change temperature in the console log. I have never seen this happen before but Lambert from Techzone has mentioned to me earlier that they've experience it. After the first time, I changed the extruder firmware to use bang-bang control instead of PID on the extruder tip. But it happened again after that.

I'm not sure if this is because of the change I made above to the firmware so I just removed the #if statement so that it will now call manageAllExtruders(). I'll see if this fixes it. But I don't see why this would have affected the extruder controller since I didn't see anything in that call that does anything with the RS485.

Edited 1 time(s). Last edit at 03/31/2011 05:56AM by brnrd.

Limiting Z-Axis speed?...Does the printer freeze when moving the Z-Axis?

I set mine to 1mm/min...

No. Z axis is not an issue at all.

After freezing while printing with the reprap host at 40 mm/s with the steppers at 1/2 steps, I'm now convinced that the the communication issue is not specific to repsnapper or reprap host. It must be a flaw in the firmware as jamesdanielv wrote earlier. So, I'm now back to repsnapper since it, at least, allows for me to continue printing by hitting the "Kick" button or issuing an "M105" to read the temperature. I just have to watch the print regularly so that the blob that forms once it pauses doesn't get too big.

So I'm ready to move on to a different motherboard and I'm considering the RAMPS setup. But reading the RAMPS forum, I'm not so convinced that it would be more reliable than the Gen 3 electronics. Perhaps there's still firmware out there that will work reliably with either the Mac and reprap host, repsnapper or even send.py (skeinforge).

jamesdanielv mentions that the serial bug was fixed in later firmware releases but I couldn't find much information about this. Can anyone tell me in what version that was done?

can you share your firmware with us? maybe someone here can figure it out? thx

brnrd Wrote:
-------------------------------------------------------
> No. Z axis is not an issue at all.
>
> After freezing while printing with the reprap host
> at 40 mm/s with the steppers at 1/2 steps, I'm now
> convinced that the the communication issue is not
> specific to repsnapper or reprap host. It must be
> a flaw in the firmware as jamesdanielv wrote
> earlier. So, I'm now back to repsnapper since it,
> at least, allows for me to continue printing by
> hitting the "Kick" button or issuing an "M105" to
> read the temperature. I just have to watch the
> print regularly so that the blob that forms once
> it pauses doesn't get too big.
>
> So I'm ready to move on to a different motherboard
> and I'm considering the RAMPS setup. But reading
> the RAMPS forum, I'm not so convinced that it
> would be more reliable than the Gen 3 electronics.
> Perhaps there's still firmware out there that will
> work reliably with either the Mac and reprap host,
> repsnapper or even send.py (skeinforge).
>
> jamesdanielv mentions that the serial bug was
> fixed in later firmware releases but I couldn't
> find much information about this. Can anyone tell
> me in what version that was done?

Have you noticed where the print freezes?...If the Z-axis is set to fast this will happen at random intervalls. German forum was full of it. I also suffered from this.

It seems that the problem with the extruder controller was due to the ATX power supply that I thought had enough current on the two 12 V rails: 18 A on each. I had the extruder controller on one rail and the heated bed on the other. But it seems that it was well overrated since I can see a 0.2-0.3 V drop everytime the heated bed comes on. I've been using this configuration for a while but I think the new hot end using Adrian's resistor design takes more power than the previous one using nichrome wire. Yesterday, I connected the extruder controller on a separate 12 V adapter rated for 6 A and the problem has so far gone away.

I also haven't seen a communication freeze yet. When it did freeze before, it happened at any time. Not related to z moves at all. I don't see why z moves would cause the controller to freeze.

thanks this was helpful for me. I'm going to diligently check power supplies, lengths of wire and ground connections!

jamesdanielv Wrote:
-------------------------------------------------------
> can you share your firmware with us? maybe someone
> here can figure it out? thx

I posted my extruder firmware in this topic in the firmware forum. It supports the Techzone Thermocouple A-D board and a heated bed. Techzone's firmware didn't include support for a heated bed.

brnrd Wrote:
-------------------------------------------------------
> using nichrome wire. Yesterday, I connected the
> extruder controller on a separate 12 V adapter
> rated for 6 A and the problem has so far gone
> away.

I started a print last night and after 5 hrs, I noticed that nothing was coming out of the extruder. I was sending g-code using the reprap host and there were no error messages and the tool head was moving as expected. This time, the tip and the be was still hot and showed the right temperature when I quit the host and i looked in repsnapper. The pinch gear has dug into the feed. So, I would guess that at some point, the tip cooled down to the point that filament didn't move anymore and extruder dug into the feed. Then the tip warmed up again but it was too deep to move at that point.

Lambert from Techzone has told me that they have also observed this problem where the extruder seems to lose the setpoint while printing. Their solution is to set the temperature every once in a while during the print. They have a web based tool to generate g-code that does this. But, I'm not ready to accept this solution.

I'll check the supply line with a scope to take a closer look at what's happening. It might very well be a reprap firmware bug as Lambert suspects but it can also be hardware. Yes, I don have a ground wire between the MB and the extruder controller.

Anyway, I'm waiting for the RAMPS assembled kit to go back in stock at ultimachine. I have ordered the Arduino 2560 already. This gen 3 electronics seem fine for printing small parts but I need bigger parts that takes hours to print. And I think the printer can go faster than this electronics allows.

brnrd Wrote:
-------------------------------------------------------
> brnrd Wrote:
> --------------------------------------------------
> -----
>
> I started a print last night and after 5 hrs, I
> noticed that nothing was coming out of the
> extruder. I was sending g-code using the reprap
> host and there were no error messages and the tool
> head was moving as expected. This time, the tip
> and the be was still hot and showed the right
> temperature when I quit the host and i looked in
> repsnapper. The pinch gear has dug into the feed.
> So, I would guess that at some point, the tip
> cooled down to the point that filament didn't move
> anymore and extruder dug into the feed. Then the
> tip warmed up again but it was too deep to move at
> that point.
>

I found the cause of the tip temperature problem: One of the heater wire terminals screws in the extruder controller was loose. I guess at some point, I either loosened the screw or I forgot to tighten it. After tightening the terminal screw, I was able to print a set of parts that took 16 hrs successfully. I printed at 20 mm/s. So, getting back to the topic, I guess this is how fast I can currently go without running into communication issues at 1/2 step on all stepper motors.

brnrd I Also posted this in your firmware discussion.

this is a copy of your firmware, what i modified was the fast writes to replace digital writes and a step delay of 2 instead of 5 for pulse delay.

FiveD_GCode_Interpreter.zip

see if you can get it to work. if there are issues with steps let me know. I have not tried this as i don't have time tonight to switch firmware to sanguino, i just know it compiles ok. If it works, then it should allow a 40% increase in speed. all the time saving from i/o changes makes the stepping parts about 20 times faster, but you have math delay, and communication issues still.

there are some other things to try, including fixing the communication issue, math caching, and buffering serial send data.

let me know if this works. baud is still to be run at 19200.

James