Hello,

We've been running our printers with Duet 2 Wifi's for a long time and we are currently having an issue with one of them.

The board in itself seems to be auto-rebooting after random times while printing a job.

Hard and Firm specs are the following:

Duet2 Wifi + Duex5
Firmware ver 3.3

We've been using this firmware version + boards + same config files for other machines without issues.

Debugging data gives us the following information:

We're currently lost on how to proceed on this one so any suggestion will be appreciated.

Thanks in advance

Hello

We’ve been having issues with our prints when the resurrect print feature is used, specifically in the cases were babystepping has been applied previously.

We know the babystepping in itself is only meant as an auxiliary tool but in our case we have found there are two use scenarios were its use is necessary for us:

-When printing with our heated chamber machines as the variations between materials and temperatures often require adjustments in the first layer
-When printing with our one cubic meter machines as they are located in a warehouse and the bed behaviour varies depending on the climate.

It’s been noticed that the machine reapplies the babbystepping at the resurrect.g before launching the print.

As we do not home the Z axis when the resurrect is launched then the posible outcomes are the following:

Assuming that when there is a power outage the Z will remain at the correct height then reapplying a negative stepping will lead to the nozzle going further into the model and reapplying a positive stepping will lead to the nozzle getting further away from the model.

Is there any way to avoid this ?

As the resurrect.g is launched after the resurrect_prologue then we haven´t been able to find a way to clear the babystepping prior to the resuming of the print

Thanks in advance

Trideo3D team.

Thanks for the response.

I have tried similar aproaches.

The thing is that using "if move.axes[0].homed = true" does not work properly if inserted inside de homex.g as it seems the machine actually resets the X homing value when that function is run and before entering into the code, and that results in move.axes[0].homed being equal to false every time or at least this is what I understood from the different tests I've made.

Hello,

I'm running a machine using a Duet wifi 1.4 board + Duet extension 5X with firmware version 3.2.

I've been looking for a way to prevent the user from being able to manually perform a homing sequence once the print has begun or at least create a warning requiring user confirmation ONLY if the printer is already doing something else.

At the moment I have tried to use meta commands to consult the state of the machine prior to entering the home routine but this has not been successful since when executing the homing itself the machine changes state to "busy".

I have also tried to query if the machine has already been referenced in a previous home to avoid doing the same again, but it happens that when executing the homing itself, the state of the same is reset.

I wanted to know if there is any way to achieve this since in our case the machines use a BLTouch as a Z probe and executing a Z homing during a print could result in damage to it.

Thanks in advance.

Hi There,

We are currently running reprap Firmware V3.2, can we speak about this topic as meta command example?
It will be a useful for us! There is a C, C++ programmer in our team who can't wait to start playing with it!!

Best regards,

Simon

@bearer thanks for answering! About BLTouch connector, we wrote to AntClaBs directly but they newer answered, any news I keep you informed!

Thanks @Stephen6309, actually we are trying to reduce printer wire types and use a "standard" 4 wires connection for BLTOUCH should help us a lot. Our technical team want to try a 4 wire connection, shorting one negative wire, so before doing a bad move, I preferred to ask here

Thanks

Simon

Hey There,

Can we connect the BLTouch as shown below? 4 Wires connection?

Thanks!

Simon

Hi there,

My printer already works very well with stall detection enable for sensorless homing.
I wanted to make it "safer" to prevent false homing detection during sensorless homing.
For example, after homing X to Xmin, I want to get X axis to Xmax and during this move, run stall detection to detect any mechanical collision.

• If the printer go to Xmax without any stall detection events, that significates that Xmin detection did well. Nothing to report
• if the printer go over Xmax and get a mechanical clash, use stall detection to stop current move, stop homing procedure and also upcoming print and report it.

Can I do that?

Thanks for your support,

Simon

@dc42 Exactly! I'm referring to it "Filename too long" when connected in access Point Mode. We are currently preparing a "migration" to RRF 3.x but it wont be ready until several weeks.
I would like to give a quick solution to mi clients.
One of them answered me that he doesn't use Kaspersky AV....
Thanks for your support !
Simon