Z-probe released with a solenoid

Marcossf

@sinned6915 Thank you very much. In our case we need to adapt your code and macros a bit because we do not have to take a sled, but when we do a test we do not lose anything.
The only thing the solenoid does is deploy or hide a probe. Once deployed, it activates an optoendstop by touching the probe to the bed. Simple.

It is quite clear that it is something in the homing files or in the sw configuration we have, since the activation and the hw part is proven to work.

We came from Marlin and RRF its new for us. Simple things like a homing turn into this "jam"

sinned6915

@marcossf i think you need some logic statements in your macros to checks/verify actuation.
my macros work b/c i am checking the conditions of the circuit via probe value.
you could easily add another sensor as an endstop to veify engagment. i dont know if i would use the solenoid trigger as that check, but a seperate sensor.

dc42

@marcossf, from your photo I can't tell which pins of the 5-pin connector the Z probe opto endstop is wired to. Please provide another photo that shows this clearly, perhaps taken from a different angle.

I think you said that G30 does deploy the probe, but triggering the opto endstop does not stop the G30 movement. Is that right? Does the Z probe reading in the web interface jump to 1000 if you trigger it during G30 movement?

Marcossf

@dc42 said in Z-probe released with a solenoid:

@marcossf, from your photo I can't tell which pins of the 5-pin connector the Z probe opto endstop is wired to. Please provide another photo that shows this clearly, perhaps taken from a different angle.

I think you said that G30 does deploy the probe, but triggering the opto endstop does not stop the G30 movement. Is that right?

Yes, it is correct.

Does the Z probe reading in the web interface jump to 1000 if you trigger it during G30 movement?

Yes, it is correct.

dc42

@marcossf, thanks. I can now see the problem. Your config.g file includes this line:

M584 X40.0 Y0.1 Z121.0 E0.2             ; set drive mapping

So you are driving the Z axis from an expansion board (I presume a Duet 3 Tool Board) at address 121. However, the firmware limitations document at https://duet3d.dozuki.com/Wiki/Duet_3_firmware_configuration_limitations#Section_Temporary_limitations includes this:

Endstop switches and Z probes connected to the main board cannot control motors on an expansion board. This is planned to be fixed in release 3.4.

If you use a Z probe then the Z motors must be connected to the main board. This is planned to be fixed in release 3.4.

So in order to get this working completely, you will need to connect your Z motor to the main board instead.

However, RRF 3.3beta3 released yesterday already includes some of the changes to remove this limitation. If you upgrade to that release, then a G30 command should stop the Z motor even if it is connected to the tool board.

A remaining issue that is not fixed in 3.3beta3 is that when the Z motor stops during probing, there may be a very slight overshoot due to transmission delay over the CAN bus, and there is no correction for this. This overshoot should not matter when doing a single Z probe e.g. for homing Z; however when doing mesh bed probing, the error will build up with each probe attempt. As a result, the accumulated error may cause an apparent tilt in the Y direction.

We have work in progress to undo any overshoot after probing. Meanwhile, it can be reduced by using a low Z probing speed. When homing Z, you may wish to do a fast G30 command at a high probing speed (M558 F parameter) first, then lift Z a few mm and do another G30 at a low probing speed.

HTH David

Marcossf

@dc42 said in Z-probe released with a solenoid:

@marcossf, thanks. I can now see the problem. Your config.g file includes this line:
M584 X40.0 Y0.1 Z121.0 E0.2             ; set drive mapping
So you are driving the Z axis from an expansion board (I presume a Duet 3 Tool Board) at address 121. However, the firmware limitations document at https://duet3d.dozuki.com/Wiki/Duet_3_firmware_configuration_limitations#Section_Temporary_limitations includes this:

Endstop switches and Z probes connected to the main board cannot control motors on an expansion board. This is planned to be fixed in release 3.4.

OK, you're right, Z motor are in a external board in this model. In this case a 1LC, but all motors in the final printer are closed loop servos controlled each by a 1XD board.

If you use a Z probe then the Z motors must be connected to the main board. This is planned to be fixed in release 3.4.

So in order to get this working completely, you will need to connect your Z motor to the main board instead.

