IDEX and Z Offset

mbtobeca

M98 P"config.g"

HTTP is enabled on port 80
FTP is disabled
TELNET is enabled on port 23
Warning: Heater 1 appears to be over-powered. If left on at full power, its temperature is predicted to reach 953C.

m122

=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.05.1 running on Duet Ethernet 1.02 or later + DueX5
Board ID: 0JD0M-9P6M2-NWNS4-7J9D4-3SD6Q-1V1ZL
Used output buffers: 3 of 24 (17 max)
=== RTOS ===
Static ram: 25712
Dynamic ram: 93552 of which 0 recycled
Exception stack ram used: 320
Never used ram: 11488
Tasks: NETWORK(ready,628) HEAT(blocked,1176) DUEX(suspended,160) MAIN(running,3728) IDLE(ready,160)
Owned mutexes:
=== Platform ===
Last reset 00:33:40 ago, cause: power up
Last software reset at 2021-01-20 08:35, reason: User, spinning module GCodes, available RAM 11488 bytes (slot 1)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 0
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 7.4ms, max retries 0
MCU temperature: min 32.8, current 33.1, max 33.4
Supply voltage: min 24.1, current 24.1, max 24.2, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: standstill, SG min/max not available
Driver 1: standstill, SG min/max not available
Driver 2: standstill, SG min/max not available
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max not available
Driver 5: standstill, SG min/max not available
Driver 6: standstill, SG min/max not available
Driver 7: standstill, SG min/max not available
Driver 8: standstill, SG min/max not available
Driver 9: standstill, SG min/max not available
Date/time: 2021-01-21 09:21:18
Cache data hit count 4294967295
Slowest loop: 10.83ms; fastest: 0.07ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Move ===
Hiccups: 0, FreeDm: 160, MinFreeDm: 160, MaxWait: 0ms
Bed compensation in use: none, comp offset 0.000
=== DDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
=== Heat ===
Bed heaters = -1 -1 -1 -1, chamberHeaters = -1 -1
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Stack records: 2 allocated, 0 in use
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
serial is idle in state(s) 0
aux is idle in state(s) 0
daemon is idle in state(s) 0
queue is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 27.45ms; fastest: 0.06ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 2 of 8
Interface state 5, link 100Mbps full duplex

I wanted to try to correct before deciding to switch to RRF3, but if I can't find it, I will upgrade.

Thanks

Phaedrux

Well there has been a year of bug fixes since 2.05 so it would be nice to test on current code base.

mbtobeca

I upgraded everything, but that doesn't change anything ...

Veti

there are a lot of bugfixes in rrf3 regarding offset of tools

mbtobeca

I look in bugfixes, but not find.
Here is the error message after tool change :

Error: New tool too close to Z axis limit. Aborting tool change

Veti

@mbtobeca said in IDEX and Z Offset:

I look in bugfixes, but not find.

see https://github.com/Duet3D/RepRapFirmware/blob/v3-dev/WHATS_NEW_RRF3.md

search for offset

mbtobeca

In fact, I did find this page, but I couldn't find anything about my problem. I even believe that it is a desired security. I saw that he was talking about the max limit in Z, but not the min limit:
"If a tool change is requested but changing tool would cause the Z max limit to be exceeded because of the changed tool Z offset, the tool change is now aborted"

Thanks to try help me

Phaedrux

So you are on 3.2 now?

mbtobeca

yes i'm on 3.2

hestiahuang

I hit the same issue when I config as below.

Start script:
T1
G28
T0

Root cause:
Reading from code is due to I am using zmin as probe, however I have zmax endstop too. And my zmax saved is small then actual.

Solution:
However I don't want to config zmax again and again.
comment the code and build without checking
Gcodes4.cpp
// auto currentTool = reprap.GetCurrentTool();
// if (currentTool != nullptr)
// {
// const float newZPos = (moveBuffer.coords[Z_AXIS] - currentTool->GetOffset(Z_AXIS));
// if(newZPos > platform.AxisMaximum(Z_AXIS) || newZPos < platform.AxisMinimum(Z_AXIS))
// {
// gb.MachineState().feedRate = toolChangeRestorePoint.feedRate;
// doingToolChange = false;
// gb.MachineState().SetError("New tool too close to Z axis limit. Aborting tool change");
// AbortPrint(gb);
// gb.SetState(GCodeState::checkError);
// break;
// }
// }

alankilian

How are you planning on getting each nozzle down to where they need to be to print a layer when they are 6.5mm offset in Z?

Won't one need to be 6.5mm BELOW the level of the print to get the other one down to the level of the print?

I'm probably misunderstanding something. (as usual!)

hestiahuang

I think this is unnecessary logic. Why I can't switch tools when I am using the zmax endstop? That is the problem in that logic.

hestiahuang

if it is zmax already, tools are far enough to the buildplate, why need such stupid logic.