Once again many thanks for your reply. Using M201.1 to reduce the acceleration has enabled me to achieve a sensorless home! I now feel able to adjust the various parameters to get a reliable performance.
I have read the document on stall detection many times; in fact it was the existence of that document which convinced me that sensor less homing was a viable option. On reading the document I hadn't realised that stealthchop needed to be specifically selected with M569, or that M201.1 could be used to control acceleration whilst homing.
I relied heavily on the section titled Configuring Sensorless Homing, and that doesn't mention these commands. However I also realise that describing stall detection and configuring it is a complex area given the range of stepper drivers used by Duet; and that it would not be possible to describe the software configuration for all hardware combinations
When I set out on building this coreXY machine I realised that there would be a number of challenges along the way and this seems to have been one of them, however it is a good and enjoyable experience when supported by folk like yourselves.

Best posts made by ProfChris
-
RE: Duet3 sensorless homing corexy failure
Latest posts made by ProfChris
-
RE: Duet3 sensorless homing corexy failure
Once again many thanks for your reply. Using M201.1 to reduce the acceleration has enabled me to achieve a sensorless home! I now feel able to adjust the various parameters to get a reliable performance.
I have read the document on stall detection many times; in fact it was the existence of that document which convinced me that sensor less homing was a viable option. On reading the document I hadn't realised that stealthchop needed to be specifically selected with M569, or that M201.1 could be used to control acceleration whilst homing.
I relied heavily on the section titled Configuring Sensorless Homing, and that doesn't mention these commands. However I also realise that describing stall detection and configuring it is a complex area given the range of stepper drivers used by Duet; and that it would not be possible to describe the software configuration for all hardware combinations
When I set out on building this coreXY machine I realised that there would be a number of challenges along the way and this seems to have been one of them, however it is a good and enjoyable experience when supported by folk like yourselves. -
RE: Duet3 sensorless homing corexy failure
Many thanks for your help. I had not appreciated the need for the M569 command. I have added the M569 commands with the D3 parameter - but no stall detected.
I then added V100 to the M569 command - The carriage just moved a small amount but stall detection had worked just over sensitive! I thought I could leave the V100 as my understanding is that it doesn't affect the sensitivity of stall detection, just the switch from stealthchop to spreadcycle.
I have then tried changing the S parameter of the M915 command. I ve found that S7 appears too sensitive (i.e. premature stall detected) and S8 not sensitive enough (i.e. no stall detected).
I am encouraged by now being able to detect stalls, but do not understand which parameter (or command) I need to change to further control the sensitivity of the stall detection. -
Duet3 sensorless homing corexy failure
I am having difficulty understanding why stall detection does not seem to be happening on my new build corexy printer. I have a mini5 connected to a 1lc and a rasperry pi working in sbc mode. I have been working through the commissioning document, and all is fine until I get to the motors section. All the motors are now working, and moving the axes as expected. I attach the config.g file.config.g
I have spent some time trying to understand what is going wrong and have tried to simplify the problem in the attached homex.g filehomex.g
The M574 & M915 entries are there for convenience (they are in the config.g file as well). when I run this file from the dashboard all seems well until the G1 H1 X... command, the carriage moves, hits the end stop and stays there. The current X position in the dashboard updates to 355 (which would be the end of travel of the G1 H1 X.... command), making me believe the stall endstop has not triggered. Unsurprisingly the system returns a G28 failure.
Clearly something is wrong with the setup for detecting the stall - any help in finding where this is will be much appreciated -
RE: 1LC 5 volt supply
@dc42 Thanks for the reply. I thought that that was probably the case
-
1LC 5 volt supply
I am connecting my 1LC to a mini5+ via CAN bus. I am also supplying the 1LC with 24 volt power. I also have a 5 volt power supply routed to the 1LC location. I intend to connect a neopixel to IO_0, and another probe to IO_2. Both of these run on 5 volts. I note that the internal 5 volt capability of the 1LC is very limited. Is there a way to connect my external 5 volt supply to the 1LC such that these devices pick up this supply, or must I power these directly from the 5 volt supply, not involving the 1LC?
-
RE: Order of starting with config.files
Thanks for the reply. I'll try setting up a daemon.g file and macro.
-
Order of starting with config.files
I am running a duet 2 with RepRap 3 firmware. When my machine start I would like to include a user dialogue item within the startup sequence. I have tried putting a dialogue in the config-user file, however the machine hangs without establishing a connection - I imagine that the config files run prior to a console connection being established. Is this correct?
Assuming that this is correct, what is the method for interrogating values in the object model, and performing a dialogue during the startup process, after communications have been established.
Any help appreciated.