Idk if I should call this a bug or feature request, but the input shaping plugin is pretty much impossible to use for viewing data on mobile. 
If the motion profile list and graphs were to stack vertically on mobile that would be cool. I tend to use my phone as an adhoc hmi, so being able to run input shaping effectively would be nice (but if this is difficult to change, I realize that it’s a very low priority UI change)
I just got the Duet3D Accelerometer installed, and in the process of playing with it, I've noticed very inconsistent results in the data collected without any shaping applied. In the interest of taking a slightly scientific approach to this problem, I ran the following move several times with different number of samples:
G1 X45 Y45 G4 S3 M956 P0 S4000 A1 F"9-XY45-135-0-none.csv" G4 P10 G1 X135 Y135 F20000
Here are the outputs for the different runs:
S500:
S1000:
S2000:
S2500:
S3000:
S4000:
Here is the summary of peak frequency for each axis at each resolution:
As you can see the amplitude changes a lot with each increase in resolution, and the overall results seem to change a lot with results until I'm above S3000.
I'm not sure what to do with the results at this point. The difference in peak between X and Y does make sense for my printer layout (Dual Wire Gantry, Bowden), but the highly variable results are concerning. Is this going to strongly affect the output of applying input shaping during real prints?
I'm running @jay_s_uk '2 speed and accel tuning script, but my printer uses sensorless homing, and I don't have the necessary full step resolution to get reliable difference measurements at the end of the script.
Instead I am hoping to use stallguard detection events to determine if I skipped any steps during the running of the script. How can I count or detect the number of events reported by M915 and then add them up at the end of each iteration?
ETA: I'd like to do something similar but with max actual speed during each given move
Idk if I should call this a bug or feature request, but the input shaping plugin is pretty much impossible to use for viewing data on mobile.
If the motion profile list and graphs were to stack vertically on mobile that would be cool. I tend to use my phone as an adhoc hmi, so being able to run input shaping effectively would be nice (but if this is difficult to change, I realize that it’s a very low priority UI change)
@Phaedrux sure thing here are all the home.g and my starting machine gcode.
Also, its worth noting that I just had a similar issue with just starting a job (it didn't happen the second time I ran the job). so it might not be a race condition, and instead an issue somewhere else. I also disabled skew compensation entirely (M556) for now
; homeall.g
; called to home all axes
;
; generated by RepRapFirmware Configuration Tool v3.3.16 on Fri Oct 27 2023 16:48:23 GMT-0700 (Pacific Daylight Time)
G91 ; relative positioning
G1 H2 Z5 F6000 ; lift Z relative to current position
G1 H1 X-205 Y205.5 F1800 ; move quickly to X and Y axis endstops and stop there (first pass)
G1 H2 X5 Y-5 F6000 ; go back a few mm
G1 H1 X-205 Y205.5 F360 ; move slowly to X and Y axis endstops once more (second pass)
G90 ; absolute positioning
G1 X40 Y9.5 F6000 ; go to first bed probe point and home Z
G30 ; home Z by probing the bed
; Uncomment the following lines to lift Z after probing
;G91 ; relative positioning
;G1 Z5 F100 ; lift Z relative to current position
;G90 ; absolute positioning
; homex.g
; called to home the X axis
;
; generated by RepRapFirmware Configuration Tool v3.3.16 on Fri Oct 27 2023 16:48:23 GMT-0700 (Pacific Daylight Time)
G91 ; relative positioning
G1 H2 Z5 F6000 ; lift Z relative to current position
G1 H1 X-205 F1800 ; move quickly to X axis endstop and stop there (first pass)
G1 H2 X5 F6000 ; go back a few mm
G1 H1 X-205 F360 ; move slowly to X axis endstop once more (second pass)
G1 H2 Z-5 F6000 ; lower Z again
G90 ; absolute positioning
; homey.g
; called to home the Y axis
;
; generated by RepRapFirmware Configuration Tool v3.3.16 on Fri Oct 27 2023 16:48:23 GMT-0700 (Pacific Daylight Time)
G91 ; relative positioning
G1 H2 Z5 F6000 ; lift Z relative to current position
G1 H1 Y205.5 F1800 ; move quickly to Y axis endstop and stop there (first pass)
G1 H2 Y-5 F6000 ; go back a few mm
G1 H1 Y205.5 F360 ; move slowly to Y axis endstop once more (second pass)
G1 H2 Z-5 F6000 ; lower Z again
G90 ; absolute positioning
; homez.g
; called to home the Z axis
;
; generated by RepRapFirmware Configuration Tool v3.3.16 on Fri Oct 27 2023 16:48:23 GMT-0700 (Pacific Daylight Time)
G91 ; relative positioning
G1 H2 Z5 F6000 ; lift Z relative to current position
G90 ; absolute positioning
G1 X40 Y9.5 F6000 ; go to first probe point
G30 ; home Z by probing the bed
; Uncomment the following lines to lift Z after probing
;G91 ; relative positioning
;G1 Z5 F100 ; lift Z relative to current position
;G90 ; absolute positioning
And here is my custom start g-code:
M140 S[first_layer_bed_temperature] ; Set Bed Temp
M190 S[first_layer_bed_temperature] ; Wait for Bed temp to reach target
M104 S[first_layer_temperature] T0; Set extruder Temperature
M109 S[first_layer_temperature] T0; Wait for extruder to reach set temp
G28 ;Home
M572 D0 S0.5; Enable Pressure Advance
G29 S1 ;Load Heightmap and enable bed mesh leveling
M376 H1; Taper mesh compensation after 2mm
;Prime the extruder
G92 E0 ; Zero Extruder
G1 X-1 Y-1 Z3; Move just outside origin and up 3mm,
G1 E40 F500; Extrude 35mm filament
G1 Z0.25 X50; Squash blob
G92 E0; Reset Extruder position
Not sure if this is the right place to post this.
Just today, I managed to accidentally create a z-homing race condition by telling my printer to Home all axes and then sending another command that caused the X and Y axes to not move to the z-homing location before attempting to home Z. the two sequences are listed below:
Scenario 1: Use DWC to initiate "Home All", and then clicked "run mesh compensation" before homing had finished. This resulted in the printer failing to home z because my probe is off the build plate when the hot end is at the Y-home position.
Scenario 2: I started a print (which included homing as part of the starting g-code), and then went to use Z-Babystepping. the same thing happened as before where the X and Y homed, but then failed to move before initiating Z-home routine.
Is there a setting or configuration change I can do to prevent this from happening. I don't recall ever having this issue before (despite doing similar sequences), and its been at least a month or more since I last changed the firmware. The only config changes I made were to reorder M556, and adjust it's values.
I'm running this FW config
@tas I just assumed that Z was 1 because of gravity. I think that the frequency domain analysis of each axis is done independently since Z shows a very small amplitude in all of my original graphs.
@gloomyandy thank you, I did eventually figure that out. I did check the wiki and firmware, and the accelerometer is already collecting data at the max frequency (1600 hz). And the biggest issue that was occuring with the long tail of data is the hot end cooling fan frequency was creating a false signal.
Regarding my specific case, I was able to solve a lot of my issues by securing the cable to the gantry because the rubbing on the frame was causing lots of noise. And the low amplitude seems to just be from my printer being particularly rigid at the speeds I can go (score 1 for past me!). I'm currently limited by hot end flow rate, so maybe if I switch back to my volcano, this will become more important.
I reconfigured my setup so that the accelerometer cable is secured to the hot end gantry, and I'm now getting more consistent results. (yay!)
And I think I figured out why the results change with data samples qty. That option doesn't actually change the rate of data points, just the total number of samples. So increasing that number just increases the signficance of ambient vibrations of the system. In my case the fans become the biggest influence.
With Fan
Fan off:
All that being said, I'm now curious if my data is really showing that Input shaping will help me. it seems like my printer is rigid enough that the fans are the primary source of hot end vibration. I'm guess I can try for even more agressive jerk and accelerations until those become relevant.
@Notepad Interesting. I've got speed, accel, and jerk all basically uncapped at this point with the goal of finding the true limits of my printer, but maybe that's contributing to the variable results.
So I've done more testing with lowered limits, and even still, this is feeling more like a random number generator than a measurement tool. It seems like the cable position is just as significant a factor as the actual motion settings.
I just got the Duet3D Accelerometer installed, and in the process of playing with it, I've noticed very inconsistent results in the data collected without any shaping applied. In the interest of taking a slightly scientific approach to this problem, I ran the following move several times with different number of samples:
G1 X45 Y45 G4 S3 M956 P0 S4000 A1 F"9-XY45-135-0-none.csv" G4 P10 G1 X135 Y135 F20000
Here are the outputs for the different runs:
S500:
S1000:
S2000:
S2500:
S3000:
S4000:
Here is the summary of peak frequency for each axis at each resolution:
As you can see the amplitude changes a lot with each increase in resolution, and the overall results seem to change a lot with results until I'm above S3000.
I'm not sure what to do with the results at this point. The difference in peak between X and Y does make sense for my printer layout (Dual Wire Gantry, Bowden), but the highly variable results are concerning. Is this going to strongly affect the output of applying input shaping during real prints?
@phaedrux Thank you! (that did not come up when I did a search before posting)
I'm in the early stages of designing a tool changing platform, and am curious if it is appropriate to hot swap extruder stepper motors for the modular hot ends. In order to simplify the wiring harness, and reduce the cost of electronics, I am hoping to use a pogo pin connection between the tool heads, and the tool holder. I would ideally include channels for the heater core, thermistor, cooling fans, and direct drive extruder motor. The first 3 seem fairly easy to manage from gcode macros, and I'm not aware of any electrical reason that hot swapping those could be a problem. The motor on the other hand has me a bit concerned.
Based on the documentation here: https://duet3d.dozuki.com/Wiki/How_to_destroy_your_Duet_2 it seems like I should be able to avoid problems as long as the motor is powered down during the swap, but I just wanted to confirm that before I go too far down this design path. (I guess this technically wouldn't be hot swapping, but I'd still like to be able to switch out tool heads (with motors) as frequently as once per layer.)