drlex0 / mightyvariablefan Goto Github PK

It seems impossible to eliminate the risk of missed detections completely. Occasionally a detection still fails due to one of the beeps not being recognized. It is unclear why, maybe the printer just botches up an M300 command or maybe there still is an occasional glitch in the audio stream. The risk of this happening seems to be around the level of 1/1000 which makes it nearly impossible to debug.

Still, the risk remains that such failure will happen right at the moment the last fan speed change for a long while is supposed to be performed. If this is missed, the fan could keep blowing at much too high or low speed and ruin the print.

A workaround is to repeat a sequence after a few seconds, if no new sequence follows within reasonable time (say 10 seconds). The risk that two consecutive sequences fail should be extremely low.

The streamed data flow in pwm_postprocessor makes this a bit tricky to implement. The simplest way is probably to make two passes over the G-code, keeping track of when and where sequences were inserted during the first pass and then inserting duplicates in the second pass.

Add an option to take acceleration into account when calculating the duration of print moves. This will make the timing of the fan speed changes more accurate. Currently the timings can be off by quite a bit if there are many small zig-zag moves right before a fan speed change, because these are slowed down considerably by accelerated moves.
Ideally the splitting of print moves should also take acceleration into account, but I reckon this will require a lot of effort for only a marginal improvement, the simple linear split should be good enough.

Currently the detection algorithm is biased towards positive signals. Any series of three signal frequencies with acceptable timings is treated as a positive. There is only some awareness of negative indicators like harmonic detection. The result is that some of the tunes can still trigger a false positive. This is not really a problem when using the Sailfish build with the heater tune toggle option, but it is annoying.

Another problem is that playback of M300 commands will likely become less accurate in future releases of Sailfish. This means the detection parameters will need to be made more lenient which again increases the risk of false positives.

To both reduce the risk of false positives while allowing more sloppy timings, I propose to update the detection routine to evaluate groups of 3 possible signals as a whole instead of sequentially.
The false positives I have seen, all have a whole bunch of ignored simultaneous signals. The motivation for this was that a sharp bang on the printer housing must not cause a detection to be aborted, but a sharp bang will only cause 1 or maybe 2 FFT frames with multiple signals, not 10 like I often see in a false detection. So if a candidate sequence has more than 2 simultaneous signals, discard it.
Similar for timings: if the timing of one beep and one pause is somewhat too long but the other timings were perfect, the printer was probably slowed down while playing an actual sequence and it should be accepted. If all timings are suspicious, then it should be discarded.

This can be implemented as a penalty system where each simultaneous signal case adds a score, an each timing flaw adds another score. If the total score exceeds a threshold, discard. A fancy way to determine optimal scores would be to gather a lot of examples and then throw some learning algorithm against it, but good results can probably be obtained as well with some common sense.

One of the motivations for using the buzzer as a communication channel was that it doesn't require installing a custom firmware. However, due to the annoying heaters tune played by recent Sailfish builds, a custom firmware build is needed anyway to remove the risk of this tune messing up beep sequences. The pull request to toggle the tune might some day be merged into Sailfish, but it could take forever before this ends up in firmware that the average Joe can easily install.

Hence if (for the time being) a special Sailfish build needs to be flashed anyway, the possibility should be investigated whether an extra X3G command could be added that can send short strings to the second serial output (UART1) of the MightyBoard. This would provide a more reliable communication (and silent) channel to the Raspberry Pi, and open up the possibility to control many other external devices from within a print.

Just followed this guide and put everything together and all is working and all calibrations are good. Only problem is I use S3D and not Slic3r and was wondering if you could provide a way to post-process the GCODE that is output from S3D. Tried feeding some S3D gcode into the phython script and it complained that M126/M127 commands are being used. Found some in the start gcode (also some in your Slic3r start/stop snippets). Can you provide some guidance please? I really need to use S3D due to the processes.