Right! If the user does nothing, the Auto Bed Leveling code would do the default case of doing the whole bed. But if the user cared, they would just tell their Slicer to post process the GCode and the area being probed would shrink.
Right! If the user does nothing, the Auto Bed Leveling code would do the default case of doing the whole bed. But if the user cared, they would just tell their Slicer to post process the GCode and the area being probed would shrink.
Dacb:
May I ask for a couple more changes to your fork? There are 3 items. First, can we put this in the Configuration.h file?
That is where it really belongs. (And of course, it needs to be deleted out of Marlin_main.cpp) I just put it with the C code in Marlin_main.cpp to make it easy on people. But if this is going to be merged back into the main tree, this option should be in the Configuration.h file. And also note the #define AUTO_BED_LEVELING_GRID_POINTS 5 and the explanation for it. Because of the change in what it does, probably that explanation is important so people can get full functionality.Code:
// set the max number of grid points per dimension
// The G29 command defaults to 3 if nothing is specified. But setting the number of probed
// points higher is very useful when getting a Bed Topology Report (G29 n 5 T)
#define AUTO_BED_LEVELING_GRID_POINTS 5
// Uncomment one of the following four lines so the Bed Topology Report can produce a map
// that relates accurately to your bed orientation.
#define ORIGIN_FRONT_LEFT
//#define ORIGIN_BACK_LEFT
//#define ORIGIN_FRONT_RIGHT
//#define ORIGIN_BACK_RIGHT
The other change I'm hoping you can paste into your fork is a comment block in front of the G29 command. It will help people understand how to use it. Unfortunately, this isn't complete. We will probably want to add some more comments about getting the post processing setup for different slicers but I guess that can wait until we have that done.
And soon... I think I'm going to have a few more lines of code to paste into the G29 that does range checking of the post processing parameters. The reason is I'm noticing Slic3r actually generates X & Y coordinates that are outside of the specified bed size. My Y goes from 0mm to 180mm but for some stupid reason Slic3r is generating G1 commands with a slightly negative Y number for the skirt under certain conditions. I need to finish getting my Post Processor going, and run it on some Slic3r generated GCode files to figure out how to handle it in a reasonable manner.Code:#ifdef ENABLE_AUTO_BED_LEVELING
//
// Enhanced G29 Auto Bed Leveling Probe Routine
//
// This updated code provides a Bed Topology Report, Ability to control engagement and retraction of
// Z-Probe and varying levels of verboseness. It also allows the selection of the n x n grid at
// print time instead of being fixed at the time the firmware is built. It also handles probe retraction
// issues for probes that require clearance much more gracefully.
//
// Parameter usage:
//
// n (u & U) Controls the size of the grid that will be probed. Typical usage would be of
// the form G29 n 4 u & U were added because of deficiencies in the Repetier client
// not being able to use even a lower case n
//
// V Controls the verbose level. Typical usage would be of the form G29 V 3
//
// T Controls generation of the Bed Topology Report. Typical usage would be of the
// form G29 n 5 T to get a detailed map of your bed. This is very useful
// for manual bed leveling as well as knowing where imperfections exist on your
// bed (to assist with part placement)
//
// E Controls engagement and retraction of the Z-Probe. It Defaults to leaving the
// probe engaged during the probing of the n x n grid. This helps the repeatability
// of the Z-Probe and produces better Auto Bed Leveling results. Typical usage
// would be of the form G29 E
//
// These following 4 parameters are typically generated by a Post Processing script
// configured within your slicer to process the generated GCode. Currently Curra and
// Slic3r are supported. The Post Processing scripts for these slicers will determine the
// size of the print on the bed and limit the Grid Probe to the required region in order to
// increase the bed leveling accuracy. Please not that these position parameters assume
// Left is the smallest X-Axis coordinate, Right is the larger X-Axis coordinate and Front is
// the smallest Y-Axis coordinate and Back is the larger Y-Axis coordinate.
//
// L Controls left side grid probe position. If unspecified, will use LEFT_PROBE_BED_POSITION
//
// R Controls the right side grid probe position. If unspecified, will use RIGHT_PROBE_BED_POSITION
//
// F Controls front side grid probe position. If unspecified, will use FRONT_PROBE_BED_POSITION
//
// B Controls the back side grid probe position. If unspecified, will use BACK_PROBE_BED_POSITION
//
//
case 29: // G29 Detailed Z-Probe, probes the bed at 3 or more points.
// Example Syntax: G29 n 4 V 2 E T L 50 R 150 F 25 B 125
{
THANKS!!!!
Nice work... Comments / documentation is super important. Here is the commit: https://github.com/beckdac/Marlin/co...32f725c23ab670
Roxy, that comment block explaining the different arguments passed to G29, the one for E is not clear to me. If one uses E, what should they expect to see? From what I've seen in your Probe Repeatability test, E caused the servo to lift the probe each time. In this comment block, though, it sounds like it's used to keep the probe extended for the duration of probing.
So I can't speak definitely! I haven't run this code yet. I'm going to have to port it back to my machine. But the Enhanced G29 is supposed to leave the probe down while taking all the points by default. Specifying the E option should make it go back to the original behavior and 'E'ngage the probe and un-'E'ngage the probe for each point.
The comment says:
So specifying the 'E' would Control engagement and retraction of the Z-Probe.Code:Controls engagement and retraction of the Z-Probe. It Defaults to leaving the
probe engaged during the probing of the n x n grid.
With nothing specified, the default behavior is to leave the probe engaged.
Please feel free to help make the documentation clearer! For sure people writing code make assumptions about what is obvious and what is not obvious. And if you do make the comments better... Maybe you can make the Left, Right, Front, Back comments better! The big problem with that is it assumes the origin for the person's bed is at the left front. That is not always the case. (I'm exactly opposite to that because of early flaws in the G29 code where it could not take negative offsets) But what can be done (either by switching the option names or by a different explanation) to make that better?
Yes, this is the biggest problem right now. It won't affect anyone in the MakerFarm family, so far as I know, but it does prevent the change from being pushed back to trunk without further consideration. I think it will also have an impact on any post-processing scripts. This really makes me want to rename or reannotate the L, F, R, B parameters to reflect that they are really Xmin, Ymin, Xmax, Ymax.
BTW, if anyone wants to get added as a contributor to the repo, just drop me a private message.
I would say
Code:// E Causes the Z-Probe to Engage and retract with every probe point. Do not use if you want to leave the
// probe Engaged during the probing of the n x n grid. Leaving the probe Engaged helps the repeatability
// of the Z-Probe and produces better Auto Bed Leveling results. Typical usage
// would be of the form G29 E
Could the L, R, F, B arguments be tied to the #define ORIGIN setting? If the user sets the origin as #define ORIGIN_BACK_RIGHT, we know where the larger and smaller coordinates will be. What I mean is, with #define ORIGIN_BACK_RIGHT, we know that F will be the larger Y coordinates, L will be the larger X coordinates, and so forth.Quote:
Maybe you can make the Left, Right, Front, Back comments better! The big problem with that is it assumes the origin for the person's bed is at the left front. That is not always the case. (I'm exactly opposite to that because of early flaws in the G29 code where it could not take negative offsets) But what can be done (either by switching the option names or by a different explanation) to make that better?
Would Delta and SCARA machines even use the G29 code?
Actually, my machine was originally setup with the origin in the front left. But there were problems with the least square fit of the Auto Bed Leveling in the early versions where they could not handle negative coordinates. The easiest answer was to rotate my origin to the back right. Then my probe was always in positive space. What I'm arguing is the type of machine may not insulate you from the issue.
I think having the parameters named Xmin, Ymin, Xmax, Ymax is much clearer. The big problem is none of the other GCode commands use long parameter names. And there is no support for the longer parameter names. The support code would not be difficult to do. But....
One idea would be to change the Code_Seen(char ) function to be Code_Seen(char *). It would be very quick to go through the code base (and probably it is just Marlin_main.cpp) to put double quotes around all the existing characters in Code_Seen() functions. We could leave everything else the same where it leaves a pointer looking at the numeric value for the hunted parameter. If we did that... Xmin, Ymin, Xmax, Ymax would work nicely and avoid a lot of confusion for people.
Right now, Code_Seen() is pretty trivial:
Code:bool code_seen(char code)
{
strchr_pointer = strchr(cmdbuffer[bufindr], code);
return (strchr_pointer != NULL); //Return True if a character was found
}
If we went that way... It would turn into something like this. But we may want to desensitize the comparison to upper and lower case. I don't know.
Code:bool code_seen(char *code)
{
strchr_pointer = strstr(cmdbuffer[bufindr], code);
return (strchr_pointer != NULL); //Return True if the specified parameter was found
}
The idea of Xmin, Ymin, Xmax, and Ymax seems so much clearer. EDIT: Stated before I read Roxy's post on limitations.
In tune with calling things really what they are, I'd recommend using n-by-n text in lieu of n x n in the comments. Those unfamiliar could think x is a variable, or an axis...
To facilitate merging the updates back into the Marlin trunk, I'd reconsider whether the fork uses the MakerFarm changes to the Type 6 thermistor. The Marlin trunk isn't going to want the Type 6 table changed - there could be people out there used to how it measures temperatures. Your configuration.h file also still contains the now incorrect comment about Type 6 not being as accurate as Type 1 and being created with a Fluke thermocouple. My vote would be to revert thermistortables.h back to the Marlin Type 6 data and change configuration.h to use Type 1 thermistors. Beyond what I concluded in the referenced thread, I think someone said zennmasterM has also said it's OK for MakerFarm people to use Type 1 when they update their firmware as part of his video on auto leveling.
EDIT: BTW - I've been using Type 1 just fine the last week or so. If, for some reason, we're uncomfortable switching to Type 1, the MakerFarm thermistor table could at least be defined as a new thermistor type that is used rather than modifying the Marlin type 6 table.
Dacb: Random new topic here: You modified the code to allocate space this way:
(I might have already added this code to your branch of the Marlin tree... But I could not Sync it)
This really is a better way of doing it than assumming the stack is deep enough to handle those large arrays. But we probably should check that the memory was available on the heap. We might want to add right after the malloc()'s something like:Code:// "A" matrix of the linear system of equations
double* eqnAMatrix = (double*)malloc(sizeof(double) * (n_points*n_points*3));
// "B" vector of Z points
double* eqnBVector = (double*)malloc(sizeof(double) * (n_points*n_points))
and the memory isn't free()'ed at the end. At some point, the Arduino board won't be able to do Auto Bed Leveling any more! :(Code:if ( eqnAMatrix==NULL || eqnBVector==NULL) {
SERIAL_PROTOCOLPGM("?Memory not available for Auto Bed Leveling.\n");
if (eqnAVector)
free(eqnAVector);
if (eqnBVector)
free(eqnBVector);
break;
}
Mean while.... I've got my post processing script for Slic3r finding the print's size and modifying the G29 in the GCode file. I guess I'll use F, B, L, R for right now... But I think my vote is for using XMIN, YMIN, XMAX and YMAX.Code:#endif // ORIGIN_FRONT_RIGHT
}
set_bed_level_equation_lsq(plane_equation_coefficients);
free(plane_equation_coefficients);
free(eqnAVector);
free(eqnBVector);
#else // AUTO_BED_LEVELING_GRID not defined
Forgive me if this is already addressed, I did not read every post thoroughly. I really need to be able to set a small Z raise before retracting the Z probe during ABL. At each point of bed probing, the probe is lowered and then retracts before moving again. The bottom of the switch housing sometimes hits the bed and sometimes hangs up. This could be fixed differently/mechanically but it seems like something pretty easy.
I also have a problem sometimes where if I have done a print that is only 2-3 layers tall, such as a business card, and then home Z, the nozzle is too low to allow the Z probe to extend. My ABL z offset is 5.6 mm currently, so this could happen on any print that ends at less than that height. It would be wonderful if this code could address raising Z by the probe offset plus a bit to avoid this.
I expect that if Roxy's keep probe extended setting is still an option this has already been considered. Again, thanks for all the work guys, it is appreciated greatly by us non-coders.
Yes, that is already handled in the Enhanced G29 code. And that can be obtained here: http://3dprintboard.com/showthread.p...ed-G29-command
But my suggestion is for you to wait a few days, because we are very close to having some other enhancements in place in the G29 and a specific version for the MakerFarm.
Again, thanks. I'll eagerly look forward to that update.
What? Somebody doing a malloc in Arduino code? Man, my respect for dacb just went up a few notches.
Dacb: I might have successfully cloned your latest branch of the Marlin code on my machine. I made the malloc() changes. But it would not let me sync them. The sync fails because I do not have permissions. Can you grab the code I added?
Also, I attempted to push my Slic3r G29 Post Processing script up into your PlugIns directory. I don't know if that worked either. Can you see it and grab it?
I looked through a bunch of documents about G-code and "standards" and I don't feel that multi-letter parameters is in the spirit. I would propose I, J, K, and L. These are clearly an array but not overly misleading in specificity (e.g. L,F,R,B). Each of these followed by a value in mm.
I have to agree with this. Going back to master on thermistors just makes sense, here is the commit: https://github.com/beckdac/Marlin/co...f473eed821097b
I can't actually take credit for that code, it is from https://github.com/ErikZalm/Marlin/pull/1022
Good catch on the missing free.
I'm a die hard 'avr-gcc/avr-libc and nice tight hand crafted libs on a Tiny' kind of guy, so I have to confess I don't use the Arduino environment for my AVR projects (but I love AVRs!). Hate the idea of loosing timers and the overhead. I guess with the 2560, this isn't really a problem.
Can you PM me your github username? I'll add you as a collaborator so your commits give you the recognition you deserve!
I understand your thoughts! And I 3/4 agree. The big problem is these one letter variable names cause all kinds of problems. And given the code cost is so minimal to support long parameter names, I'm actually thinking it makes sense to make a transition. After all... If somebody doesn't want to have a longer, clearer variable name in the G29 command, they don't need to use it. But with that said, I'm perfectly fine moving to some parameter names that mean nothing and add no confusion. It will be easy to document that I is the minimum X-Axis coordinate to probe. J is the maximum X-Axis coordinate to probe, etc, etc. What we really are trying to do is set this up so people aren't pulling their hair out trying to get it working. (and longer parameter names would do that just as going with I,J,K & L will do it. )
I don't need credit... But being able to make updates is helpful. I sent you a Private Message. But isn't all that stuff public anyways? Anybody that is using a fork in the tree can trace it back to every change that is made and who made it, right?
What are your thoughts on the Post Processors? The problem is even though I'm a big proponent of Open Source, I do use MSVC Studio for most of my C code when I'm playing around. I put the whole Slic3r Post Processor 'MSVC Solution' into your PlugIn folder. I deliberately made the thing very straight forward C code that uses nothing but generic library functions. It doesn't even have a header file. So it will compile with just about anything. But with that said... I'm wondering if the Open Source fans are going to be hostile about that? I guess if they don't like it, they can spend the time to take the single .C file and set up a GCC environment for it.
I understand your thoughts! And I 3/4 agree. The big problem is these one letter variable names cause all kinds of problems. And given the code cost is so minimal to support long parameter names, I'm actually thinking it makes sense to make a transition. After all... If somebody doesn't want to have a longer, clearer variable name in the G29 command, they don't need to use it. But with that said, I'm perfectly fine moving to some parameter names that mean nothing and add no confusion. It will be easy to document that I is the minimum X-Axis coordinate to probe. J is the maximum X-Axis coordinate to probe, etc, etc. What we really are trying to do is set this up so people aren't pulling their hair out trying to get it working. (and longer parameter names would do that just as going with I,J,K & L will do it. )
And perhaps we are worrying too much about the confusion. Anybody that uses this feature is going to be using the slicer (either Cura or Slic3r) Post Processors. The Post Processors will know the correct parameter name for each of the values. So everything will magically work for the user. Right???? (I think and hope so!)
Thanks! Mostly I do this just for fun and I don't need credit... However, being able to make updates is helpful. I sent you a Private Message. But isn't all that stuff public anyways? Anybody that is using a fork in the tree can trace it back to every change that is made and who made it, right?
What are your thoughts on the Post Processors? The problem is even though I'm back proponent of Open Source, I do use MSVC Studio for most of my C code when I'm playing around. I put the whole 'MSVC Solution' into your PlugIn folder. I deliberately made the thing very straight forward C code that uses nothing but generic library functions. It doesn't even have a header file. So it will compile with just about anything. But with that said... I'm wondering if the Open Source fans are going to be hostile about that? I guess if they don't like it, they can spend the time to take the single .C file and set up a GCC environment for it.
I totally understand your frustration about the parameters. I think your approach of using solid documentation like you have done in the past will be the way to signal the correct usage of more generic parameters like I, J, K, L.
Yes. I am a big proponent of github, but with this instance I was very frustrated. I spent a good half an hour trying to search through the master Marlin pull requests and I couldn't come up with your github username. I know you had the repeatability pull request accepted, but I just couldn't find a good way to search the history. WTF github?!!? I'd love for someone to tell me how to make that search work.
Emphatically: no problem. If you put your stuff in a repo, you are tacitly agreeing to the license that is already in place? I see now reason why your solution can't be considered open source. Open source is about making the source open, not about making it compile on everyone's OS. Can't wait to have your commits!
I have TortoiseGit installed and I can see changes in Windows Explorer to the files. They seem to track the status in the Git help as I commit and do things. But when I try to Push the changes (I'm right clicking on the top directory of your cloned branch in Explorer, selecting TortoiseGit and then saying Push) I get this window:
Attachment 2843
And when I say 'OK' it does this:
Attachment 2844
But it depends on the way I try to do the Push. Other paths produce a box saying this message:
fatal: Unable to find remote helper for 'https'
And of course... searching on the web doesn't really help. It seems like everybody getting this message is on a Linux machine and I'm using Windows. They want me to rebuild Git. They want me to switch to a different version of Ubuntu Linux. They want me to run a configure script and then do a Makefile with some options. Aaaargggghhhhh.....
This Git stuff is *NOT* easy to use!
And one more thing.... I did a revision graph of your fork. Can it be 'Re-Based' off of something higher up so it doesn't fall behind?
Attachment 2846
I really wish I could offer more support for using the git clients. I am mostly on the command line, but I have found the "official" github clients work well, I know there is a windows one: https://windows.github.com
I will periodically pull against the upstream master and resolve conflicts, but for right now we should be current. Is that what you mean?
OK! That sort of worked. I think I got the memory leak update pushed up. And I think I got the Slic3r Plug-In uploaded. But I'm not sure they are 'Committed'. I can view them on GitHub's web page and it shows your name in the fork so I think they are there. But then going any further up the list of changes I get conflicts and can't resolve them. There isn't anything that is worth resolving... I just made a couple of changes to the Configuration.h file to test if I could sync and commit this morning.
Maybe the thing to do is have you check if everything is still good and working... If you publish a link I'll re-clone starting at that point? That would get rid of all my conflicts and let me start fresh.
Well, it looks like Erik Zalm has made a couple of releases since you branched off. I was mostly wondering if I interpreted that right, and was curious why you didn't branch from a higher level.
* The memory leak fix committed fine: https://github.com/beckdac/Marlin/co...46120e33f10927
* as did the Slic3r script: https://github.com/beckdac/Marlin/co...87c5bb8b292614
* It looks like you didn't do a git pull before starting the changes to Configuration.h and the termistor table stuff reverted: https://github.com/beckdac/Marlin/co...87c5bb8b292614
I dropped your changes to Configuration.h (too hard to discern from the log, sorry) and reverted to the type 1 thermistor: https://github.com/beckdac/Marlin/co...21af567a295c68
Maybe you can do a git pull and then restore you Configuration.h changes?
* Finally, I noticed that your awesome missing free fix referenced the wrong variable name, I fixed this and it compiles great. I'm testing this on my machine right now. Commit: https://github.com/beckdac/Marlin/co...306c106ceaf9b6
I've pulled all those and incorporated them so we are good to go there.
That is certainly a possibility. In your web browser, click the fork link on my repo and get started. Issue a pull request when you have something to incorporate. Personally, I'd rather we were all operating on the same repo vs. another merge set, but open source works many ways and a fork of a fork is absolutely fine. Let me know which way you choose.
Thanks for all your hard work.
Great! I'm starting to figure out the process! The Slic3r one has more stuff in it, right? It has the both the Memory Leak fix and the Slic3r G29 Post Processor stuff? If so, that will be the one I should start from next.
I don't understand. I got the whole code base. Can't I just make changes to test stuff and send it back when it is right? I guess I don't understand this Push and Pull stuff. When I did the clone, doesn't that 'Pull' everything from the branch so I have it too? Or is the problem the fact that other changes were made in the mean time? If that is the case, my guess is there is a way to merge the two divergent paths back together again. But right now... I'm not advanced enough to do that.
I'll do a diff but I suspect there is hardly anything there to preserve. I was unable to make the Push work so I wanted to just have a simple change to the Configuration.h file to see if I could make it happen. I cleaned up some wording on a comment. It was a worth while fix but nothing that will be noticed if it isn't done.
Oooops! I went back and looked at my post. (And I cut and pasted that into the cloned image I grabbed.) I didn't have any way to compile it or I probably would have found that mistake. Sorry!
I certainly don't need to Fork! The reason I said that is that is the only experience I have for getting a code base. Is a Clone and a Pull the same thing? If so, then I understand why you said what you did. It would make sense to just Pull the current code base and use that as a new starting point. But I still don't understand why I needed to Pull the Configuration.h file to make a small change when I already had it. Maybe the answer is I didn't have the most recent version. The code base had already moved on from what I had???
You know, the lingo takes some getting used to. Here are my simplified thoughts... When you clone a repository, you make a local copy. As you work in there, you can commit changes to your local copy. Periodically, you can push those changes back up to the main repository from where you cloned the repo. Periodically, while working with your local copy, you want to pull down any changes from the main repository to your local so that you are current. I almost always do this before a commit on a group project so that I can resolve any conflicts beforehand. The idea of a local copy that only syncs with the main when you do a push is different from other source control tools.
When I fork someone's main repository, we branch off on separate development paths. When the repository that I forked from changes in, I can do an upstream pull where I sync changes in the main repository to my fork. You can also do this on a commit by commit basis so that you can test out each change from the main in the context of your fork. If I think I have some good changes in my fork that the main repository could use, I can issue a pull request. This is one thing that confuses people because you think of it as a push request from your fork, but the logic is the main repository maintainer has to issue the pull, not the fork maintainer issuing a push which could wreak havoc on the main repo's possibly unwilling recipient.
There are some canonical names (that can be overridden) for different pieces of a source tree. One of them is master which refers to the main branch that I sometimes call trunk because I also use subversion, sorry for that. There are also branches which can be given a name, e.g. RoxysAwesomeFeatureBranch. This is sort of a mini fork within a repository. One way to manage multiple people working on the same repository is to give them each a branch for development and then periodically after code review, the branches are merged back into the master.
For good software hygiene, I try to monitor commits and pull early and often. This way I can be proactive about dealing with conflicts, before I commit.
Hurray for software jargon!
I don't know if that helped or was just telling you stuff you already know.
Yes! Thank You for spending the time to explain that. That helped a lot. I need to get this latest code working with my printer so I can test out (and probably improve) the Slic3r Post Processor.
Note to DACB: I'm swamped with other things... But I'm going to be working on this when I get some time. The Slic3r Post Processor needs to be shaken out before it gets checked in.
Roxy, in the Mechanical Calibration section of your firmware, for the hobbed bolt, which part is the measurement? The bolt itself, or the hobbed part?
I believe that is the inner diameter of the 'hobbled' part of the bolt. I inherited those settings (or definitions) when I got the kit. I modified some of the things like the gear ratio on that line. But I did not create the original version of that definition. I did do a calibration early on in the build process and the extruder did put out the correct amount of filament, so until I changed the gear ratio, I left well enough alone.
I've found that 900 works for me for extruder steps, so I just played with the bolt diameter number until the equation gave as close to 900 as I could get. I really don't want to disassemble my extruder to be able to measure the bolt. I emailed Colin for a measurement, but that'll have to wait until tomorrow.
I am using the G-29 enhancements. I have a problem with the servo continuing to move during the print. it tries to rotate past the retracted position during printing and gets stopped by the X carriage. one time it went so hard it was stuck and I had to move it manually to get it working again.
I have the line
#define PROBE_SERVO_DEACTIVATION_DELAY 500
in config/h, so it's not the chattering thing.
Appreciate any help/ideas. Thanks.
If the servo really is deactivated, it shouldn't move. So that is one thing we will have to explore. The other thing we should check out is if your angles are correct for engaging the servo and retracting it.
Is it possible to post a picture of your Z-probe (and as much of the servo as possible) in both the up and down position? And can you post your Configuration.h file? What I'm thinking is we can give you some simple commands to verify that the angles are correct. And that the servo is being powered (and unpowered) at the correct times.
"This branch is 20 commits ahead, 34 commits behind ErikZalm:Marlin_v1"
Any news on what's going on with this fork?
I am in the process of setting up Auto Bed Level and ran into a few issues.
I used this set of videos to help me through the process...
http://www.youtube.com/watch?v=YpiOsetkIRg
When I went to run the G28 command to home the printer, it now homes near the center of the bed, and not the very back right corner like it used to.
How do i change this back? I am afraid to run the auto level command, cuz I think it will try to go off the bed too far now sense its starting in the middle.
This is probably due to the home position being different in the firmware linked in the first post here.
EDIT
Just went ahead and tried the G29 command to have it run auto level. (still cant figure out how to get home back to 0,0,0)
That seemed to work fine, it took 6 readings and stopped at the last position.
But, if I have the printer start a print, it does not autolevel first.
Is this something that will have to be added to all my gcode?
I see in Cura I can put commands at start and end.
Should I add the G29 command that? Or should I remove the 2 lines that have the G28 command and put G29 there?
I pasted my start code below.
And if I do, I assume it will run autolevel before the print, and store those readings, and proceed to do the print with those readings?
;Sliced at: {day} {date} {time}
;Basic settings: Layer height: {layer_height} Walls: {wall_thickness} Fill: {fill_density}
;Print time: {print_time}
;Filament used: {filament_amount}m {filament_weight}g
;Filament cost: {filament_cost}
;M190 S{print_bed_temperature} ;Uncomment to add your own bed temperature line
;M109 S{print_temperature} ;Uncomment to add your own temperature line
G21 ;metric values
G90 ;absolute positioning
M82 ;set extruder to absolute mode
M107 ;start with the fan off
G28 X0 Y0 ;move X/Y to min endstops
G28 Z0 ;move Z to min endstops
G1 Z15.0 F{travel_speed} ;move the platform down 15mm
G92 E0 ;zero the extruded length
G1 F200 E3 ;extrude 3mm of feed stock
G92 E0 ;zero the extruded length again
G1 F{travel_speed}
;Put printing message on LCD screen
M117 Printing...
EDIT.......................
OOOOOOOOOOOK, well taking out the 2 G28 lines and adding G29 was baaaaaaaad
Extruder moved RIGHT, hard crashing X and tried to go even further, slipping the belt, had to flip the power switch !!
Should the G29 line have anything after it? Or just G29?
EDIT..........................
Well this is odd, now G29 doesnt even work in Pronterface.
Printer does nothing, Proterface reads...
SENDING:G29
echo:Home X/Y before Z
It also says that if I try to home just Z
X and Y will home seperately just fine.
G28 seems to work, though it homes Z in about the middle of the bed.
The printer moves to the X and Y end stops,
then moves to about the middle of the bed, lowers the probe and end stops it, raises the probe, and stays there.
Now if I try to do a print, and have the original G28 commands in the gcode like before I started all this autolevel stuff,
the printer will home X and Y, then just start printing, without homing Z
It starts to print, and it too low, touching the bed.
So, I am basically stuck at this point and cant print till I get something working right :(
You need to have a G28 in your start GCODE, followed by the G29. You need both.
G28 X0 Y0 ;move X/Y to min endstops
G28 Z0 ;move Z to min endstops
You can change those lines to one "G28", it'll do all three axes if none are specified. Then put a G29 after them.
Yes, it'll do that if you have Safe Z Homing enabled. It's a feature, not a bug. :)Quote:
G28 seems to work, though it homes Z in about the middle of the bed.
OK, I see now that G28 has to be done befor eyou run G29,
that works fine in Pronterface, but when I tried to do a print the extruder homed X and Y, but then started to lower itself to home Z like it always does...
but it didnt lower the prob. And I killed the power just before it hard crashed into the bed.
So, do I need to put the prob extend command in my start code before I tell it to home Z with the G28 Z0 command?
Its odd that running the G28 command in proterface, the printer knows to lower the probe, but not when it was starting a print.
Just tried a print with this code....
G21 ;metric values
G90 ;absolute positioning
M82 ;set extruder to absolute mode
M107 ;start with the fan off
G28 X0 Y0 ;move X/Y to min endstops
M280 P0 S68
G28 Z0 ;move Z to min endstops
M280 P0 S155
G29
it acted very odd, it went through all the motions, even doing the auto bed level....
But never put the probe down at ALL.
Yet, it still lowered Z down and would stop, as if it had hit an endstop, then raised, and went to the next place, etc.
ahhhh, WTF? lol
Why are you calling M280 in the start GCODE?
Here's my start code:
M117 Resetting Printer...
G28 ; home all axes
M117 Heating Print Bed...
M190 S[first_layer_bed_temperature] ; set bed temperature, wait for it to reach target before proceeding
M117 Homing...
G28
M104 S[first_layer_temperature] ; set hotend temperature. Use M109 to set and wait
M117 Auto Bed Leveling...
G29 n 4 ; auto level
G1 X99 Y99 Z1 F1500; reposition extruder
M117 Printing...
I added the M280 to try to get the probe to extend, but it has no effect.
What is the n 4 you have after G29?
Also, if I use the Prusa LCD control and tell it to Auto Home,
when it moves to the center of the bed to home Z, it does not extend the probe.