auto level doesn't stop on Z-Probe

[walrhe93]

I'm trying to get Marlin-RC4 working on my Kossel XL. It seems to be working, except for the auto level. After sending the G29 command the printer starts with auto level, but when the z-probe switch is pressed it doesn't stop going down. When I used the serial interface to check the end-stop and probe switches, I can detect the probe switch being pressed. Does anyone know how I can solve this??

Configuration.txt

[Roxy-3D]

Can you put the nozzle in the middle of the bed, but up in the air? And then do an M119.

Are all of the end stops reporting the correct values? Then Manually trigger each endstop and do an M119. Do you see the end stop that you are manually triggering indicate a change?

[ghost]

FIX_MOUNTED_PROBE is inductive probe. If your probe resembles this, you should select the Z_PROBE_ALLEN_KEY. Configuration.txt

If your probe resembles this, Marlin no longer support probes of this kind since RC4. [for your information] However my experimental branch supports those probes, therefore try to the my branch If you use probe of this kind. Configuration.txt

[walrhe93]

Yes, I use the meganism in the picture. I'll try your experimental version tomorrow. Thanks.

[thinkyhead]

@esenapaj I'm trying to come up with a good general description to put into the configs and documentation. How should we describe a "mechanical probe"? What do they all have in common?

I'm also curious about the probe in the picture. How does that one operate, exactly?

[Roxy-3D]

I'm trying to come up with a good general description to put into the configs and documentation. How should we describe a "mechanical probe"? What do they all have in common?

