Found easy Z Axis limit method for M2

[Rick Roemer]

Hi everybody...wanted to let you know I figured out a much easier way to lock the z-axis stop limit bolt. Just unscrew the nut & bolt and remove the nut. Screw the bolt back in and put the nut back on Underneath the platform. That makes it really easy to get ahold of the lock nut.

Hope this helps, Rick R.

[Bryan Boettcher]

Rick,

This is what I did with mine, although I flipped the whole setup upside down.  I change hotends frequently and they're slightly different heights so I'm constantly readjusting Z.

On Tue, Feb 11, 2014 at 3:12 PM, Rick Roemer <rickro...@gmail.com> wrote:

Hi everybody...wanted to let you know I figured out a much easier way to lock the z-axis stop limit bolt. Just unscrew the nut & bolt and remove the nut. Screw the bolt back in and put the nut back on Underneath the platform. That makes it really easy to get ahold of the lock nut.

Hope this helps, Rick R.

--
You received this message because you are subscribed to the Google Groups "MakerGear - Make Today, Change Tomorrow" group.
To unsubscribe from this group and stop receiving emails from it, send an email to makergear+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Rick Roemer]

Good idea Bryan, that works too!

[Theo McCormick]

I put a spring on mine and got rid of the locknut. The spring keeps it from moving.  I found the idea here on the group.

[jimc]

bryan thats what i did as well. the bolt goes from the bottom up with the nut on the underside as well but then i got a nylock nut and put it on the end of the bolt so the nut makes contact with the micro switch. this way i can do big changes from underneath but if i need just a slight adjustment i can take my little wrench and turn the nut 1/2-1 flat at a time to fine tune. i can do that without loosening anything. it works great. i can see a spring like theo did working well also.

[Jin Choi]

On Tuesday, February 11, 2014 7:32:45 PM UTC-5, Theo McCormick wrote:

I put a spring on mine and got rid of the locknut. The spring keeps it from moving.  I found the idea here on the group.

How does the spring work? 

[jimc]

It will keep constant tension on the bolt so it wont move but it will allow you to adjust without messing with a jam nut

[Gary Schwartz]

My experience supports what Jim says.  Big time saver.

[Jin Choi]

I mean, where does it go? I imagine you just put it around the bolt, like a spacer?

My limited experience trying to use springs has been that, unless you have just the right one already on hand for some reason, they are hard to shop for.

[Docta Yeti]

I designed the following thing for quick adjusting the bolt that I'd like to share:
http://www.thingiverse.com/thing:198811

It is a pair of tools that allows for independently turning the bolt and the nut at the same time.
They are used in a nested configuration.

[jimc]

it slips over the bolt then the bolt screws in. you can order from mcmaster carr im sure if the local home depot, hardware store or napa doesnt have anything.

[Ed Nisley]

If you'd like to never adjust the Z-axis switch again, move it to the middle of the gantry where it directly senses the platform glass:

More details, including changes to the startup G-Code that probe and set the Z-axis value:

http://softsolder.com/2013/10/14/makergear-m2-relocating-the-z-min-switch/

Perfect results every time!

[Bryan Boettcher]

I like that solution, Ed.  I could build separate gcode profiles for whatever hotend I have on the machine at the time, since they're all slightly different heights. 

[Ed Nisley]

> separate gcode profiles

If the hot end mount has good mechanical repeatability, then one number in the startup G-Code defines the offset from the switch trip point to the nozzle position. I'd be tempted to gimmick up an editor script that would set that value based on which hot end was on the machine, which would eliminate having multiple profiles that differ only in a single number.

If the mechanics aren't precisely repeatable, then you must measure the nozzle position to find the offset. You'd have to do that anyway, so it's not a disadvantage of the fixed switch and you avoid twiddling a screw to change the distance, which I think is a major win.

There's a slightly prettier switch mounting block, too:
http://softsolder.com/2013/11/04/makergear-m2-re-relocated-z-min-platform-height-switch/

[Ketil Froyn]

Ed, I take it you have to make sure to avoid homing all axes with a simple "G28"? That homes all axes to 0, in the order X, Y and then Z, which with your configuration would cause a nozzle crash. Provided some care is taken, that should be fairly easy to avoid - or have you figured out some way to hack the firmware so it relocates X (and Y) before homing Z when issuing a G28?

Cheers, Ketil

--
You received this message because you are subscribed to the Google Groups "MakerGear - Make Today, Change Tomorrow" group.
To unsubscribe from this group and stop receiving emails from it, send an email to makergear+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
-Ketil

[A. Elias]

Looks like you can do a G28 for only the x and y

---

If you add coordinates, then just the axes with coordinates specified will be zeroed. Thus

G28 X0 Y72.3

will zero the X and Y axes, but not Z. The actual coordinate values are ignored.

---

Unsure on the actual operation, but you could home X Y then move the extruder off the bed then home Z.  

[Ed Nisley]

> avoid homing all axes with a simple "G28"?

It's definitely newbie-hostile, I'll grant you that. [grin]

