@benecito Duets have always used true USB ports, unlike the old 8-bit boards that Repetier was originally designed to work with. Because of this there is flow control over the communication channel. So there is no maximum buffer size, because when the Duet is unable to receive more data this will be signalled to the PC, which will stop sending data until the Duet can accept more. Depending on how Repetier is written, the task in Repetier that is trying to send more data may block until the data can be sent.
If you use a very large buffer size then the time it takes to respond to a pause or other interruption commanded by Repetier will increase. This is because there is no mechanism in the serial GCode protocol for the pause message to jump commands that have already been sent (unlike when printing from the Duet's SD card).
The USB receive buffer sizes in various builds of RRF are as follows:
@sbNielsen Have you tested both 1XD boards? I can imagine a fault on one board, but not on both. If you don't have an oscilloscope, you could wire an LED on each output (as the signalling is 5V), and see if they light up during the move (you may have to adjust the frequency to do this).
@dc42 Thank you for the heads up. I will continue to post crash logs as I receive them. I suspect mine is related to a hardware issue and static. I was on 3.4.5 and it was crashing with the same type of error.
Initial testing after moving the chamber thermistor is promising. I was able to do 2 successful prints that were 3 hours long.
Is there a way to ground the thermistors on the Duet side in order to protect the board? I'd rather wire something in if it all possible to eliminate that as an issue. the hotend thermistor has a metal enclosure and is grounded by the hotend. The other thermistor is bare with just the two leads going to it. I am not sure if it is acting as an antenna for static when it is near parts interacting with filament or what. I am really just shooting in the dark as this point.
@TheMikke Unfortunately, RRF for the Duet 2 WiFi doesn't have the ability to talk to the TMC2209 drivers via the UART interface, and the Mini 2+ doesn't have an option to set the motor current using a potentiometer.
Driver 0 seems broken. Finally checked the others (why not earlier? - don't know) and they work. Also the scope looks like I would expect it to look with a pulse length of 2.5us:
(48V DC recommended for Nema 34 & 36V DC for Nema 23 )
3 x Nema 34 Closed Loop Motor ( 86HSE8N-BC38 ) each with HSS86 Hybrid Servo Driver
2 x Nema 23 Closed Loop Motor ( 57HSE76-2N-D25) each with 2HSS57 Hybrid Servo Driver
Open Loop Motors:
( 24V DC recommended for Nema 11 & 17 )
As per the support info from this forum, i might not need to use the 9 x External drivers for the 9 x Motors directly connected to 3 x 3HC expansion boards
3 x Nema 17 Open Loop Stepper Motor (Benzhi BD4248 ) each with Benzhi Microstep Driver(DM542 driver clone, i think) for driving the 6 heads/Nozzles along the Z-axis
6 x Nema 11 Open Loop Stepper Motor (Benzhi BT12811 ) each with Benzhi Microstep Driver (DM542 driver clone, i think) for the Nozzles/Heads
1 x Duet 3 6XD Main Board ( All Closed Loop Motors & Drivers will connect to this 6XD board)
3 x Duet 3 3HC Expansion Boards ( All Open loop Motors will directly connect to 3 x 3HC expansion boards therefore avoiding external drivers and using 3HC in-built Drivers)
Several endstops (20+) for the various Axes as required--- Panasonic PM25U & PM25L
@samtrust For a new 6HC? Yes. I think that's the only board that has so far been updated to USB C. All others use USB Micro B. Make sure it's not just a charging cable, though, and that it can carry data too.