Repetier Firmware and Host

Please post in the repetier forum section

There is now a separate Repetier section for questions around Repetier-Hosts and Firmware, please ask your questions there:

http://forums.reprap.org/list.php?267

Hi,

in the last months I managed to write a completely new host software and matching firmware. Both have many improvements which were often requested in the forum and some I wanted for my self. I hope, someone likes it:-)

Repetier-Firmware

See Repetier-Firmware

It's a nearly complete rewrite (80%) of the well known Sprinter firmware. While rewriting it to simplify it for future improvements and to improve the speed, I added tons of remarks and documentation, helping everyone, who wants to change it a bit.

Features:

• RAMP acceleration support.
• Path planning for higher print speeds. (since version 0.32, 2011/9/24)
• Fast ooze prevention system. (since version 0.35, 2011/10/8)
• Trajectory smoothing for smoother lines. (since version 0.32, 2011/9/24)
• Nozzle pressure control for improved print quality with RAMPS. (since version 0.32, 2011/9/24)
• Fast - 16000 Hz and more stepper frequency is possible with a 16 MHz AVR. (since version 0.32, 2011/9/24)
• 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 easyly 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.
• User defined and generic thermistor table( just set r0,t0,beta,r1,r2) in config (since version 0.31).

---

Repetier-Host



See full documentation at Repetier-Host

Also the firmware uses the same standard codes, it has many new features which are not suppored by any host software. I liked the concept of RepSnapper except the print quality. The new Host software has a similar concept integrating a printer control, a STL composer and a slicing tool (I use Skeinforge from within the software).

Features:

• Communicates in classic ascii mode or using binary Repetier-Protocol.
• Easy to use GUI.
• Buildin Slic3r for fast slicing.
• Integrates skeinforge for good print results.
• STL composer - place, rotate and scale your STL files on your printbed and store or slice it.
• STL files are automatically converted to gcode.
• Visual preview of G-Code.
• SD card support (since version 0.28)
• G-Code editor with syntax highlighting and syntax help. (since version 0.28)
• Visualizes the G-Codes send to printer.
• Shows estimated print time.
• Simple control panel for tests.
• Jobs can be changed in internal editor befor sending it to the printer.
• Supports multiple 3D printer.
• Logs commands and responses.
• Change EEPROM settings.
• Show temperature graph over time.
• Test generator for calibrating advance control.

It comes with an easy to use windows installer, Mac DMG image or Linux tarball.

---

Repetier-Protocol

I don't want to go into details about this protocol. The main advantages compared to the standard method are:

• Compatible with standard method.
• Autodetect binary/ascii data.
• Less data to send in binary mode.
• Faster interpretation of commands.
• Improved error correction.

I will update an exact protocol definition in the near future on the firmware page.

State of development:

On my system with my configuration it is stable. If you have found errors or have improvements, please contact me.

And now have fun!

Edit: Added new features for firmware 0.32 and Host 0.22

Edited 7 time(s). Last edit at 04/09/2012 12:08AM by repetier.

---

Ordbot + iRapid + Mendel
Repetier-Software the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware

That must have been quite a lot of work! Well done.

---

------------------------------------------
garyhodgson.com/reprap | reprap.development-tracker.info | thingtracker.net

Looks very promising. I'd like to try the host and firmware but it looks like the host only supports Windows. Any chance of supporting the Mac OS?

@garyhodgson Yes, I hat quite some hard months coding this. But finally I think it was worth the work.

@brnd It's written in c#. Perhaps it can be made running using Mono, but I have no expeariance with Mono. Could help to port it to Linux, too. But without a Mac I can't even test this. What should work is using Bootcamp or Parallels virtual desktop and Repetier-Host.

If you don't have one of those, you still can use pronterface for the Repetier-Firmware.

In Arduino 021, it the firmware compiles as downloaded but not when I change the motherboard to 3 (Ramps 1.2 and earlier) and board to Arduino 2560 or Mega.

@brnd Fixed the error. GEN 6 doesn't have a LED to turn on, so I diddend see a misspelled variable name. Download the new Extruder.cpp and it should compile.

I can't find the thermistor tables.

The thermistor tables are all inside Extruder.cpp. All tables are stored in flash memory, so I can have all tables compiled in the firmware. You only need to set EXT0_TEMPSENSOR_TYPE to the correct thermistor type, the correct table should be used automatically, see below.