I'm such a creature of habit that I never manually home the axes: homing happens only at the start of a print under control of the startup G-Code routine.

The chunk of code that handles axis homing lives about halfway down Marlin.ino: look for HOMEAXIS. However, just reordering those lines won't solve the problem, because you need a fairly complex sequence:

• Increase Z to ensure the nozzle & switch clear the platform
  
• Home X and Y
  
• Move X to put the nozzle at a safe off-platform location
• Home Z

That's what the modified startup G-Code does. The firmware doesn't have the safe location built in, so it'd be tough to make it work in the general case.

I think the right solution would be a retractable Z-axis probe mounted on the extruder (or X axis stage) that works with the firmware's multi-point probing and automatic platform leveling. But that's a project for another day...

[Gary Schwartz]

It seems that M207 fits somewhere in this discussion:

"M207: calibrate z axis by detecting z max length

Example: M207

After placing the tip of the nozzle in the position you expect to be considered Z=0, issue this command to calibrate the Z axis. It will perform a z axis homing routine and calculate the distance traveled in this process. The result is stored in EEPROM as z_max_length. For using this calibration method the machine must be using a Z MAX endstop.

This procedure is usually more reliable than mechanical adjustments of a Z MIN endstop."

[Ed Nisley]

> For using this calibration method the machine must be using a Z MAX endstop.

The M2 has a Z-min switch, so you must add another switch at the bottom end and (I think) tweak the firmware to enable it.

There's less opportunity for unhappiness if you directly sense the platform position near the position you most care about, when you care about it, but that's just me... [grin]

[Gary Schwartz]

Too quick to reject the statement "It seems that M207 fits somewhere in this discussion:"

Let's consider it a thought starter ... there may be some good work arounds. 

[Toby]

I've been puzzling over this also.  I'm too new at this to know if this is workable, but it seems that if I level the bed using Creator to jog around, then once I'm finished I also have the bed in a position that I want to be z=0.  Since I'm connected to the M2, I ought to be able to send a command that says "Where you are right now is z=0.  Home to that."  

Why would any other measurement have to made?  If the motors got disconnected then this wouldn't work on reconnect, but presumably the M2 knows when that happens and could then automatically revert to using the end stop.

[Bryan Boettcher]

There's a command for that: G92 Z0, but that doesn't change the homing behavior.

You could change your workflow slightly.  Maybe the first step you do when powering on the machine is to home all axies, and change the "start" GCode to G1 X0 Y0 Z0.

On Sat, Feb 15, 2014 at 11:21 AM, Toby <torl...@gmail.com> wrote:

I've been puzzling over this also.  I'm too new at this to know if this is workable, but it seems that if I level the bed using Creator to jog around, then once I'm finished I also have the bed in a position that I want to be z=0.  Since I'm connected to the M2, I ought to be able to send a command that says "Where you are right now is z=0.  Home to that."  

Why would any other measurement have to made?  If the motors got disconnected then this wouldn't work on reconnect, but presumably the M2 knows when that happens and could then automatically revert to using the end stop.

--

[Ed Nisley]

> Let's consider it a thought starter

Fair enough...

I think that when you're trying to determine the position of the printing surface to an accuracy better than 0.05 mm, you should directly sense the top of the glass plate.

M207 requires sensing the bottom of the Z-axis stage at the bottom of its travel where Z is about 185 mm, subtracting the sum of several variable distances, then assuming the result determines the Z coordinate at the top of the glass surface.

That seems fraught with peril: it's how my old Thing-O-Matic worked and that wasn't very well. Admittedly for other reasons, too, but that's why I added a switch directly to the platform; all those tweaking problems Went Away.

[Gary Schwartz]

How about:  1) Position the nozzle at the center of the build surface.  2) Adjust build surface Z position that provides the paper-thickness (or whatever) distance between nozzle & build surface.  3) Move nozzle to maximum X ... or enough to get it east of the build surface.  4) Send M114 to get Z position.  5) Raise build surface until stopped by a very securely mounted Z Stop switch.  6) Send M114 to get Z position.  The difference between this & Step 4 reading is Z offset.

Now comes the hard part: Tweak firmware, software, Z Stop connections, M207, or ??  to have steps 3,4,5 & 6 done, on command, automatically, after we've done Step 2.  I don't yet know how to do that, and I'm not about to say it can't be done. 

[Ed Nisley]

That's pretty much what a tool length probe does for a living; it's a straightforward chunk of G-Code in the LinuxCNC dialect of RS-274 that I use every time I fire up the Sherline CNC mill. Unfortunately, that functionality isn't in the RepRap dialect.

Over in the Sailfish (aka Jetty Firmware) forum, they're kicking around Z=0 probing and auto leveling, so there's hope that some automated functions will make it into the Arduino-flavored firmware.

In order to do all of that automatically, however, the notion of eyeballing the nozzle position must Go Away: the measurements must come directly from the controlled point or a datum that's a known, fixed distance away from it, without human intervention. Marlin has support for a servo-rotated Z switch actuator that might suffice.

