tach_redline experimental firmware coming shortly.

I don't know if we really need another wild firmware out there or not, but since this firmware is experimental, I don't want to tarnish tonokip/or sprinters name. The firmware that will be released is basically sprinter with a few tweaks. what i hope happens is these features make it into a sprinter branch. Some of features will be usefull, others may not.

This will be a released firmware based on sprinter and it will have the following features, and they may not work correctly at first, so this is the forum to comment on its features, and to correct the issues with the firmware.

Also this firmware is built on sprinter, and utilizes some fancy optimization tricks that may not settle well with some firmware programmers. It uses direct port manipulation, modifies Interrupts, and uses adc conversions in an interrupt context to free up resources. If anything else is needed it is better utilization time for the buffer to fill properly.

The next build beyond this will be based on bare bones multi task operating system and include sub sampling and other features that are too buggy for this release, and fit better in an event driven system.

I plan to release the code this weekend, but wanted to see what the community is prepared for in terms of features and in the understanding of what max performance means. I'm also going to request a testing standard for these high speed tests. It does no good to show a square box being drawn and a 45deg angle being done. Those are effortless and do not cause jittering, or stalling. This testing request will be posted in this topic, and the general top forum and basically be a outlined drawing with special shapes, and the printer speed will be the line distance/time of completion after completing 2 passes. a more satisfying benchmark if it is able to do 2 layers over eachother that line up.

The tach_redline firmware basically pushes the printer firmware into the red line zone like a car. So if settings are set too advanced, the machine will literally fall apart. So I will be releasing this firmware with conservative settings, and you will need to go in and play around with them. Testing versions I compiled with tonokip I shook all the bolts loose on my test printer (bfb rapman using now an for testing atmega, because the bfb loves abuse)


A few features that are of this firmware:

Capable of pushing >2000mm/s with 16x multiplier (not all the time mind you! and only with low gear ratios)
Adjustment for what distance to apply acceleration or not (set to something like 5mm, works great for circles)
safe_speed (runs like hell on certain angles, and slows down on others to prevent jittering)
Larger buffer (buffer needs work as I can not get it to store and fill more than 10 buffers at a time, although it includes 64 buffered moves)
Reverse e distance limit. This allows extruder reversals to be controlled and not go on forever, or crash firmware
Priming of e before moves, and pullback after moves (just 0- 20steps only)
adc instant reads reliant on interrupt for adc.


the firmware will be linked in this form by the latest Monday night July 4th, feel free to add comments before hand. also comment in this forum for bugs and issues you see.

edit: Monday night/Tue morning pacific standard time. 2 alpha releases are already posted here.

Edited 2 time(s). Last edit at 07/05/2011 03:24AM by jamesdanielv.

it would be nice if we had a torture test for printers so we know how they ran fast. here is an stl file that can be run with infill turned off. the speed of printer is mm distance travel/time completed. the test pasts if it successfully builds up the walls. with infill off nozzle size should not matter only perimeter distance. also thinner layers should not matter because it increases distance. the test also provides a reference of where the printer weaknesses are, and the limits to the firmware.

also as part of the spec, a fastest theoretical speed should be provided, that is fastest actual tested maximum pulsed per second on x or y axis, and fastest pulses per second with and x and y move. divide those numbers by the minimum stepper multiplier used to pass the stl test

here is a printer its specs according to the benchmark are:

printer speed: mm/s [unknown]
theoretical limits are: [unknown]
single axis speed: [unknown]
multi axis speed: [unknown]

this is torture test, and it includes 45,47 deg angles and 2 sizes of circles, and a large area for acceleration results. this test will provide a more reliable average speed for printers.


OK here is a genuine test for printers. this tests uneven angles , 45 deg angles, circles of various diameters, and allows range for acceleration.

it is 3mm high, so it does involve more than 2 passes. to run the test, turn off infill, and setup the max speed you have for your printer, time it until complete, and then divide it by the mm distance total travel.


if the printer passes the test then the speed value can be stated as the max speed of printer. if this object is successfully printed at that speed,. then it is considered a stable speed for printer. If a firmware is optimized to work for this stl it will be stable at the speed it ran. a printer passes the test if with infill turned off, it outlines the inside and outside of object, and produces the object to 3mm in height consistently. it is not important that it is perfectly aligned to pass this test, just that it builds up the walls completely.

here is stl file stl test file

i am posting this both in firmware section and general sections.

Edit: changes have been made to account for infill speed of short segments
details are in general form discussion [forums.reprap.org]
the hope is that people realize that max speed is not really a clue as to how well something runs, it is average speed and how well the acceleration works, and keeps positioning.

Edited 1 time(s). Last edit at 07/02/2011 08:22PM by jamesdanielv.

Any torture test needs a section of rapid short back and forth movements at different frequencies. Something like a 2 lines that are a few degrees from parallel, with solid infill between them. How a machine and firmware handles these types of very fast, short, repeated back and forth movements is important to good surface finish.

noted, so use infill then. or if what you want is 2mm infill lines then i can upload the image as a wider wall filed. infill is normally done at 45 degrees with both motors and max speed is 1.4 because of the angle. i can upload and slightly change the test tomorrow.

Edit: modifications are uploaded.

Edited 1 time(s). Last edit at 07/02/2011 08:23PM by jamesdanielv.

you want a zigzag that slowly converges to a point so the frequency increases, have one parallel to both axes so we can find out the mechanical resonance frequency of X and Y independently. See nophead's Frequency Limit post.

