Topics created by gloomyandy

@chrishamm Yes but why does doing a browser "refresh" fix the problem? As far as the WiFi server is concerned it is just seeing http requests so I don't see why the refresh would fix a problem at the server side? It seems odd to me? Maybe it is just a change in the timing of requests? If we can understand why that refresh fixes things it might help us resolve the problem (if there is one) in the WiFi server.

@gloomyandy Thanks, updated. It was getting a bit long winded, so I moved the parameter description to a note.

Ian

M106 entry updated.

Ian

@gloomyandy no, the only special thing about system macros (apart form being invoked automatically) is that they ignore workplace coordinate offsets.

@pcr Short answer no.

Longer answer:
At the moment beta6 does not allow you to capture more then 64K samples. But you may be able to get it to work by using a lower capture data rate in M956 and then modifying the script to match, but this is not something I have tried. It looks like the next RRF build should have support for larger captures: https://github.com/Duet3D/RepRapFirmware/commit/020e9fbc171b1a519d9b8f01df2e68f1c273beaf

0 dc42 committed to Duet3D/RepRapFirmware Support collecting more than 64k acceleraometer samples

@gloomyandy Thanks, I'll check what's going on. It will be fixed in the upcoming version.

@gloomyandy said in Input shaping testing and thoughts:

I wonder if there is any way that the shaper tuning process could identify and ignore things like this?

I seem to recall it being suggested that the accelerometer could be attached to the frame for a base run and then subtract that from the print head run, but I'm not sure what became of that idea.

@gloomyandy thanks for reporting this. I have reduce the stack usage of ExpressionParser::ParseIdentifierExpression, which had grown in beta4, and increased the SBC task stack size from 820 to 1000 words.

Ah that makes sense! Thanks for the info Chris.