chas2706

undefined

Hi Folks.

Just thought you may be interested in my setup.
I have Duet3 with SBC but I followed the instructions to install DSF on Rasbian so I could use the extra features and programs.

I installed Slic3r and Slicer Prusa Edition on the SBC and am very happy to find that they both work great.
Here's some photos:

Slic3r Prusa Edition.jpg

The stl's slice and produce the gcode as expected and they print just fine.

I also have the option to connect a Bluetooth mouse and have an on-board keyboard.

undefined

I have 3 printers, all of them (until recently) running on duet boards and all until recently producing unacceptable quality prints.
One of the printers is a VCore Pro that cost me £1200 without the electronics. Another is a Tronxy X5S that has had many
hardware upgrades and a considerable amount of money spent on it.

Both of these printers run on Duet3 boards in SBC mode and are both on the current "stable" firmware.
TBH both printers are far from producing "stable" prints and like others recently on this forum, I am now tired of trying to
find solutions. In my opinion the SBC integration is just a novelty that highlights and adds to all current issues with the
firmware. With SBC attached you get the added bonus of intermittent disconnections of DWC or DCS or your print stops in mid flight without explanation.

Putting these issues aside, I am still left with disappointing print quality. It seems to me that ringing, round corners and
general poor quality is inherent. I feel I have tried everything to reduce the ringing and other faults but no setting makes
any difference for me whatsoever.

The Tronxy X5S used to produce acceptable prints until I "upgraded" it with a Duet3 with SBC!
It puts me straight off these days when I fire up any of the two SBC connected printers and be greeted with the well known
phrase "could not connect to DCS".

I am not seeking answers here because been there done that, tried this, tried that, sick of it!

My 3rd printer which is a mere £250 Ender3 pro dropped in print quality from the day that I "upgraded" the electronics to a Duet 2 ethernet about 18 months ago, but initially I put it down to tweaking of the settings etc but never got the quality prints I would expect.

I have now found a simple and cheap solution for the Ender3 Pro. The machine is both silent in motion and the print quality
is second to none.
The answer is to rip out the Duet board and replace it with a Creality 4.2.7 32bit silent board for the mere cost of £32!

I know some people on this forum may not be happy with my personal findings and don't want to hear any of it but what really
annoys me is that last year I was all excited about setting up my new 500x500x500 VCore Pro it being of good build quality
with its quality linear rails, high quality belts, bearings etc but 12 months on I am no further to producing anything like good
quality prints on it and there must be hundreds of forum users that have been told to "check your hardware" before blaming the firmware when questioning bad print quality.

Now, my cheap Ender3 Pro is the big winner, the downside being having a mere 230x230 print surface.
You simply upload a print to the sd card, press print and then just wait for your high quality print to finish. Works every time!
No more abandoning of prints because the Z height has somehow changed from last time or the SBC communication failed etc, etc.

undefined

I have a large heavy printbed that had the same problems with dropping unlevel at power off.
Here's how I overcome it:

I grabbed a stepper brake design from thingyverse and modified it for use with a solenoid.
Here is the final result:

Z Brake.jpg

I have these on all 3 Z steppers and they are controlled by a cheap arduino nano.
The nano is used as an interface to be able to control the braking exactly how I want.
It looks for a brake control signal that I set up on the Duet 3 board.

By default the brakes are on. When the printer is powered up one of the first commands in config.g is to enable the Z motors. This locks their positions and therefore is now safe to release the brakes without causing any Z movement.
The only downside is that for complete control I have to use my own board reset, e-stop and shutdown macros but this is not a real problem for me.

Visually, I no longer see any Z drop but to be safe after every power up I do one quick bed level
which before the upgrade would have not been enough to level the bed accurately.
Now, I see no bed drop and the bed is guaranteed level within seconds of power up.

Here is what is required:

In config.g:

; Z brake control
M17 Z ; enable Z motors to hold bed position before brake is released