However, RRF 3.3beta3 released yesterday already includes some of the changes to remove this limitation. If you upgrade to that release, then a G30 command should stop the Z motor even if it is connected to the tool board.

Ok, I can test with the beta3 today and see if this limitation was gone.

A remaining issue that is not fixed in 3.3beta3 is that when the Z motor stops during probing, there may be a very slight overshoot due to transmission delay over the CAN bus, and there is no correction for this. This overshoot should not matter when doing a single Z probe e.g. for homing Z; however when doing mesh bed probing, the error will build up with each probe attempt. As a result, the accumulated error may cause an apparent tilt in the Y direction.

We have work in progress to undo any overshoot after probing. Meanwhile, it can be reduced by using a low Z probing speed. When homing Z, you may wish to do a fast G30 command at a high probing speed (M558 F parameter) first, then lift Z a few mm and do another G30 at a low probing speed.

Still haven't build the mechanical parts for test it. At this moment all boards and pheriperals are laying on the desk, so i can't do measurements or test with the real axes. We need a minimum capable firmware to put in the machine when the build start.

Another thing we tested is remove the external mosfet and use the fan pins to drive the solenoid as you suggest (tested out4 and out7 connectors so far) and we was unable to do with the out4 pin:

We define the pin:

M950 S0 C"out4"   ; create pin 0 for solenoid out4
M106 P0 I-1		; disable the pin as a fan

Tested it with M42 P0 S1 and the pin doesn't out 12v between out4 and gnd. Tested other pins in this bank as well: v_outlc1 its fixed at 12v out and out4.tach its 0v and doesn't switch when its commanded. I don't know how use this pins.

However, with Out7 pins, it is OK.
I can drive the solenoid, M42 P0 S1 enable it giving the 12v out, M42 P0 S0 disable it BUT leaving the pin with 5v instead 0v. This could destroy the solenoid at long term.
How can i get 12v when on and 0v when off??

Thanks,
Marcos

dc42

@marcossf said in Z-probe released with a solenoid:

We define the pin:

M950 S0 C"out4" ; create pin 0 for solenoid out4
M106 P0 I-1 ; disable the pin as a fan

You don't need that M106 command, that was for RRF2.

Tested it with M42 P0 S1 and the pin doesn't out 12v between out4 and gnd. Tested other pins in this bank as well: v_outlc1 its fixed at 12v out and out4.tach its 0v and doesn't switch when its commanded. I don't know how use this pins.

Connect the solenoid between voutlc1 (+ve) and out4neg (-ve).

How much current does the solenoid draw, or what is its resistance?

Marcossf

@dc42 said in Z-probe released with a solenoid:

@marcossf said in Z-probe released with a solenoid:

We define the pin:

M950 S0 C"out4" ; create pin 0 for solenoid out4
M106 P0 I-1 ; disable the pin as a fan

You don't need that M106 command, that was for RRF2.

OK. The wiki documentation is quite tangled and I find it difficult to see what can and cannot be done in each version.

Tested it with M42 P0 S1 and the pin doesn't out 12v between out4 and gnd. Tested other pins in this bank as well: v_outlc1 its fixed at 12v out and out4.tach its 0v and doesn't switch when its commanded. I don't know how use this pins.

Connect the solenoid between voutlc1 (+ve) and out4neg (-ve).

I measure 12v between these two pins, always. Never switched to 0v.

How much current does the solenoid draw, or what is its resistance?

Solenoid could drive from 3v to 12v DC. The max pulling force its at 12v. Resistance is 44.4Ohm.

dc42

@marcossf, use the pin labelled out4 (which on the underside of the board is labelled out4_neg), not the OUT 4 GND pin.

Marcossf

I can't update the 3.3beta3 from 3.2.2 standalone mode.

Downloaded the Duet3 files from the https://github.com/Duet3D/RepRapFirmware/releases/tag/3.3beta3

and from DWC > system >upload system files>choose all the files>ok

It keeps "updating" but nothing happens. If I refresh the web its how nothing would hadn't been uploaded.

Retried it three times with same behaviour.

Marcossf

@dc42 said in Z-probe released with a solenoid:

@marcossf, use the pin labelled out4 (which on the underside of the board is labelled out4_neg), not the OUT 4 GND pin.