// What type of sensor is used?
// 1 is 100k thermistor
// 2 is 200k thermistor
// 3 is mendel-parts thermistor
// 4 is 10k thermistor
// 100 is AD595
// 101 is MAX6675
#define EXT0_TEMPSENSOR_TYPE 3

I'll change those values to match my thermistors. The problem is that there are many different types of thermistor with different beta values and the same resistance at 25C that are used. So, it's best to make it easy for the users to use their own tables and to identify the values for the tables. I think you used the same values as in the Sprinter firmware so this is also a problem with Sprinter.

One thing I wanted to get around to was just specify the beta, r0, r1, and r2 and let the firmware calculate the table on start up. Most users in the know end up generating their own table anyways and those that don't know end up with slightly incorrect temps. The processing time to create the table doesn't really matter since it is one time. The only overhead would be the ram to store it. I think Sprinter stores the table in non-progmem (ie ram) anyways.

I extended the thermistor methods in the Repetier-Firmware (Version 0.31).

I don't like the idea, that someone needs to change more then configuration.h to get a normal system running. So I added a user defined thermistor table definition in configuration.h. Use type 5 to select this one. User defined tables are also stored in flash, to have more free RAM.

@jv4779 The genieric way is not as exact, but sufficient. So if someone just wants to set the r0,t0,beta,r1,r2 values and the number of table entries, hi can now activate the generic table creator. A nice sideeffect is, that the lookup in generic tables is faster then the other lookups. Use sensor type 99 for the generic table. If you define #define DEBUG_GENERIC you can even see the created values on the output (connect printer, then press reset).

I hope the temperature computation is now flexible enough for everyone.

Now I want to get rid of the extrusion lag using RAMPS. I've seen a cool idea from Matthew Roborts (see ADVANCE method) to get rid of these blobs.

---

Ordbot + iRapid + Mendel
Repetier-Software the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware

repetier Wrote:
-------------------------------------------------------
> I don't like the idea, that someone needs to
> change more then configuration.h to get a normal
> system running. So I added a user defined
> thermistor table definition in configuration.h.

I wondered why thermistor tables arent in config.h and there are like tones of other files like temperature.h + thermistor table.h and messed up stuff like that. Really thumbs up for those who care enough to work "organized" and "clean".

> @jv4779 The genieric way is not as exact, but
> sufficient. So if someone just wants to set the
> r0,t0,beta,r1,r2 values and the number of table
> entries, hi can now activate the generic table
> creator.


Beta gives only some approximation which probably wont exactly fit on real life data at a given point. I can change the beta to make the extruder high temperatures to match reality, but then the lower range temperatures are going to be off. If i make the heated bed lower temperatures to fit reality, then the high temperatures will be off. I would think of changing the beta not of a way to remove an error, but to hide it under carpet instead. My case is extreme, coz i have the thermistor at the edge of my heated bed, so thermistor read 40C at edge when i have 120C in middle (homemade pcb etch heater on a 6mm fr4-ish material so it doesnt dissipate as much as aluminium). In spite of using same thermistor in this setup, if it would be just a beta value, it would have to be "different" beta for heated bed and for extruder, if the temperatures would have to match real life. And it would be more trouble to find the beta which reads ok at lower temps and another beta which reads ok at high temps.

But with tables, i can get a system which gives best fit or best approximation to the entire range. From one iteration only. Being tweak-able at any point. E.g. if from 200C it read 5C more, i change only those values manually, and so on. So i can get something that fits in the entire range, instead of something that is off on the other side. I like tables for this reason. If i am allowed, i would give tables a thumbs up too. Much better way to do it than any alternative - if you want to get some proper readings on the full range that is.

Dunno if i put it the right way, but tables are like a linear "snake" which will "flex" on any of its intervals to better fit the reality from 0 to 300C. Instead of simply beta which is a certain "fixed" curve or shape, which when we try make it fit one side, will translate and swing away from the other side.