; set up servo brake signal on out5
M950 P5 C"io5.out"
M42 P5 S255 ; brake off

My Macros:

E-Stop:
M42 P5 S0 ; brake on
G4 P500 ; wait 500 milli seconds
M112

Reset:
M42 P5 S0 ; brake on
G4 P500 ; wait 500 milli seconds
M999

shutdown:
; macro to shutdown printer after hot end has cooled down
; carry out some checks first

G10 S0 R0 ; Set active and standby temps to zero to ensure nothing is on standby
M140 S0 ; heated bed heater off

; only shutdown if extruder temperature is below 70

    while true
       if sensors.analog[1].lastReading > 70            ; if hot end temperature is 70 or above then cool down
        M291 P{"Hot end temperature too high, cooling in progress!" } R"Power Management" S1 T0
        ;break                                          ; if not true, go to next command
    
       if sensors.analog[1].lastReading < 68 
        M291 P{"Hot end temperature < 68, shutting down now" } R"Power Management" S0 T4
         M42 P5 S0   ; apply Z brakes
          G4 S2		; wait 2 seconds
           M81                                              ; atx power off

Arduino code:
#include <Servo.h>

//Define duet output pin
#define inPin 12

#define PUSHED HIGH // look for active high

byte lastState;
unsigned long startMillis; // time variable
Servo servo1;
Servo servo2;
Servo servo3;

void setup()
{
servo1.attach(3); // servo 1
servo2.attach(4); // servo 2
servo3.attach(5); // servo 3
pinMode(inPin, INPUT_PULLUP);
//keep brake on at power up (brake arm is at 90 degrees when in off position!)
servo1.write(0); // brake on
servo2.write(0);
servo3.write(0);
delay(10000); // delay for duet initialisation
servo1.write(100); // brake off
servo2.write(100);
servo3.write(100);
delay(10000);

}
// duet in control from here onwards
void loop()
{
byte thisState = digitalRead(inPin);

//look for changed state?
if (lastState != thisState)
{
//update to the new state
lastState = thisState;
//record time
startMillis = millis();
}
//check for changed state
// if (lastState == PUSHED) {

// inPin state must have changed for >= 2 seconds to eliminate false triggers
if (lastState == PUSHED && millis() - startMillis >= 2000UL)
{
servo1.write(100); // brake off if input high
servo2.write(100);
servo3.write(100);
delay(1000);
}
else
{
servo1.write(0); // brake on if input low
servo2.write(0);
servo3.write(0);
delay(1000);
}

}

undefined

Question... How do you expect to get help after you abuse everyone and everything?

undefined

Your attitude stinks, you don't deserve any help. I don't care what you think of me. I don't care about your "business". I just hope you treat your "customers" with respect. I'm done with this thread>

undefined

Initially I purchased a clone duet wifi for £100. I suffered with it for nearly 12 months, putting up with real bad connection issues and random sd card reader failures.

I then went on to purchase a genuine Duet Ethernet and had no issues whatsoever.
The professional quality, warranty and after sales service that comes with the genuine boards has now inspired me to purchase a Duet 3.

I am unwrapping it tomorrow as an xmas present from my wife!

undefined

@dc42 Is there a time frame when the DSF will be updated so us Duet3 + SBC users can take advantage?

undefined

Paul, your homez.g should look something like this:
; homez.g
; called to home the Z axis
;
; generated by RepRapFirmware Configuration Tool v2 on Sat Nov 10 2018 14:56:37 GMT+0000 (GMT Standard Time)
; Use the probe offset

G91 ; relative positioning
G1 S2 Z5 F100 ; lift Z relative to current position
G90 ; back to absolute positioning
G1 X160 Y160 F4000 ; Go to centre of bed

; Probe
M558 A1 F350 ; Set single probing at faster feed rate
G30 ; Do a single probe to home our Z axis
M558 A10 F100 ; Set triple probing at slower feed rate
G30 ; Probe again to get a more accurate position and set Z to trigger height

