RRF 3.4 input shaping preview available

MikeS

@jenpet Right now these are my settings, but not sure if they are good. I'm just trying atm:

M566 X1500 Y1500 Z60 E8000          ; Set maximum instantaneous speed changes (mm/min)
M203 X20000 Y20000 Z6000 E15000 	; Set maximum speeds (mm/min)
M201 X20000 Y20000 Z3000 E1800      ; Set maximum accelerations (mm/s^2)    
M204 P7000 T7000 					; Set printing acceleration and travel accelerations

Be sure that your M201 has higher values that the one in M204. This was the issue for me

JenPet

@mikes I am using lower values, I would try it
M566 X300.00 Y300.00 Z24.00 E300.00 P1 ; set maximum instantaneous speed changes (mm/min)

skrotz

@dc42 I think the breakdown so far for 7-28 3.4 build is:

With No PA and no input shaping, things look normal. No extrusion blobs or zits. Corners bulge a bit due to no PA as one would expect. (Just did this print). Things look identical to RRF 3.3.

With no PA, but EI3 input shaping enabled, I get no clunking or hiccups/errors, but I do get some small occasional extrusion zits/blobs, in the same place each print. Corners bulge a bit more than the print with no PA and no input shaping - probably an artifact from the ei3 input shaping?

With PA at 0.12 and no input shaping, I am getting the clunking noise, usually when printing the gyroid infill. I do not get this clunking with 3.3, it is abnormal. The print has extrusion issues.. lines where the head is moving to print the X or the Y of the cube seem to be over extruded at times, some maybe under extruded. Parts of the X look a bit jagged. (just did this print). M122 reports 2679 hiccups but no errors for MainDDARing move stats.

I assume with PA and EI3 input shaping, I'll get clunking plus the layer shift others are reporting, but I haven't done that print yet on 7-28 3.4.

dc42

@skrotz thanks for the feedback. I have found a bug that may explain the issue when PA is enabled, and I expect to make a new binary available tomorrow.

nuroo

Sry to butt in, but this is the most active accelerometer thread.
Have the LIS3DH installed on my printhead. I'm not sure if I chose the correct orientation for the sensor in relation to my actually printer xyz axis. Hoping for an auto setup feature in firmware which deterimes orientation of sensor and configures itself.

20210606_181844 (1).jpg

MikeS

@nuroo I don't know which orientation your chip is on the board but if your drawing is correct for sure the first number of I parameter should be 0 (top of the chip facing +X axis). Probably your second number should be 5 (-Y) or 1 (+y), it depends on how the chip is placed on the board.

dc42

@nuroo identify which of the images at https://www.dropbox.com/s/hu2w5mk57l4zqpg/Accelerometer Orientation.pdf matches your setup.

MikeS

So today i tried my first real print with the new beta and also i'm hearing the extruder doing something weird with PA on. It's more noticeable during sharp corners (for example in the transition from 1 perimeters to the next one).
Actually i'm using this:

M572 D0 S0.03

Video of the print where you can hear the "clicks" will be soon available there:
https://youtu.be/7EV2qz565SQ

nuroo

@MikeS @dc42

Thanks for trying to help. I did see the orientation.pdf but I was unable to determine which orientation I should choose based on the picutures because I have the adafruit sensor. When I initially set up the sensor I chose I50, but I'm unsure if it correct.

M955 P0 C"spi.cs6+spi.cs5" I50 Q2000000 ;LIS3DH Adafruit2809

The main point I failed to make with my past post was I wish the firmware determined the correct orientation. Couldnt the printer do a series of moves and see how user has sensor mounted??
I mean the printer knows what are the correct X and Y axis. If printer issues an X+ move but sensor registers a Z- for example. Then another movement to determine 1 other axis. 2 axis known. Third movement unnesscary because if 2 axis known, third is whats left???

I imagine lots of troubleshooting ahead if users are picking the wrong orientation. Then try to tune the wrong axis to fix ringing <<--like this guy

MikeS

@nuroo thanks for the photo! From these i can see that your accelerometer Z axis is facing -X (4) and X axis is facing -Y (5) so your correct I parameter should be 45.

For the auto detection i think it wouldn't be a problem but also finding it manually is not so complicated once you understand how it works. Also this need to be done only one time if you don't plan to move the accelerometer.

I'm planning on also removing the accelerometer once the readings are done and installing it only if i retighten the belts.

nuroo

@mikes thank u, Sir.

I would never have chosen that orientation even after viewing the pdf. It confuses me, I wont be the only one I think.

