Multi extruder support for kraken hotend

[Charly333]

The text mentions 1 Sensor and (several) pins. Can I have 4 separate Sensors with this plugin?

[maocypher]

Hi :) currently one sensor per time is supported. You can attach several sensor, but before starting the print you need to change the configuration. I could think about something like saving several configurations and sensors, but you need to activate one specific before starting the print or I check if it is possible to bind it to the connected printer that is connected to Octoprint. Is it heading into the right direction?

[Charly333]

Hi, unfortunatelly not. Im working on a 4 channel kraken hotend. So up to 4 filaments are used in a single print.

[maocypher]

This should be possible to be implemented, but I cannot test it, because I only have an Ender 3 with Micro Swiss All Metal Hotend.

As I soon as I finished the development of the current feature. I could create a special branch for your feature request and from time to time I ask you if you would like to test it.

What do you think about it?

[Charly333]

Yes, would be pleased to test.

[maocypher]

Okay, great, I inform you as soon as I have a testable version

[maocypher]

Hello @Charly333 as promised I prepared a version with multi extruder support. Currenlty it is rather pragmatic and I going to improve the GUI in the next days. https://github.com/maocypher/Octoprint-Smart-Filament-Sensor/archive/MultiExtruder.zip Please ensure to read the instructions properly. I would be glad to here if it is also working with several extruders.

[Charly333]

Hi, read the instructions - any special things to take care of cause of multi Sensoring?

M600 is a problem to me. Got a Btt 35 V2 TFT on that printer without any button. So M600 will trigger an endless loop I can´t interrupt from this. Any reason not to go along with my own Pause / Resume scripts?

Using raspberry 3b+, so any additonal suggestions for Pins to make use of? At the moment I´m using Pin 37 (board mode).

[maocypher]

I started with one command. I could offer a text box or you tell me which command you are using? Standard pause?

No, no special recommendations. It is implemented so that you can connect several BTT sensors.

[Charly333]

OK - that installation script killed my octoprint instance at all. Even no response on putty any more. Fool me tried that installation on an unsaved copy with all testing and setups for the kraken for the last two weeks. Now taken that lesson will have to set it up from scratch.

[maocypher]

Do you still have your logfile in the logs folder? On my Pi everything went fine, so it would be good to see what caused the troubles. Btw. you can remove the plugin from the octoprint/.../python/site-packages folder. Then you don't need to set up everything from scratch

[Charly333]

The card doesn´t show up any more. In Pi with putty I´ve got a short connection that was terminated directly. Now Host is not available is the message. With Windows I´m just checking the card with a bunch of adapters, but don´t bring it to live even there.

[Charly333]

OK, even my camera that takes each and any card is refusing it. So maybe octoprints Message "There went something wrong during installation" and the card fail on the reboot right after might have been an accidental meeting. Nevertheless it will take me couple of days to get it running again. Beeing somewhat scared about redoing all the synchronisation testing on the 4 extruders...

[maocypher]

Omg... that sounds awefull... i am doing several instations per hour during developing the plugin, sounds like something broke on the SD card... I had it once on my mobile and all pictures were gone... I hope you can fix it... Maybe it is worth a try mounting it with Linux stick, sometimes you are lucky and can mount it although no other device can

[Charly333]

Just ordered two new SD cards, so I will be prepared with the next installation attempt. Will be back on you as soon as I´m ready to go ahead testing. Filament out ist still an open to do on this 4x4 carriage as well as with the 3in1 interchangeable one.

[Charly333]

Hi, can you tell me how you handle waiting phases? Tool changing takes up too about 45 sec - evenmore when a tool is used for the first time, where no filament action is done. So is interpretation of fil sensor signal related to G1 or even better to extrusion commands? Can timeouts change over time? Ironing with 10mm and 10% flow will get quite different readings than standard printing with up to 400mm/sec and 100% flow on 0,8 nozzles. With speed like this 300 mm filament (from sensor to extruder) is a matter of seconds.

[maocypher]

I need to check your exact in the latest version the distance detection is based on G0, G1 and in near future also G2, G3 commands. I don't know all commands by heart yet ^^" If you have some more commands, just let me know. Timeout detection is currently bases on time since the last signal of the sensor. For a first small test object this might be better. The distance detection in your version is still sendinh M114 to the printer, i.e. outdated... On the weekend I hope I have time to merge the code, so that I can provide you the latest changes

[Charly333]

So tool changes are recognized by the position of the tool? Do you need M114 detail activated in firmware?

I too can go ahead first at the weekend. At the moment I´m trouble shooting jittering termistor readings on M5 additional board for T4. Only 3 heads- connected to GTR Board - are working fine.

[maocypher]