> Raise build surface until stopped by a very securely mounted Z Stop switch.

The switch should trip without much force, so there's no need for a very secure mount, other than to make sure the switch doesn't move. You don't want the switch pressing firmly on the platform, because that would change its position... even for platforms that aren't spring-mounted.

All in all, what you want to do is do-able... all we need is a nozzle position sensor!

[Jin Choi]

On Saturday, February 15, 2014 7:02:03 PM UTC-5, Ed Nisley wrote:

The switch should trip without much force, so there's no need for a very secure mount, other than to make sure the switch doesn't move. You don't want the switch pressing firmly on the platform, because that would change its position... even for platforms that aren't spring-mounted.

All in all, what you want to do is do-able... all we need is a nozzle position sensor!

What about something mounted to the rear of the x carriage, probing off the back? 

[Toby]

I like Gary's solution until there's an automated system that can detect nozzle position relative to the bed.  But I'd like to implement it in Creator.  Problem is it takes more than a Creator macro- we would need to control the M2, get position data, do a calculation, then use that to set parameters and/or g-code inside creator.   What this is calling for is a plug-in architecture for creator.  If we had that we could be testing the idea right away instead of just talking about it.

[Tony Shulthise]

The CubeX printer I had for a while used a Hall effect sensor to detect a magnet in the build platform to set the Z offset.  It wasn't very consistent though.  Some type of non-contact sensor that doesn't cost a fortune and has very good repeatability would be great.  I don't know of any that meet both criteria though.

[Gary Schwartz]

Now we're making progress.  My brain is in storm mode, so I may write stuff that's off base. 

Some of us will want to do it in Creator, some not.  The same goal can be pursued in both routes.  To start the Creator route I see the following issues:

A) Do we need more than a macro in Creator?

B) We need something to tell the M2 to get position data.  M114 reports the current position of X,Y, & Z, but how do we motivate the M2 to obtain & record it?

C) That data needs to be processed.  *Is probe at correct X & Y position? *Compare the Z reading with another Z reading.  *Compute & report Z0 to ??

D) Create a macro that accomplishes the above.

E) Toby: I need help understanding what "plug-in architecture for creator" would be.  (A macro?)

F) Let's think crazy.  I have a strong suspicion that some Gcode could accomplish stuff it wasn't intended for.  Maybe two switches at the same end of Z travel, one called Max & one called Min.  Maybe they each reverse Z travel, sending the platform back toward the other while counting steps.  I have NO IDEA how this would help us ... just planting a seed that fell out of my head.  Spending some time looking at all the Gcodes could pay off.

On Saturday, February 15, 2014 6:36:40 PM UTC-7, Toby wrote:

[Toby]

Why is contact bad for a position sensor?  I had this vague idea of taking a piece of paper and coating it with conductive paint, then rigging up a circuit to the brass nozzle which would complete when the nozzle touch the paper.  From there you could programmatically make a map of the bed height and presumably control the print without ever having to set the zstop or level the bed.

[Gregg Bone]

The trouble with "contact" like that is two fold:

1:  The contact gets dirty.  The reason for a limit switch is that the actual "switch", which is a contact, is inside a hopefully clean sealed container, and the contacts themselves are make of some non-oxidizing conductive material.  Environmental contaminants do not hurt.  Even with this if you put a limit switch on a good oscilloscope and watch the voltage signal as the contact, well, contacts, you will see lots of bouncing of the voltage, often for about 5 milliseconds or do, and often as much as full voltage swings.  Different things are done in real life to mitigate this bouncing, capacitors, will average the signal out, so rather than giant bouncing swings, you get slower but smoother transitions.  But the most common approach is to "fix it in software" by sampling, and requiring multiple consecutive samples to agree before believing the switch has "switched".

2.  There is time from when the contact is made until the software knows about it.  The solutions to problem #1 add to this delay, and if the delay is too long stopping the Z-travel might not happen fast enough to prevent a head crash.  Assuming the hot end crashing into the glass does not break the glass, the big problem here is that the stepper misses steps, the the Z-axis is not where the rambo thinks it is, defeating the whole purpose of a "home".

That brass extruder nozzle is not going to stay clean (mine get gunked up with different plastics all the time).  There are solutions to all this of varying complexity.  Use a limit switch not to tell where the "end" is, but when the end is near, then slow way way down to creep up on the bed with the nozzle so you don't hit hard.  Use a led/photodiode gap sensor mounted to the edge of the bed, and make the Z-home do a X-axis move off bed first to position the nozzle tip to hit the light beam when Z is homes.  This would give us a tip to sensor reference.  Then some calibration could be done to get beam interruption to bed distance (or we could mechanically adjust the sensor to be coplanar with the bed - less nice).  That system still requires the bed to be adjusted flat, I really like the idea of getting bed tilt information and taking that out in software - but that's a big job in marlin.

You sensor idea works great - for 10-20 uses.

Gregg

[Toby]

Thanks, Gregg.  I guess this is why I ended up in software.  High tech hardware is so nice conceptually and so messy in reality.  The optical idea sounds pretty clean though.