The G30 command above is using the probe to home Z. You need to adjust your homeall.g as well by replacing the section where Z is homed with the above gcode.

undefined

@frank26080115 Im using a raspberry pi running motioneyeos which boots up as a standalone camera surveillance operating system. You can view live streams, record video ,time lapse etc. The beauty with this one is that there is no operating system running in the background.

undefined

I think you need to calm down and look up the term "candidate release". You were not forced to upload it. It is there for testing by us if we choose. Let me know if you selling your duet board on the cheap!
P.S. Have you forgotten your anger management pills?

undefined

I have a large heavy printbed that had the same problems with dropping unlevel at power off.
Here's how I overcome it:

I grabbed a stepper brake design from thingyverse and modified it for use with a solenoid.
Here is the final result:

Z Brake.jpg

I have these on all 3 Z steppers and they are controlled by a cheap arduino nano.
The nano is used as an interface to be able to control the braking exactly how I want.
It looks for a brake control signal that I set up on the Duet 3 board.

By default the brakes are on. When the printer is powered up one of the first commands in config.g is to enable the Z motors. This locks their positions and therefore is now safe to release the brakes without causing any Z movement.
The only downside is that for complete control I have to use my own board reset, e-stop and shutdown macros but this is not a real problem for me.

Visually, I no longer see any Z drop but to be safe after every power up I do one quick bed level
which before the upgrade would have not been enough to level the bed accurately.
Now, I see no bed drop and the bed is guaranteed level within seconds of power up.

Here is what is required:

In config.g:

; Z brake control
M17 Z ; enable Z motors to hold bed position before brake is released

; set up servo brake signal on out5
M950 P5 C"io5.out"
M42 P5 S255 ; brake off

My Macros:

E-Stop:
M42 P5 S0 ; brake on
G4 P500 ; wait 500 milli seconds
M112

Reset:
M42 P5 S0 ; brake on
G4 P500 ; wait 500 milli seconds
M999

shutdown:
; macro to shutdown printer after hot end has cooled down
; carry out some checks first

G10 S0 R0 ; Set active and standby temps to zero to ensure nothing is on standby
M140 S0 ; heated bed heater off

; only shutdown if extruder temperature is below 70

    while true
       if sensors.analog[1].lastReading > 70            ; if hot end temperature is 70 or above then cool down
        M291 P{"Hot end temperature too high, cooling in progress!" } R"Power Management" S1 T0
        ;break                                          ; if not true, go to next command
    
       if sensors.analog[1].lastReading < 68 
        M291 P{"Hot end temperature < 68, shutting down now" } R"Power Management" S0 T4
         M42 P5 S0   ; apply Z brakes
          G4 S2		; wait 2 seconds
           M81                                              ; atx power off

Arduino code:
#include <Servo.h>

//Define duet output pin
#define inPin 12

#define PUSHED HIGH // look for active high

byte lastState;
unsigned long startMillis; // time variable
Servo servo1;
Servo servo2;
Servo servo3;

void setup()
{
servo1.attach(3); // servo 1
servo2.attach(4); // servo 2
servo3.attach(5); // servo 3
pinMode(inPin, INPUT_PULLUP);
//keep brake on at power up (brake arm is at 90 degrees when in off position!)
servo1.write(0); // brake on
servo2.write(0);
servo3.write(0);
delay(10000); // delay for duet initialisation
servo1.write(100); // brake off
servo2.write(100);
servo3.write(100);
delay(10000);

}
// duet in control from here onwards
void loop()
{
byte thisState = digitalRead(inPin);

//look for changed state?
if (lastState != thisState)
{
//update to the new state
lastState = thisState;
//record time
startMillis = millis();
}
//check for changed state
// if (lastState == PUSHED) {

// inPin state must have changed for >= 2 seconds to eliminate false triggers
if (lastState == PUSHED && millis() - startMillis >= 2000UL)
{
servo1.write(100); // brake off if input high
servo2.write(100);
servo3.write(100);
delay(1000);
}
else
{
servo1.write(0); // brake on if input low
servo2.write(0);
servo3.write(0);
delay(1000);
}

}