Explicit tool change is not yet supported, only simple commands. I think I should go through the GCode commands again to support them. I started 3d printing in May so I am not very experienced yet. Still at the beginning of getting in touch with all the features. I merge the code first then M114 is not necessary anymore

[maocypher]

I did some analysis: if some pausing commands from your GCode are ignored, please try to add them in Settings -> Serial Connection -> Firmware & Protocol -> Pausing Commands. OctoPrint only recognizes these commands as pausing commands. Then also the sensor should pause its detection.

[maocypher]

As promised I merged the latest changes from the master branch into your version. Feel free to test it. It is roughly tested (as far as possible for me) and M114 is not needed anymore. Additionally I added alternative pause commands.

[Charly333]

Hi, great, what´s the download for that version?

I don´t make use of that fancy tool changing stuff. Only use T1 / T2 / Tx and have octoprint doing the work via "before" and "after tool change" scripts.

before: M201 T0 E1500 ; speedup M201 T1 E1500 M201 T2 E1500 M201 T3 E1500

G60 ; save position

G92 E0 ; retract a bit G91 G1 E-0.5 F1500 G90

G0 X0 Y0 F20000 ; move to changing position

G92 E0 ; getting filament out of the nozzle G91 G1 E-49.5 F1500 G90

M104 S150 ; start cooldown to wait temp

M201 T0 E40 ; go back to normal not dripping extruder speed M201 T1 E40 M201 T2 E40 M201 T3 E40

after Toolchange:

M109 S220 ; heat extruder up - here is an additional script necessary to heat up for layer 2 with diff temp and so on

G91 ; prime the tool G1 E51 F1500 G92 E0 G90

G61 F20000 ; return postion saved

So even if there is no wait code in this, I do have a break between Toolchanges (beside heating waits) I can´t explain. Crawled Marlin Firmware and too could not find a reason for that break.

At the moment beside I´m fixing one of the last issues. Had to step back from UBL to bilinear Mesh-Leveling and deaktivate any automatic mesh recalculation methods to keep the kraken flying in constant hight over the bed. First layer is somewhat tricky, for the slightes stickig up of filament or unecessary lowering by software precalculation of the bed and it will be torn away by the inactive nozzles nearby. If first layer did survive, it works like a charm.

[maocypher]

The link is the same as before, just a newer version :) Try distance detection, this interprets G0, G1, G2, G3 commands. For pausing I catch the pause event from OctoPi i.e. if you have any pause commands, that are recognized check it in the OctoPi configuration.

If there is any strange behaviour you identify, also provide the GCode, so that I can check and try to debug what happend

[Charly333]

For me G60 as a Pause start and G61 as Pause end would be perfect too. Don´t need it for timelapse or so.

[Charly333]

same procedure... Installed your new plugin. "something went wrong" ist what octoprint tells. "no host avalable" is what putty says.

This time i was more carefully, so got a backup and - to test if plugin manager works - did update some other plugs right before with no problems...

[maocypher]

Do you install from Zip or URL? I never ran into such problems. With every change I install from Zip File

[maocypher]

I created a Discord server: https://discord.gg/YQsXrSwrV7 If you like I can try to give you better support here. If your octoprint.log is still available it would be helpful if you could provide it for further analysis.

[Charly333]

I Installed from ZIP. "No Host available", so I don´t have access to logs.

It was a blanc installation - so I don´t have your official version installed previous - should I?

A printjob is running now, so I´ll be back on you tomorrow afternoon.

[maocypher]

It shouldn't be necessary. I try a complete fresh installation tomorrow and try to reproduce the error.

Which plugins do you have installed? I had some troubles with restarting when Spaghetti Agent is activated. Then I can check for possible incompatibilities.

[maocypher]

I checked the fresh installation once on my OctoPrint running on Raspbian and once on OctoPi Image, both worked without any issues. If you could try to install it again and also provide the output during the installation, this could also be helpful

[Charly333]

No Spaghetti Agent installed

But Action Commands, Backup Scheduler, Bed Visualizer, Consolidated Tabs, Cura Thumbs, Dashboard, DisplayLayerProgress, Exclude Region, Fan Speed, Filament Manager, filament Sensors Revolutions, floating Navbar, Navbar Temperature Plugin, OctoPrint-Wide Screen, Octolapse, Print Job History, Printer Notifications, Prusa Slicer Thumbnails, resource Monitor, Sidebar Webcam, TP-Link Smartplug, Tempsgraph Plugin, Terminal Commands, Themeify

Already had a similar issue once with Dashboard plugin, that crashed octoprint. They handed out a new version and from then it updates with no problem. But don´t know what they changed.

Maybe some trouble with phyton version? Did not install ARC welder because of this.

