Ability to change movement/feedrate button increments, please

I work with a 8x8x6 meter concrete printer...... 100mm is not very long to move, and 6000mm/sec is just slow af....

Kulitorum

@Kulitorum here.

I tried to use G2 and G3 but they are not interpolated very nice in current firmware and pausing during a G2 or G3 messes up and the printhead moves in random directions. I talked to dc42 about this, but I guess the current use of G2 and G3 is too low for him to spend time with it.

So I use very short lines of a max of 5 mm. With good jerk and acceleration parameters, that moves smoothly and allows me to pause a print at any time within 25mm, in regards to 4-5 commands being buffered in firmware.

Your slicer should keep an eye on overflow (crossing 360 degrees) and if needed "rewind" the rotation back to 0 to untangle your wires.

Now watching thread, if you need more help. Unfortunatly I can't share my code.

Kulitorum

750w servo motor on the x-axis.

https://www.youtube.com/watch?v=nMCpMZPh6Ds

I hope to print at this speed, but I have set the expected speed at 300mm/sec. We'll see what the concrete pumps can do.

Kulitorum

This is the printer:

@t3p3tony Yes, I did that already, so that you can pause the machine quickly if there's a minor issue. I'm cutting all moves into 5mm sections.

How did you get a Duet to be this noisy?

The design is wasting a lot of space on the XY plane, and not gaining much from it. And you move a lot of weight around for no real reason.

The couplers have to be 100% centered, and I doubt these are, as they are tightened from one side.

At least put the motors "outside" the moving area, so they "stick out" of the frame. This will increase your printable area around 10cm on both axes.

Lots of design issues IMHO

Xa Xb Xc, Ya, Yb, Yc ?
D,H,I,J,K,L,M ?

That worked. Thanks.

Fark.... Powercycling did nothing, it is unreachable

Now what?

Nope

Trying 3.0 now. It pretty fast lost connection to the interface, and now I can't connect to it. How long is this supposed to take? - Looks like it's just gone. How long should I wait before I power cycle it?

When I run M997 S0, it says something like "please wait while firmware is being updated" - Then after a while is says "operation has been canceled" - No explanation.

What to do?

9/6/2020, 7:58:59 PM M122
=== Diagnostics ===
RepRapFirmware for Duet 3 v0.6 version 3.0alpha running on Duet 3 version v0.6
Board ID: 08DGM-9T66A-G63SJ-6J9FJ-3SD6R-KS0ZA
Used output buffers: 2 of 32 (8 max)
=== RTOS ===
Static ram: 67772
Dynamic ram: 156016 of which 0 recycled
Exception stack ram used: 612
Never used ram: 168816
Tasks: NETWORK(ready,456) HEAT(blocked,1208) CanReceiv(suspended,3804) CanSender(suspended,1496) CanClock(blocked,1432) TMC(blocked,592) MAIN(running,3472) IDLE(ready,156)
Owned mutexes:
=== Platform ===
Last reset 00:02:44 ago, cause: reset button
Last software reset time unknown, reason: User, spinning module GCodes, available RAM 168424 bytes (slot 1)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x04429000 BFAR 0x00000000 SP 0xffffffff Task 0x4e49414d
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 25.0MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 42.7, current 43.2, max 44.1
Supply voltage: min 20.0, current 20.1, max 20.2, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.0, current 12.1, max 12.2, under voltage events: 0
Driver 0: standstill, reads 4336, writes 14 timeouts 0, SG min/max 0/0
Driver 1: standstill, reads 4338, writes 14 timeouts 0, SG min/max 0/0
Driver 2: standstill, reads 4339, writes 14 timeouts 0, SG min/max 0/0
Driver 3: standstill, reads 4341, writes 14 timeouts 0, SG min/max 0/0
Driver 4: standstill, reads 4345, writes 11 timeouts 0, SG min/max 0/0
Driver 5: standstill, reads 4347, writes 11 timeouts 0, SG min/max 0/0
Date/time: 1970-01-01 00:00:00
Slowest loop: 1.55ms; fastest: 0.29ms
=== Move ===
Hiccups: 0, FreeDm: 375, MinFreeDm: 375, MaxWait: 0ms
Bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
=== AuxDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Stack records: 1 allocated, 0 in use
Movement lock held by null
http is idle in state(s) 0
telnet is idle in state(s) 0
file is idle in state(s) 0
serial is idle in state(s) 0
aux is idle in state(s) 0
daemon is idle in state(s) 0
queue is idle in state(s) 0
lcd is idle in state(s) 0
spi is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 25.26ms; fastest: 0.03ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8

