Posts made by ajdtreyd

@gloomyandy

I've been trying out your script and I think it's working well but I have a couple of questions/comments.

When viewing the resulting .csv file in the Accelerometer plugin the sampling rate (from the last line of the csv file) is auto-set to 28. This is too low and the "Analyze" button does not activate (the minimum appears to be 400). I assume I should change this to 1320 (from "var datarate=1320" in the script) but I have to wonder why the M956 command is writing "Rate 28" to the end of the csv.

In order to make use of the "var axis" variable, lines 41 and 42 should be changed from:

echo >>"/gcodes/vtest.gcode" "G1 X" ^ var.nX ^ " F" ^ var.max_v*60
echo >>"/gcodes/vtest.gcode" "G1 X" ^ -var.nX

to:

echo >>"/gcodes/vtest.gcode" "G1 " ^ var.axis ^ var.nX ^ " F" ^ var.max_v*60
echo >>"/gcodes/vtest.gcode" "G1 " ^ var.axis ^ -var.nX

Thanks for the good work! This is really cool. I especially like that it's collecting so many data points and from both positive and negative directions of movement.

Also, so far sampling with Accelerometer plugin, Input Shaper plugin and your script all agree showing peaks @53 (+/-2) for X&Y on my delta.

@gixxerfast
From the photos it looks like either the commands failed or there were other settings preventing the modes from working.

Watch the console/display for any errors. It looks like those commands are fine but I've had errors returned for copy/pasted commands that include quotation marks. Alternatively, you can verify the IS mode is being set correctly by running "M593" in the console during each 5mm part of the print.

I don't know what your other settings are so I'll state the following:
For testing the IS modes you should first be sure pressure advance has been disabled, set your accelerations (M201,M204) to 10000 for X&Y and jerk (M566) to 300 for X&Y. The print speed should be between 50-80mm/s (too slow and ringing artifacts are too close together, but too fast and they start getting smeared out and less pronounced).

Hopefully this is helpful

@fred-y said in InputShaping-Plugin-0.2.0-pre7 released:

A suggestion would be to add a Z position, this is mainly an issue with Delta as the recording will fail if we don’t move down the effector after having homed the printer.

+1 for this

Also, to take this a bit further, it would be nice to be able to specify test moves by XYZ coordinates. On deltas (mine, at least) the resonances vary a lot based on effector position and direction of travel. Currently I do this using the Accelerometer plugin, but that has no way to overlay FFT graphs of multiple recordings and it takes a long time to do comparisons.

Hehehe ... sounds like I'm complaining, but this tuning process is soooo much better than it was in 3.3!

@gixxerfast

Ah, sorry, I didn't notice the recommended frequency. It's clearly wrong. I have seen others reporting this same issue.
Anyway, your X graph looks relatively smooth (max g = 0.0012) so I'd focus on that peak at 60.5 for Y. I'd add a config at 59, 60 and 61Hz for each mode to both Y and X and see how those look.

@gixxerfast

The way I have been using it is the same as you have shown, but once you have the recommendations you can select any/all and then click the "add configuration to session" button which is below the table of recommended configurations. This will add those to the Configure section. Then go to Record section and record actual results from the recommended configurations. You can then view those results in the Analysis section and choose the one that gives the best smoothing.

In Analysis and Recommendations sections you can sort the tables by clicking any of the column titles along the top to make it easier to choose the best candidates, but I've found it's best to just add them all for recording and then choose the smoothest curve(s) from the Analysis section to test on an actual print.

The plug-in seems to use the max acceleration, jerk and speed that is already configured (from conf.g or from the console). When I change these on the console between recordings it does seem to effect the results.

I wish there was much more documentation on input shaping both on duet's and klipper's wikis. Specifically on how max accel and jerk effect each IS mode. If/when there are conditions when IS won't be applied, and what accels/jerk are used in those cases.