[maocypher]

I try installing the plugins you use and see what happens. Even if Octoprint crashes I still have access to my Raspberry, because I ran Raspbian. I inform you as soon as I have news for you

[Charly333]

Putty doesn´t find any host, so I can´t contact to my raspberry after that crash - can I?

[maocypher]

You could plugin keyboard, mouse and monitor to the pi and then log in the classical way to see what happend. Or eject the SD card and mount it with Linux live stick to get all the data.

[Charly333]

Placing that 150kg printing monster - pi digged deep in it´s intestines - nearby the flatscreen in the living room might not be the best idea to surprise my wife - but this would be the only HDMI monitor available...

So after the actual print I´ll do a new installation and and if it crashes I will dive into that Linux stick adventure. At least this had to happen already long ago...

[Charly333]

Finaly I did succeed installing your version. Had some other plugins refreshed before and now it´s working and I will go ahead testing. Again the questions what raspbery (3b+) pins you´d recomend for the other sensors?

[maocypher]

Good to hear :) I recommend all pins without special functionalities like CLK or similar

[Charly333]

As Pause command I´d need to have that Octoprint pause Script executed - is it possible? As a trigger to pause detection I´d need G60 and to restart detection G61 - is it possible? Tool changes T0 / T1 /T2 won´t be that good, for times to change the tool varies a lot.

[maocypher]

You want G60 as pause command instead of e.g. M1? For all other commands I could provide a free configurable value, but on your own risk, that it is supported by your printer. I looked up the most common pause commands

[Charly333]

No.

1. I need to interrupt the sensor tracking the filament during tool change to avoid false positives G60 (save position) always is the startpoint for tool changing. If tool change is finished G61 brings back the nozzle to and the sensor schould go ahead tracking the filament. So precise action driven commands will take over during the changes. Timing or Length are only relative commands and so for Tool-Changing not so good.

2. what has to happen if filament sensor reports truly out of of jamming? Here I don´t need a single Command. Octoprint has Gcode scripts for print pausing and restarting print. I want to trigger those gcode scripts by your plugin.

[Charly333]

Will be back in a few hours...

[maocypher]

The GCode scripts for pausing is triggered. I use it to move the nozzle up so it doesn't stay on the print. This is handled by OctoPrint itself if the command is added in Settings -> Firmware -> Pausing Commands. M0, M1, M25 are configured by default

[Charly333]

OK thing we´re looking at the same from different point of views.

Settings -> Firmware -> Pausing Command seems to be listening if the defined triggers occur and if so sends out what is defined in Settings > Gcode Scripts > After Print Job is paused (is it so?) This way the handling of filament out / jam is totally fine. To get system printing again, Octoprint get´t manually the resume command and send out what is defined in "Before print job is resumed"

Second I was talking about is that this mechanism has to be interrupted during Tool-Change. No sensing of filament - or other way round - simulation of "filament OK" for that time. And the trigger for Tool-Change is G60 - and here we do have an automatic retrigger when change is done with G61 to start sensing again. But I don´t know where to implement this break in sensing. Maybe filter out any Settings -> Firmware -> Pausing Command commands to prevent printing pauses till G61 is starting it again - or on a lower level generate a static "filament present" signal for the time after G60 and before G61.

Was this understandable in some way?

[maocypher]

Is your tool change manually or fully automatic?

Sorry this is quite difficult for me, becausr I only own a simple Ender 3

[Charly333]

Please do feel free to ask for each and any detail. I know how confusing my start in multi-tool printing was.

The tool change is fully automatic.

T0 (T1 / T2 /T3) in printfile-gcode triggers the start of the tool change. None of the details what´s to happen after this code is specified in printfile-gcode. The toolchange is accompanied and guided by gcode that octoprint injects:

"Settings > Gcode Scripts > Before tool change": G60 ;saves position of actual tool G0 X0 Y0 F20000 ; brings the printhead to the border, for toolchange has some oozing G91 ; relative mode so retraction is "unseen" to the system - otherways this movement might mixup the extrusion for the print. G1 E-50 F1500 ; have filament out of the heated area of the tool G90 ; go back to absolute position. M104 S150 ; reduce actual heating temp to parking temp

After this the the Tx itself command is executed. With Kraken hotend therefore only the printhead is realigned so that next nozzle is positioned on X10 Y10. Which direction to move for each tool to match this reference point is defined in "Settings > Gcode Scripts > Before print job starts": M218 T0 X10 Y-10 M218 T1 X9.75 Y9.75 M218 T2 X-9.3 Y9,4
M218 T3 X-9,7 Y-10 (this could have ben done in firmware, but I prefere to set each and every detail that can be overwritten in Settings > Gcode Scripts > Before print job starts)