Also dunno why there are multiple thermistor settings either, as far as i can think there should be only one table, with a big warning that everyone should make their own. And ppls need to learn how to compile their own tables, and how to test and adjust the tables aswell. It wont work (properly) without these steps, regardless if pre-set tables are provided or not. And it shouldnt be provided, because while the thermistors are able to read temperatures up to 300C or more, they are usually not interchangeable above 150-160C, which technically means if my thermistor broke and i replace it with another of same type/batch, i should still have to re-test and re-adjust my table. On the other hand when you provide pre-set tables for thermistors, ppls start to think that that values *must* fit, which i think its wrong to think, although most ppls want to see it like that and pass over for simplicity. See [content.honeywell.com] somewhere down in low letter says "These Glass Encapsulated Chip Thermistor units are specifically designed to offer interchangeability over the standard temperature range of 0 °C to 100 °C" - which i think it means over that temp they are no longer "interchangeable", hence any preset you or others may give has to be more or less off-scale. Ppls need to understand that thermistors arent thermocouples, and really should learn how to make tables and how to work with them, and trying to make them look the other way and hope for the best isnt quite the right thing to do imo. Really aint that hard to make a table and to adjust it in one iteration with a multimeter t-couple reading each of the table values against real life and make a simple math operation. Now I dunno why do we have multiple thermistors settings and why this gives ppls impression that as long as they bough that thermistor model then it should work with pre-set values at 230C? It basically shouldnt, although it might or might not, but its not the proper way to do it - imo (in my opinion). I also learned this stuff this way, and honestly it would of been easier for me if someone putted the subject in the right light / proper way from the start.

Edit2:
Btw, very nice work and it looks really cool!

Edited 2 time(s). Last edit at 09/28/2011 05:14AM by NoobMan.

My observations after trying it for a few days. Comments are a mix of Repetier-Firmware and Host:

• Repetier was very responsive to my email inquiries.
• EEPROM config is neat and works very well
• (it is confusing that the compile defaults only matter the first time and after that EEPROM overrides)
• As a long time RepG user I was surprised that the center of the platform was not 0,0 but 100,100 (out of 200x200) but it can be adjusted with the right G92 in the "prepend"
• The "prepend" and "append" method of bracketing SF's gcode is handy in some ways but annoying in others: If I want to run some non-printing gcode (eg a circle movement test) having a preheat/etc cycle in "prepend" is annoying. My many prior SF profiles usually have minor variations in start.gcode too.
• The Host is fairly stable. Probably as stable as RepG which is obviously not perfect. I got it to wedge when I hit the heater toggle during a connect once.
• Many rough edges in the UI: Misspellings, strange word choices, strange button placement, lack of rollover help text, etc. Mousewheel didn't scroll the gcode window. Pasting into "prepend" ran all the lines together.
• On the whole though it has a lot of potential compared to RepG. Having all the manual controls integrated into the print panel is very handy. The previews are great -- helped me spot unwanted support before I even started the print.
• It would be really neat if the live model update used a different color for new threads and faded back to yellow after a while
• The previews and the way you assemble STL is very handy. It's great being able to manipulate the STL but keep the original. Being able to build "plates" live is a huge win: I'd probably print a lot more multiples using Host than with RepG.
• The mouse navigation in the 3D window could use some polish. I always feel like I'm fighting it.
• As a long time RepG user I was thrown in the deep end when it came to installing, configuring and using Skeinforge with Repetier-Host. I thought this was the biggest obstacle to transitioning someone from RepG. Paths (under Host's SF settings) needed quotes but didn't get them by default. An export suffix was assumed but not default in SF (and I'd never used it before). Took me a while to see that SF status was going to the "print" tab log after launching SF from "model". Heck, when I started I didn't know how SF even selected what profile to use since RepG handles all that for you. RepG also creates many entire config trees as opposed to using SF's own hierarchy.
• There are a lot of queued commands in the firmware that keep executing when you hit stop. If those are long moves you can wait a long time for it to stop.
• When waiting in M109 the log backs up (or perhaps the whole command queue?) and then burps out all at once.
• Should be an option to send M84 at stop (several similar things are checkbox items)
• The Host seemed to randomly send lines like "Z0 F0 S0 P0" and confuse the FW. Didn't investigate.
• Prints with Repetier-Firmware at "normal" print speeds and fast rapids were fine.
• Test movements at high speeds (eg large circles) were fairly smooth. Far better than the Klimentkip (pre-Sprinter) I upgraded from but not as good as Marlin.
• High-speed prints did not come out well. Also, some movements would start with inexplicable super-slow ramp ups. Short movements with corresponding tiny filament advance would sometimes just buzz and not advance the firmware. The same gcode printed fine with other firmware on the same printer.
• Extruder temperature control (and the temperature monitor in Host) were much better out of the box than probably every other firmware I've tried on gen6. Now that I think about it those two things are probably related!

After trying Repetier-Firmware (including tweaking parameters with the EEPROM editor) I moved on to try Marlin driven by Repetier-Host. There is some slight confusion at connect time but it connects successfully and everything worked. I did several prints that way.

I did not actually try Repetier-Firmware with RepG! The Host was good enough for everything I tried plus it had extra integration (like the temp monitoring and EEPROM config) that RepG would not.

I would like to try this but I can't get passed the thermistor settings. I can see where to put my own thermistor table for the extruder in configuration.h, but I don't know where to put the table for the bed thermistor. I don't have the same thermistor on the bed. Even if you have the same type, it's probably more optimal to use a different table for the extruder and the bed so that you can optimize the table for the temperature range of interest (180-250C for the extruder and 25-150C for the bed). I'm also not sure how to specify that I have a heated bed.

I also doesn't make sense to define tables in extruder.cpp. There are many possible thermistors and it doesn't make sense to be carrying the specific ones that were defined there if it's not being used. It makes more sense to have a separate temperature.h or thermistor.h file that would have the tables for all the thermistors used in your system. Then the user just has to edit his own or pick one of the pre-configured ones by renaming the file. This is actually where the Five-D firmware is better than Sprinter.

Noobmans comments are right, with the special table for every thermistor. As a result, the next update will have three user defineable temperature tables for user tables.

@brnrd Wait for the next update, then you have two tables for use.

Printing at higher speeds shows a problem with the integer update of the acceleration. I'am currently working on this. I will upload the corrected version with the extra temp. tables. Wait for version 0.34 if you can. For normal speeds (60mm/s and 1000mm/s acceleration) the error is neglectible. Now I'm trying 100mm/s and 7000mm/² and there you feel the problem. Could be smoother and will be in near future.

@BenJackson Thanks for testing so far. Software is still in development, but as you already pointed out already usable. In fact, I only use my software to see whats wrong. As your comments pointed out, everyone uses software a bit different and run into problems I never had with my own workflow. Thats one reason for publishing it early.

If someone sees spelling errors, strange formulation etc., yes english is not my language. Tell me my errors and I will correct them.

If someone has ideas for what is missing, tell me too. If it sounds usefull and is implementable I will. So far, I have the following updates for the Host software in the future:

- Selectable Skeinforge profile from host.
- Replace .NET text editor with a better one. If someone knows I free texteditor control with linenumbers, it comes faster.
- Improve 3D navigation
- SD Card manager for printing/uploading to SD card.
- Stop steppers control in command panel
- Nicer gui (least priority, better get a good working software first)

I fell in love with the host.

I am trying to use it with teacup firmware, and have printed few objects so far, and seems to work well.

- for some reason, each time i start to print the temperatures get turned off, including the buttons go from green to red, i find this pretty annoying tbh, and trying to fix it too fast sometimes ruins the comms.
- would like to know if there is a way to have second homing button for homing with G161 ...
- "go dispose" coordinates could have a Z - i dont have the "crack" in the bed, i just raise the bed 3-4 cm and extrude a little on a piece of paper (like the post-it type)

Other than that, looks very neat really

I just found the bug (at least I hope it the only reason). The bug caused wrong deceleartion behaviour resulting in strange timings. Acceleration with 7000mm/s² and moves up to 260mm/s are now possible on my printer (80 steps per mm), which wasn't possible before. Thats just 770 processor ticks per Step. If there are still printing problems, just tell me. The new version is now uploaded.

@NoobMan G161 is not listed in the RepRap G-Codes. What does it exactly? Sprinter a clones don't know this. Perhaps I can emulate it, so it will work on more firmware versions.
"Go dispose" always goes to predefined x,y coordinates. I could add an optional Z-raise if z is below the printer height, set in config. Perhaps a go to x,y and raise to 40mm above printbed if lower would be the better option. For safety, Z-raises will only work, if the z-axis was homed before.The spindle has too much force to let it go uncontrolled.

The heater buttons going from green to red may have a very simple reason. The host has a G-Code analyzer. You see this at the top, where you see the coordinates and the realtime renderer uses it too. If it gets a command M109 0 or M104 0, which turns the heater off, it will show this in the panel, too. Check your G-Code if you have such a code at the beginning.

The G161 i think its the "true" homing for teacup whereas normal homing will just go to the stored values, if i get this correctly is to avoid using the endstops too much in order to avoid false flags.

About the buttons going from green to red - i dont really use any temperatures at all in my gcodes, i set them manually prior to printing and they just remain as that. Sometimes i change them manually a little during printing even. But not inside gcode. The only place the M104 - 140 are mentioned is at the very end, from end.gcode file, so it always ends like that. Nothing in the rest of the gcode, or in start.gcode either. I also print same file with pronterface for example, and the issue never appears.
At connection, my firmware replies with ...teacup...Protocol version 1.0 [bla-bla-bla]... HEATERS:0 - could that be a reason? I thought that was just informative.


About go dispose its allright i was just mentioning it as its the way i do it, not rly sure any1 else does the same.

Also another thing: would be useful if the job window will retain and show up the name of the gcode file that was loaded last. I cant find anything like that and i keep having doubts of what i loaded

Edited 4 time(s). Last edit at 09/29/2011 11:58AM by NoobMan.

This page will help [reprap.org]

Do not lose this page. It is impossible to find again.

---

FFF Settings Calculator	Mini Printable Lathe	Geometric Object Deposition Tool Blog
Tantillus.org	How NOT to install a Pololu driver

The firmware still has issues with acceleration/deceleration timings. Will update that asap.

Version 0.25 of repetier-host is released. It fixes several important issues. Update recommended.

New features:
- Stop motor (M84) in print panel
- Z-Min for dump position. The new behaviour is now as follows. It moves to the assigned x/y position to get the nozzel away from your print, before ooze starts dropping on it. If Z-Position is known an lower Z-Min, it will raise the head to Z-Min. I like a value of at least 10mm. That way, the head doesn't during the first homing on the next print.
- No more quotes in skeinforge path needed (only with spaces in path needed anyway)
- Fixed some other bugs and spellings.

---

Ordbot + iRapid + Mendel
Repetier-Software the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware

Tried the new version today and all the issues with the heaters going red are fixed. Works nice.

Only printed like 2 objects so far, i will give it more stress the coming week, so will keep printing and reporting back.

After two weeks of work on the next firmware version, the known problems are all gone. The firmware is even better and faster then before.

I added a new feature, that I call OPS (ooze prevention system). The basic idea was to use the better control over the printer to decrease print time by optimizing anti ooze actions. While the way, skeinforge reduces ooze is good, it can be done faster. The normal procedure is to retract 3 mm filament at the beginning of a travel move and push it back after the travel is finished. I thought, why not start earlier and start pushing the filament back, just before we arrive at the end of the travel move. And it worked. I now can start moving, after a fixed length is retracted. I description can be found here. I also made a little video. This was captured in slow motion. If you look closely, you will see, what I mean.

Feedback needed

I think, the current version is stable enough, that other can test it. It would help to improve the firmware, if I could get some more feedback. The feedback so far already helped me improving the firmware. Especially users with non gen6 boards are needed, as I already know how good it works with gen6.

---

Ordbot + iRapid + Mendel
Repetier-Software the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware

The ReplicatorG version of Skeinforge has a plugin called "reversal.py" which does something very similar. The MakerBot does not use FiveD/dimension.py so they needed an alternative. I submitted patches to make it compatible with dimension.py and it can speed up prints with frequent reversals quite a bit.

I like your slo-mo extrusion. I note that you still get some ooze while traveling (PLA and high temp?) so maybe you should extend your model to be: 1) quick reverse as you reach the end of an extrusion, 2) slow continuous reverse during travel, 3) enough forward move to undo all of 1/2.

