Maybe there’s not an easy way to run Travis outside of GitHub. I would be fixing this offline before pushing the fix. But then you couldn’t watch…
I just looked through the travis site, it seems to be tied to gethub, but not part of it? This last test was so much closer. It didn’t totally blow up just one little error with the Z axis and we didn’t touch that one! High five.
I just looked at running Travis locally. That’s clearly not part of their business model, so they haven’t designed for it.
I did find the funniest name for a package ever: https://github.com/grosser/wwtd
W.W.T.D. What Would Travis Do? Perfect name.
It does look like you can build a docker image similar to what Travis uses. But then you’re stuck running each command in the travis.yaml yourself. It would be nice if the configs from the failed builds were available at least, then you could plop them into your local checkout and at least get pretty confident it would build.
Also, also, I wonder if those config scripts would help you with your deliveries.
I did see the config scripts wondering how it was happening. I think the software you built for me will work, I seem to understand it well enough. I have just been so sick of looking at the firmware, merging, compiling and testing I was going to wait to use yours on the next round firmware updates. That email is one of the only ones in my inbox…and i’m pretty good at keeping my inbox at zero.
I am tuning in the new firmware now that it is merged. Can you tell me why you wanted to change it? Was there an issue or just personal preference? To me it seems the safest thing to do is pick the Z axis up before moving.
Well at the time I was still figuring out my g code and how I wanted to use the machine with a home position. The clearence of the Z turned out to be a non issue after a I figured out what i was doing. It’s a good thing, it would be nice to know what that clearence is. There could be instances where you might want it higher or lower. You could always do this with g code. The software endstops really messed me up at first, and had me blaming the clearence plane of the Z. But it was just the non ability of going negative in the Z and my correct commands causing it to move in the opposite direction. So, clearence is good on Z but should be notated as to what that clearence is. In my opinion the software end stops should be completely disabled as well in the firmware…all in all after trial and error it’s so nice to have a home position I can rely on. Thanks Ryan. I want to put a video or two up of the feature when I find the time.
Thanks,
Andy
We also got a change in to configure soft stops by axis, so you should be able to leave on in X and Y but turn it off in Z.
I’m not sure anyone has successfully tested it, but it’s in bugfix.
I have tried a few times, still nothing. I haven’t looked to see any obvious problems though.
Damn. I’ll have to check this out. The code was so simple. Can you PM me a link or zip to exactly what you’re running?
Quick overview video as promised.
Like the video!
Dupont 2.54mm (0.1")
I think your touch plate interference is from the spindle power supply.
We can tighten up your Z routine, soon. Sorry it has been a busy week and setting up the new firmware keeps getting pushed as I prep orders. Worked so dam hard to get it merged now I am lagging with instructions…lame.
Thanks Ryan, nice clarification on the pin spacing of the DuPont connectors…Ya theres a good possibility that could be causing it…at this point the paper is working great, so I’ll stick with it for a while…
Hey man don’t beat yourself up we all get busy and get behind, you can trust me on that! Running a small business isn’t easy…takes commitment, infinite patience, and a lot of a thing called hard work. My Dad’s been running one for 30 years, and I’ve been right there experiencing it. I have great respect for the ones that make a go of it. Keep up the good work.
Andy
1 Like
2.54mm is 1/10th" or 0.1" /pedantic
I just updated my MP3DP to bugfix 1.1.x, and I tried the softstops by axis configuration, and it worked the way I expected.
Configuration.h
// Min software endstops curtail movement below minimum coordinate bounds #define MIN_SOFTWARE_ENDSTOPS #if ENABLED(MIN_SOFTWARE_ENDSTOPS) #define MIN_SOFTWARE_ENDSTOP_X #define MIN_SOFTWARE_ENDSTOP_Y // #define MIN_SOFTWARE_ENDSTOP_Z #endif // Max software endstops curtail movement above maximum coordinate bounds #define MAX_SOFTWARE_ENDSTOPS #if ENABLED(MAX_SOFTWARE_ENDSTOPS) #define MAX_SOFTWARE_ENDSTOP_X #define MAX_SOFTWARE_ENDSTOP_Y // #define MAX_SOFTWARE_ENDSTOP_Z #endif
After that, I had the hotend in the middle of the space somewhere, powered on and through the LCD menu, I tried moving around. I could move negative in the Z, but not in the X or Y. I think that’s what we want. That was before homing, and then I tried it again after homing. I assume 2.0 would work the same.
On another note, while looking through the configuration, I noticed a comment that points out M120/M121, which will enable/disable the endstops. So if anyone is having probe/interference issues, you can add M121 to the start of your cut, and M120 to the end.
http://reprap.org/wiki/G-code#M120:_Enable_endstop_detection
Sweet heffe I am glad to hear it. The hacks I had to do to Arduino to get it to work with the 2.0 version must be the issue. I had another problem with it a few days ago. It doesn’t let go of the compiler data or something I could delete whole lines out of the configs and if the versions didn’t change they’d still compile. I have to reinstall Arduino and try to figure out what the heck is going on. To get things to work I had to use the newest Arduino beta so I knew it didn’t have the hacks in it that seems to work. Today my plan is to get all the firmwares done and out and do some testing.
Sorry to have made you get out the ramps. I knew something was fishy that’s why I didn’t make a big stink.
I think you might be seeing why people like platform.io 
The Arduino IDE doesn’t reload file changes outside the program unless you have “use external editor” on in the preferences.
I tested with 1.1. I’m not trusting 2.0 until there’s a release. I hope there’s nothing wrong with the soft endstops in 2.0, but I trust thinkyhead do have integrated that correctly.
I have ramps on my MP3DP, my piCNC on my low rider, and my mini Rambo on the zen (Which I intend to move to the MP3DP). I also didn’t try dual endstops, just the soft endstops.
I know its all getting so complicated and dam marlin is moving really fast right now, so many updates and new features. If they start focusing on just one branch we will have some serious innovations.
I have a stack of boards in front of me that all need firmware and testing…Might be time to set up that script.
I was just told about what seems like a pretty mature python firmware “kippler” Might be right up your alley?!?
Yeah, I was thinking about that script again this morning. I had to make a bunch of identical edits for my MP3DP for the version I was interested in, and I thought that maybe I should just make the script do it. But, it wasn’t bad for me.
I can’t find any kippler stuff (besides info on the fish). This is CNC firmware?
Also, sorry Andy, we’ve hijacked your thread.
My impeccable spelling might have been the cause.
Dang Heffe I figured it out…I doesn’t work in repetier host after homing, but it does work with the LCD, I typically only test with repetier since it’s faster…Shoot, I don’t see an easy way around it in the settings either.
// Min software endstops constrain movement within minimum coordinate bounds
#define MIN_SOFTWARE_ENDSTOPS
#if ENABLED(MIN_SOFTWARE_ENDSTOPS)
#define MIN_SOFTWARE_ENDSTOP_X
#define MIN_SOFTWARE_ENDSTOP_Y
//#define MIN_SOFTWARE_ENDSTOP_Z
#endif
Andy, I have a 2.0 ramps dual endstop firmware on my github page, when you get a minute can you see if you can compile it. It works for me as is with arduino 1.8.5.
Ok. I can try that easily, now that I’ve upgraded to 1.1