After this the code in "Settings > Gcode Scripts > After tool change" is executed: M109 220 ; powers the new tool up to printing Temp G91 ; relative mode, so priming is "unseen" to the system G1 E51 F1500 G90 ; go back to absolute positioning G61 F20000; return the new tool to the postion saved from the old

After this the normal print routine starts automatically using the new Tool. Hope I could explain why G60 and G61 are the indicators for start and end of the time where no "Filament out" is allowed to be send - neither triggered by time or by motion. Motion during retract and priming - by changing absolute and relative positioning - is hidden to to the system and the time for tool-changing can vary widely. If T4 - for example - first is needed after 50cm of print hight, nozzle won´t be preheated and held on wait temperatur like those tools swapped in and out on each layer. So heating for this tool can take a couple of Minutes.

Manual interpolation is not needed for the tool change at all. What I named "Manual interpolation" only is needed if during normal print a correct filament out situation was sensed and octoprint hast triggered the code from "Settings > Gcode Scripts > After Print Job is paused". In my case too the printhead is raised and the nozzle temp of all nozzles is set to 0 while the temperature for bed is kept untouched. So it doesn´t matter if I can change the filaments hours later only. The piece of old filament has to be removed then and new Filament entered and primed down to the nozzle. During all this octoprint goes to "Pause" and offers a button for resuming. This is pressed "manually" so the print can go ahead.

[maocypher]

Okay, I think I understood now. From your description during the automated tool change and you are using distance detection, eveything should be fine if the filament is moving and not stuck. I.e. if the sensor is still enabled it should recognize a jam or run out.

If it is not working for you though, I could think about providing a funtionality to pause the sensor detection

[Charly333]

OK, I´ll try that. At the moment the sensors are not recognized at all as it seems. For neither manually removed filament nor unplugging the sensor during print causes any pausing at all. So I´m switching the waiting queue for the sensor test function ;) Thank´s for your support until now.

By the way: The setup then should too work with btt 3 in 1 hotend. As soon as Kraken is running with sensors and plugin, I´ll go ahead testing the interchangeable printing plate with that setup and will report.

[Charly333]

OK, here´s another information for you. Just cleaned up my plugin assortment and reinstalled your plugin when I found, that there is no text on the setup tab of your plugin any more. I figured out, that this was caused by "consolidated tab" plugin. Deactivating that brought back the text and fields. Maybe this was a reason for the crashes too.

[Charly333]

Finally it´s working - for one sensor on board mode pin 11. All the others tested until don´t trigger pause. Hopefully tomorrow I can test the rest of the pins to check out if we will find 4 working ones.

[maocypher]

Cool, thanks for the feedback. As soon as I have time I take a look of the compatibility with consolidated tab plugin.

I received new hardware for my printer ^^"

[Charly333]

How´s your printer doing? Already capable to do the dishes too?

Got some more results:

The higher Pi Pins, I did try first, didn´t work for me. Board 11 / 13 / 15 / 16 do work.

Did increase distance detection in steps of 5 mm - after about 10 print resumes there´s a great chance the pi will not be available by wlan any more, but will do one more pause with no chance to resume. That´s totally fine for me. Don´t expect to have more than one filament change per extruder per print :)

Had to raise the distance detection to 100mm at least - especially for the first layer usually printed with 10 to 15mm / sec and any layer with large slow ironing sections. This is half of the nearest distance between sensors and extruders when printhead is near the middle of the bed. For extruders do ride the printer cartridge and spools/sensors are located at the frame, moving around the 400x400 bed will tear a lot of filament through the sensor needing quite a pretty printing distance to melt it onto the bed before asking for more. For filament out sensing it seems to be quite OK. An option to activate the Sensors from Layer x upwards might help to bring the distance a bit lower.

My jam tests did fail with these higher distance presets. Before the jam is recognized the extruder in combination with printhead movements had either grinded the filament - what´s hart to remove if you can´t move around the printhead still planing to go ahead printing - or that four 73 (N.cm) Motors on x axis just tore more older and more brittle filament into pieces - what´s quite easier to fix ;) Shaking and tearing the filament that hard seems to be missunderstood by sensors too - leading into moving signals . Hopefully the sensor test function will point it out more clearly - the script is beyoind my skills.

Even if the shaking and tearing ain´t that hard on normal movements, I´m a bit worried how you handle sensing informations from different sensors? Do you sum up signals, or are they taken from sensor related to the active extruder only? At the moment I didn´t face that special error in my limited tests, but on prints consuming a couple rolls of filament, to have a movement information from the wrong line whilst the active tool is running out would be quite a bit annoying ;)