M150 Filter. #143
Comments
|
What do you mean filter the command? It should still pass the command to your printer. If it's not doing that then it's unexpected. |
|
That is exactly what it is not doing. With the plug in enabled it is not passing through the M150 command. I rebooted to safe mode which disabled all 3rd party plugins which Tasmota is the only one on this instance and it started sending the M150 and then I rebooted the instance and disabled the plug in and OctoPrint started sending M150 commands when issues either through a print g-code or entered in the terminal. |
|
I have three OctoPrint Instances set up and I went back to check to make sure it wasn't a mistake on my part and the other printer that has the plugin installed also doesn't pass through the M150 command while the third instance without the plugin does. |
|
I'm looking into the code later today to see why this is happening, but initial discussion on Discord has indicated that it shouldn't be getting gobbled up like it is, but during testing I found that if you include the I value in your M150 command it does go through. Maybe that will be an interim workaround for you until I can figure out why it's not working. |
jneilliii
added
bug
|
I've fixed this with the above commit and made a version 1.0.4rc1 for you to test out and verify. You can change your release channel in software update settings for the plugin to Release Candidate and then install the update when prompted. |
|
I've got about 20-35 minutes left on a print with a printer that uses the plugin as soon as it finishes I will upload the release and test it. |
|
I tested the RC on my one printer that already had it installed and it started passing through the M150 command and i installed the plug in on my one printer that didn't and was able to reproduce the issue on the stable release and then changed to the RC and it started passing through the command as well. The printer that I initially noticed on as about 4 hours left in a print before I can test the RC on it. |
|
Tested the RC on the printer I first had issues with and it now passing through the M150 command. |
|
Cool, I'll close the issue and will be available in the next official release. |
* fix bug with M150 command not having I parameter causing the command to get lost in the queue, #143 * make request timeout configurable in settings, #142 * add numeric StatusSTS messages for chk values, #150 * account for energy data with multiple relay device, #155 * M118 support for LED commands for more real-time control based on what's happening on the printer (ie waiting for heat up). The function is similar to the M150 support but you will need to use the command `M118 TASMOTA_M150 I192.168.0.105 R### G### B### W### P###`
I saw with the last change log that you added M150 control.
Most recent changelog
1.0.2 (04/09/2021)
add uptime library to resolve issues with idle timeout and initial pi boot
add label to warning prompts for better identification
resolve issues related to thermal runaway only being triggered once until a restart
add LED control via M150 gcode commands.
My LEDs are controlled off of the main board itself but I use tasmota to control the PSU. Is there any way to have the plug in not filter the command when the LEDs are controlled by another source?
The text was updated successfully, but these errors were encountered: