I have a BTT smart runout sensor and due to bricking a control board in the past I don't want to reflash the firmware right now to try and get it running on the printer itself, and I use octoprint on a mini PC (could never get rid of the low voltage alert). I found SIO control and thought it would be great but I can't see a way to configure exactly what it does when it detects a filament run out. And because the way the smart one does it its not really just a "runout" its a did the state stop changing at some point.
I misunderstood the description and when I first saw it and thought it convinced other apps that the device had IO pins and just passed them along so other plugins could use it but I must have just misread that or something.
Any ideas? Honesly I'm hoping to catch the creator jcassel here for some thoughts?
When using the SIO Control, the filament run out is detected through an IO point changing state. One would configure this IO point in the integrations section. When the SIO Control integration detects the expected state change, it will pause the print (same as a filament runout sensor would). Its expecting an input that would be normally high or low and the change to the other state would be the trigger that something changed with the filament. The result is that it will send a pause.print singal.
What you do with it from there is up to you. You can setup scripts for when your print is paused or you manually take actions.
I'm not sure what part is giving you trouble. Can you tell me about your setup in relation to what you are using for your Hardware IO. I'm not clear on if you have a microcontroller and if so, have you successful detected runout/change in state from your sensor.
ah sorry I don't think I explained it well.
The smart filament runout sensor (at least this one) going high->low->high->low etc as the filament is pulled through (I think a wheel thing turned by the filament moving and light sensor) so just detecting a change is state isn't enough. There is another plugin called Octoprint-Smart-Filament-Sensor that checks it and compares it to time (like filament hasn't moved in awhile oh no) or detects it by distance (looks like its reading the actual Gcode commands) to see if it should have toggled but didn't meaning that the filament isn't moving.
I was hoping your plugin could be used by theirs or something instead of the raspiberry pi gpio pins, but sadly no. I'm right now thinking about extending your plugin to add something like a smart filament runout option but I don't actually know if I'm a good enough python programmer to do so.
Ok, I think I understand. First, you are right, there is no current support for what you were thinking. I have thought about making it just simple IO but that would be really limiting in lots of ways. Part of the long term vision for SIOC is to allow some closed loop control and reporting. So it would be difficult to allow for direct fast(sub ms) IO access from other PlugIns.
I took a look at the smart sensor plug in and I understand what it is doing. Its main mode takes the Gcode movement of the extruder and tries to match that with the sensor.
Given how it is reading the ticks of the IO, it would be hard to do the sensing of distance in the same way as the using the SIOC's method of reporting IO changes. Not impossible but I could see where a lot of "ticks" could be missed and that would for sure cause a good bit of issues.
I think the better way to do it would be to do the tick counting in the firmware and then just do the math in the PlugIn. Likely would be able to pull a lot of the code from the SFRS to ensure it was pretty close. Doing this would for sure have some complexity. First the released version of the SIOC only supports Simple Digital IO reporting (Ones and Zeros). So you would have to build out the ability to report the count and then interpret it. That is trickier than it sounds. I am in the middle of adding PWM output and I have had to go thought setting that up. Not as easy as I was hoping. I am thinking about longer term stuff so I have to take care to not paint myself into a corner.
It might not be so bad if you were to just strip out everything not needed and just focus on the tick counting. Could use an atiny8x and just keep it to handling the sensor output.
I ordered a BTT Sensor and will take a look at what I can do with it when I am past the current work I am in the middle of. Likely a 2-3 months.
wow I appreciate it, I didn't expect you spend money on my unusual request.
I wasn't thinking about the time scale of the ticks being a concern like that, in their description they mentioned using a timeout before movement again of 45 seconds. Obviously if I tried to make it go by distance of filament between ticks it could be pretty quick if I'm printing faster.
I am interesting in contributing trying to see if I can add this as another option using the current IO reporting method you have, but I don't want to be stepping on your current work. I'm planning on making a branch from yours on Github and seeing if I can add it without messing to much up in the meantime.
The code is out there. Let me know if you have questions. If you find you have something that works, let me know I can take a look at it and see if I can pull it into the main project.
Firmware wise, I suggest you to stick to the code in the Esp32 2 relay branch as its the firmware that I update first. Some of the lower capable devices may not get future updates as they may not support them or have room for the code.