Homing Inconsistent Duet 3
-
The config tool generates homeall like that. Nothing wrong with it, but... I'd consider changing homeall to something like:
M98 P"/sys/homex.g"
M98 P"/sys/homey.g"etc, etc.
-
Also, I'd apt-get everything to the latest. Be sure you are on the "unstable" channel:
https://duet3d.dozuki.com/Wiki/Getting_Started_With_Duet_3#Section_Software_Installation
-
@Danal thanks for the suggestions, the issue with apt-get everything is g32 read outs aren't reported after the system updates to 1.2.4.0. also we are running duetpi which I believe the documentation states that process is unneeded.
-
@projectR3D said in Homing Inconsistent Duet 3:
we are running duetpi which I believe the documentation states that process is unneeded.
would depend on the age of the image; at least the early ones only tracked the stable repo even before the 3.0 release.
-
@bearer all of the images have been between the end of January until now.
The newest images have been the ones with the most issues.
-
Understood on the G32. I have lost those as well... living without for now.
Anyway, I would give a try to the homeall calling all the other files.
Delta / Kossel printer fanatic
-
@projectR3D said in Homing Inconsistent Duet 3:
@bearer all of the images have been between the end of January until now.
The newest images have been the ones with the most issues.tbh I don't know when/if they changed it, but you can check the files in /etc/apt/ to see if you have stable + unstable or just the one.
pi@duet3:~ $ grep duet3d -r /etc/apt /etc/apt/sources.list.d/duet3d.list:#deb https://pkg.duet3d.com/ stable armv7 /etc/apt/sources.list.d/duet3d-unstable.list:deb https://pkg.duet3d.com/ unstable armv7 Binary file /etc/apt/trusted.gpg.d/duet3d.gpg matches pi@duet3:~ $ -
@Danal I will give it a try, thank you
-
@bearer ill Take a look thanks!
-
have a similar issue.
reported here@tobias_munich said in RepRapFirmware 3.01-RC3 released:
homeall.g issues:
some times my homeall.g is not working correctly. its straight forward (see below).
it does the 1st line (homex.g) correctly and sometimes it goes directly to the last line homez.g without executing the 2nd line (homey.g)no problem if i run each script separately .
M98 P"homex.g" M98 P"homey.g" M98 P"homez.g" -
Update:
I played around and changed the order of homing x and y in my homall.g
it was ok for 2 days. But today in the morning I had the problem again.
would say in 95% of the cases its ok and randomly it fails.homall.g definitely has a problem.this macro looses lines to execute.
next step; I will setup a separat macro with the same content. lets see what's happend
surprise, surprise. -
I think this needs attention from @chrishamm because as far as i can see, only users running DSF+RPi are experiencing this problem. But here is a wild guess: what happens if you put another command between each pair of M98 calls, for example M400?
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
another thing to look at is the DSF log when this happens, it may shed some light.
if you do
sudo journalctl -u duetcontrolserver -fIn a console on the Pi you will see the latest log entries for duet control server. As a macro is called and expanded each command will show in the logs. It will be helpful to see if there is a difference between when a macro works and it does not.
-
@projectR3D said in Homing Inconsistent Duet 3:
M201
i had a similar issue. decreasing x and y acceleration (M201) helped.
-
I run a Pi 4, when I've encountered this and when looking for anything useful in the journals the cupboard is bare, the control server is basically disconnecting from the duet it seems, it doesn't see the problem and logs no error. My theory is that it sees no response from the Duet and remains 'busy' which locks out any other commands, it never times out but it sees no error since it hasn't actually crashed.
The only way to recover is to either reboot or use sudo systemctl restart duetcontrolserver in a terminal window, then the system will respond again, like the OP most of the times I have seen this is during homing operations which aren't particularly complex in communication terms. This works not because the control server has failed but because the item holding / excluding other actions is forcibly removed from the queue.
This behaviour is random and unpredictable and I've yet to find a trigger, we could do with a way to make the control server reporting a little more verbose - i.e to log all commands sent, responses received - to log the conversation.
-
@Garfield ok, yes if DCS hangs then it does not log. This is a different issue to one we had much earlier on i think. It would be worth trying what @dc42 suggested and putting a M400 between macro calls to see if that solves the issue.
How deep are your macros nested, like homeall->homez->deployprobe->(somecustommacro)->anothercustommacro...?
-
I have no macro nesting at all currently my homing files are all separate with no M98 calls, I don't use deployprobe (don't see such a macro anyway or knowingly call it).
I'm not sure the DCS is hanging - p[retty sure that when I ran sudo systemctl status duetcontrolserver it comes back as 'running' but next time it does this I shall confirm exactly what status returns.
I shall also try the M400 (once I've seen the error again - problem is that I can't reproduce it at will).
-
@dc42 (M400) thats a good point. will test it.
and good to know, that you have it on your list, many thanks.but again. it's not a major issue. the homing scripts are working independently very well
-
I'm a Duet 3 user, with SBC and single 3HC, 3.01 RC3, DSF 1.2.4
My homing is now consistently bugged when using the homeall.g command, regardless of whether I call individual macros or not.
It happens on my X-axis, and behaves like the X Limit Switch is pressed, immediately stopping when X is homed.
I have verified using the machine-specific diagnostics that the trigger is not being pressed, and I've confirmed that it does register correctly when I use my homex.g command and I can see it press, as well as manually pressing it.
I've tried M400 as well as changing homeall.g to incorporate the gcode from homeX, same result, it behaves like the button is always pressed but then processes homeY+homeZ appropriately.
Something weird is afoot here!
-
@Luke-sLaboratory said in Homing Inconsistent Duet 3:
I'm a Duet 3 user, with SBC and single 3HC, 3.01 RC3, DSF 1.2.4
My homing is now consistently bugged when using the homeall.g command, regardless of whether I call individual macros or not.
It happens on my X-axis, and behaves like the X Limit Switch is pressed, immediately stopping when X is homed.
I have verified using the machine-specific diagnostics that the trigger is not being pressed, and I've confirmed that it does register correctly when I use my homex.g command and I can see it press, as well as manually pressing it.
I've tried M400 as well as changing homeall.g to incorporate the gcode from homeX, same result, it behaves like the button is always pressed but then processes homeY+homeZ appropriately.
Something weird is afoot here!
@Luke-sLaboratory please post your config.g, and homing files.