@ThinkyHead I'm of the opinion there are at least two different characteristics to 'Manual' probes. Some probes are manually deployed (and retracted) like my lame Allen Key Z-Probe. But independent of that, on the Delta Automatic Mesh Bed Leveling System that I'm doing, there will be a 'Manual' Z-Probe that you never deploy. You will be running the nozzle (very carefully) down to the bed using PronterFace or the the LCD Panel. So... Right there, you have two independent 'Manual' characteristics. (I don't have the answer your looking for. I was just trying to make sure you get my situation into your final answer!)

[ghost]

I'll be grateful that Marlin development team embarked on re-support of this kind of probe. Honestly, this modifying work is beyond me.

What do they all have in common?

It's difficult for me, but if given a common point, "Probe of how the tip is operated by being pushed up mechanically" or "Probe tip is operated by collision mechanically to bed" ...? Allen Key is "pushrod", but (probe by)hotend is no saying a rod, http://www.thingiverse.com/thing:892398 is also. mechanism of http://www.thingiverse.com/thing:1093345 is mechanical, but switch is optical...

How does that one operate, exactly?

In case of these types of probes in the picture or my printer, nozzle(hotend) also serve as a probe and mount for hotend is movable. If nozzle is pushed to the bed, then mount is raised and switch on the effector is opened or closed. please see the following page. http://www.thingiverse.com/thing:1093345 https://www.youtube.com/watch?v=rXsIVvhuK7s Switch of this type of probe is operated when the nozzle has been lifted slightly, then Z0 position of "probe(by nozzle)" is slightly higher than Z0 position of "nozzle". Therefore Z_PROBE_OFFSET_FROM_EXTRUDER of these probes should be set more than zero, I think.

About my experimental branch, I was planning 3 levels of feature proposal. But "Level 3" is at a standstill because I've very limited coding skill, therefore the exposed branch is "Level 2".

Level 1: minimum support for mechanical probe. mechanical probe is approved with only delta machine, like the Allen Key.

Level 2: support for mechanical probe with more architectures(cartesian, etc) because in principle, mechanical probe doesn't mean that it can't be used with except delta machine.

Level 3: It re-define the Allen Key as "performing the operation specified in the before and after leveling" general-purpose "recherche probe (tentative name)", and routine of the recherche probe support "not recherche" mechanichal probe. This will enable the following not only support simple mechanical probe but also support "probe like the Allen Key with cartesian printer", for example these PR. https://github.com/MarlinFirmware/Marlin/pull/3190 https://github.com/MarlinFirmware/MarlinDev/issues/397

[thinkyhead]

I see. So a "mechanical probe" is usually the nozzle itself, which can cause a switch to become disengaged (or engaged) if it tries to move "below" the bed. So in essence, it needs no deployment and no stowing, but it does need to be "enabled" (as endstops are for homing). By contrast, an "Allen Key" or "Sled Probe" needs some special movement at the start and end to "deploy" and "stow."

After we finish scrubbing the current group of bugs, we will have to revisit the topic and see if we can find some patterns to work around. When we have groups of conditions appearing a lot (like HAS_SERVO_ENDSTOPS || ENABLED(Z_PROBE_ALLEN_KEY) || ENABLED(Z_PROBE_SLED)) I find it helps to make a new item in Conditionals.h to capture their meaning as a group. The more we do that sort of thing, the more it will become clear how these different families of probes relate to one another at a behavioral level.

[thinkyhead]

manually deployed (and retracted) like my lame Allen Key Z-Probe

@Roxy-3DPrintBoard Is that different from the "usual" Allen Key probe, which uses configured GCode to bump against something to "deploy" and "stow"? You actually have to "deploy" and "stow" it by hand?

[Roxy-3D]

manually deployed (and retracted) like my lame Allen Key Z-Probe

@Roxy-3DPrintBoard Is that different from the "usual" Allen Key probe, which uses configured GCode to bump against something to "deploy" and "stow"? You actually have to "deploy" and "stow" it by hand?

Yes. There are some very lame printers sold by Geeetech and I am the sad owner of one of these. These printers need the user to put the Allen Key probe down by hand. That is not so much of a problem because you can do this before you start the print.

But you need some special GCode after the G28 & G29 to move the effector very slowly and to a safe location so you have time to manually stow the Z-Probe. I've patched my deploy_z_probe() and stow_z_probe() to wait on a click from the LCD Panel. That works much better than the BS Geeetech was doing to move the effector very slowly to give you 30 seconds to manually stow the probe.

Anyway... A Z-Probe Object may be in the process of being written. If so... I'll keep an eye on it and make sure this characteristic gets included as one of the sub-options.

Another sub-option that definitely will need to be included is the move to special locations to deploy and retract a probe. That Tilt-Probe shown in the YouTube video here is in that category:

https://github.com/MarlinFirmware/MarlinDev/issues/397

In my mind, that is the same as the Allen Key movement to get deployed and stowed except it is going in a different sequence of moves. I think we all agree some option in deploy() and stow() to allow a movement based operation makes sense.

And lastly... Coding is going slow because I just can't find the time I need to sit down for a few hours at a time. But I'm building a Mesh Editor into the code I'm doing. It is going to be possible to use the Mesh Bed Leveling even if you don't have a Z-Probe. The user would manually run the nozzle around the bed and very carefully move it so it just touches the glass and indicate the current location should be sampled. This is probably Yet Another Manual Z-Probe.

[Sniffle]

I see this acting software wise the same as the fsr pads or inductive sensor its just always there and always active and when it triggers it acts as the Z max switch. Maybe call it a "constant" probe type that is always considered to be deployed and can not be retracted.

[Blue-Marlin]

Right. A FIX_MOUNTED_PROBE

[ghost]

Hum... I tried to draw those in the diagram.

It's complexly intertwined...

[Roxy-3D]

Hum... I tried to draw those in the diagram.

A diagram like this is very helpful. Especially as we try to figure out how to simplify the #defines that configure the probe(s). But it is also helpful as we try to figure out how a Z-Probe Object should be designed. For example, should there be a base class that various types of probes extend? Or instead of extending, should weird Z-Probe types just over ride stuff that is inappropriate for them in the base class? Or should each probe type just be its own code? Is there an opportunity to leverage common functionality across multiple probe types?

But, lets try to figure out a good name and put the "Manually moved around nozzle with some type of trigger" on to the diagram too! And very possibly, there are two or three types of triggers on this type of probe. There will be an LCD Click. There will very likely be a sub-code of the G29 sent from PronterFace to tell the firmware to sample. (It is possible the LCD code just injects this same GCode into the command buffer) And lastly, it maybe we want to allow the user to just tap an existing endstop switch to signal the firmware should take the sample.

[Sniffle]

OK, the way I am currently thinking of this is a master probe class, that probe class tracks whether the the probe is extended or retracted and allows a call to be made to the probe object for the probes current status. In full OO it would also be passed the reference to the motion_control object so that a call could be made to the motion control object to extend/retract the probe from the probe object, most likely by extending the motion control object itself.

from that base probe functionality that covers the most basic and original probe that is on an arm actuated by a servo(I chose this to be the base probe class because it pretty much the original, as far as i know) , we extend and override the base probe class so that we can then override the extend and retract functions to cover all other scenarios, so that each real scenario is covered and handled independently and completely so that basically all probe scenarios are covered in a proper OO fashion and they are each independently handled properly and broken out as they need to be.

The only thing that is common between all probe type is its state and the need to access that state, it is either extended or retracted, even the probes that are "constant" like the inline delta probes with 0 offset or the FSR probes can be considered Extended at all times.

[Roxy-3D]

The only thing that is common between all probe type is its state and the need to access that state, it is either extended or retracted, even the probes that are "constant" like the inline delta probes with 0 offset or the FSR probes can be considered Extended at all times.

Just one small point to make sure everybody is on the same page:

I think what we have settled on is if the probe is stowed, it should not be checked in the low level code that is looking for an end stop violation. (The fact the probe is "Constant" does not enter into the logic. In fact, in the case of the Allen Key probes, many of them show up as Triggered when they are stowed and that is the reason for this logic.)

[Sniffle]

Don't we only check the probe endstop while probing just because of that very problem? The constant probe types —even though always extended— also should never be triggered unless there is an issue. As with the correct offset (and printing properly) the bed is never pushed down with sufficient force on the FSR, nor is the nozzle ever pushed up again with the inline delta configs. As a proposed solution for kn(o)wn offenders like the allenkey probe we can probably set a flag to ignore erroneous depressed endstops when not probing.

[jbrazio]

I am currently thinking of this is a master probe class, that probe class tracks whether the the probe is extended or retracted

OOP (without interfaces):

• Find all methods that are common to all probes: create Probe object
• Find all methods that are common to a group of probes: ProbeGroup extends Probe
• Find specific methods for each probe: ProbeABC extends ProbeGroup

[Roxy-3D]

As a proposed solution for kn(o)wn offenders like the allenkey probe we can probably set a flag to ignore erroneous depressed enstops when not probing.

Yes. There are outstanding Pull Requests that do this but have not been merged yet. Probably, the Probe keeps track of whether it is stowed or not. And obviously, it can return whether it is triggered or not. With those two things, we can make the right thing happen.

[AnHardt]

• Normal Allen-Key probes are triggered when stowed.
• Some kinds of servo probes are triggered when stowed.
• Inductive/Capacitive -probes are triggered when close to zero level.
• Not-perfectly-adjusted FSR are known to give lots of false positives.
• For the simple mechanical probes i guess a bit of over-extrusion is able to trigger them. ...

For all these probes we used to need ENDSTOPS_ONLY_FOR_HOMING to print reliably. ENDSTOPS_ONLY_FOR_HOMING implies not testing x and y endstops most of the time. So for majority of machines with probes, a valuable safety feature, was switched off.

The concept: "Probes are only tested when deployed" allows to leave ENDSTOPS_ONLY_FOR_HOMING off. So x,y and even separate z-endstops can be tested all the time.

The calling functions now have to deploy every kind of probe, which is a simplification. They don't have to look for every kind of probe if to deploy or not. The aim here is to move the complexity from the calling function to the deploy-function/method (of the probe object).

For all kinds of probes, not needing a physical action to deploy, deploying is only setting a flag, so from then on the probe pin is tested.

For stow() it's the same.

The next ma(j)or step for a unification wo(u)ld grant that the x/y-position before and after deploy/stow is the same.

[Roxy-3D]

The next ma(j)or step for a unification wo(u)ld grant that the x/y-position before and after deploy/stow is the same.

Can you help me understand why having the same X & Y location for deploy() and stow() is valuable? The reason I'm having trouble understanding this is because when a 3 x 3 grid is probed, you may want to kick down the probe at the first probed point. But it is very possible you want to retract the probe as soon as you finish measuring the last point in the grid. And as a result, the X & Y location is going to be different for the deploy() and stow() operations.

[jbrazio]

Actually it may be probe type dependent where you stow or deploy it. Remember that mechanical one without servos ?

[AnHardt]

Sorry maybe a misleading explanation.

• Deploy should end at the same y/x it started with.
• Stow should end at the same x/y it started with.
• Stow does not need to end at the point Deploy started.

For most probes that is already true, but for example Allen-Key-probes end somewhere.

Actually it may be probe type dependent where you stow or deploy it. Remember that mechanical one without servos ?

It's not a big thing to remember the x/y-pos. and return to there.

G29 E and M48 E are trivial then - for all kinds of probes.

[Roxy-3D]

OK. That is easier to understand. I think what we are doing is adding a requirement that if a Probe Object needs to move to cause a deploy() or stow(), it should remember where it started the operation and return to that location prior to leaving the function.

[thinkyhead]

I notice that you could probably infer a "mechanical probe" from a positive Z probe offset, instead of negative as it is with other types of probes. But perhaps there are are other kinds of probes that could have a positive Z probe offset.

[thinkyhead]

@walrhe93 We got a little off-track here, sorry! Are you able to work around your issue currently, or does it look like we need to add the MECHANICAL_PROBE option before it will work properly for you?

[walrhe93]

I didn't have a lot of time last week. Today I've been trying to get it to work.

At the moment I've got two versions. The first one is the one provided when I bought the printer. This is a Chinese version. It based on the original Marlin firmware (don't exactly know what the differences are). This version is working with the probe, only the auto level feature is not compensating the heated bed correctly. (Keeps scratching the bed at various points) The second one is the Marlin-RC4. In this version I can't get auto-calibrate to work at all. (I can't even get the current version to compile correctly). It also doesn't seem to recognize the SD card, so I'll have to look into that as well.

