RepRapFirmware 3.0beta 11 released

A Former User

@stereo said in RepRapFirmware 3.0beta 11 released:

where Duet3iap_sd_MB6HC.bin?

https://github.com/dc42/RepRapFirmware/releases/tag/3.0beta10 ?

stereo

@bearer 3.0beta10.. need 3.0beta11

A Former User

@stereo said in RepRapFirmware 3.0beta 11 released:

@bearer 3.0beta10.. need 3.0beta11

the IAP file is probably the same if its not listed on the beta11 release

stereo

@bearer yes, work. install beta11

A Former User

@dc42 said in RepRapFirmware 3.0beta 11 released:

It works for me. Tested using a BLTouch connected to zprobe.in and exp.heater3, G31 P value set to 100.

hm, that's not good

It's possible that you have a G31 command in config-override.g.

I did not create it, I don't see it trough web interface..

btw you don't need the M401 and M402 commands in your homez file, because probe deployment/retraction is done automatically (this has been the case for many firmware versions).

so G30 auto deploy/retract? nice.. but I'm now more concerned that after G30 I touch the probe, the probe detects me, bed still moves, the probe deploy again, touch again, detect again, deploy again .. bed still moving etc etc.. so no bed stop and no retraction happening at all (G30 not finishing) .. exactly the same config on b10 works, b11 don't. tried G31 P10, P100, P200 .. It's not a working printer (yet) so not a big deal but if there's anything I can help debug lemme know (I can hook up oscilloscope or .. ) .. this is supposedly original bltouch v3 .. but "original" when bltouch is can be tricky ... I have 2 "original" (from "original aliexpress store" paid original price), I have 2-3 clones too that I can try also .. might be the timing issue and not only the trigger level?

Danal

@smece said in RepRapFirmware 3.0beta 11 released:
It's possible that you have a G31 command in config-override.g.

I did not create it, I don't see it trough web interface..

If you don't see it via the web interface, it is likely not there.

But just to help understand the full picture: That file is created and/or updated when you issue an M500. That is often documented in other firmware as "save settings to EEPROM". Duets do not have EEPROM, so they save settings to /sys/config-override.g

Anyway, sounds like you don't have one.

A Former User

@Danal thanks for explanation! ... did not do M500 yet since this is a work in progres conversion to duet, and I never used duet before, i'm trying to setup everything directly in main config's for now .. that's also why I started with RRF3 and not gone with stable version (still don't have thermistors nor heaters in the hotends so..)

dc42

@smece, just to confirm:

You are using RRF3 on a Duet WiFi
You have connected the BLTouch white wire to IN on the ZProbe connector, and the black wire to GND on the ZProbe connector
You are getting a reading of 0 for the Z probe in DWC
If you disconnect the BLTouch from the Z probe connector, you get a reading of 250 for the Z probe
If you send G31 without parameters, it reports the P parameter is 100 (or whatever you set it to, less than 250)
You had the BLTouch working with firmware 3.0beta10

Is that all correct?

stereo

On update 10->11 not work homex(y)(all) files. Change S1 to H1..

G91 ; relative positioning
G1 H1 X-355 F1800 ; move quickly to X axis endstop and stop there (first pass)
no reaction to the command at least earlier moved where necessary.

Immediately provide 0.

G91
G1 X-5
NOT WORK TO! IF X = 0

A Former User

@dc42 said in RepRapFirmware 3.0beta 11 released:

@smece, just to confirm:

You are using RRF3 on a Duet WiFi

No, Duet2Ethernet, RRF3.0beta10 works, RRF3.0beta11 does not

not sure if duet wifi is the same board (I guess it is, with the net module difference, but can't be sure)

You have connected the BLTouch white wire to IN on the ZProbe connector, and the black wire to GND on the ZProbe connector

Yes

You are getting a reading of 0 for the Z probe in DWC

Yes

If you disconnect the BLTouch from the Z probe connector, you get a reading of 250 for the Z probe

No clue what was DWC showing but when I disconnect zprobe (just the zprobe.in and gnd, was not touching the power and servo) and shoot G31 I get

Current reading 250

So I assume DWC is doing same and showing 250

If you send G31 without parameters, it reports the P parameter is 100 (or whatever you set it to, less than 250)

Yes

You had the BLTouch working with firmware 3.0beta10

Yes, it's on beta10 now and works flawlesly

When on beta10 I disconnect probe
DWC shows 1000
G31 shows

G31
Current reading 1000, threshold 100, trigger height 2.20, offsets X35.0 Y0.0

rebooting now into beta11

DWC showing 250
G31:

G31
Current reading 250, threshold 100, trigger height 2.20, offsets X35.0 Y0.0

connecting connector back
DWC showing 0
G31:

G31
Current reading 0, threshold 100, trigger height 2.20, offsets X35.0 Y0.0

executing
G0X0Y0
G30 ; so no deploy/retract as you said

bed start closing in as expected, I trigger the bltouch with finger, bed continues to move bltouch deploy again I trigger again it deploys aga I trigger again ... bed moves ... I powercycle the printer

A Former User

now I tried (beta11) to jenk the cable during G30 and

10/23/2019, 10:05:32 PM 	G30
Error: Z probe already triggered at start of probing move

this error is probbly 'cause my probing is configured (don't remembe where) to touch out 2 times so when it started the second round it was still triggered..