[Jin Choi]

Regarding the previous talk in this thread about "plugins": that sort of thing properly belongs in the firmware, I think. Otherwise you are limiting yourself to one slicer/host program. I've had a look at the firmware, and it doesn't seem difficult to modify at all to do the sorts of things you're considering.

On setting the z-axis end stop height:

I've just put up my latest model (http://www.thingiverse.com/thing:250957), a "mount" that clamps onto the X axis gantry and provides an indexing position for a dial indicator. I saw some tutorials that require you to remove the extruder and place the indicator in its place. I'm not removing anything to set the z-height! This goes on and off easily and quickly.

There is a hole for the shaft of the indicator; the "sleeve" has a flat bottom and rests on top of the mount. This provides a decent enough indexing position for determining the end stop limit point. Raise the bed until the switch triggers, make a note of the reading, then continue raising the bed until it touches the extruder (easiest to do when using a plain glass bed, as you can see when the extruder touches its reflection). The difference will tell you what your z-height is set to. It is best to do this when the bed is at printing temperature.

Sadly, there is enough play that this is not currently usable to level your bed with. Small variations in positioning and clamp pressure cause noticeable variations in the indicated value. However, I have found the results to be very repeatable in a single location; the trigger point always reads the same value. I guess given the z-height at a number of different points, you can use this for bed leveling, although it would be tedious at best. I am hoping this can be improved.

I am using a Tekton 7169 indicator ($16.50 from Amazon). Other indicators may require customization. Irritatingly, this one reads in mils and not millimeters, so I have to do some conversion.

[Gary Schwartz]

I spent about an hour this morning preparing a reply that vanished.  Did anyone receive it as an email

?

On Tuesday, February 11, 2014 2:12:45 PM UTC-7, Rick Roemer wrote:

Hi everybody...wanted to let you know I figured out a much easier way to lock the z-axis stop limit bolt. Just unscrew the nut & bolt and remove the nut. Screw the bolt back in and put the nut back on Underneath the platform. That makes it really easy to get ahold of the lock nut.

Hope this helps, Rick R.

[Ed Nisley]

> position the nozzle tip to hit the light beam when Z is home

Remember that plastic extrusion nozzles tend to drool at temperature: expect a non-conductive layer on the tip that also defeats optical position sensors.

Achieving reliable 0.05 mm accuracy with affordable remote-sensing widgetry poses some hard problems, indeed!

> getting bed tilt information and taking that out in software

Remember backlash and stiction: turning the motor a few microsteps in one direction, then a few in the reverse direction, doesn't bring the stage back to where it started. In fact, a microstep or two may not move the stage at all, depending on other factors. While you can compensate for static backlash by over-turning when reversing direction, that doesn't handle the dynamic loads during normal operation.

That's another hard problem!

[Tony Shulthise]

Be careful using that type of dial indicator.  The spring pressure could be enough to deflect the springs on the bed more than a negligible amount.  

I ran into this problem trying to calibrate a 3 axis mass spectrometer gantry I designed at work... On a granite table I would find the method worked great.  In the machine I kept getting readings that didn't make sense and were not repeatable.  I eventually figured out that the spring force of the dial indicator was deflecting the bed by about 0.005" and that deflection varied with position.  I switched to a different type of indicator that had about 10% as much spring force and the problem was solved.  One easy option, if this one has too much spring force, is to change the spring in the indicator to a weaker one.

[Gary Schwartz]

On Sun, Feb 16, 2014 at 12:07 PM, Ed Nisley <ed.n...@gmail.com> wrote:

Remember backlash and stiction: turning the motor a few microsteps in one direction, then a few in the reverse direction, doesn't bring the stage back to where it started. In fact, a microstep or two may not move the stage at all, depending on other factors. While you can compensate for static backlash by over-turning when reversing direction, that doesn't handle the dynamic loads during normal operation.

​Ed,

Do you have supporting data?​

      Gary
Make Better Things
Make Things Better

 

 

 

 

[Gary Schwartz]

On Saturday, February 15, 2014 10:34:25 PM UTC-7, Toby wrote:

Thanks, Gregg.  I guess this is why I ended up in software.  High tech hardware is so nice conceptually and so messy in reality.  The optical idea sounds pretty clean though.

 In reading the recent posts I believe that the knowledge to solve this issue exists in the topic's participants (and probably its readers).

Something I'd like to reach agreement on is what the solution will require of the user.  I'll start a list of proposals with:

A) The user must assure the tip of the extruder is free of anything that affects its actual Z position.

B) ??

I'm not sure we all have the same concept of "Switch".

I see it as having two parts: 1- Sensor, and  2- Something that will make or break the continuity of an electrical circuit in response to a signal from the sensor.  This is probably the real switch.

The sensor could be:

*Mechanical ... physical contact, 