At this point I can't print any large objects because of bad calibrations. I'm hoping to get the printer working with auto-level so I can start printing larger objects.

[ghost]

@walrhe93 I've created a branch that it integrated your custom config(and modified for SD card and so on). At least it didn't causes compilation error at this time. Please try it if you want. https://github.com/esenapaj/Marlin/tree/support-simple-mechanical-probe-for-walrhe93

[walrhe93]

@esenapaj Thak you. The SD card seems to work. however Auto level still has a bug. It works once in a while. It detected the Z-Probe switch being pressed a couple of times (randomly it seems). Most of the time it still doesn't stop when the switch is pressed.

[ghost]

@walrhe93 I'm sorry for the inconvenience. I've confirmed just now that something was broken (by merging with newest official RCBugFix?). I try to fix.

a soliloquy: I'm searching now, and it seems that RC4 not only excluded simple probe but also broke essential something about delta.... Although conditions are not clear, but I'm confirming strange phenomenon with non-modified RC4. What is this... RC3 looks like fine. ...

https://github.com/MarlinFirmware/Marlin/commits/186629aee87988ece3e4609ce5d3e2c53fbb613f ok https://github.com/MarlinFirmware/Marlin/commits/79778d46d908f241a532fa134eb39e1ec4dbcbb6 ng