If your goal is to print as fast as possible, some code to avoid the resonant speed of each axis is paramount since mechanical resonance will cause inaccurately placed extrusion, missed steps and loss of position. I'm not sure what will happen /above/ the resonant frequency, you may wish to find out

I think you'll also have to implement the red sections of this for extrusion to have a chance at working properly at extreme speeds and accelerations.

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

I think faster firmware will provide a more tunable printer. currently ultimaker claims around 500mm/s is max that can be pushed from firmware. using digitalWriteFast it is faster.

This is not the final version, and there are some bugs that need worked out, and i think there are some subtle changes in how sprinter acceleration works versus a month ago.

I tried moving code changes to the latest version of sprinter from tonokip


here is a alpa/beta release that has the following errors.
adc is not working correctly all of a sudden
errors with safe_speed so code deleted
errors running e axis without another axis

I'm sure its something i need to just look over.

what it does include is digitalWriteFast, some code optimizations for removing a few lines of code, and faster adc conversions, but it is not reporting it to repsnapper...

alpha_version

I will work on the code more tonight. adc should be easy. next week or so will place code on git.


speed should be there though. it should at least in theory by pulse rate push more than 2000mm/s

added features are slim currently other than speed. look in redline_configuration.h to do changes

#define endstops 0 //dont check endstops during run! check set to 1
#define pulsehightime 32 //time in 1/16us using nop operations for a pause to happen between pulses. useful for optical isolators.
#define minimum_distance_for_acceleration 5// NOT SURE THIS IS NEEDED ANYMORE.
#define e_backStepsAllowed 1000 //how many steps back allowed for e- prevents long pauses
#define e_feedrate_loneaxis 3000 // hpw fast e moves when it is only axis moving
#define lowest_feedrate 20.0 //sets lowest feedrate to run at all was set as hardcoded at 10 can now be changed.

the real difference is in the speed of execution of the linear_move loop.

Edited 4 time(s). Last edit at 07/04/2011 07:15AM by jamesdanielv.

here is second beta. fixed e not moving when it was only axis , just a typo in code, celebrated July 4th and came back with a new set of eyes..
tonokip works ok, but moving the code into sprinter took a little effort.

fixed analog read sort of, every so often it seems to flip. rewrote adc changes, and it works much better now, also changed area of code to where adc is enabled to after while statement rather than in the loop.

there is a setting now in redline_configuration.h to not show bed temp reads in repsnapper.

alpha release2

what i need to still work on and fix is the safe_speed feature. this prevents running at a speed that causes extreme jitter and allows max speed to vary during a build based on it.

also need the e step push/pull to be included.
also i need to put in a feature in adc reads that verify adc sample goes to correct channel. it happens correctly 9 times out of ten but 1 time out of ten it picks up wrong channel. not fatal, but annoying.

once i fix the adc random error read, and include the safe_speed i will list anther file link called beta_redline. once it is on git there will be version control, and such.

I also am tempted to rewrite the acceleration part of software. well my next week will not be board. it just seems more effective to rather than set a specific delay for max speed, look at delay loops and calculate max delay such as for 10- 20mm/minute when compiling. it means regular delays could be used with minimal math to calculate speed. also makes it far easier for calculating speeds for kinetics.

a few things i want still in this version as soon as it is workable

compressed buffer, quadratic kinetic references and compensation with known mass
I also want to verify that my change to multiplication over division is faster. as far as i can tell division is not included in avr, but multiplication is with a second register for it. 200 cycles versus less for multiplication i think. don't jump all over me for assuming that, just let me know if you have data either way.

Edited 3 time(s). Last edit at 07/05/2011 03:23AM by jamesdanielv.

> printer (bfb rapman using now an for testing
> atmega, because the bfb loves abuse)
...
> Capable of pushing >2000mm/s with 16x multiplier
> (not all the time mind you! and only with low gear
> ratios)

How low a gear ratio (your steps/mm values look near-stock, but back EMF makes more than 200-250mm/s implausible on a physically standard RapMan), and how does this speed compare to standard firmware on the same mechanics?

Firmware is capable of that speed. rapman is just the machine i use to make sure steps and acceleration work ok. speed of 2000mm/s is based off of max pulse speed using mendel steps/mm gearing for 16x motor. technically it is possible to push over 10000 mm/s with 1x divisor using mendel gearing. I don't own a machine that can do more than 1200mm/s

low gear ratio is whatever the regular is for mendel. I'll update this forum later on tonight with gear ratio's i use.

i don' think there currently exists a machine that can do 2000 mm/s the faster speed just means that acceleration algorithm improvement, design changes for axis systems will increase speed!

this firmware once the bugs are worked out will be very very useful.

i am in the middle of writing a subject in this forum that explains how it does floating point math 3 times faster than the regular firmware!

don't look at how it runs on my machines. try it on yours. let me know the bugs and issues, help its features get into sprinter, stuff like that. thanks!

edit: i'll show my gear ratios tonight. i think the only gear ratio that needed a lot of change was the z axis for the bfb machine.
2000 mm/s is the rate with the pulse speed and 16x multiplier and using mendel steps per mm size.
the peek step rate with this version so far is around 160khz and 121khz with both axis moving at same time. so as long as your gear ratio is around 60-100 steps/mm you will get this speed. i have some further optimizations that will push the limit further

edit::gear ratios are the same except for z axis. z axis is 300. another thing, i'm running my rapman with an atmega on a 24volt system and a chopper circuit, so back emf is reasonably controlled.

Edited 4 time(s). Last edit at 07/13/2011 06:38PM by jamesdanielv.