• Ethernet -
  State: 5
  Socket states: 5 2 2 2 2 0 0 0
  === Linux interface ===
  State: 0, failed transfers: 0
  Last transfer: 164619ms ago
  RX/TX seq numbers: 0/1
  SPI underruns 0, overruns 0
  Number of disconnects: 0
  Buffer RX/TX: 0/0-0
  9/6/2020, 7:56:19 PM M997 S0
  Operation has been cancelled
  9/6/2020, 7:55:36 PM Connected to 192.168.1.229

Thank you, but it completed the previous print without any hiccups, does it make sense that the fuse would blow just as I reset the board?

I have a Duet3 lying around, I will rebuild the machine.

After completing a 67 hour print I reset the duet (with the red STOP button on the display) and after rebooting my temp readings are both 2000c.

Disconnecting the bed termistor cable and shorting the pins makes no difference.

What could posibly explain this?

Thank you - turns out the UM2 does not use Thermocoubles, but a PT100 RTD (Resistance Temperature Detectors) Device, so I did have the correct daughter board, I just had to short the solder pins (red circles) and my config (that works) is:

; Heaters
M308 S0 P"spi.cs0" Y"rtd-max31865" ; configure sensor 0 as thermocouple via CS pin spi.cs0
M950 H0 C"out0" T0 ; create bed heater output on out0 and map it to sensor 0
M143 H0 S120 ; set temperature limit for heater 0 to 120C
M307 H0 B1 S1.00 ; enable bang-bang mode for the bed heater and set PWM limit
M140 H0 ; map heated bed to heater 0
M308 S1 P"spi.cs1" Y"rtd-max31865" ; configure sensor 1 as thermocouple via CS pin spi.cs1
M950 H1 C"out1" T1 ; create nozzle heater output on out1 and map it to sensor 1
M143 H1 S280 ; set temperature limit for heater 1 to 280C
M307 H1 B0 S1.00 ; disable bang-bang mode for heater and set PWM limit

I can't find anything in any documentation - Where do I install it, and in what orientation?

Tried this - it seemed logical, is this correct?

I'm connecting it to a Ultimaker K-Type thermocoupler - is my configuration correct?

; Heaters
M308 S0 P"spi.cs0" Y"thermocouple-max31855" ; configure sensor 0 as thermocouple via CS pin spi.cs0
M950 H0 C"out0" T0 ; create bed heater output on out0 and map it to sensor 0
M143 H0 S120 ; set temperature limit for heater 0 to 120C
M307 H0 B1 S1.00 ; enable bang-bang mode for the bed heater and set PWM limit
M140 H0 ; map heated bed to heater 0
M308 S1 P"spi.cs1" Y"thermocouple-max31855" ; configure sensor 1 as thermocouple via CS pin spi.cs1
M950 H1 C"out1" T1 ; create nozzle heater output on out1 and map it to sensor 1
M143 H1 S280 ; set temperature limit for heater 1 to 280C
M307 H1 B0 S1.00 ; disable bang-bang mode for heater and set PWM limit

Thank you.

I guess we will at most move 9 axies at the same time - XYZEU, 'X'Y'E'U for a two head move - in 1-2 years maybe 18 (with 4 heads)

We have a vertex for every 10mm in the XY plane, and run at 500mm/sec (working towards 1000mm/sec, give it a year)

Kulitorum

So I suppose the lowercase - 'A 'B 'C etc. solution would be the prefered then? - That would release 26 extra axies.

how many axies do we have CPU power to drive?

Kulitorum