1

Topic: alternative firmware Selfish

http://www.thingiverse.com/thing:32084


this new firmware  (jetty evolution) seem to be very good and better than marlin (dixit author) .. it work with Replicator 1, ThingOMatic and Cupcake.

Someone to make a solidoodle version ? wink

2 (edited by IanJohnson 2012-10-13 13:33:32)

Re: alternative firmware Selfish

The Jetty firmware was based on Marlin, with improvements to print quality at high speed.  With the current Solidoodle Marlin at github you can run the printer as fast as 250mm/s.  However the limitation is the extruder, and how fast it can push the plastic through.  If your print has large, simple shapes and not too many changes of direction you can get by with 100mm/s. 

Quality can begin to suffer however.  Due to the weight of the motor, at high speed it can overshoot a little at the places where it makes sharp changes of direction, like corners, or the ends of long lines.  This shows up as rounded corners and little blobs on the surface here and there.  With Slic3r, you can set the exterior perimeter to run at a slower speed, a higher speed for inner perimeters, and then a much higher speed for fill.

If the extruder is having a hard time maintaining the flow at high speed, remember that at .1mm layers, it only needs to extrude 1/3 of the plastic.  Keeping quality issues in mind, you can use high speeds to cut down the time of .1mm prints.

Keep in mind this is all with the updated Marlin from github - https://github.com/mlaws/solidoodle2-ma … /Marlin_v1

3

Re: alternative firmware Selfish

Had a quick look at the Sailfish firmware and it's MakerBot only.

4

Re: alternative firmware Selfish

Have you looked at the Repetier firmware? Any reason we might consider it over Marlin?

5

Re: alternative firmware Selfish

Just browsed the GitHub readme:

https://github.com/repetier/Repetier-Firmware

The interesting bits:

You may ask, why did I rewrite a functioning firmware. First, let me say, there
is nothing wrong with the original Sprinter software. After studying the code,
I know how much effort was put into it, to get it running on many different
platforms. At first I just wanted to test
a different communication protocol, which is more reliable and faster
compared to the ascii method. So I invented the Repetier-Protocol, which sends
values in binary format. This reduces the size of data to less then 50% and
no conversion from ascii to float/int is needed. An improved checksum method
should make mistakes nearly impossible.

Features

- RAMP acceleration support.
- Path planning for higher print speeds.
- Ooze prevention system for faster anti ooze then slicer can do,
- Trajectory smoothing for smoother lines.
- Nozzle pressure control for improved print quality with RAMPS.
- Fast - 30000 Hz and more stepper frequency is possible with a 16 MHz AVR.
- Multiple extruder supported (experimental).
- Standard ASCII and improved binary (Repetier protocol) communication.
- Autodetect the command protocol, so it will work with any host software.
- Continuous monitoring of one temperature.
- Important parameters are stored in EEPROM and can easily be modified without
  recompilation of the firmware.
- Stepper control is handeled in an interrupt routine, leaving time for
  filling caches for next move.
- PID control for extruder temperature.
- Interrupt based sending buffer (Arduino library normally waits for the
  recipient to receive written data)
- Small RAM memory print, resulting in large caches.
- Supports SD-cards.
- mm and inches can be used for G0/G1
- Works with Skeinforge 41, all unknown commands are ignored.
- Dry run : Execute yout GCode without using the extruder. This way you can
  test for non-extruder related failures without actually printing.

Some of the performance features like the oozing and smoothing sound promising. It would be nice to see a side by side of the printed results.

For me, the biggest trouble is that there is no support for Panelolu.

6

Re: alternative firmware Selfish

lawsy wrote:

Just browsed the GitHub readme:

https://github.com/repetier/Repetier-Firmware

The interesting bits:

You may ask, why did I rewrite a functioning firmware. First, let me say, there
is nothing wrong with the original Sprinter software. After studying the code,
I know how much effort was put into it, to get it running on many different
platforms. At first I just wanted to test
a different communication protocol, which is more reliable and faster
compared to the ascii method. So I invented the Repetier-Protocol, which sends
values in binary format. This reduces the size of data to less then 50% and
no conversion from ascii to float/int is needed. An improved checksum method
should make mistakes nearly impossible.

Features

- RAMP acceleration support.
- Path planning for higher print speeds.
- Ooze prevention system for faster anti ooze then slicer can do,
- Trajectory smoothing for smoother lines.
- Nozzle pressure control for improved print quality with RAMPS.
- Fast - 30000 Hz and more stepper frequency is possible with a 16 MHz AVR.
- Multiple extruder supported (experimental).
- Standard ASCII and improved binary (Repetier protocol) communication.
- Autodetect the command protocol, so it will work with any host software.
- Continuous monitoring of one temperature.
- Important parameters are stored in EEPROM and can easily be modified without
  recompilation of the firmware.
- Stepper control is handeled in an interrupt routine, leaving time for
  filling caches for next move.
- PID control for extruder temperature.
- Interrupt based sending buffer (Arduino library normally waits for the
  recipient to receive written data)
- Small RAM memory print, resulting in large caches.
- Supports SD-cards.
- mm and inches can be used for G0/G1
- Works with Skeinforge 41, all unknown commands are ignored.
- Dry run : Execute yout GCode without using the extruder. This way you can
  test for non-extruder related failures without actually printing.

Some of the performance features like the oozing and smoothing sound promising. It would be nice to see a side by side of the printed results.

For me, the biggest trouble is that there is no support for Panelolu.

We know a certain firmware coding hero who might implement it!

Former Solidoodle employee, no longer associated with the company.