So the solenoid negative pin is out4 pin and positive is V_outlc1 ???

dc42

@marcossf said in Z-probe released with a solenoid:

So the solenoid negative pin is out4 pin and positive is V_outlc1 ???

Yes. The pin labelled out4 in the MB6HC wiring diagram should be labelled out4_neg. I have asked for the wiring diagram to be corrected.

dc42

@marcossf said in Z-probe released with a solenoid:

It keeps "updating" but nothing happens. If I refresh the web its how nothing would hadn't been uploaded.

What happens if you send M997?

Do you have a PanelDue in your system? if so, it should display messages during the main board update process.

Marcossf

@dc42 Ok, the solenoid working correct in the out4 pin now.

No paneldue attached.

When issued:
M997
Error: M997: In-application programming binary "Duet3_SDiap32_MB6HC.bin" not found

The files doesn't have been uploaded, but why?

dc42

@marcossf, try uploading just that file again, then run M997 again.

Which version of Duet web Control is currently running? See the Settings General tab.

Marcossf

@dc42 This one:

Unable to upload the files, not even one by one.

I can try some options, try to run from USB (bossa method) or write the files directly to SD card....

dc42

@marcossf said in Z-probe released with a solenoid:

@dc42 This one:

Unable to upload the files, not even one by one.

I can try some options, try to run from USB (bossa method) or write the files directly to SD card....

You are running a version of DWC older than the version of RRF installed on your main board.

If you send M115, what firmware version does it report? Maybe it has upgraded the main board firmware already.

Are you able to upload the DuetWebControl-SD.zip file from the 3.3beta3 release?

Marcossf

@dc42 OK, done!

First of all i updated the DWC version uploading the ZIP. After that, uploaded the files remainig succesfully.

Just intuition. There isn't documented or advert anywhere.

m122 b121
Diagnostics for board 121:
Duet TOOL1LC firmware version 3.3beta3 (2021-04-21 20:42:51)
Bootloader ID: not available
Never used RAM 4320, free system stack 0 words
Tasks: Move(notifyWait,0.0%,153) HEAT(delaying,0.0%,81) CanAsync(notifyWait,0.0%,66) CanRecv(notifyWait,0.0%,79) CanClock(notifyWait,0.0%,66) TMC(delaying,2.9%,57) MAIN(running,92.1%,413) AIN(delaying,5.0%,62), total 100.0%
Last reset 00:01:21 ago, cause: software
Last software reset data not available
Driver 0: position 0, 400.0 steps/mm, standstill, SG min/max 0/0, read errors 0, write errors 1, ifcnt 61, reads 40626, writes 12, timeouts 0, DMA errors 0, steps req 0 done 0
Moves scheduled 0, completed 0, in progress 0, hiccups 0, step errors 0, maxPrep 0, maxOverdue 0, maxInc 0, mcErrs 0, gcmErrs 0
Peak sync jitter 8, peak Rx sync delay 217, resyncs 0, no step interrupt scheduled
VIN: 23.9V
MCU temperature: min 33.4C, current 33.5C, max 33.7C
Ticks since heat task active 60, ADC conversions started 81304, completed 81302, timed out 0, errs 0
Last sensors broadcast 0x00000000 found 0 64 ticks ago, loop time 0
CAN messages queued 26, send timeouts 0, received 421, lost 0, free buffers 36, min 36, error reg 0
dup 0, oos 0, bm 0, wbm 0
Accelerometer detected: no
I2C bus errors 4619, naks 4619, other errors 4619

