No, I think that’s the software endstops. The is an x and y size set in the firmware. In Configuration.h.
If you comment out MAX_SOFTWARE_ENDSTOPS. Then that should take it away, or else you can set the bed size right above that in the file. The default is 200mm, but I’m not sure if Ryan’s default is something else.
Where do I adjust how much the z axis raises before homing?
Thanks
Pretty sure it’s the clearance setting.
I know about that setting in estlcam but that’s not the case for this particular thing I’m talking about…If you home without any g code entered it still pulls the Z up before homing…I thought I seen where Ryan said he set this distance in the firmware somewhere??
I’m not sure, I can;t find it right now I looked. I do not think it is hard coded but could be. I see three options in config and config adv 2mm 5mm 10mm, measure yours and change that setting to see if it effects it.
I could have sworn it was a setting but, I have been in 2.0 for a while now so I can’t remember.
I found the post I had read.
What line numbers are these setting your talking about? I’ll have a look tonight and see what I can do.
As another note, do you have software end stops disabled in the regular firmware? I didn’t notice dealing with it before…it effects my ability to go negative in the Z axis. For now I’m simply using “M211 S0” to disable them before doing anything, and that works.
I am also now having more issues than ever with the touch plate sensing randomly on its own before actually touching. I probably need to start a new thread explaining that issue.
Thanks,
Andy
I have not touched this, since Marlin V2, we got another update, hopefully it will get pushed soon. I can’t support all these firmware and do custom edits right now. As soon as v2 gets pushed I will spend more time updating settings.
What issues are you having with the z picking up, it is a really good safety feature.
I hope that doesn’t come off as rude. Maybe I should explain.
Trying to get 750+ lines of code pushed means I am updating my branch several times a day whenever they push an official update. Then I have to merge all 3 branches I am using to test, flash the ramps version and Rambo version and test them an a cnc. If there are errors I have to figure out what happened and fix it. 2.0 is starting to be very different and I am not enjoying spending so much time with the firmware. When the update gets pushed I can edit my branch to my hearts content and not worry about screwing up an official branch I have a feeling I will only get one shot at this and if I screw up chances of me getting anything else pushed will probably pretty slim. Coding isn’t my comfort zone.
No worries ill get it Figured it out. I about have my g code the way I want it to accommodate homing and eliminate the z touch plate in tool changes for now. I wonder if heavy shielded wires would help the z touch issue? Anyone have any experience with this?
On the upside…sounds like thinkyhead is looking to merge your changes today! So hopefully this code will be officially an official part of Marlin REAL soon 
Downside is neither work right now…1.1.x is only 1/2 working and I haven’t looked at it in a long time, 2.0.x hasn’t been compiling in arduino for a few days So I have no way to know if my edits still work. They all develop on platform.io and it is causing me nothing but issue in arduino, but if it doesn’t work in arduino I do not see many people using it. Some of there attitudes are “arduino needs to update there IDE to make it work if not we will just stick with platform.io”…I can not get it to flash an arduino board, so how many other people will have issues?
Platform.io is awesome. It can flash Arduinos fine. But excluding Arduino ide isn’t very smart. There are so many reasons Arduino is the first thing people use. Platform.io is a second step for most people.
Hopefully, Arduino ide will update by the time they stabilize 2.0. if not, then it’s worth pushing the fix until it gets closer to release.
I looked at the code, but I skipped a bunch because I was just looking on my phone. Maybe I’ll get some time this afternoon to look closer at the changes and send why it’s doing what you’ve described. Do you anything you want to add? Only one stepper is moving, is that all the time, or just during homing?
We have put so much time and effort into this. What crazy timing to finally get this pushed. Both versions not working, choosing the other branch instead of the new one, and I have been out working on the business side of things not R&D for the first time ever…Grrrrrrr.
M119 seems to work m666 seems good. Moving and homing the steppers engages both but only the first, not the secondary move I think. I will re-flash and double check right now.
The other thing that didn’t work was enabling the dual and not enabling the corresponding max endstop didn’t throw an error…which it always used to. Which makes me think this is a big error.
Sh%t it works, the X2 and Y2 got swapped, thats all my bad, sorry.
I looked through it with an actual screen, and it still all seems fine to me (but I’m not an arduino, so your testing is worth a lot more). The commits coming from 1.1.x or 1.1.5 with us into bugfix still bothers me, but I seem to be the only one that cares. Oh well. It will be nice when this gets merged. I assume 2.0 merge will be soon thereafter.
It also seems like 1.1.x is not abandoned yet, not by a long shot. Developers sometimes drag these big version releases for a long time, even if the features they have are ready. It’s an excuse to make a mess, and fix things that you have wanted fixed for a long time, so I’m guessing they will put more and more features into 2.0 until it just has to be finished, and that could be a few years from now. I hope they will get your PR in much sooner than that, but I wouldn’t expect using 2.0 as your branch for your software configurations anytime soon.
Something that would be really nice to come out of the HAL would be some kind of simulator. Something where they could run the whole bunch of code with simulated hardware, which could then be automated, and things like this dual endstop stuff could be tested without an actual board, and without actual motors, in a fraction of a second. Something like that would be very valuable considering the number of configurations they are supporting. Maybe soon, we’ll have to maintain some MPCNC version of their simulator, with different configurations, and a list of tests needed to verify that Marlin will work for everything we end up doing that’s different than most.
I am glad I am no the only one lost by how that all works. I figured open source, volunteers, it is a mess because of that. I barely understand this whole thing, I thought he had made all those changes this morning I didn’t even know those were just comments…My bad, I appreciate you making those changes. I Can’t say it enough but I truly appreciate all the help you have given me and all the time you spend on these crazy tangents (testing all the machines, coding, sandify, emails, forum support). Dude, High five!
It does suck about the 2.0 platform.io thing, I get that it is easier but 2.0 works great and compiles smaller when it isn’t messed up by the file structure of arduino vs platform…And doing 2 sets of commits, yikes. I can tell you all major printer manufacturers rarely ever update the firmware to avoid drama. So they are maintaining two versions for the few early bleeding edge adopters, I vote make the jump to 2.0.
I’m dropping off today’s orders and then I will come back and see why this thing isn’t passing the travis test now that the PR moved.
It’s fun. But thanks for the thanks.
W.r.t. the Travis this, I thought he pushed a fix for that, but I can’t tell from my phone. The sanity check seems fine, I think the travis.yaml needs to be updated for that dual_endstop_z test. I didn’t realize it was doing that. It might make sense to put your configuration into the travis.yaml so it starts testing the dual x, dual y configuration so no one else breaks it (I’m looking at you, delta people!). I wonder if there’s an easy way to run Travis locally.
Just got back, downloading it now, it still says fail, but also says no conflicts? Never seen that before. The previous branches passed the test but I also know the test…doesn’t test it.
Ahhh man, how do I download it? With your branch I had access. Now what?
Everyone cross your fingers right now!!! Travis test compile is happening right now