Posts made by DuetUser

@dc42 There was no info like "Phase A short to ground" on Panel Due, usually there is.
We've never experienced such problems not related to hardware issues you describe, on 3.5RC firmware.
I know them well because they occur when reconnecting extruder motors to the toolboard and damaging wires / pins.
We roll back to 3.5 RC3 and see what happens.

I don't want to do this because the machines are all sheetmetal and if somebody accidentally connect mains + to mains - on the power supply, while assembling or servicing, it could end up unwell.
So we grounded every printhead, cried over stupidly damaged toolboards and PT1000s, and went on !

Thanks and sorry for replying after weeks

We run 14 (MB6HC) machines on 3.5RC3 firmware, for months, without problems, we do not ever turn them off.
I updated 2 of them to 3.6 RC3.
After hours of idle, I tried to print something and noticed that one of the motors (a co extruder connected to MB6HC driver) vibrates instead of extruding.
I restarted the machine and the problem went away.
The second one was merrily printing until in a random moment a Z motor started to vibrate (like phases being messed up) instead of moving the bed up and down. This was a serious thing, which could easily lead to a disaster.
Again after a restart, everything went back to normal.

Both machines were operating correctly on 3.5RC3 for a long time.

Please correct if I'm wrong, we do not have PSU PE and V- connected, so the toolboard will not be grounded this way.
The toolboard, extruder motor and hotend are mounted to a metal X carriage plate.

To ground the printhead correctly, this metal plate should be connected to global machine PE (machine frame) at common point right ?

The only problem could be PTFE tubing accumulating electrostatic charge, would it be enough to connect it to the carriage, or should it be wrapped with copper shielding ? There are meters of it ...

Thanks, it looks like a good idea to read the docs eventually

We have a long story of failed toolboards.
5 pieces of 1.2A version with different errors like wrong temperature readout, unable to connect or not extruding.
1.3 are much better, but today the second one went bust out of the blue with :
"Error: Expansion board 121 stopped sending status"

I'm not here to complain or rant,
although I hate them with passion due to microscopic connectors and cables in all directions :).
We definitely will be using them forever as they reduce cable mileage.

The question is are there any safety concerns while connecting them, maybe there is a surge from 3m PTFE tubing or something alike. I assume they operate in suboptimal conditions which cause problems.
I just don't know what can be possible errors with mounting/wiring ?

I'd like to revive this subject as can you share some experience?

We are building a large coreXY with 4 XY motors (nema 17 60mm)
I wonder if there are any reasons not to connect two motors to one driver?

The drivers are 4.5A so there is some overhead and the setup will be 48 V. We used nema 23 with one driver on Duet 2 ethernet but only on Z axis so they have much less to do and worked for years without problems, but this time they are on XY and there will be a lot of long fast travels.

@dc42 Thanks a lot David, I should definitely forget it

Is it possible to resolder a MOSFET and a few small warehouses on the board to be able to apply 48 V or should I forget it ?
We have a fair amount of older MB6HC on large machines and 48 V would greatly help with long fast travels.
I'm aware we can order new Duets or expansion boards.

@sebkritikel Thanks, I'm concerned only about the motor characteristics of servos / steppers.
With fast long travels steppers have very little torque and are troublesome.
But on the other hand step dir is not a perfect solution to drive servos also.

There is little info about these subjects so probably we will go all Duet to save time and trouble.

We had leadshine easy servo and DCS303 connected to Duet ethernet a few years ago.
Everything was fine only the prints were wavy distorted by layer shifting or something else and after some trial and error we dropped the project.

Now a new light shines, there are better Duet expansion possibilities and more motor options.
We need very fast travels on a large machines and total immunity to position loss.
There would be two ways, and I'm not certain if the second would work at all:

1. Just plug Duet close loop steppers (23CL) and forget.
   We are stuck with stepper specs but with 48V it could be just enough, on the other hand the setup should be totally hassle free.
2. Try Duet 6XD with one of these: https://www.omc-stepperonline.com/integrated-servo-motor
   and enjoy servo advantages along with a bag of extra troubles.

What are real life differences in two ways?
Do we lose on the servo side due to 5ms min signal length comparing to probably faster stepping rate with 23 CL?

@chrishamm There is and I successfully do it by passing an iterator as "data" to POST request, it feeds the request with chunks of data. Everything is fine but it is a blocking IO. I'm trying to make it async, ond one of the ways is to pass chunks sequentially in subsequent POST requests, only RRF treats each chunk as a separate file.
I have to dig into it more and perhaps make an async iterator and use it with async uploader, which I failed to do as of yet.

This is a working non async upload code:

import requests

class upload_in_chunks(object):
    def __init__(self, filename, chunksize=1 << 13):
        self.filename = filename
        self.chunksize = chunksize
        self.totalsize = os.path.getsize(filename)
        self.readsofar = 0

    def __iter__(self):
        with open(self.filename, 'rb') as file:
            while True:
                data = file.read(self.chunksize)
                if not data:
                    sys.stderr.write("\n")
                    break
                self.readsofar += len(data)
                percent = self.readsofar * 1e2 / self.totalsize
                sys.stderr.write("\r{percent:3.0f}%".format(percent=percent))
                yield data

    def __len__(self):
        return self.totalsize

def sendme():
    requests.get(baseurl+'/rr_connect?password=reprap')
    requests.post(url, data=upload_in_chunks(afile, chunksize=10))

I try to write a simple python software to upload gcode to a machine in async manner.

I have it working synchronously by passing an iterator to request object, but I need async to send lots of files to different machines.

A file is divided into chunks and each chunk is an async task.
The problem is that subsequent chunks gets uploaded in separate POST requests as separate files, overwriting each other, so the uploaded file has last chunks size.

I've set the X-File-Id header but it does not seem to work.

So the question is is it at all possible to send one file in many POST requests to RRF?

@Phaedrux
Always wired.

I cannot reliably upload a g-code file via DWC on a Linux Mint 21 machine. It starts and after proceeding for a while the connection goes down and upload fails. The printers have Duet 6HC boards with 3.4 firmware. Uploading from W10K works normally, only on Mint it fails, I tried Firefox and Brave, same result, no matter what connection settings are in the DWC. Perhaps there are some networking settings I don't know about. Did you have any problems alike?

@deckingman
Ofcourse! Thanks a lot it's so elegant!

@oozebot So it is a loop. What a nice idea.

When 2 motors are connected this way is it possible to drive only one of them (to load filament)
One way would be to create a dummy tool :

M563 P1 D1

and driving it :

T1
G1 E1500 F1000

but it is too much of a hack.

I know there is M302 P0 to allow cold extrusion, but is there a
way to force a certain piece of silicon on the board to feed pulses to connected motor?

Great, happy to hear it!
What do you mean by "loop"? Is it a physical loop of filament? Where is it placed in the printer?
I've just connected the secondary extruder (42mm NEMA 17), set it to 300 mA, and mixed so it extrudes more than tha main extruder.
We'll see how far it goes

@dc42 Thanks a lot! works like a charm!