@norder Great! Thanks!

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?