...I've found it. https://github.com/MarlinFirmware/Marlin/commit/fbfbc5e330259331bef99d7e8f73d81133b6ef44 That's to say, watchdog breaks something of delta? ...The other is my highly stepping rates(400step motor * 128microstep RAPS128). If I set rates to 64microsteps, it seems that watchdog doesn't causes troubles.

[thinkyhead]

@walrhe93 So if you disable USE_WATCHDOG everything works perfectly? (I would be surprised if it has any effect.)

@esenapaj It looks like @walrhe93 needs that MECHANICAL_PROBE feature. I see you have a branch all ready for @walrhe93 . So I guess we should bring this into RCBugFix soon.

[ghost]

@thinkyhead About USE_WATCHDOG, It looks like that it doesn't causes problem except ultra high stepping rates (for example 1600steps/mm, it's my unfinished delta). I'm still searching about it.

I guess we should bring this into RCBugFix soon.

It's grateful for me also. But my branch similar to ad hoc, so I've misgivings it. In your eyes, would this branch be acceptable?

...oh, I had forgotten that description for MECHANICAL_PROBE. But my english is very poor... So I'm terribly sorry, but I've quoted your comment. https://github.com/esenapaj/Marlin/commit/a3b2dca41a1379e6a92dbb4731cffc4b8aeb98dd