*Optical ...  this could be a broad area. Stuff that come to mind are: Laser,  Lens,  Mirror,  Photo sensor (CCD or CMOS from unused digital camera), Strobe,  CHDK has firmware hacks that will detect a lightning strike & trigger the camera's shutter,  I recall WWII low-altitude bombing where proper altitude was determined by the convergence on the water of the spots of two lights, mounted near the end of each wing.     More ???

* Magnetic ... ???

* ???

[Ed Nisley]

> Do you have supporting data?​

The LinuxCNC mailing list went over this in grisly detail several times in the recent past, with a bunch of guys running Big Iron pointing out the fallacies in the "fix it with firmware" approach. Subtractive machining has the additional problem of forces from the cutters shoving the table around, but backlash also comes into play on tables undergoing high acceleration and deceleration.

The emc-users mailing list archive seem to be un-searchable right now; I tried a few obvious terms from my email heap and came up with totally bogus results.

I just gimmicked up a dial indicator, similar to Jin's setup, but bearing on the Y-axis rail:

Some interesting observations on Z axis motion:

The overall distance seems to be quantized at 0.0150 mm = 6 step intervals. You can command a motion between those steps (G0 Z0.0025, G0 Z0.0075, etc), but the motor doesn't turn until the distance exceeds the next interval (G0 Z0.0150 causes motion). This isn't stiction, because the firmware isn't activating the motor.

Stepping up and down in 0.025 mm increments (10 steps, but not an even multiple of the 6 step quantization intervals) over a 0.100 mm range produces about 0.01 mm = 4 steps of backlash. Some of that definitely comes from the quantization interval, but it's not consistent, so there's also mechanical backlash.

Frankly, that's better than I expected, but any motion less than about 4 steps probably won't happen and the errors are on the same order. Whether the firmware itself can compute and apply a smaller motion isn't clear.

The controller doesn't know where the platform is, at least in an open-loop stepper system. That means when the commanded motion is on the same order as the backlash, the controller can't make the proper adjustments. As long as the positioning error remains smaller than the tolerance, it's all good; expecting 0.020 mm resolution and accuracy seems reasonable.

But it's only a quick-and-dirty test, so I wouldn't read too much into it.

[Gary Schwartz]

Thanks for the good info Ed.  I'm curious to know how Z readings in M114 would compare with the dial indicator.

[Gary Schwartz]

Does anyone know if Excel or similar spreadsheet can read or write a value from/to Creator or Pronterface? 

[Ed Nisley]

> how Z readings in M114 would compare with the dial indicator.

I didn't bother with the dial indicator, but running similar G-Code commands produced similar results.

Moving in 0.0025 mm increments produces no motor action until 0.0150, as before, with M114 reports 0.00 for all commands until the last, when it's suddenly 0.02.

Commanding 0.030 = motion, M114 = 0.03

Commanding 0.020 = no motion, M114 = 0.03

Commanding 0.010 = motion, M114 = 0.01

The results from M114 have 0.01 mm resolution, but do not correspond to either the commanded or actual position. That's independent of stiction and suchlike.

Based on discussions about Sailfish, I think Marlin keeps track of fractional motion and steps, so that the final total after a succession of small moves will be correct, but it's fairly obvious that you cannot command small moves and expect motion corresponding to each command.

[Bryan Boettcher]

All of this is silly.  I'm not negging on your efforts Ed, but we as a community should be looking into techniques that don't require sub-millimeter precision for getting started on prints, since our homing accuracy isn't that great.  The CNC guys use sacrificial beds right?  I think our closest equivalent is rafts which reduce surface finish.  I wonder if we could do something similar with a consumable bed material, like expanded polystyrene or polyurethane foam.  Something that the nozzle can easily drag through and is super cheap to replace.

--

[Tony Shulthise]

Firmware/stepper position errors would be at the bottom of my list for key contributors for position errors.  You are showing about a 0.0007" position resolution which is very good.

I wish I would have measured linear guide slop before and after I replaced mine with better quality guides.

Sources for position error include:

--X-Y Linear bearing slop (its bad enough that you can feel the slop by touch when you twist back and forth on the linear bearing blocks.  This error amplifies with increased acceleration and distance from the block)

--X, Y, Z bearing errors.  I would not expect them to run true (flat, straight, parallel, plumb) to better than +/-0.010" without special assembly techniques which I'm sure aren't used for this machine.

