stevegt
-
Posts
91 -
Joined
-
Last visited
Content Type
Forums
Events
3D Prints
Posts posted by stevegt
-
-
On the other hand, if your existing PT-100 is still working electrically, you might just get some high-temperature adhesive and re-install it in the old sleeve that's stuck in the existing block. It sounds like that's what failed in the first place anyway. Could be the vendor for that PT-100 cartridge used the wrong epoxy. The 1185 data sheet wants a 0-400C temperature range.
Steve
-
The UM2 github repository shows that thermocouple as Ultimaker part number 1185-B2P-A, PT100 B sensor, 3 mm diameter. https://github.com/Ultimaker/Ultimaker2
Some quick googling found this one -- not an exact match, but the diameter is right:
http://www.tme.eu/en/details/pt106054/resistive-temperature-sensors/
I don't see any epoxy step in the assembly manual -- I wonder if the thermocouple sleeve is fusing to the block in some sort of thermochemical process?
It just occurred to me... the STEP file is in github, and Shapeways can print in brass. You'd want to tweak the STEP before exporting as STL (make drill holes smaller and make sure the external threads have the right OD for use with a hand die). Then finish the printed part by hand, drilling and threading the details. So, if you're in a hurry, you could get a raw brass block in hand from Shapeways, in a couple of weeks, for about $25 USD (not including shipping). :smile:
Steve
-
Thank you Daid!
I quick touch test of the 14.06-RC6 .deb works for me. I'll print a minical or something and report back.
Conz, thank you. That sounds much better now. I think you'll find over the next few days that you're spending a lot less time adjusting the bed. :-) Don't worry about first observations -- it took me a while to figure out what the heck I was looking at too. And if you want to see me floundering around myself, just google for "umforum linux usb reset". Still working on that one.
Steve
-
In my own repo copy I now have:
// 72 = Ultiboard v2.0 (includes Ultimaker 2)
...I tried to also say something about future UM1 kits, but got all tangled up in time warp grammar and gave up.
I'll include this in a lifetime_stats Makefile update I'm sending your way.
Steve
-
I can tell you my story -- several weeks ago, my wife and I had finally decided to pull the trigger on buying a printer for our 7-person cable manufacturing business. I had settled on either a UM1 or a UM2. I really wanted to put a UM1 together myself so I'd be able to better understand and hack things, but since this was after all a business tool, it was harder to justify the time it would take me to assemble, test, debug, modify, and finally get the printer the way I wanted it. My wife agreed, and she also liked the looks of the UM2.
So, being in the States, I checked the Maker Shed web site for a UM2: "Out of stock". Ultimaker web site: "8 to 10 weeks". I was feeling about like you probably are right now.
But life finds a way. In my case, I finally realized that the San Francisco Bay Area Maker Faire was coming up in three weeks, and *surely* Maker Shed would have some for sale there... And they did, 30-40 of them. Full story of that escapade is at http://umforum.ultimaker.com/index.php?/topic/5787-post-maker-faire-um2s-in-stock-at-maker-shed/.
Maker Shed is still showing them in stock as of today. Shipping cost to the UK should be about 75 GBP.
Worst case, if I had ordered a UM2 from Ultimaker when I first wanted it, I probably would have gotten it about three weeks from now.
In my case the UM2 is well worth it, and this community is where half the value is. In three weeks I've been able to print the parts for a tricky project that would have taken me all summer to machine on my CNC mill. I did run into one bug, but with the help of these folks I was able to figure it out, and because Ultimakers are open source I was able to fix it, build my own firmware, and contribute the fix back via github. My bug fix is coming out in this week's UM2 firmware maintenance release, less than a week after I first found the bug itself. Granted, as I did in buying the printer, I did put some effort into making this bug fix happen, but I doubt I would have had anything like the same good experience with a closed-source printer.
If you're still on the fence, I just noticed that the Paris Maker Faire is coming up in a couple of weeks -- might be a fine excuse for a Eurostar trip. :wink:
Steve
-
Okay, it's all in github, I've renamed the repository on github as well, added a README, and adjusted the URL in my first post above accordingly.
Still haven't gotten around to checking that math. ;-)
Steve
-
Hey George,
Go ahead and change the thread title (just delete the "UM2"?).
Thanks anon, I'll get it into github, probably add some docs there as well.
Steve
-
Another clue -- got a string of timeouts from Cura today, no luck loading firmware. Exited, restarted, same problem. Connected via pronterface, no issues there. Went back to Cura, loaded firmware on first try, works fine since then.
The timeouts always come in solid strings. They're not intermittent; it either works or it doesn't. Recalling my earlier experiences, Cura had upload timeouts for the first two days I had it. I gave up, started playing around with pronterface, didn't get it working because of the old pyserial, went back to Cura and it began uploading fine.
Hypothesis: Something pronterface does with DTR or the Linux USB device is cleaning up whatever problem Cura is having.
When this happens in the future, I'll try other tools -- miniterm, stty, and setserial -- and see if any of them have the same curative effect. I'll also see if pronterface is consistent in its effect.
Since I can't make the timeouts happen on demand, this is going to take a few weeks, maybe months. :wink:
Steve
-
Checking in... So far I haven't managed to melt the plastic feeler gauges. The manufacturer says they're "polyester with max. operating temp of 200F", but I haven't paid any attention to the temperature and they're surviving fine. They're cheap, come in packs of 5, and I haven't thrown away the first one of each pack yet.
The thing I'm liking about the polyester versus metal feelers is the flexibility -- they're 12" long, lay flat on the bed, and are easy to scoot under the nozzle and sense friction.
Steve
-
I think this sounds great at first but sometimes other things need to be considered. If the switch is broken and shorted it will always report closed so step 1 may be an infinite loop plus you might break the glass. 7mm is a good compromise.
Agreed. Simon, in his earlier algorithm description, added a 20 mm travel limit to handle the case of a stuck switch.
Assuming 7 mm works for the UM2 (and I think it will), refactoring the homing code falls into the category of "risks breakage, but will get rid of three of the many magic numbers that have to be tuned for new printer models". Magic numbers bad, autodiscovery good. Not urgent, but worth thinking about for the next time someone has to touch that section of code.
I'm still thinking about whether that 20 mm can be replaced with (Z_MAX_LENGTH / 10), for instance.
(BTW, I'm used to seeing CNC mill and other machine limit switches open on contact, not close, because that catches more failure modes. Are we backwards in our conversation here, or did someone back in the depths of reprap time decide to make them close on contact instead?)
Steve
-
Oh, that is strange. Hmmm...
My firmware is 14.04 from April 24th, too. (Installed with the RC5 WIn7 exe)
I have printed some parts of roberts feeder. No releveling was necessary. Before that update I have had a lot of leveling problems.
Maybe the version tag is wrong? Or there must be something different that has been fixed with this update.
I'm a little bit uncertain now.
Maybe you're just lucky today. :wink: No worries, we'll figure it out.
Can you try something for me?
- turn off your printer
- press down on the back of the bed until it moves all the way down to the floor
- turn the printer on
- hit "Maintenance|Advanced|Lower buildplate", and watch how the bed moves
If the bed only moves up 3 mm and stops, then you still have the old code. If the bed moves up 7 mm, then down about 4 mm, then stops, you either have the new code, or your printer is one of those whose switch is opening right at 3 mm, which means sometimes it'll work with the old code and sometimes it won't.
Occam's Razor says you have the old code. I've been watching and working among Daid's recent github checkins, and I can't see any way the version string would still say 14.04 but be the new code. He incremented it to 14.04.1 later in the day on Apr 24th, and then 14.06.1 today, Jun 5th. The copy I downloaded has the 14.04 version number, and it behaves like 14.04. The difference between building either of the two is only one git command.
Just hang in there -- I'm pretty sure he'll wake up in the morning, read all this, whack his forehead and then sort it out. :wink:
Steve
-
For those with this problem and not wanting to venture into firmware building themselves.
I've uploaded an RC5 with this firmware fix:
http://software.ultimaker.com/Cura_closed_beta/
If nothing is wrong I will make this an official release tomorrow (I really need to do this maintenance release, also to fix the quality bug)
Daid, when I install http://software.ultimaker.com/Cura_closed_beta/cura_14.06-RC5-debian_i386.deb, I do get Cura 14.06-RC5, but when I run that and "Machine|Install default firmware" it installs Marlin 14.04 from April 24th, and I get the old behavior.
Conz, Didier, hang in there, we'll have you running in a bit. :wink: If there's any doubt (maybe it's only the .deb that's behind), just check "Advanced|Version" on your LCD. It should have a build date of June 4th or 5th, with a more recent version number (github shows 14.06.01 right now).
Steve
-
Just a followup from those measurements I posted last night, and what I was saving to mention until I had time today... What it appears is happening on my particular printer is that the 3 mm retract distance in 14.03 almost exactly coincides with the point where the switch opens when the bed is moving in a upward direction. If my switch were opening a fraction of a millimeter earlier, I may never have seen this bug myself. That helps explain why the reports of this bug have been so cryptic -- even some people with falling beds may not see it, or may only see it intermittently.
Simon, without looking at the code again myself, based on those measurements it looks to me like the homing algorithm as written is not the one you and I would expect, but is instead The Simplest Thing That Could Possibly Work:
- move in a direction that would take us away from the switch
- stop after traveling Z_HOME_RETRACT_MM
- move toward the switch until it's closed
- stop, consider homing complete
I haven't yet tried to check it electrically, but I think my limit switch really and truly might never be opening when homing from the full-down position. This is causing no movement in step 3 above -- it looks like we're skipping 3 and jumping right to step 4. That theory is consistent with what I'm seeing the printer do -- it just moves up from the floor and stops.
A good refactoring might, I think, replace all of the *_HOME_RETRACT_MM constants with a seeking algorithm similar to the one you described:
- move away from the switch until it's open
- move towards until it's closed
- stop
That would keep the same build volume that we have now, and get rid of these magic numbers. If I understand Daid correctly, we may not be able to detect switch opening while moving, but maybe we can do that move iteratively.
Steve
- move in a direction that would take us away from the switch
-
Did you use this for your source?
https://github.com/Ultimaker/Ultimaker2Marlin
If so then in Configuration.h I found:
#ifndef MOTHERBOARD
#define MOTHERBOARD 72
#endif
So I suspect 72 is correct. The UM1 uses the arduino mega2560. I don't know which arduino chip the UM2 uses.
Yes, that's what I'm using for my upstream. I also saw that #define, which is what made me try 72 when 7 didn't work.
Over in https://github.com/Ultimaker/Ultimaker2Marlin/pull/30, Daid seems to be saying that 72 is wrong for the UM2 though. Googling for those DIOSDCARDDETECT_PIN errors didn't find me much, which makes me think that building with 7, while using the Makefile or Arduino IDE, isn't something that many people are doing right now.
I haven't dug through what differences there might be between codeblocks and the other build methods (and I might need the codeblocks XML to do that). It could be this is just a case of both the Makefile and .pde drifting behind codeblocks, getting the #ifdefs tangled up in such a way that 72 just happens to make it work right now.
Steve
-
Just measured. In the CAD model it's 4.9mm of maximum travel. And I'm measuring about the same on a real limit switch. So I rather put this move-back value at 7mm to be on the safe side.
Hi Daid!
If the model shows 4.9, then yes, 7 makes more sense. I also saw you changed the other switches as well. I've just tested that, looks good as far as I can tell right now without doing any real-world printing.
Steve
-
Okay, right after I posted those numbers, I started staring at them. I'm not even going to say what I'm thinking right now -- I'll leave that as an exercise for tomorrow. There's one piece of information I'll add to this, and that is a reminder that I was measuring at the front edge, and that the front of the bed droops once it's off the floor. So, in this universe, 30.1 - 27.4 is probably going to turn out to be exactly equal to 3 mm. :-P
G'night,
Steve
-
Okay, I got some measurements. Not going to analyze them right now, because I should be asleep. I'll just paste them here and we can all look at them tomorrow in the cold light of day. George, I wasn't able to cleanly count steps, because the weight of the bed makes it tricky to feel them while rotating -- and if my finger slips, the bed falls back down. That should give you an idea of how different our leadscrews are. What I was able to do is move .1 mm at a time in pronterface, and listen for the click. I was measuring this at the front left corner, so the springiness of the buildplate and stickiness of my caliper's slide made it tricky. Next time I'll either measure at the back or rig up a dial indicator instead.
Simon, that limit switch trigger screw looks hard to get to -- have you ever tried adjusting it without removing the white cover plate? Is it even adjustable? Looking at its reflection in the back wall, I don't see any jam nuts or anything else in there that would cause it to hold if it were loosened -- it looks like it's just screwed through the bed plate until the screw head is firmly seated. I think I'm starting to see why George is suggesting that people bend the switch tab, even though the very idea makes me cringe. :wink:
All measurements are in mm, as measured from the floor to the top of the glass:
firmware 14.03:
===============
bed height grounded: 27.4
bed height after first G28: 30.1
bed height after second (and later) G28: 29.4
firmware 14.04.1-stevegt1:
==========================
bed height grounded: 27.4
bed height after first (and later) G28: 29.4
bed height when switch opens (moving upward): 30.1
bed height when switch closes (moving downward): 29.4
Am able to G28, then M18, push bed down, M17, then G1 F10 Z205; e.g.
limit switch closed doesn't prevent Z move. -
Python code to generate circle gcode for UM1.
NOTE: someone needs to check my calculations especially around the extrusion amount.
Very cool. I'll see if I get a chance to check the math for you tomorrow -- where did the 0.2925 number come from? Or is that one of those black magic UM1 potions that wood machine masters keep under wraps? ;-)
Is it okay if I add that script to the github repository alongside the UM2 version? Or even -- horrors -- merge the two scripts? I'd want to credit you either way (GPL okay?).
Steve
-
The purpose of the homing-retract distance is to move the head up above the switch, and re-approach more slowly. Setting any amount there shouldn't cause the bed to ever bang into the floor when homing. The bed will move down until the endstop is triggered, then move up by the retract distance, and then go down until it triggers again.
It seems that the distance is also used as the initial 'try to move up until its not triggered anymore' distance if the endstop is already triggered when homing. Not sure that it really should be - it's two totally different concepts. The way it should really work is that there's a maximum limit set, and if that's not enough to untrigger the endstop, then the printer should abort. E.g., set a limit of 20mm. If the endstop is already triggered when homing, then it should move up until it's not triggered any more. Then move up more by the homing-retract amount, and then go back down to the trigger point, and stop. If in trying to do that it goes up by more than the limit of 20mm without ever untriggering the switch, then the printer should just abort with an error message, as that means that there's an endstop problem.
Okay, Simon, your description of how the algorithm should work is the way I would do it. I was thinking it already does that. If it doesn't, then that would be a good reason why I haven't yet been able to understand the code. It's not making sense to me as-is, which is why I wasn't too sure why messing with the retract distance was working in the first place. If it turns out that it's really this broken, I'll take on the job of trying to refactor it, assuming Daid doesn't beat me to it.
Steve
-
I was almost about to ask for a tune-option for fine tuning the Z-calibration on the fly when the print is started.
By the way, I was thinking of adding this same feature, which is what led me to write the leveling rings gcode as an interim tool. You can run that and adjust things before you start your real print. Google's crawled it now, so you should be able to just search for 'leveling-rings.gcode'.
Steve
-
Hi Steve! No, it's only started being reported recently... maybe something has changed about the configuration. It sounds like the issue is that the travel on the switch can be more than 3mm past the click point - so if the bed goes all the way down, moving it up 3mm doesn't fully unclick it?
I'm thinking that a couple of ways to fix this - apart from the firmware fix. One might be to bend the switch as George suggests, but I think it needs to go the other way - to trigger it later? Alternatively, giving the trigger screw in the base of the bed a few turns to shorten the amount protruding downwards might overcome the issue too?
Ah, okay, now I see what George is going on about -- as I said to him, I'm still getting the geometry into my head. I'll measure the switch travel on mine tonight. I've been assuming that the UM2 works like my old CNC mill, refusing to execute a G move if any limit switch is closed. But if Marlin actually will allow a G move when the Z switch is closed, then, yes, it's possible that my Z switch is never even opening when homing is started with the bed against the floor. I'll check that as well.
Even if the screw adjustment works for me, though, we're still going to have that question of how best to fix the printers that are already in the field. Because the UM2 is supposed to be more of a turnkey machine, normally I'd say "fix it in firmware", while anyone who doesn't want to wait can just twist the screw. But given that the screw adjustment would decrease the clearance under the bed (unless I'm thinking backwards), suggesting that people shorten the screw now might actually prevent them from safely applying fixed firmware later -- I'll try to think all of this through some more after I check things out tonight.
Steve
-
Steve if you turn off power on your UM2 and rotate the z screw with your fingers so that it goes all the way down, then go up and count the stepper motor steps - how many steps does it take before you hear the Z limit switch click? For me it's 16 to 17 (2.56 to 2.72mm).
I'm not at the machine today so can't count that right now, but I did do a quick measurement this morning with a caliper: I'm seeing 1.3 mm difference from resting on the floor vs properly homed, *after* I've applied my firmware patch. That's substantially different from the 2.5-3 mm you're seeing. This evening I'll go back to 14.03 and measure that same distance, and see which way it changes, if any. I don't have the geometry in my head as well as you might, so I don't know if the retract distance subtracts or adds to this number. Could it be that my 14.03 "resting vs homed" difference is about 5 - 3 + 1.3 = 3.3 mm? If that's true, then changing this to 5 mm like I've done in my patch lowers the bed by 2 mm. That might risk some machines banging into the floor when trying to home, and the correct fix might need to be elsewhere. We'll see tonight. In the meantime, I'll ask Daid to hold off on merging the change.
If, on the other hand, my difference of resting versus homed is only 1.3 mm regardless of firmware, then that would lead me to believe that you might be on the right track with some sort of limit switch height adjustment. 1.3 mm doesn't sound to me like it gives enough collision margin.
Steve
-
My bed never droops when power is off. I have to push pretty hard to make it go down.
Bingo!!! If your bed doesn't drop easily, then you aren't as likely to see this problem. I think we're going to find that's the main determinant in whether people have noticed this bug or not.
-
If you're having issues with the bed leveling after a power cycle, you might try doing a factory reset on the printer; I suspect if might be related to incorrectly saving the settings in PRAM - perhaps because the PRAM layout has changed between versions of Marlin?
Hi Simon! This is a brand-new printer, and had only ever had 14.03 installed on it. I'm the guy who showed you the blue robot Sunday morning at Bay Area Maker Faire; I'd just printed it on this printer and you gave me a buncha suggestions for improving the quality. I was happy enough with the whole experience that I didn't want to dampen the mood by mentioning one key fact: That robot was my second attempt. The first, printed at the end of the first-run routine, had air-printed.
Here's what happened: I unboxed the printer that morning, powered it up and carefully went through the first-run bed leveling, taking my time and reading both the manual and LCD instructions in parallel. Looking back, I'm pretty sure that the bed must have settled to the floor of the machine before that first powerup (or maybe I pushed it down after removing the shipping cardboard that was underneath). That would be consistent with the symptoms I'm seeing now, and would have caused the first print to be executed with the bed .7 mm too low. As soon as I saw the first layer going down badly, I aborted, re-ran the bed levelling routine, and then printed the robot you saw. Again, consistent.
I'm a little concerned that first-run users are probably seeing this behavior pretty frequently.
Remember how you commented that I'd put too much glue on the glass? That extra dollop of glue was what I'd applied before the second print, thinking that I needed more to make it stick, when in fact it turns out the bed was probably just too low.
It sounds like you've never seen this -- does your bed not settle to the floor when the steppers are de-energized?
Steve
Z axis homing inconsistent on UM2: workaround and patch
in UltiMaker Cura
Posted
Robot prints fine with 14.06-RC6.
Steve