@walrhe93 I think that your settings of endstops possibly incompatible with your hardware. Thus, I've prepared branches that those are several types. case A: I think that this is best? deleted https://github.com/esenapaj/Marlin/tree/for-walrhe93-config-A

case B: it resembles mine deleted https://github.com/esenapaj/Marlin/tree/for-walrhe93-config-B

case C: it similar to mine deleted https://github.com/esenapaj/Marlin/tree/for-walhe93-config-C

case D: it same as yours deleted https://github.com/esenapaj/Marlin/tree/for-warlhe93-config-D

I recommend that you throw M502 and M500 from host software, or you click "Control -> Restore failsafe" and "Control -> Store memory" before test. M502(Restore failsafe) loads Hardcoded default settings. M500 (Store memory) store the loaded settings to the EEPROM. These operations refresh EEPROM on your board.

And, I recorded a video clip that it include operations of "Restore failsafe" and "Store memory". This video was taken with experimental branch, it's same as I prepare to you.

[jbrazio]

About USE_WATCHDOG, It looks like that it doesn't causes problem except ultra high stepping rates

This is weird, why a performance impact when USE_WATCHDOG is enabled ? It should be only updating a register periodically.

[Blue-Marlin]

1600steps/mm

A 'normal' delta has about 80steps/mm. Even then most users experience a limitation in the possible feedrates or 'segments/time', especially when used with a full graphic display. 1600 is about 20 times faster - so it's very likely all processor time is used in the stepper interrupt and no time is left to the normal loop, so there is no time to refresh the watchdog-timer.

If you have a 16Mhz Atmel, 1600 is simply too much.

[walrhe93]

@esenapaj Thank you project from case A is working with auto calibrate and sd card.

There's only one problem. After calibrating the print head keeps scratching the pate at various points. Does anyone know what might cause this problem?

[Roxy-3D]

There's only one problem. After calibrating the print head keeps scratching the pate at various points. Does anyone know what might cause this problem?

Does the nozzle sag or dip down when you tell it to move 100 mm horizontally?

[zylantha]

Thank you @esenapaj ! I have had the same issue as the OP with RC5 for two days now and this has finally stopped my print head drilling through my build plate ignoring the z_min trigger!