I have used the printing simulation utility to test how different IS modes effect print times. zvd and mzv are the fastest at 80mm/s (at least at the frequency I'm configuring), but at 160mm/s they're much closer in overall print speed for my calibration cube model.

I have in the past had wifi issues like you describe after doing an update or reverting to an older release. I think sometimes the wifi firmware gets messed up. Try reflashing it by running

M997 S3

from the console and when that completes, switch the power off and on again.
It might take flashing a couple of times but this should work.

Found a bug!

I used -75 and 75 as my start positions for the initial config of my sessions. After doing record and running recommendations, I selected a couple of algorithms and added them to the session. All good. But when I went back to the CONFIGURE tab the start positions had reverted to the defaults of -115 and 41.
I figured this was just a GUI issue and ran the recordings, but the newly added algos used the default start positions.

Another "nice to have" (but not a bug) is to reset the Input Shaping mode to it's original state when 1) the recording phase has finished AND 2) when the recommendations have completed. Currently M593 mode is left with whatever setting was last used by the plugin.
I have this in my bed.g so probing uses very low accel/jerk and then the original values are reset:

; -- set accel/jerk vars to current values
var x_accel=move.axes[0].acceleration  ;set variable to current acceleration
var x_jerk=move.axes[0].jerk  ;set variable to current jerk
var y_accel=move.axes[1].acceleration  ;set variable to current acceleration
var y_jerk=move.axes[1].jerk  ;set variable to current jerk
var z_accel=move.axes[2].acceleration  ;set variable to current acceleration
var z_jerk=move.axes[2].jerk  ;set variable to current jerk
. . .
M201 X{var.x_accel} Y{var.y_accel} Z{var.z_accel} ;restore orig accel
M566 X{var.x_jerk} Y{var.y_jerk} Z{var.z_jerk} ;restore orig jerk

Overall the plugin is working really nicely!
Thanks!

Should it be possible to add more than one axis to a single session?
I have tried adding tests for X and Y axis to a single session and then when recording, all tests are run, but only along the axis which was selected for the last configured test.

thanks!

@dc42
All connections between the accelerometer and duet were mapped correctly when I checked this morning. However, after re-seating at both ends everything is working as expected. Perhaps one of the wires is intermittently breaking. I used a solid core Cat6 cable and should probably remake with silicon jacketed, braided wire given all the movement.

I assumed that the issue was software because I had tested the accelerometer just before the update and the failure occurred just after. A good example of "correlation doesn't equal causation"!

Thanks for the help and pointing out the obvious thing I should have checked!

I get a system reset now every time I run M956.
This was working fine on 3.3 using same macro and entering commands from console.
The command from the macro is

G1 X50 Y0 G4 S2 G1 X-50 Y0 F15000 M400 M956 P0 S1000 A0 F"{var.runTime}_PAR-Xneg"

But I have tried the following from the console with the same result

M956 P0 S1000 A0 F"test-123"
M956 P0 S1000 A0
M956 P0 S10 A0

The following M122 was taken while running a macro just before crash:

=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.4.0beta6 (2021-11-06 11:37:41) running on Duet WiFi 1.02 or later
Board ID: 08DGM-917NK-F23T0-6JKF0-3SD6S-TGBJD
Used output buffers: 3 of 24 (24 max)
=== RTOS ===
Static ram: 23772
Dynamic ram: 77400 of which 0 recycled
Never used RAM 7908, free system stack 122 words
Tasks: ACCEL(notifyWait,0.0%,350) NETWORK(ready,14.6%,228) HEAT(notifyWait,0.0%,326) Move(notifyWait,0.0%,305) MAIN(running,85.4%,442) IDLE(ready,0.0%,30), total 100.0%
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 00:05:29 ago, cause: software
Last software reset at 2021-11-06 15:43, reason: HeatTaskStuck, GCodes spinning, available RAM 8116, slot 2
Software reset code 0x4143 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f80f BFAR 0xe000ed38 SP 0x2001899c Task ACCE Freestk 350 ok
Stack: 00434589 0045639a 21000000 00000001 200182d8 00000006 00000028 a5a5a5a5 a5a5a5a5 20004c08 00455eeb 40000000 200182d8 00000007 000003e8 00000007 00456163 200182d8 10000007 00000007 0000000a 2000118c 004559f1 a5a5a5a5 a5a5a5a5 a5a5a5a5 a5a5a5a5
Error status: 0x04
Aux0 errors 0,0,0
Step timer max interval 0
MCU temperature: min 31.5, current 32.3, max 32.7
Supply voltage: min 12.3, current 12.4, max 12.5, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/1, heap memory allocated/used/recyclable 2048/46/36, gc cycles 0
Driver 0: pos 51839, standstill, SG min 0
Driver 1: pos 61904, standstill, SG min 0
Driver 2: pos 57130, standstill, SG min 0
Driver 3: pos 0, standstill, SG min n/a
Driver 4: pos 0, standstill, SG min n/a
Driver 5: pos 0
Driver 6: pos 0
Driver 7: pos 0
Driver 8: pos 0
Driver 9: pos 0
Driver 10: pos 0
Driver 11: pos 0
Date/time: 2021-11-06 15:49:25
Cache data hit count 4294967295
Slowest loop: 7.90ms; fastest: 0.15ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 0.8ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 83, segments created 6, maxWait 143612ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 15, completed 15, hiccups 48, stepErrors 0, LaErrors 0, Underruns [0, 0, 1], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters 0 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP is doing "G4 S2 " in state(s) 0 0, running macro
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
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty
=== Network ===
Slowest loop: 200.00ms; fastest: 0.08ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions
HTTP sessions: 1 of 8
- WiFi -
Network state is active
WiFi module is connected to access point 
Failed messages: pending 0, notready 0, noresp 1
WiFi firmware version 1.26
WiFi MAC address b4:e6:2d:52:f5:b7
WiFi Vcc 3.36, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 25040
WiFi IP address 192.168.0.22
WiFi signal strength -41dBm, mode 802.11n, reconnections 0, sleep mode modem
Clock register 00002002
Socket states: 0 0 0 0 0 0 0 0

This one was from after the resulting reset:

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.4.0beta6 (2021-11-06 11:37:41) running on Duet WiFi 1.02 or later
Board ID: 08DGM-917NK-F23T0-6JKF0-3SD6S-TGBJD
Used output buffers: 3 of 24 (20 max)
=== RTOS ===
Static ram: 23772
Dynamic ram: 75252 of which 0 recycled
Never used RAM 10200, free system stack 184 words
Tasks: NETWORK(ready,13.7%,228) HEAT(notifyWait,0.0%,326) Move(notifyWait,0.0%,364) MAIN(running,85.0%,440) IDLE(ready,1.2%,30), total 100.0%
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 00:01:16 ago, cause: software
Last software reset at 2021-11-06 15:49, reason: HeatTaskStuck, GCodes spinning, available RAM 7908, slot 0
Software reset code 0x4143 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f80f BFAR 0xe000ed38 SP 0x2001899c Task ACCE Freestk 350 ok
Stack: 00434589 0043458a 61000000 00000001 200182d8 00000006 00000028 a5a5a5a5 a5a5a5a5 20004c08 00455eeb 40000000 200182d8 00000007 000003e8 00000007 00456163 200182d8 10000007 00000007 0000000a 2000118c 004559f1 a5a5a5a5 a5a5a5a5 a5a5a5a5 a5a5a5a5
Error status: 0x00
Aux0 errors 0,0,0
Step timer max interval 0
MCU temperature: min 31.8, current 32.6, max 32.8
Supply voltage: min 12.3, current 12.4, max 12.5, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/0, heap memory allocated/used/recyclable 2048/18/18, gc cycles 0
Driver 0: pos 113137, standstill, SG min n/a
Driver 1: pos 113137, standstill, SG min n/a
Driver 2: pos 113137, standstill, SG min n/a
Driver 3: pos 0, standstill, SG min n/a
Driver 4: pos 0, standstill, SG min n/a
Driver 5: pos 0
Driver 6: pos 0
Driver 7: pos 0
Driver 8: pos 0
Driver 9: pos 0
Driver 10: pos 0
Driver 11: pos 0
Date/time: 2021-11-06 15:51:03
Cache data hit count 2715428994
Slowest loop: 8.38ms; fastest: 0.17ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 0.8ms, write time 1.1ms, max retries 0
=== Move ===
DMs created 83, segments created 0, maxWait 0ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters 0 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
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
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
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty
=== Network ===
Slowest loop: 15.45ms; fastest: 0.00ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions
HTTP sessions: 1 of 8
- WiFi -
Network state is active
WiFi module is connected to access point 
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.26
WiFi MAC address b4:e6:2d:52:f5:b7
WiFi Vcc 3.36, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 24960
WiFi IP address 192.168.0.22
WiFi signal strength -40dBm, mode 802.11n, reconnections 0, sleep mode modem
Clock register 00002002
Socket states: 0 0 0 0 0 0 0 0

I'm getting no errors from my config.g:

M98 P"0:/sys/config.g"
HTTP is enabled on port 80
FTP is disabled
TELNET is disabled

I get no errors configuring the accelerometer through macro or console:

M955 P0 C"spi.cs1+spi.cs2" I20
M955 P0
Accelerometer 0 type LIS3DH with orientation 20 samples at 1344Hz with 10-bit resolution, SPI frequency 2000000

I did a search for M956 causing reset but found only one post for one of the 3.3 pre-releases.
Thanks in advance!

@dc42 Perfect timing for starting my weekend!

I'll be downloading and installing while having my morning cup of joe. I'm excited to test the new IS modes.

Thx!

@nxt-1

Sorry about that. Sounds like if the dumps don't provide insight it's gonna be a soldering exercise.

@nxt-1

One more question/suggestion; Have you tried reflashing the wifi module ( M997 S1 )?
Back when 3.3 was in pre-release I was doing a bit of version hopping and occasionally the wifi module would give me some erratic connection problems. Sometimes it would take a couple of poweroff/on-flash-poweroff/on cycles to get the wifi stable again, but this has worked for me. Dunno if that will do the trick, but it takes about 5min and no soldering skills to try.

Hi,

This thread is for reporting incorrect behavior for the M568 command.

I started a print this morning using wood-filled PLA. I setup a lot of z-height based temperature changes using M568 because it is now the preferred method for setting tool temps.

The 1st temp change command in the gcode file was reached and the error, "M568: missing parameter 'P' in GCode file" appeared on the panel due. I did a quick check through the console and the command, 'M568 S225' returned the same "missing P parameter" error.

When generating the gcode file I omitted the 'P' parameter because the wiki ( https://duet3d.dozuki.com/Wiki/Gcode#Section_M568_Set_Tool_Settings ) states, "Pnnn Tool number. If this parameter is ont provided, the current tool is used." and also "Remember that any parameter that you don't specify will automatically be set to the last value for that parameter."

I stopped the print and regenerated the file with 'P' defined and all is working now. I just wanted to report that the behavior is not consistent with the documentation.

• Trey

Edit:
HW: Duet 2 Wifi
FW: RRF 3.3, DWC 3.3.0, WiFi Svr 1.26

@ccs86

If you need to buy one, I can recommend the PNY EliteX U3 V30 64GB. It's getting 3.8-4Mb/s write speed in my Duet 2 Wifi.

@ccs86

About the overflows - I was getting these at first. Turned out the write speed of my SD card was abysmal (0.8MB/s). I got a new SD card and all is good now.

Try running an SD read/write test ( M122 P104 S[file size in MB] ) and get a new card if write speeds are under 1.5MB/s

@Nxt-1

I wonder if this might be a DHCP issue. Is your Duet configured for DHCP or static IP address? If DHCP, try configuring it with a static IP (that is outside the DHCP lease list range). Aternatively, try changing the lease period expiration on the DHCP server (probably the router) to zero (or whatever = never).

@mikes

Hehehe, yeah. My v2 sat unused in the corner for almost 2 years. In its stock form I don't think that printer found too many owners able to make it live up to the marketing claims. Like the 280mm (11 inches) diameter build area when the arms are only 270mm long. Their forums were full of complaints about print quality for anything more than 100mm from center. I guess my point is, don't judge all deltas by a really old model with poorly designed geometry and a pressboard (MDF) frame.
After a couple years of upgrading my knowledge and my delta, I'm printing dimensionally accurate parts with no trouble. Here's a test print I did after my latest upgrade (replacing the too flexible molded cheapskates with carriages I designed and printed).

I still needed to tune PA, used no input shaping and I used some old, loose PLA for the test print so its not as good as the printer can do. I had just watched Nero3DP's video "toasty is melting" during which he was asked what his typical print speeds and accels are. He displayed the speed/acceleration page from his SuperSlicer profile and so I used those settings to print the voron cube.

All this said, I would recommend to anyone who has a stock v2 or v3 (or even v4 ??) not bother upgrading unless they are into it for the learning. Contrary to my belief when I started the upgrade process, it's cheaper, easier and faster to just build a new printer. You can sell the old one to someone with an unusual appreciation of nostalgia!

• Trey

@dc42 does that new SE plan also include an integrated accelerometer? Surely there's room!