I'm using complete code bases, I learned the hard way years ago not to mix old configs with new ones. What get's me with this is usually you cannot use the sdcard functions at all, with this one I can read the sdcard but it just wont print them....
Printable View
I know there have been some additions and changes to the SD Card code. But I don't use the SD Card stuff. It might be worth while to do a diff between the old and new code and see what you can spot. I don't think there have been that many changes so most likely it won't be too hard to spot. If you upload the source to the version that works, I can take a look too.
Not to confuse myself more than I already am, but take a look at this thread http://3dprintboard.com/showthread.p...s-enhancements
For some reason after making the changes for my printer, it compiles and it is also working, I can run a print directly from the sdcard now....
There are a lot of conditional defines (#define, #ifdef, etc.) in the Marlin codebase and it isn't hard to utterly confuse their locations, particularly given the formatting.
Glad to hear that fork is working for you.
Oh, and please: Make sure you update your E-steps and set the ABL servo angle before using!
I have also integrated the bonm14 into current Marlin including Roxy's changes (fork available here: https://github.com/beckdac/Marlin ). I had to do some work to reconcile the two approaches, particularly for handling the number of points, but that is done. Please see this post for more information: http://3dprintboard.com/showthread.p...ll=1#post28235
If you have a post-processing script already setup, syl20, I'd love to have a look at it.
Well, it wasn't code... I just used a calculator to get that number. And remember... I have 4 spring loaded screws holding my bed. Not 3 so maybe this doesn't work as well for MakerFarm's??? But as it turns out, that number isn't actually usable. It will move that corner up or down that much. But the problem is that pushes the mean of the sample points up or down by half that much.
I wonder if a better approach would be this: Get the bed very close to level, and then 'unadjust' one of the screws by one turn and see how much it shifts the topographical map. Then put it back and 'unadjust' the next axis at see how much it shifts things.
If we can figure this out... It might be good to have a Configuration.h parameter for the important (heavily owned and used) machines where the user can uncomment the appropriate line.
Ha! I thought that output was from Marlin on serial. You keep great inline notes!
Interesting! I have one solid nylon spacer in a corner (the XY homing corner) and three springs with M3 socket caps through the glass, heated bed, and air gap/cardboard + birch wood with thumbwheels capturing nylon lock nuts below. I calibrated my Z_PROBE_OFFSET_FROM_EXTRUDER in the fixed corner with the nylon spacer because I thought it was invariant.
Yes, I do have a slight hump in the middle, but the springs are pushing up on the bed, not pulling the corners down.
Recv: Bed Height Topography:
Recv: --0.05021 --0.00271 +0.00104 --0.05196 --0.15621
Recv: --0.02296 +0.05454 +0.08254 +0.02554 --0.09296
Recv: --0.02321 +0.05554 +0.09354 +0.04929 --0.07521
Recv: --0.02246 +0.05329 +0.08929 +0.06579 --0.02796
Recv: --0.05021 +0.02954 +0.05879 +0.05604 --0.13871
Can I say again how much I love this enhanced code? Yes, it shows me I have a slight hump in my printbed, but it also shows me that it's damn near perfectly level, too. :)
That bump looks like it is due to your probe being there. Mine was really bad so the only thing I could do with it is make the bed NOT level which removed the bump (due to the boro glass being perfectly flat) then the ABL worked flawlessly. I wish I could fix the level and the bump manually but I couldn't after several hundred hours of trying. Now I live with it and ABL happily does its job.
You mean it's showing how much the glass is flexing from the probe coming down to touch it? Awesome :)
In your case YES. I was seeing the same thing until I removed the thermistor then I lifted the entire setup higher so the thermistor was floating in the air (basically) and the bump was gone. The only issue I finally had, that I could not correct on the I3, was that it refused to go level. So, yeah, that bump is probably your thermistor and if you could see the actual stress (I forgot what camera testing setup does this but I saw it once) you would see how it pokes in the middle and goes down like a stake in a tent until it finally rests again. This is how much Z has in resolution to allow us to see this.
Pretty awesome stuff actually, heheheh.
I don't see how it could be the thermistor. It's on the opposite side of the heatbed from the glass. And the heatbed is suspended above the wood platform by one spacer and three springs.
Might not be in your case (the heated bed needs a thermistors in the middle if you are using a heated bed) but are you using boro glass? Plain window glass isn't as stiff, nor as flat, as boro glass and it was the best 25 dollars I spent on this printer BECAUSE nothing else worked.
Nope, using glass from Lowes. Don't know where to pick up any borosilicate.
Yep, I tried dollar tree glass frames (was 1/16in thick and far too thin to even cut and I had to buy 5 before I said eff it due to that and how it was flexing so easily). I bought one from Lowes that they cut for me (was 1/8 inch thick) and it helped but still no go as it would flex downward by a small amount as soon as I put the clips on. So I bought the Borofloat glass for $24.99 delivered and never looked back. My seller is no longer selling any but here is the alternate one I was going to buy before I found his excellent price - http://www.ebay.com/itm/Borosilicate...item3388c8d3a8
Mail http://www.ebay.com/usr/bluskreen?_t...10.m2749.l2754 (bluskreen who was my seller) as he will respond quickly and is in the USA.
What's with the odd dimensions? 214x200. I might need to get the corners cut off at that size.
Those are the proper dimensions as a heated bed has the solder terminals on one side so that is where the 200mm goes and the actual bed is 214mm. In my case Y is the 214mm and X is 200mm and it fits perfectly on the MK2b heated bed. I use 4 clips and they are on the 214mm side (in my case forward side of Y and the backside of Y of the heated bed).
Huh. My solder terminals are on the bottom of the heatbed, so I guess it doesn't matter which way I orient the glass. I'll have to get bigger clips to hold a 3mm piece of glass.
if you did it right the wires go through the holes and are soldered on the opposite side.
edit: No matter there is no reason to have glass over those holes/pads either because you don't want heat near them via transference from the glass and you don't have any heating elements there anyway.
No holes, surface-mount MK1. So you have the glass longest dimension sideways, along the X axis? My heatbed connection is at Y max.
On my I3, looking from front to back, I have the wires on the left side and the clips on the front side and the back side. The glass is a perfect fit.
http://reprap.org/wiki/PCB_Heatbed I updated a lot of the stuff on there earlier this year.
Here is a picture I added of my MK2b (the black one):
Attachment 3044
Here is my full board I added to the wiki:
Attachment 3045
Guys... This thread is already a ridiculous number of pages long... May I ask you to move this discussion to a new thread so this one doesn't get any more chaotic than it already is?
Thanks!
This is nothing but chaos already but I do think the people out there attempting to use ABL need to realize that plain window/picture frame glass is a futile effort at best. It may work for now but might not in the future and is far from flat like borosilicate (known as Pyrex glass as well) is. It all adds up to people being happy and getting this routine to work.
I know if someone was not using boro glass I would stop the help right there and I say that after using, and attempting to use, the other types of glass.
Hi,
I hope it is not too late ! I have written a regular perl script for post processing with slic3r. This script replaces the custom Gcode parameters [G29XMIN], [G29YMIN], [G29XMAX], [G29YMAX] by their values.
The script is very fast (thanks to perl).
You can download the script here : https://github.com/syl-20/Marlin/blo...inting_area.pl
And just to keep things together and easier to find: This is the current Slic3r post processing program. It is untested but appears to do the right thing. We need to either update the original post in this thread to support the extra (and new) parameters or get the new G29 command folded back into the main code tree. But first we need to get some test time on the new code to shake out any bugs.
Hi Roxy,
With my script :
- only one script file (~80 lines) ;
- no need to compile ;
- no initialisation for x_min, x_max, y_min, y_max (with yours, theses variables are set to 9999.9 > if marlin is set to use micrometer ? )
- no need to create a new gcode file ; the user file is updated in place ;
- input and outptut are streamed ;
I didn't know enough to get a Python script running on Slic3r, so I just made a quick and dirty C program to do it. If 9999.9 mm isn't enough, it is Open Source! The user can change it to 99999999.9 mm ! :)
Anybody that doesn't want to compile, can just use the executable. Compiling isn't a big deal to (or for) me. I like my C compiler! :)
I could have updated in place by opening the file for read / write, but the problem is the G29 line grows in size when you add the extra parameters. So, it is more difficult than just inserting the extra information. Hence... the generation of a temporary file. Its only a few lines of code to rewrite the file once you know what you are going to do to it, so that is the path I went.
But back to your point.... If you can get your script to work with Slic3r, it probably would be best to just have one solution that works for everything. Do you care to give it a try?
Of course, it works and you can try it !
1-just download the file from github : https://github.com/syl-20/Marlin/blo...inting_area.pl
2-add the path to the post processing script in your slic3r config ("print settings" tab / "output options" section)
3-add your custom start gcode ("printer settings" tab / "custom gcode" section) like this one : G29 L[G29XMIN] F[G29YMIN] R[G29XMAX] B[G29YMAX] n4
Thats all !
Before the script, the gcode is :
After the post-processing script, the gcode :Code:...
G1 Z5 F5000 ; lift nozzle
G29 L[G29XMIN] F[G29YMIN] R[G29XMAX] B[G29YMAX] n4
M109 S200 ; wait for temperature to be reached
...
Code:...
G1 Z5 F5000 ; lift nozzle
G29 L73.340 F73.340 R126.660 B126.660 n4
M109 S200 ; wait for temperature to be reached
...
Hi Roxy,
So I test my perl script with the fork of beckdac ; it is perfect ! The probe is restricted to the printing area, the repetability test is OK, .... Congrats !
So I fork the fork of beckdac and integrated my script + the last commits of ErikZalm.
Everything is here : https://github.com/syl-20/Marlin
Thanks a lot
I havn't been able to get that Perl script to work. (slic3r throws up errors about "Cant do inplace edit without backup") What version of Perl are you using?
Having some issues here, would greatly appreciate any help.
http://3dprintboard.com/showthread.p...ll=1#post31462
Working through most of my issues I had in my other post, but wanting to fix this also.
I need my Z axis to raise before it retracts the Z probe,
I saw your post mentioning changing the code in Marlin_main.cpp
but for the life of me, I dont see what you are seeing to change. Your examples look identical to me.
If you're using the Marlin MakerFarm fork from the other topic, those changes are already in your firmware, I think.
So far, I haven't been able to get it to work either. But to be fair, I've been super busy and haven't had the time to invest in this. The whole reason I did the .EXE file was because I use Slic3r and wanted it supported. So, you might want to give that a try.
One caution.... There script version is better about parameter names because it is very clear what is being put in place. It is searching for substituting the right numbers into the [G29XMIN], [G29YMIN], [G29XMAX], [G29YMAX] items. The .EXE version just looks for a G29 and tacks on the extra information needed.
Sly20, can you take a quick look at getting your script to work with Slic3r? That would help a lot of us out.
Hi,
On Slic3r / Linux, the script is OK as it is. Perl is installed by default.
On Slic3r / M$, you just have to :
- install perl if you do not have it (https://www.perl.org/get.html) ;
- just download this script (https://github.com/syl-20/Marlin/blo...inting_area.pl) and uncomment the line 22 (#$^I = '.bak'; for m$ only) ; I recently add this feature for M$ OS that does not support inplace streaming.
I have tested both (Debian OS and M$ XP) with success.
Roxy,
I have some questions :
Why do I have some "+-" before some values of the topography ?
I have "+", "-", "--", "+-" !!! I see in your code, you add some extra for the font used in pronterface. But what I understand, is that you double the sign, so why do I have many "+-" ?Code:--0.22982 +0.00091 +-0.17644
-0.22815 --0.00807 +-0.13478
-0.17552 +0.19074 --0.04623
In addition, I do not understand the values of this matrix ; here are the values :
With Libre Office Calc, my matrix isCode:Bed x: 78.00 y: 71.00 z: 3.21
Bed x: 101.00 y: 71.00 z: 3.67
Bed x: 124.00 y: 71.00 z: 3.62
Bed x: 78.00 y: 97.00 z: 3.44
Bed x: 101.00 y: 97.00 z: 3.43
Bed x: 124.00 y: 97.00 z: 3.63
Bed x: 78.00 y: 123.00 z: 3.27
Bed x: 101.00 y: 123.00 z: 3.31
Bed x: 124.00 y: 123.00 z: 3.40
Eqn coefficients: a: 0.01 b: -0.00 d: 3.24
Mean of sampled points: 3.442588
-0,232588 -0,002588 -0,172588 0,227412 -0,012588 -0,132588 0,177412 0,187412 -0,042588
Some values mismatch too much with the topography given by the code ... I do not know why ?
Thanks a lot