undefined

@droftarts said in Daft Question?:

@chas2706 I've updated https://duet3d.dozuki.com/Wiki/SD_Card#Section_Creating_the_file_structure and https://duet3d.dozuki.com/Wiki/Firmware_Overview#Section_SD_card_structure.
Also, the Configuration Tool has been updated and does now create a /firmware folder if you select '3.3 or later' as your firmware version on the 'General' page. Otherwise firmware files are put in /sys. But note that you don't need the firmware files on the SD card to run (the firmware is already flashed to the Duet processor), only to update.
Ian

Thanks for looking into this and updating.
I was changing form SBC mode to Standalone and came across these.

undefined

Why isn't there a "Downloads" section on the main web site that gives you the option to download the latest "stable" or "unstable" versions of the firmware for the individual Duet boards and configurations rather than all of them exposed in one location for you to work out the ones that you need?.
Currently, you have to spend loads of time researching to identify the files that you require for your particular board or configuration.
Also, the newer releases require that the firmware files be placed in a folder called " firmware" , but if you use the RRF Configurator it does not create that folder? It didn't for me anyway!
So if I upgrade to RRF 3.3x, it will fail!

Phaedrux MODERATOR 21 Aug 2021, 07:14
@gbusy24 said in Updating from 3.0 to 3.3 gone wrong:

Error: M997: File 0:/firmware/DuetWiFiServer.bin not found

Place it in the firmware folder on the SD card as that is where it's going to be looking in 3.3.

To me it just looks a mess and I am posting this because I am having difficulties changing from SBC mode to Standalone Mode.
Also, why isn't the sd card structure updated in the "Documentation" section to reflect this change?
Sorry to sound so negative but see my previous posts concerning RRF+SBC.

undefined

Sorry to hijack this thread but would just like to get something off my chest.
Ive had problems with both my corexy printers regarding Z height and first layer issues since upgrading from RRF3.1.1. Both printers have SBC. They both now running on RRF3.2.2 and neither are capable of printing anything from scratch without my intervention. Each time I have to adjust babystepping to get the first layer height correct.
Example: In config.g one printer has Z offset G31 X-30 Y-5 Z2.72 which was found by doing correct process to find Z height. On attempting to print, Z is too high. If I lower Z by 0.28 using on the fly babystepping the first layer is spot on. Before next print I change G31 in config.g to G31 X-30 Y-5 Z3.0 so as to equal the difference with babystep. On next print Z is too low and babystepping back up by 0.28 corrects this!!!!
Just in case I'm doing something wrong I then change config to G31 X-30 Y-5 Z2.44 (minus 0.28). This time the print too low by 0.28!!!
Both printers have similar issue and neither printer has any other G31 command in any other piece of gcode or macro.
I have only one functional printer which is old faithful ender 3 pro which in my opinion prints every time because there's no Z probe present, everything is set up manually, no SBC attached and therefore much simpler.
Ever since RRF3 firmware versions have been available I've had issues and still have issues with SBC not always connecting to DCS, when booted up, sometimes config.g not been processed so DWC shows no extruders, no heaters, no fans etc...
It was months and months ago that i first reported an issue that any gcode command that I enter into the console in DWC has to be clicked on twice before DWC responds, I find that this issue is STILL present and has now even expanded to include the emergency stop icon on DWC. So at one point my head crashed into the bed because the emergency stop does not always work first time!!!
Lastly, I fail to understand how on both printers with SBC attached i often encounter "network failed, no network connection" showing on SBC's DWC but im somehow happily connected to DWC via laptop!!
I spent £1500 on my last printer but the best and most reliable prints come from my simple £250 Ender 3.
R

undefined