@dc42 Yes, I am doing that now. However, I want the prompt to contain options that are dynamically created based on the content of "0:/filaments". I don't want to update the prompt every time I add a filament, or modify the name of a filament. Just like how DWC creates the prompt when pressing the 'Load Filament' button.

@Esteban said in Untimely stop and reversal of movement, SZP sensor reading error:

I get an error telling me that the points have been skipped

This means your grid has points that are outside of the reachable area of the probe. When choosing the grid extents, take into account any offset your probe has.

For the problem of prints failing, can you gather a diagnostics report using M122 right after it happens?

For the problem with drivers, it's not totally clear what the issue is. Are you saying that motors connected to the mini2 card, don't work?

In general I think it would be beneficial to split up your issues into individual forum posts. It's much easier to tackle one thing at a time.

Also please share your config.g and the results of M122 here so we have a better idea of what you're working with.

@Bridge-Of-Don said in Auto matic Levelling Error:

Ian, Many thanks, all seems to work just fine, onwards??

I thought I should post the result of our efforts, seems to fairly flat?
Height warm with dual Z screws.png

Typically we get this sort of report. . . .
Leadscrew adjustments made: -1.525 1.940, points used 2, (mean, deviation) before (0.208, 0.970) after (0.000, 0.000)

@nicaris said in Duet 2 wifi homing issue:

The probe does deploy. I can home the x and y but the head will move away from the x and Y axis along the x axis (emergency stop triggered !

Can you share a video if what you're seeing during homing?

RepRapFirmware for Duet 2 WiFi/Ethernet version 3.6.0-beta.2

It may be a good idea to go back to firmware version 3.5.3 stable release until everything is working well before testing a beta firmware.

@Alva Looks like it is a timing problem or something.

@dc42 Thanks for this clarification.
I'm currently using 2 motors because I originally had two limit switches which didn't work so well. that's why I wanted to switch to only one limit switch. The only problem was that I couldn't find a closed belt that was the length I needed. The chamber is heated (theoretically up to 120°C) and therefore I cannot use just any belt. I would also have to switch to a Nema 23 motor so that I can generate enough torque for both lead screws but I don't have the space for that. So, for me the option with the least effort was to use 2 motors which I then connected with the longest belt I could find.

As soon as I find the time, I'll try again with the current configuration and pay more attention to the belt tension. I probably made a mistake last time when connecting the two motors.

In your opinion, does it make more sense to use two limit switches or to connect both motors?

@developeralgo222 if you don't need isolation between the sensor and the Duet, just use 2 resistors as a voltage divider.

A better solution would be to use sensors that provide a digital interface that the Duet can use, for example Modbus RTL via RS485. You cold put all 6 sensors on the same RS485 bus provided that the sensors provide a way to set then all to different slave addresses.

We have a small number of prototype 2-channel ADC daughter boards designed for reading 0 to 10V signals.

@Surgikill said in Filament change logic is not making sense.:

First, if I select the filament from DWC and click 'unload', it heats the bed and waits for the bed to reach temperature first. Is this intended? This is even before it executes M702. This seems counterintuitive. Is this being influenced by tool change macros? When I run T0, it puts the bed into standby mode. However, my toolchange macros don't call for that to happen.

That does not happen on my machine. When you unload a filament, the corresponding tool (T0) is selected beforfe M702 is called. If the tool has an active temperature set and if M116 is in your tpost0.g, RRF will wait for the active temperature to be reached before the filament change happens.

@Surgikill said in Filament change logic is not making sense.:

Also, when loading filament, it does not load the selected filament parameters before loading.

Are you missing M703 to execute the filament's config.g after M701? DWC calls that automatically after loading via M701. Note that M703 within the load.g macro of your filament has no effect. M703 should be called when the filament has been loaded, because the filament mapping is NOT updated before load.g finishes.

@oliof
Thank you sent an email to the seller.

@rqthree Nice find!
I started looking for a wood lathe and the turning tools I'd need and guess what I've found:
Wood turning Tungsten carbide round cutter
They come in different sizes from 8.9mm to 16mm dia. A set of 10pcs is ~18€ which would be a lifetime supply for our usecase
Wendemesser_10x.jpg

@jensus11 Q50 is fine. You will probably hear a slight buzz.

@semi55 He's still busy with 3.6! To reiterate the question for @dc42 :

User wants to hide the U axis on an IDEX, so his users don't jog it and get unexpected movement. Seems fair, but:

If he hides U with M584 P3, when U is mapped to X, and X is moved, there's no movement. This seems like a bug, as I thought M584 P# only hid the axes in DWC. I have not reproduced this. Is this expected behaviour with hidden axes that are mapped? As far as I'm aware M584 P should only hide the axis/axes homing and jog controls in DWC, but it seems to affect axis movement. I always thought it was odd that you had to unhide axes to home them, though again I haven't really experimented with it. Alternatively, to keep U and X in sync without extra movement (again, I haven't tested if this is the case, but he reports it), DWC could send an M400 after each time a U move is sent, maybe? Or would this cause problems with stuttering movement if a jog button was pressed multiple times?

Ian

@Surgikill yes you need to re-enable the trigger using parameter R0, R1 or R2.