P1 type probe feed rate for "near"

arhi

At the moment M558 allow us to define probing feed rate ( Fnnn Feed rate (i.e. probing speed, mm/min) ) but the way that it is implemented now is for the IR probe that returns an analog value corresponding with the proximity of the barrier so in order to increase precision RRF slow down when the probe is near the threshold so the speed decreases as the distance decrease. Great, if you use IR probe, very very bad if you use e.g. piezo probe, as there is zero change in analog value due to the nature of the probe and this assuming difference to trashold is distance makes fine tuning the speed of the probe impossible.

There was some talk about adding a new probe type for Piezo analog or adding a new parameter for the P1 type probe for this "slow down near trashold" (so we can set that "near" == 0 disabling this functionality all together) so I'm adding a FR here to the wishlist list as it would help some piezo sensors work much more reliable.

gtj0

@arhi How would you know when you're "near"? Regardless of mode, a piezo isn't going to be activated until the nozzle touches the bed. Even in analog mode, the range of motion between first contact and triggered is tiny. Wouldn't you have to have something like a secondary sensor to determine when the bed is approaching the nozzle or vice versa?

arhi

@gtj0 said in P1 type probe feed rate for "near":

@arhi How would you know when you're "near"? Regardless of mode, a piezo isn't going to be activated until the nozzle touches the bed.

Exactly why I want option to TURN IT OFF!!!

ATTM firmware expects IR probe there and IR probe obviously return the analog value that corresponds to the distance to the bed. That's why when you have probe of type 1 when you look at M119 you get values like:

not stopped
near stop
at min stop

The speed at "not stopped" is what's defined in M558 Fxxx but speed when you are near stop is lower (for e.g. if 558 declares 20mm/sec the speed at "near stop" is only 7mm/sec)

Since there is no "near" wrt piezo I don't need this behavior, especially as I'm allways operating in "near stop" region.

With piezo I need to have "fast change", a "tap" on the nozzle, not a sloooooow pressure as it is not reacting to a very slow (and 7mm/sec is slow) change

gtj0

@arhi Now I understand!! I also have a piezo (Orion) which is why I was confused. The threshold for "near" seems to be 60 below the G31 P setting so if you set G31 P to about 65 above your non-contact reading you should be "not stopped" and get the full speed. The output from the piezo rises and falls very sharply so you may not see the actual peak reading in DWC but it still should trigger fine. I haven't looked at the the code to confirm "60" but I will tomorrow. In the mean time, experiment.

Here are the settings that work for me with a non-contact reading of 535.

; Z-Probe     Precision Piezo Orion
M574 Z1 S2
;              Probe                 Probe  Dive    Travel  Probe
;    Pin       Type   Invert  Settle Speed  Height  Speed   Attempts  Tolerance
M558 C"io4.in" P1     I0      R1.0   F1600	H5.0	T6000	A4        S0.025

;   Trigger          Trigger
;   Value    Offset  Height
G31 P600    X0 Y0   Z-0.10

I've had the M558 F value set to 2400 and while it works fine, having a 500x500x6mm chunk of aluminum moving that fast just scares me.

Oh, having the option to turn it off and even set the value for "near" is still a good idea.

arhi

@gtj0 said in P1 type probe feed rate for "near":

I also have a piezo (Orion)

