- October 19, 2017 at 2:31 pm #46301
Andy, most likely what actually smoked is the plastic in the green connectors. Without that power coming in, or only very little of the power coming in, anything that requires 12V will be left unpowered. Also if you don’t have a USB connection to a computer the 5V stuff will also be off. Your symptoms match that, since the steppers and such use 12V and the display uses 5V. When you were getting a faint image I bet there was just a trickle of power getting through that melted plastic.
Easiest fix is obvious, replace the RAMPS. Harder but still doable is to replace the green connector. Unsolder it off the board and solder a new one in place. Don’t try it if you’re unsure of your soldering skills since it’s not out of reach to lift a trace up when unsoldering the old one, breaking the board more completely. 🙁
You can use the A4988 drivers, but you’ll have to tweak the software since they don’t support 1/32 stepping. There’s not really a large cost difference between the two types, so I always go with the better DRV8825 drivers.
1 user thanked author for this post.October 19, 2017 at 3:20 pm #46309
Ok thanks a lot for the info…Do you think the lcd is probably good??…ok I wondered which driver is better, I’ll definitely go with the drv8825’s then.
Since I’m on this topic and I haven’t ordered yet. Is there a board that cost marginally more than the Ramps that is a worthy upgrade, that would still function exactly the same as far as firmware and capabilities?? I wouldn’t mind to spend a little more but not quite ready to lay down the cash for a full Rambo…the mini won’t work for this dual end stop setup of course.
I see that these Ramps kits are branded differently on amazon..Do the brands mean anything at all or there all just the same thing?October 19, 2017 at 4:08 pm #46311
From what I’ve seen, ramps are ramps. Some use better components, and others color code their boards differently. For the price, they all pretty much seem to do the same thing.October 19, 2017 at 5:26 pm #46313
That’s about what I figured…thanksOctober 23, 2017 at 10:24 pm #46569
Finally got my machine back together. Its about 1 a.m here. Pretty excited about this, i think it will really help me. I am running into a small issue though, that i hope i can get some help with. When i move either axis far enough away from the end stops, they move a certain amount and then stop like they have hit end stops when they really haven’t. When it does it, it seems to move the same amount of distance before hitting the non existent end stops. I can hit home again and it will go the rest of the way and home properly. I have no idea but could the firmware only be allowing it to move a certain amount to home, like the machine had a set size or something? When it reaches that “Size” it tells it to not go any farther as a fail stop?? I know very little about the programming/firmware side so i am just throwing out a thought. I have some videos to put together of the swap over process including video of this issue i am talking about. I hope to get it put together and submitted for the contest if there’s time (Had to wait for another ramps stack). If not ill put just a video up of the issue if necessary.
AndyOctober 24, 2017 at 4:01 am #46572
That’s usually electrical interference. Your endstop wires are inducting a small voltage from something and it’s tripping the endstop circuitry. Mine does that occasionally too, but I’ve never had an issue while milling something. Not sure if the endstops are active while milling.October 24, 2017 at 4:10 am #46576
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.October 25, 2017 at 9:57 pm #46693
Where do I adjust how much the z axis raises before homing?
ThanksOctober 26, 2017 at 5:54 am #46714
Pretty sure it’s the clearance setting.October 26, 2017 at 6:06 am #46715
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??October 26, 2017 at 6:59 am #46718
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.October 26, 2017 at 8:50 am #46726
I found the post I had read.https://www.thingiverse.com/thing:1023985 They snap on without removing the rails, I typically use zip-ties to keep them on screws are overkill. With this firmware you just need to get the endstops close and you can fine adjust an offset to get it really precise. This also picks up the Z axis before homing, I have it set to 10mm right now I think but usually that is plenty. A bunch of it is adjustable, which axis homes first, all at the same time, whatever. I need to get a better video of it but, I kinda got stuck on another project at the moment.
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.
AndyOctober 26, 2017 at 6:42 pm #46739
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.October 26, 2017 at 6:51 pm #46740
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.October 27, 2017 at 9:14 am #46763
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?October 27, 2017 at 9:54 am #46766
JasonParticipantWhen 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.
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 😀October 27, 2017 at 10:26 am #46769
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?October 27, 2017 at 10:51 am #46770
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?October 27, 2017 at 11:03 am #46771
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.October 27, 2017 at 11:13 am #46772
Sh%t it works, the X2 and Y2 got swapped, thats all my bad, sorry.October 27, 2017 at 1:19 pm #46777
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.October 27, 2017 at 3:45 pm #46785
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.October 27, 2017 at 4:05 pm #46786
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.October 27, 2017 at 4:11 pm #46788
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.October 27, 2017 at 4:13 pm #46789
Ahhh man, how do I download it? With your branch I had access. Now what?October 27, 2017 at 4:57 pm #46797
Everyone cross your fingers right now!!! Travis test compile is happening right nowOctober 27, 2017 at 4:59 pm #46798
Ahhhh so close, Thinkyhead is re configuring the way the endstops are called and has implemented the Dual end stops into the travis test compile. It didn’t work but it is sooooooo close right now.October 27, 2017 at 5:01 pm #46799
I would have never guessed in a million years I would be so stoked to watch someone compile code on a Friday night.
…My life is different now…October 27, 2017 at 5:09 pm #46800
Travis is compiling it, the conflicts is just git saying there won’t be any conflicts. There would be conflicts if both branches had changed the same line, or one branch had deleted a file and the other changed it.
You can click on the details on the right of the Travis line and it will show you what’s failing. For some reason, the Travis and conflicts lines aren’t showing up on my phone.October 27, 2017 at 5:12 pm #46801
I am that nerdy now I am watching the travis tests happen as he tweaks things. Looks like he tried to condense some of the endstop code and it isn’t playing nice.
You must be logged in to reply to this topic.