A small error in Temperature.cpp in this branch surfaced for me - if (ELAPSED(ms > next_auto_fan_check_ms)) { // only need to check fan state very infrequently

needs ">" replaced with "," (probably fixed upstream)

[Blue-Marlin]

@zylantha Please help us to analyse your problem. What kind of machine? What kind of probe? Where connected? Configuration? At the first, or subsequent probing points? What endstops do you have? What does M119 show in mid air? Are Z_RAISE_BEFORE_PROBING, Z_RAISE_BETWEEN_PROBINGS, Z_RAISE_BETWEEN_PROBINGS all big enough to untrigger the probe?

[zylantha]

I have a Kossel XL with the same type of mechanical probe as the OP which uses the nozzle on a hinged effector to trigger a micro switch as the level sense.

With RC5 it would drill straight into the build plate on the first probe.

The same configuration but with mechanical_probe set on the new branch - worked first time.

Sent from my iPhone

On 13 Apr 2016, at 11:45 PM, Makaira notifications@github.com wrote:

@zylantha https://github.com/zylantha Please help us to analyse your problem. What kind of machine? What kind of probe? Where connected? Configuration? At the first, or subsequent probing points? What endstops do you have? What does M119 show in mid air? Are Z_RAISE_BEFORE_PROBING, Z_RAISE_BETWEEN_PROBINGS, Z_RAISE_BETWEEN_PROBINGS` all big enough to untrigger the probe?

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/3335#issuecomment-209446499

[ghost]

@zylantha I've updated my experimental branch(and the other branches in this thread) by rebasing with newest official RCBugFix in haste.

@Blue-Marlin supplementary explanation: "mechanical probe uses the nozzle on a hinged effector to trigger a micro switch as the level sense." is like this. It's "simple mechanical" in the diagram, and comment of @thinkyhead is useful reference.

[ghost]

@walrhe93 I found another incompatibility with your hardware(, I think.) In case of using simple mechanical probe, value of Z_PROBE_OFFSET_FROM_EXTRUDER(It called "Z Offset" in LCD menus) needs to be set positive number. Because point of "probe" is slightly higher than point of "nozzle", in mechanism. I've updated the branch. https://github.com/esenapaj/Marlin/tree/for-walrhe93-config-A deleted (Please use the latest RCBugFix + config for you)

I set the Z_PROBE_OFFSET_FROM_EXTRUDER to 0.3 in this branch, but I'm not confident in that that this value match the your machine. Fine adjustment needs to be done by yourself.

I think that It's various methodology are available for adjustment of z offset with bed leveling. I introduce my methodology tentatively.

1. g28 from Host software(I use Repetier-Host)
2. g29 from Host software
3. g0 f1000 x0 y0 z0 from Host software
4. measurement distance between the nozzle and the bed by 0.2mm clearance gauge or paper that it has an approximate thickness
5. If distance doesn't reach 0.2mm, increase the "Z Offset" in LCD menus, and go back to 1.
6. If distance reach 0.2mm, scratching has been gone presumably.
7. Send m500 from Host software or click "Store memory" in LCD menus. This operation write the changed "Z Offset" to the EEPROM on your board. 

[zylantha]

That's correct - Z_PROBE_OFFSET_FROM_EXTRUDER will always be positive with this type of manual probe (despite the comments in the old config files saying that this value should always be negative - it would be good for this to be clarified).

The value of this parameter completely depends on the setup of the extruder hinge - there is a screw that goes through the extruder mount from underneath, and the end of that screw pushes against the Z endstop microswitch. The distance that the screw needs to push to trigger the microswitch will determine the required value of Z_PROBE_OFFSET_FROM_EXTRUDER.

This will in turn vary depending on the type of microswitch, and how far the screw is extended up above the carriage when the effector was assembled.

On my particular setup, I have this at 1.33mm (based on past trial and error).

[ghost]

it would be good for this to be clarified

Thank you for your advice. I've changed the description of Z_PROBE_OFFSET_FROM_EXTRUDER.

[ghost]

@zylantha @walrhe93 Fortunately, official RCBugFix has re-supported our probes just now.

[zylantha]

Great news! Confirmed as working on RCBugFix now.

[nebbian]

Thank you so much @esenapaj for your work here. I've been tearing my hair out over this issue recently, and the first firmware that worked was your branch. Now I can confirm that the latest RCBugFix works properly as well.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.