@BenJackson Yes it's PLA but I set it to 170°C, so I think it's not the high temp. What you see is more or less the start of the print. There I always have troubles. I always do G28 home at the start and that presses the nozzle in it's own ooze. It takes a few moves, to wear this off. I think, what you see in the videos are the remainder off this. The greates problem is always the pla next to the outlet. It can stay on for a while and brush through fresh printed pla. Is there a trick, to avoid it from sticking to the nozzle?

I'm not sure a continuous reverse during travel will help. As far, as I understand this, the fast reverse sucks the pla deeper inside. Then it will flow back, but if we are lucky, we reach the next printing position before that happens. A reverse must therefore be faster then the drop splitting from filament and at some point the filament leaves the filament driver. If the little ooze you see is not related to my first explaination, a longer reverse at the start should also help, avoiding point 2, which is difficult to implement and time consuming (updating the precalculated path parameter as the travel evolves). In the video, I start after 1,5mm reverse doing the rest during travel. I could set this also to 75%. I think, the trick is to find the best compromise between quality and speed.

The startup problem is solved with a silicone wiper. That's one feature of my MakerBot that I really miss on my Prusa. The wiper makes it possible to create a startup sequence that starts raftless prints consistently.

BenJackson Wrote:
-------------------------------------------------------
> The startup problem is solved with a silicone
> wiper. That's one feature of my MakerBot that I
> really miss on my Prusa. The wiper makes it
> possible to create a startup sequence that starts
> raftless prints consistently.