From tomorrow, I will most probably not. I'm done with it. I had so much fun with the old, open source, design. It works flawlesly on 4 of my printers. Both the drilled disks and the new Andromeda system attached to old style pcb. But Orion just don't work :(. I found yesterday one piece of the puzzle and that's, like usual, idiot between chair and keyboard; namely, I reused installation I made for bltouch so just a 5 wire flat cable going from extruder to the duet. Attached the scope at the end of the cable and %$#@^&#_^%$@ ugly. Today I spent hours trying to figure out what is wrong with it with duet disconnected and scope attached directly to the pcb. This mechanics is just unreliable :(, you need too much force on the Orion to get it to react :(. Dunno if that ABS notch clamp is too stiff or improperly designed or dunno what but geting to reliably function is a serious issue (compared to other solutions that just work). Loosen the screws, tighten the screws, bend it, turn it around... no schematic, LM324 with single pot and bunch of passives, dead power led on day one... I'm just done, I'll hook in the bltouch back.

The idea to have ability to control what's "near" still stands, should be useful for other purposes also.

I'll just sleep on it and bring out my 1GHz scope to see if there's something I missed with this handhald one that was comfortable to use around and on printer itself. But I don't have high hopes, not at all.

dc42

One of the items in the worklist for RRF 3.01 is to remove the automatic slow down feature and instead allow two feed rates to be given in M558, one for the first probe move and the other for subsequent probes at the same point.

gtj0

@arhi I feel your pain. I had one of the original Orions without the analog output and in the end I had to print my own mount to use with a threaded-top E3D heatsink. Fiddling with that pot nearly drove me insane. When the analog capable version came out I decided to give it a try since I already had the mount and it's been working fine. every time I fiddle with the tool carriage though I have to reset the trigger level and for a while I was getting bad readings when the carriage was in certain positions just because of the force the cables, reverse bowden tube and air duct had on the carriage.

I had a lot of luck with @dc42 's IR probe until my PrintBite surface became too mottled to give consistent readings. I've since replaced the PrintBite and if the Orion fails, I'll probably go back to the IR probe.

arhi

@gtj0 gave it today another go, found a piece of high end low noise wire (a pair of silver wires coated in ptfe with silver shirm and ptfe on the outside too) so I used that to connect orion to duet. Interesting enough, when XY is not moving the Z-probe value stay still, does not move at all (was dancing +-3-4, sometimes even more) and even when XY are moving it moves just ~2-3 counts. Of course printing is different and moves a lot. Changed my sensitivity to +2 only and now I'm very happy how it works. Looks like running analog singnal trough a flat cable trough all this EMI was not good for the quality of the analog signal (and that new schematic - digital trigger is POS). Also, it works from 3v3 no problem (I was running it from 5V before)

arhi

ha, I could not leave it alone, recompiled firmware with small addon to diagnostic report

diff --git a/src/RepRap.cpp b/src/RepRap.cpp
index 3dc5f9a1..a977a1c8 100644
--- a/src/RepRap.cpp
+++ b/src/RepRap.cpp
@@ -731,8 +731,28 @@ void RepRap::Timing(MessageType mtype) noexcept
 
 void RepRap::Diagnostics(MessageType mtype) noexcept
 {
        platform->Message(mtype, "=== Diagnostics ===\n");
 
+       const auto zp = platform->GetZProbeOrDefault(0);
+       int v0;
+       int arhi;
+       int arhi_min;
+       int arhi_max;
+       int arhi_sum;
+
+       arhi_min = 4906;
+       arhi_max = 0;
+       arhi_sum = 0;
+
+       for (arhi=0;arhi<100000;arhi++){
+               v0 = zp->GetReading();
+               arhi_sum+=v0;
+               if (arhi_min > v0) arhi_min = v0;
+               if (arhi_max < v0) arhi_max = v0;
+       }
+       platform->MessageF(mtype, "min: %i max: %i sum100k: %i\n", arhi_min, arhi_max, arhi_sum);
+
 //     platform->MessageF(mtype, "platform %" PRIx32 ", network %" PRIx32 ", move %" PRIx32 ", heat %" PRIx32 ", gcodes %" PRIx32 ", scanner %"  PRIx32 ", pm %" PRIx32 ", portc %" PRIx32 "\n",
 //                                             (uint32_t)platform, (uint32_t)network, (uint32_t)move, (uint32_t)heat, (uint32_t)gCodes, (uint32_t)scanner, (uint32_t)printMonitor, (uint32_t)portControl);

and results are crazy
best (usually this is the result)
min: 492 max: 492 sum100k: 49200000

worse (I turned on fan, touched nozzle just before runing it):
min: 492 max: 493 sum100k: 49263707

so ... kahm ... cabling

@dc42 do you think something like this might be useful part of diagnostic? not this particular code but some stat for analog inputs, maybe a separate M-code that can select analog input to stat for a period of time? I did not look trough the code too much just inserted this quickly to get the rough idea what does MCU see on the input but a proper stat for any analog input... dunno, just throwing idea.

sixfeetunder

I have the exact same problem. The probing is to slow for my piezo, but speeding up the max speed is way to fast for normal movements ob the bed. Is there already any solution so this "slowing down" ?

arhi

@sixfeetunder well the new release of the RRF is supposed to have this changed according to @dc42