do you want me to measure length of the impulse BLT sends when is triggered? I read somewhere that original v3 bltouch might be too fast for some firmware to detect.. should be simple to capture.

stereo

Do all home X, Y work fine? Am I the only one? show homex.g
On beta10

G91 ; relative positioning
G1 Z5 F6000 H2 ; lift Z relative to current position
G1 H1 X-335 F1800 ; move quickly to X axis endstop and stop there (first pass)
G1 X5 F6000 ; go back a few mm
G1 H1 X-335 F360 ; move slowly to X axis endstop once more (second pass)
G1 Z-5 F6000 H2 ; lower Z again
G90 ; absolute positioning

work good.

On beta11 goto Z5,Z-5,X5.. but does not go to the microswitch.

dc42

@stereo said in RepRapFirmware 3.0beta 11 released:

Do all home X, Y work fine? Am I the only one? show homex.g
On beta10

G91 ; relative positioning
G1 Z5 F6000 H2 ; lift Z relative to current position
G1 H1 X-335 F1800 ; move quickly to X axis endstop and stop there (first pass)
G1 X5 F6000 ; go back a few mm
G1 H1 X-335 F360 ; move slowly to X axis endstop once more (second pass)
G1 Z-5 F6000 H2 ; lower Z again
G90 ; absolute positioning

work good.

On beta11 goto Z5,Z-5,X5.. but does not go to the microswitch.

Please post your config.g file. Which Duet are you using?

stereo

@dc42

M574 X1 S1 P"io0.in" or
M574 X1 S0 P"io0.in"
on beta11 always triggered YES.

IF RUN "M574 Y2 S0","M574 X1 S0" work fine NO...

normal config on beta10:
M574 X1 S0 P"io0.in"

Duet3

A Former User

@dc42 FOUND THE CAUSE OF THE BUG

This is ZPROBE.IN in beta10 (bltouch disconnected)

as you can see ~3V with some ugly 50Hz garbage that should not interfere

but this is ZPROBE.IN in beta11 (bltouch disconnected)

as you can see it's floating around 1V at 50Hz so I'd say ZPROBE.IN is HIZ at this point and there is no pullup enabled... I don't see on schematic where zprobe_in becomes zprobe_mcu, are you using external pullup or you just need to configure it as in with pullup enabled .. anyhow .. there's no pullup on zprobe.in with beta11

A Former User

found the zprobe_in to zprobe_mcu .. just 10k trough and 2n2 down .. so def port configuration missing

and I also found the commit that introduced the bug:

src/Endstops/LocalZProbe.cpp:42

https://github.com/dc42/RepRapFirmware/blame/c25d73194252791ceb479ced79ffc77b31c810fe/src/Endstops/LocalZProbe.cpp#L42

you switched it from PinAccess::readWithPullup; to PinAccess::read;

A Former User

This will probbly work ok with bltouch v2 or v1 as they have 0/1 output, v3/v3.1 is open drain output so it can only pull low. Not sure why you switched from readWithPullup to read, but maybe create a new probe type with pullup, or should we add external pullup if this is to remain without one on the port?

Nuramori

@smece sadly, I saw your posts 3 minutes too late :p.

Thought my errant height map was a fluke due to a part swap. I dug a nice groove into my test spring plate (luckily I always use a sacrificial test plate whenever I change anything on the printer, hardware or software).

Moving back to 10 brought everything back to “normal”.

dc42

@smece said in RepRapFirmware 3.0beta 11 released:

so I'd say ZPROBE.IN is HIZ at this point and there is no pullup enabled... I don't see on schematic where zprobe_in becomes zprobe_mcu, are you using external pullup or you just need to configure it as in with pullup enabled .. anyhow .. there's no pullup on zprobe.in with beta11

Thanks for tracking this down. I removed implicit enabling of pullup resistors in beta 11 because it meant that you couldn't turn them off. If you want to enable the pullup resistor, you need to be explicit by using C"^zprobe.in" in your M558 command.

The BLTouch that I test with is the older version that drives the output high when triggered, that's why I didn't see the problem during testing.

I'll update the documentation to make this clear.

A Former User

@dc42 said in RepRapFirmware 3.0beta 11 released:

you need to be explicit by using C"^zprobe.in" in your M558 command.

Perfect, this solves the problem. Everything works ok now.

M558 P9 C"^zprobe.in" H5 F120 T3000 A2
M950 S0 C"exp.heater3"
G31 P100 X35 Y0 Z2.2