My printer has an X position that's beyond the edge of my bed. I simply wipe my nozzle there in start.gcode

---

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

The RapRap Host has the wiper function and Skeinforge has the Skirt module (set layers = 1).

---

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

More precise Skeinforge has both Skirt and Wipe modules (even to wipe between layers). Or if its just for the start of the prints, one can use a hand made start.gcode.

So far I have tried the Host and i think its quite neat. Quite happy with it. Atm I cant try the firmware myself yet coz i have a gen3 with external extruder, but otherwise i would certainly check it out.

Very nice job! Congratz!

Thanks for the many wipe resonses. Looks like I need to add a silicone wiper in my dump area. Until then, I try to wipe it by hand. For that, I will add a pause command in the host software. This will show a message and wait for the user to click ok. Will be handy to bury nuts in printed parts and continue printing after that, too. So here my planned future startup sequence:

1. Check, that nozzle is over dumb area.
2. Heat up nozzle. Remove long ooze stands.
3. G28 X0 Y0
4. G1 dump area
5. G28 Z0 - now I have no bed underneath, where my nozzle dips into it's own ooze drop.
6. Wipe clean automatic or by hand.
7. Print a fat line to refill nozzle
8. Start print

That should give a clean start.

@NoobMan As far as I can see, the only thing preventing it from working is the external extruder which is currently not supported (gen 3 has a atmega644 correct?). If you have a page describing the protocol or a firmware, which supports it, I can have a look on how easy it would to implement. I guess, it's just using the second serial console for command transfer. which would be easy to implement. But if I do the work, I need a really willing tester to find the errors. If you are up to it, I will implement it, as my time permits.

Edited 1 time(s). Last edit at 10/12/2011 09:40AM by repetier.

The extruder board is just used for temp readings and fet control atm. Its a relic, like entire gen3 is. I think initially was sort of a servo driver for DC motor with encoder, so needed separate mcu "interrupt free" (closed feedback loop & fast response), and at that time putting temps on it made some sense. Now, for extruder stepper i use stepper driver directly from motherboard. So atm extruder board is only used for 2 adc inputs and 2-3 fet outputs via rs485, thats all. It became weird because master mcu is perfectly capable of doing that part now. I dont think you should complicate yourself with this, because this is both ancient and strange, and it doesnt feel like how things should be in theory. Its just commodity that i never took the time to suplement master mcu free pins with 2 separate fets and 2 temp sensors. I dont really have an excuse for that. I would test code if you want, but i think its way too particular and strange setup for you to bother.

About how printing starts, i have the nozzle higher like 40mm up, extrude on a small piece of paper like post-it, then start the print which will go home first. During homing the Z takes its time and nozzle squirts abit which i clean manually. I doesnt matter because i still have to watch the start of print further. I use a slow speed setting via SF-raft for the first layer, and this includes skirt. The point is that during skirt procedure, i look at Z height over the bed and i can rotate the right Z M8 screw by hand to achieve what i think its best layer height (the z motors are disabled in firmware at this point). I do it like that because i have few different pieces of surfaces i clamp to the bed with those kind of "clips" and there is some difference between them, and doesnt pay up to change Z always for each situation, also changing Z would be much more tedious. This is easy instead. So doesnt matter if i have to clean up nozzle by hand, i have to be there anyway, at least to make sure first layer height is best it can be.

Edited 1 time(s). Last edit at 10/13/2011 03:45AM by NoobMan.