--Spring loaded bed (varies with acceleration but can be bad.  I would guess the bed causes up to 0.030" errors)

--Bed mounts (rubber mounts make bed positioning repeatability very poor.)

--Deflections due to loads and accelerations (ties into errors listed above but could be in the 0.030" range or higher)

--Lead screw error (even ACME screws have accuracy tolerances of around 0.001 in/in, up to +/- 0.010" over the full travel of the z axis.  If you move the table up and down during printing then add hysteresis error to lead screw accuracy error)

--Home switch repeatability will change with time and temperature variations.

--Belt/pulley hysteresis/accuracy tolerance (I would expect no better than 0.001 accuracy for any belt/pulley set.  It can be MUCH worse depending on belt tension changes and temp changes)

--Expansion/contraction due to temperature changes (can be significant for multi-material and cantilevered assemblies)

--Stepper motor accuracy/resolution

--Firmware resolution

[Tony Shulthise]

BTW... my response wasn't picking on anyone.  I was typing my last post as Bryan posted his response.  IMO, any brainstorming ideas are good for us to consider.  Here's the low hanging fruit in my opinion...

1.  Use hard mounts for the spider and bed instead of springs and rubber to give repeatable positioning without having to re-level and reset the z offset.

2.  Use better quality XY linear guides.  Gets rid of bearing slop and provides 40% more build area with a few relatively minor design changes.

3.  Use the Z home switch has to be used to set the Z offset.  This is what we are talking about here.  It wouldn't be that difficult to run the Y axis to one end to "click" the z home switch into and out of the homing position. Think of a clicker like is used on a ball point pen.

[Ed Nisley]

> techniques that don't require sub-millimeter precision for getting started on prints

How we got into this mess was directly sensing the position of the nozzle, then automagically setting the Z origin to suit. That measurement must be within about ±0.02 mm for reasonable layer thicknesses.

The screwball tiny values apply for auto bed leveling, where the platform doesn't move according to the commands. I'd like to see how those functions in Marlin actually work in practice, given my simpleminded measurements. I think it's easy to define the math, difficult to stuff the algorithms into an Arduino, and very hard to get good results from practical machinery.

[Ed Nisley]

> a 0.0007" position resolution which is very good.

Better than my Sherline CNC mill, which (at best) runs a few mils!

[Gary Schwartz]

I would add metal mounts for extruder > X linear guide.  In my experience the creep in plastic mounting is responsible for most of the slop that's evident at the nozzle.  More than once I've suspected bearing slop only to find that essentially every fastener that has a plastic bearing surface requires tightening.

I like the hard mounts for the bed proposal.  I'm also concerned about protecting against damage from nozzle crash.

#3:  Hmmm ; thought provoking.  ​

      Gary
Make Better Things
Make Things Better

 

 

 

 

--
You received this message because you are subscribed to a topic in the Google Groups "MakerGear - Make Today, Change Tomorrow" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/makergear/qzM3tjABbi0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to makergear+...@googlegroups.com.

[Bryan Boettcher]

Gary,

I've rammed my nozzle into the bed before, and the stepper gives out before anything breaks.  I don't have a microscope to check for deflection of the nozzle, but I didn't notice any problems with the prints afterwards.

--

You received this message because you are subscribed to the Google Groups "MakerGear - Make Today, Change Tomorrow" group.

To unsubscribe from this group and stop receiving emails from it, send an email to makergear+...@googlegroups.com.

[Gary Schwartz]

Bryan,

I have the high-torque stepper that Ed recommended.  Possible I could do some damage.​

[Toby]

Tony, I'm not understanding #3 of your post.  Could you explain that a little more?

Ed- In terms of the math, it doesn't look that hard to compute on the fly.  If we assume the bed is flat, all the probing boils down to is giving us two angles- the rotation of the bed around the x and y axes- plus an accurate z-offset at one point.  Assume for simplicity that point is (0,0,0).  This means if we intend to send the nozzle to (x,y,z) on a perfectly level bed with no z-offset, then the place we actually have to send is x,y,z + a precomputed 3x3 matrix times (x,y,z).  Moreover it gets even simpler when you are computing the offset while incrementing x and y on a given layer.  then it's just fixed deltas in x,y, and z for each increment in x and y.  I think anyway.  There could be a detail or two I'm missing.  But the math is just linear algebra in x,y,z with fixed coefficients.  Should not be a problem computationally.

If the bed's not flat then there is no mathematical solution for the whole bed.  Then all you can do is probe at a number of points and pick your algorithm for interpolating.  But any difficulty in computation can be pre-computed on the host computer and loaded into the arduino as a big matrix of numbers which are interpolated on the fly by simple linear algebra.  You just need some memory but it's not huge.

I believe this is what they're doing with auto-probing on delta-style printers.  But the advantage they seem to have is that there's no difference in x,y,z mechanics like there is with cartesian printers.  What I don't know is can the z-axis be reliably moved up and down on the fly in the middle of printing a layer on the M2?  It might slow you way down since the z-axis doesn't move as fast as the x,y carriages.   Also there might be more of an issue with the nozzle knocking into parts than there is if the bed really is level.  Theoretically it's the same, but practically I don't know.

[Jin Choi]

I think trying to compensate for an unlevel bed in software gives up some of the advantages of having a rigid cartesian setup. One of which is, after the first layer, everything is level to the head and you can stop messing about.

What I would be very happy with is not auto-leveling (hard to do without a servoed bed), but just bed mapping, so you could get an accurate map of just how level your bed is, and how many turns of the screws you need to get it adjust it. I think this might be not that hard to do, especially since you can use hardware that doesn't necessarily need to stick around all the time. I'm thinking of something like having a thin conductive sheet (aluminum foil?) on the bed that closes a circuit with the extruder nozzle itself, then some firmware that will run through a mapping routine and spit out some numbers you can plot in a nice display. You only need this stuff around when you're running the routine, so you can pop it on and off. Have a press-fit ring to hold a wire against the extruder, and a sheet of foil with another wire, steal an unused pin from somewhere, and the rest is software.

[Toby]

I agree, Jin.  I was thinking paper with conductive paint since foil has a tendency to crinkle when you handle it.  Gregg pointed out some of the problems with this approach earlier in this thread, but I might try something anyway.   It doesn't have to be a universal solution for all printers.  We could hardcode in knowledge of the M2- like where the spider screws are located, how much they move the bed when turned, etc, and just crank out practical information on what you need to do to level the bed.

[Ed Nisley]

> Should not be a problem computationally.

The problem is running the floating point or extended-precision integer computations in real time on an 8 bit microcontroller that's already maxed out handling the stepper pulse generation. There simply isn't any headroom for additional computation.

The LinuxCNC kinematics modules can compensate for things like non-orthogonal axes, but they have the advantage of using a 32 bit CPU...

[Ed Nisley]

> You just need some memory but it's not huge.

The ATmega 2650 microcontroller has 8 kB of RAM.

The Sailfish branch of the family allocates 7.5 kB for static variables, which leaves about 500 bytes free for call/return stack and dynamic variables.

Firmware features have long been in a zero-sum death match...

[Jin Choi]

How is that LinuxCNC conversion project coming, Ed?

It seems faintly incredible that you can get a 32 bit ARM in a box with Wifi, HDMI, and 512MB of RAM for about a quarter of the cost of an 8-bit microcontroller with stepper drivers.

[Scott Booker]

I've given this a lot of thought, and I think it's probably pretty easy to do an auto-leveling (3-point) bed, and you don't need a "servoed bed".

Find the YouTube video on how Kühling&Kühling is doing their leveling.  It's simple and intuitive.  Now replace their three locking knobs with three solenoid activated deadman pin clamps.  Those are simple (mostly printable) and cheap.  You can actuate those clamps with three mini toggle switches and combine that with a simple leveling script with pauses.  To make it truly automatic, it just involves finding two DO points on your controller and toggling them within the leveling script.  You could easily and quickly run this before every print if you were anal.

[Jin Choi]

Oh yes. I see you've already covered this ground earlier in the thread. I thought I had been following along, but maybe not as closely as I had imagined.

Gregg's objections are good ones (I know my extruder often has a blob of plastic on the end), but again, this isn't intended to be a routine homing solution, just an occasional maintenance procedure. You can require the user to make sure the extruder is clean enough to make electrical contact, and you can cut motor power, zoom to a safe z height, then start creeping up on the extruder, with a fail safe height.

With regard to memory usage, requirements would be very minor, all you have to store is maybe 12 integers, or just output them as you go. Nothing near the requirements of running complex calculations while under way.

Where can you buy conductive paint?

[Ed Nisley]

> How is that LinuxCNC conversion project coming

Poorly, I'm sorry to say, for some of the usual reasons...

The guys bringing up LinuxCNC on a Beaglebone Black can show off spectacular progress; that's definitely the way to go for a direct plug-and-chug conversion.

> a quarter of the cost of an 8-bit microcontroller with stepper drivers

The BB is cheap because of the huge economy of scale behind those chips. The BeBoPr cape (or, better, the Plus version) that adds stepper drivers seems to be both hard to get and relatively spendy... but having a serious computer and hard real time pulses makes up for a lot.

[Bryan Boettcher]

Dave Sharp has managed to use G29 on his M2 to probe 3 points on the bed and have the machine tell him how far out of level it is.

--

[Toby]

Jin- Amazon has conductive paint:

http://www.amazon.com/SparkFun-BarePaint-Conductive-Paint-50ml/dp/B007R9UMXM/ref=sr_1_1?s=office-products&ie=UTF8&qid=1392736632&sr=1-1&keywords=conductive+paint

Radio Shack also sells a conductive ink pen for $9.99 I think.

Ed- I had no idea the cpu and ram were so limited.   I just got an Arduino uno board to play around with but haven't looked at the specs.  Suddenly feel like I'm back in the days of the Vic20 counting bytes. 

I guess you could do the calculation on the host computer and print through the USB, but this idea seems to have run its course at the moment.

[Gregg Bone]

Some people want this to be a once off kind of thing, some people want it to be more integral to the machine so it can be done more often.  I print with several different materials and find myself needing to Z-axid home adjust very often because of bed thickness changing.  Also I get nozzle jams and need to take the extruder off to clean things and when I re-assemble everything the Z-axis offset has changed - readjust...

That's why I'm spending the time looking at the new printer-ninja bed material.  Claims everything works on it without tape or hairspray.  Then I would have only one bed height, but would still have nozzle cleaning issues.  So far their claims are true with PLA, it's been great, ABS testing today.  BUT it is not FLAT.  One of it's features is that it is flexible, so to remove a part you bend it slightly and the part pops off - and this works very well (for PLA so far).  I have not measured yet, but there is clearly a slight bow toward the center when the corners are clamped down.  Enough to noticeably change the distance from the extruder tip to the bed using the folded paper friction test, and enough to cause a print to fail when I used the edge to do a Z-axis adjustment, the center of the print failed because of too much extrusion material and not enough space.  I adjusted a little higher and have been getting nice prints but I'm sure the center is a little concave.

Reading all this has given me another idea, lets not do on the fly stuff for Z=2+.  Let's instead use the data of what the bed position is to dynamically change layer thickness only for layer 1.  Set Z to be minimum thickness at he highest point on the bed then extrude a little bit more material where the bed is lower so that we end up fixing bed tilt and flatness all in layer 1.  Still have to level, still needs to be flat, but not as tight tolerance as currently.  Then we have a flat and level layer 2 and up.  Comments?

Yes, that's jumping ahead a lot, still need to solve getting the data.  And to do this we need Z-offset all over the bed, or at least several points.  Something easy to use that costs almost nothing…

Thinking...

[Toby]

In that case you could just take the bed information and add it to the model while slicing.  If you filled in the "valleys" that way, the slicer would think you were trying to print in air on higher layers but maybe wouldn't care since it's so small.

One problem might be the resolution you get from the print might not match the resolution you need to be level.  I haven't thought this through clearly, but if the bed is off .1 mm from one edge to another, how are you going to print that wedge?  It's either print .1mm high or don't print it.  It's like the aliasing problem in drawing lines on a screen. 

[Ed Nisley]

> back in the days of the Vic20 counting bytes.

For all the Arduino love in the air, it's really a mid-90s architecture with most of the limitations that microcontrollers have always had. I like Arduinos a lot and use them in many projects, but it's definitely not A Real Computer.

The fact that Arduinos work as well as they do for current 3D printers comes down to the incredible abilities of some really talented programmers, but it's time to move on...

[Gregg Bone]

No, I'm talking about dynamically changing the extruder feed rate, and the M2 has plenty of control there.  We only need to make very small corrections - if the bed it tilted more than that or not flat more than that you need to fix the hardware.  Imagine a slight rise in the center of the bed (that is what I have, my edges are <.1mm lower than the center.  Enough to notice in the print quality, but usually not enough to destroy the print.  The problem is that at the fixed level 1 extrusion rate more material come out of the nozzle than there is height for in the center, causing dragging, and less comes out near the edges than needed to get good adhesion to the bed.  So given the map of tilt and bow, extrude more filament where the nozzle is further from the bed, and less when it is to close.  You end up with a flat top to the 1st layer that everything else can be built on.

[Toby]

Oh I get it now.  That's a nice idea.  I wonder if it would be possible to take the g-code from the slicer and run it through some post processing software to put in the extra commands for adjusting the feed rate based on the bed mapping.  That way we don't have to stress the controller during the print.

[Bryan Boettcher]

Toby,

Our Z axis *can* do that .1mm wedge.  It's a combination of slow Z moves (same way the vases work) and flow reduction.  It's not ideal, but it's a neat idea.

[Tony Shulthise]

Toby... I meant that accelerations cause the spring loaded bed to move so no matter how level you get it you will have artifacts (significant ones) in your prints due to that compliance.

General observations related to this thread...

• Since S3D allows a 0.2mm first layer which is, in a sense, a good way to autolevel the build surface, it is my opinion that compensating for variations in the flatness of the glass plate is probably unnecessary.
  
• Z-offset and manual 3 point leveling is very easy and fast to do simply using the 3 leveling screws.  If the M2 had a more accurate/repeatable bed frame and attachment method you would rarely have to re-level unless you changed to a different thickness build plate.  It wouldn't be difficult to add mounting points on a standardized build plate that allows adjustment to a known thickness, thus eliminating that variable.
  
• Having to set z-offset and leveling nearly every print to have confidence is one of my biggest pain points.  My guess is that a design that only requires the user to set these once for every 15 prints would be acceptable for 90+% of everyone on this board.  
• The need for automatic leveling and z offset would be very useful as the typical user profile moves from "early adopter" who is willing to tinker to "average joe" who just wants to push a button and go and won't tolerate tedious settings requirements.

[Gary Schwartz]

I agree with all four items, Tony.

Also, I think two issues are being discussed in this thread: * The original, to simplify setting Z0,  and * Automatic (or simplified) bed leveling.

Manual leveling and retention haven't been an issue for me.  Initial leveling isn't the nightmare it was on the Prusa,  as long as North-South is zeroed in before adjusting East-West.  And, doing it over the adjustment screws. It's pretty easy then to occasionally print a 150 x 150 square to check level.

Accurate Z0 setting is important for more than one reason.  And, it can easily change from print-to-print.  I think we can make it much easier and more consistent with a relatively simple macro in Creator.  I'm testing an idea now, but have been stalled with an issue on which I need help.

The issue is: Frequent failure to execute a G90 Xnnn.  It works sometimes, but fails well over half the time.  I have latest edition of Creator on Win7 machine.