23/4/2021 14:06:01	m122 b40
Diagnostics for board 40:
Duet EXP1XD firmware version 3.3beta3 (2021-04-21 20:34:11)
Bootloader ID: SAMC21 bootloader version 2.0 (2020-10-15b1)
Never used RAM 5812, free system stack 0 words
Tasks: Move(notifyWait,0.0%,153) HEAT(delaying,0.0%,75) CanAsync(notifyWait,0.0%,67) CanRecv(notifyWait,0.0%,78) CanClock(notifyWait,0.0%,67) MAIN(running,96.5%,420) AIN(delaying,3.5%,62), total 100.0%
Last reset 00:01:12 ago, cause: software
Last software reset data not available
Driver 0: position 0, 86.0 steps/mm, steps req 0 done 0
Moves scheduled 0, completed 0, in progress 0, hiccups 0, step errors 0, maxPrep 0, maxOverdue 0, maxInc 0, mcErrs 0, gcmErrs 0
Peak sync jitter 8, peak Rx sync delay 200, resyncs 0, no step interrupt scheduled
VIN: 24.4V
MCU temperature: min 21.9C, current 22.0C, max 22.3C
Ticks since heat task active 6, ADC conversions started 36374, completed 36374, timed out 0, errs 0
Last sensors broadcast 0x00000000 found 0 10 ticks ago, loop time 0
CAN messages queued 24, send timeouts 0, received 377, lost 0, free buffers 36, min 36, error reg 0
dup 0, oos 0, bm 0, wbm 0

23/4/2021 14:05:41	m122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.3beta3 (2021-04-22 16:28:03) running on Duet 3 MB6HC v1.01 or later (standalone mode)
Board ID: 08DJM-956L2-G43S4-6J9F4-3S46N-TU4QD
Used output buffers: 1 of 40 (11 max)
=== RTOS ===
Static ram: 149960
Dynamic ram: 91328 of which 24 recycled
Never used RAM 112880, free system stack 184 words
Tasks: NETWORK(ready,30.0%,254) ETHERNET(notifyWait,0.2%,117) HEAT(delaying,0.0%,353) Move(notifyWait,0.0%,150) CanReceiv(notifyWait,0.0%,907) CanSender(notifyWait,0.0%,373) CanClock(delaying,0.0%,341) TMC(notifyWait,7.5%,93) MAIN(running,62.1%,1114) IDLE(ready,0.2%,19), total 100.0%
Owned mutexes:
=== Platform ===
Last reset 00:00:52 ago, cause: software
Last software reset at 2021-04-23 14:04, reason: User, GCodes spinning, available RAM 112896, slot 1
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
Aux1 errors 0,0,0
Step timer max interval 127
MCU temperature: min 33.2, current 33.7, max 34.0
Supply voltage: min 24.0, current 24.1, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.1, current 12.2, max 12.2, under voltage events: 0
Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0
Driver 0: position 0, standstill, reads 27998, writes 11 timeouts 0, SG min/max 0/0
Driver 1: position 0, standstill, reads 27995, writes 14 timeouts 0, SG min/max 0/0
Driver 2: position 0, standstill, reads 27995, writes 14 timeouts 0, SG min/max 0/0
Driver 3: position 0, standstill, reads 27998, writes 11 timeouts 0, SG min/max 0/0
Driver 4: position 0, standstill, reads 27999, writes 11 timeouts 0, SG min/max 0/0
Driver 5: position 0, standstill, reads 27999, writes 11 timeouts 0, SG min/max 0/0
Date/time: 2021-04-23 14:05:40
Slowest loop: 3.77ms; fastest: 0.05ms
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 25.0MBytes/sec
SD card longest read time 2.2ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 125, maxWait 0ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters = -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== CAN ===
Messages queued 273, send timeouts 0, received 12, lost 0, longest wait 1ms for reply type 6042, peak Tx sync delay 6, free buffers 49 (min 48)
=== Network ===
Slowest loop: 1.89ms; fastest: 0.02ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions Telnet(0), 0 sessions
HTTP sessions: 2 of 8
- Ethernet -
State: active
Error counts: 0 0 1 0 0
Socket states: 5 2 2 2 2 0 0 0

dc42

OK, the problem was that you were running DWC 2.1.0 with RRF 3.2.2, instead of installing DWC 3.2.2 when you installed RRF 3.2.2. I'm glad it's solved now.

Marcossf

@dc42 said in Z-probe released with a solenoid:

However, RRF 3.3beta3 released yesterday already includes some of the changes to remove this limitation. If you upgrade to that release, then a G30 command should stop the Z motor even if it is connected to the tool board.

I could test really fast this with 3.3.0beta3 and its still unsolved. G30 command or home doesn't trigger when the motor isn't connected to 6HC.

The deploy and retract probe now works well in G30 or home, connected to out4 fan connector.