skrotz

@dc42 any new firmwares to test!? I’m able to do testing more easily on the weekends…

dc42

@skrotz yes I have a new one, I just haven't found time to do an actual print with it yet. I found and fixed a bug with pressure advance.

I've just put it at https://www.dropbox.com/sh/ja08b7qdzsl8kjc/AAAwUbkN2XJvurq5CuQTgx5Wa?dl=0 for you to try. This version does not support DAA, just the other input shaping types.

Also fixes in this one is simulation mode, which was broken.

Marco Bona

@dc42, should these versions also work with SBC connected? I tried to upgrade to 3.4 but when I start printing after the print temperature is reached the SBC disconnects and the printout is canceled.I upgraded with unstable branch to 3.4, in version 3.3 it works fine. I'll attach the report after I restart the machine.

m122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.4.0beta1 (2021-07-10 16:20:28) running on Duet 3 MB6HC v0.6 or 1.0 (SBC mode)
Board ID: 08DJM-956L2-G43S4-6JKF0-3S86T-9A5YD
Used output buffers: 1 of 40 (21 max)
=== RTOS ===
Static ram: 150904
Dynamic ram: 63484 of which 0 recycled
Never used RAM 139804, free system stack 200 words
Tasks: SBC(resourceWait:,2.3%,332) HEAT(delaying,0.0%,325) Move(notifyWait,0.0%,352) CanReceiv(notifyWait,0.0%,799) CanSender(notifyWait,0.0%,374) CanClock(delaying,0.0%,351) TMC(notifyWait,7.3%,93) MAIN(running,89.6%,922) IDLE(ready,0.7%,29), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:00:45 ago, cause: power up
Last software reset at 2021-07-31 18:14, reason: User, GCodes spinning, available RAM 136244, slot 1
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0044a000 BFAR 0x00000000 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
Step timer max interval 144
MCU temperature: min 31.1, current 35.1, max 35.2
Supply voltage: min 24.1, current 24.1, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.0, current 12.1, max 12.1, under voltage events: 0
Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0
Driver 0: position 0, standstill, reads 61046, writes 15 timeouts 0, SG min/max 0/0
Driver 1: position 0, standstill, reads 61046, writes 15 timeouts 0, SG min/max 0/0
Driver 2: position 0, standstill, reads 61046, writes 15 timeouts 0, SG min/max 0/0
Driver 3: position 0, standstill, reads 61047, writes 14 timeouts 0, SG min/max 0/0
Driver 4: position 0, standstill, reads 61048, writes 14 timeouts 0, SG min/max 0/0
Driver 5: position 0, standstill, reads 61048, writes 14 timeouts 0, SG min/max 0/0
Date/time: 2021-07-31 18:16:34
Slowest loop: 1.58ms; fastest: 0.05ms
=== Storage ===
Free file entries: 10
SD card 0 not detected, interface speed: 37.5MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 125, maxWait 0ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters = 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = 3 -1 -1 -1
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP* is doing "M122" in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger* is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== CAN ===
Messages queued 348, received 316, lost 0, longest wait 1ms for reply type 6042, peak Tx sync delay 179, free buffers 49 (min 48), ts 230/229/0
Tx timeouts 0,0,0,0,0,0
=== SBC interface ===
State: 4, failed transfers: 1, checksum errors: 0
Last transfer: 2ms ago
RX/TX seq numbers: 1585/1585
SPI underruns 0, overruns 0
Disconnects: 0, timeouts: 0, IAP RAM available 0x2c778
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v3.4-b1
Code buffer space: 4096
Configured SPI speed: 8000000Hz
Full transfers per second: 60.95, max wait times: 35.8ms/0.0ms
Codes per second: 4.45
Maximum length of RX/TX data transfers: 3481/980

dc42

@marco-bona I think you will need a new DSF to run with SBC.

Marco Bona

@dc42, DSF has also been updated to 3.4.

dc42

@marco-bona said in RRF 3.4 input shaping preview available:

@dc42, DSF has also been updated to 3.4.

There is a further update needed to go with this RRF build, not released yet.

JenPet

@dc42 The extrusion issue with PA is still there. A single wall line starts at my testprint at 0.45 and the line ends at 0.30 thickness.

dc42

@jenpet said in RRF 3.4 input shaping preview available:

@dc42 The extrusion issue with PA is still there. A single wall line starts at my testprint at 0.45 and the line ends at 0.30 thickness.

Is that with or without input shaping applied?

JenPet

@dc42 With Input Shaping mode zvdd @ 55Hz