Open ruedli opened 5 years ago
I'm not at home for a few days, but i will investigate on that as soon as possible.
No problem, take your time. ;-)
In the mean time I "manually" played with the gcodes, the recommended ones seem to work fine ("no cold load prevented" issued by the firmware, no clicking sounds from the extruder motors while loading). Will continue to do some test with a gcode file with "real replaced codes" as if the plugin replaced them. I will be also away from home a few days, so I'll keep you posted on my experience.
This load / unload from the Prusa side still has lacking functionality:
I will add a change request to the Prusa firmware on this, then we can configure it more to our wishes in future.
Cheers Ruud
Op zo 6 okt. 2019 om 22:46 schreef derpicknicker1 <notifications@github.com
:
I'm not at home for a few days, but i will investigate on that as soon as possible.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/derpicknicker1/OctoPrint-Mmu2filamentselect/issues/2?email_source=notifications&email_token=ABGGYOCL56QTMN4KZYEJ7JTQNJFEFA5CNFSM4I54AQN2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAOTVKY#issuecomment-538786475, or mute the thread https://github.com/notifications/unsubscribe-auth/ABGGYODDZQGFLC7FVQZRB5LQNJFEFANCNFSM4I54AQNQ .
-- Ruud Rademaker prefered mail: ruud.rademaker@gmail.com
And.... I tried it: works totally smooth, I manually loaded filament 4 first, and as expected it did normally change to filament 1 with the code below.
This was my GCODE initialisation
;Tx M701 E0 M190 S[first_layer_bed_temperature] ; wait for bed temp M109 S[first_layer_temperature] ; wait for extruder temp G28 W ; home all without mesh bed level G80 ; mesh bed leveling G21 ; set units to millimeters ;go outside print area G1 Y-3.0 F1000.0 G1 Z0.4 F1000.0 ; select extruder ;Tc T0 ; purge line
I wrote some code to easily do an Tx, but with a specified parameter for the extruder ( E(n), n=0..4). Need to do some testing and then create a pull request for Prusa, but being able to then configure the replacements in your plugin would be REALLY nice. Hope you can do it. If so, I'd configure the commands as follows (assuming (n)=0..4 as the selected extruder in your popup menu):
Original | Replacement | timeout to | comment |
---|---|---|---|
Tx | Tx E(n) | Tx | I added this E(n) option to Tx in the code I am testing |
T? | T(n) | T? | |
Tc | Tc | with the Tx E(n) option, no replacement is required. |
With the "standard" non-customized software:
Original | Replacement | timeout to | comment |
---|---|---|---|
Tx | M701 E(n) | Tx | It just loads the filament, but only in the MMU, not to the extruder |
T? | T(n) | T? | |
Tc | Tc or T(n) | if Tx was replaced, the n goes here as well, no timeout! |
hope to hear from you! Good work!
So, finally i started to implement this changes. Now M701 E(n)
will be used followed by T(n)
instead of Tc
.
Can you explain a little bit more on T?
? I never saw/used this command. Is it a MMU1 command?
Yes, T? is a valid command MMU2 command. This used to be the only command to popup a menu and have the user select the filament. After that it would load the filament into the extruder. Many users found it a problem to wait all the time for the extruder to heat up before making the selection. They would start a print walk away and many hours later found it was still waiting for a filament selection to start printing, this is why Prusa introduced the Tc / Tx pair, so you could select the filament right away. I was interacting with Prusa on this change, long time ago.
As for Tc followed by En, I found that there is no way in the MMU to send an gcode to do the equivalent of Tc followed by filament selection, triggering the filament load to just before the extruder.
By adding one line to the firmware (indeed, only one), you can interpret an optional "E(n)" parameter after the Tx, avoiding the menu and loading the filament. If the user patches this firmware (or Prusa adopts the one line) AND you issue the Tx E(n) command you have the best option. Functionally the way it works now is also OK, it just doesn't load till the extruder, just selects the channel.
Hope all is clear, and thank for yor effort! From how I read your comment, the gcodes to replace are not configurable, is that correct?
So, i tested m701 En by followint Tn. I encountered the problem, that this will not load the filament to the nozzle. So ther comes no filament out during the initial purge. Also the skirt-line is missing for small prints and the filamnet starts to flow out the nozzle during first outer layer. This beaviour is repeatable.
On T?: If the user has to wait until printer is heated up, what would be your suggestion for implementation?
In my gcode profile, I print more material into the skirt-line. I thought it was due to the longer filament path in my BMG extruder, but it might also be influenced by the Tx loading versus T(n).
I investigated a bit more. When I load with M701 and T(n) the filament is 20-30mm away from the nozzle. So i have to insert gcode for an extra amount of extrusion after T(n). Otherwise the filament flow begins to late on small prints (bad first layer). But i'm not sure if i should inject this extra amount of extrusion by the plugin. If this happens only to me, it would be a bad solution.
I believe this also depends on whether you use a BMG or Prusa MK3S extruder I had to tune the "extra loading distance" in the MMU2 single extruder setup, to compensate for that difference. It influences the amount of overlap / gap you get in between your filament in the waste tower between filament changes. Probably the firmware puts an extra amount with the Tc to compensate in comparison to a T0..4 command.
This is why probably it is best to have the actual command to be used, to
be configurable. Then users can set the "move extruder" command after the
T0..4 (separated by a colon ":"), So Replacement string defined as "T
I haven't followed this whole thread, but just an extra datapoint:
I tried this plugin with my MMU2 and the latest prusaslicer default settings. Yep - when I try to select a filament via the plugin it painfully attempts cold loading and you can hear the gears grinding filament in the MMU.
This is different behavior than if I use the standard prompt on the printer, in that case the MMU does the right thing.
Yes, my experience as well, but there are many solutions for this.
Op di 10 dec. 2019 19:59 schreef Kevin Hester notifications@github.com:
I haven't followed this whole thread, but just an extra datapoint:
I tried this plugin with my MMU2 and the latest prusaslicer default settings. Yep - when I try to select a filament via the plugin it painfully attempts cold loading and you can hear the gears grinding filament in the MMU.
This is different behavior than if I use the standard prompt on the printer, in that case the MMU does the right thing.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/derpicknicker1/OctoPrint-Mmu2filamentselect/issues/2?email_source=notifications&email_token=ABGGYOFYWIIIKMPJSK554DDQX7RIVA5CNFSM4I54AQN2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGQLSLY#issuecomment-564181295, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABGGYOE5MVWBVAVAG764UVDQX7RIVANCNFSM4I54AQNQ .
Hello, i finally had time to come back here and to rethink the behaviour of the plugin. I think i have a solution now:
Tx
is thrown away, if the user selects a tool in the dialogM109
(heat extruder and wait)M109
is seen, the selected tool Tn
is injected after the M109In this way the extruder gets heated first and then the printer loads the filament. No cold load anymore. I tested it, and it works perfect. Maybe you want to try it. I pushed the code to development branch.
Excellent, well done,
I’d love to try it, but I am in lockdown in a different country from where my printer is. This will likely be until end of next month... so don’t hold your breath and stay safe ;-).
Pretty sure your approach work, but you have created a gcode dependency to the heating, rather then relying on the existing codes. Why not replace the Tc command, that is there in the normal Prusa profile?
Cheers Ruud
On Fri, 24 Apr 2020 at 22:52, derpicknicker1 notifications@github.com wrote:
Hello, i finally had time to come back here and to rethink the behaviour of the plugin. I think i have a solution now:
- The Tx is thrown away, if the user selects a tool in the dialog
- Then the plugin waits for M109 (heat extruder and wait)
- When M109 is seen, the selected tool Tn is injected after the M109
In this way the extruder gets heated first and then the printer loads the filament. No cold load anymore. I tested it, and it works perfect. Maybe you want to try it. I pushed the code to development branch.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/derpicknicker1/OctoPrint-Mmu2filamentselect/issues/2#issuecomment-619233658, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABGGYOA6VARGRXHEC4BH5N3ROH3ZXANCNFSM4I54AQNQ .
-- Ruud Rademaker prefered mail: ruud.rademaker@gmail.com
What would be the difference? The heating code would be always there, as the Tc would. But i can try this variant.
I agree that it is the same, if the heating is there, but heating in dictates heating, some people heat to a low temperature (to low to add filament) and then do bed calibration. The Tc is meant to indicate the point at which filament is loaded, so no misunderstanding on what it means. Some people might have an M104, then wait for the bed temperature to reach the temperature only and not issue an M109, which is wrong - i know - but it could work for them. If you load filament after a M109 heating command, it would not be obvious that filament would be loaded. It is e.g. not described with the GCODE that this is an effect to be expected. With Tc there is no misunderstanding on the effect. Well, that is my opinion at least.
Op za 25 apr. 2020 om 22:11 schreef derpicknicker1 <notifications@github.com
:
What would be the difference? The heating code would be always there, as the Tc would. But i can try this variant.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/derpicknicker1/OctoPrint-Mmu2filamentselect/issues/2#issuecomment-619434298, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABGGYOB2AKXAOH5WPOOLDC3ROM7YVANCNFSM4I54AQNQ .
-- Ruud Rademaker prefered mail: ruud.rademaker@gmail.com
Ok. I get your point. I will test it, and if it works like before (why shouldn't it?), i will publish an update.
Excellent stuff, no more running to the room where the printer is...
My standard GCODE has a Tx followed by commands to heat up (and wait for heating up) and a Tc to load.
The choice on octoprint in OctoPrint-Mmu2filamentselect forces the Tx command to be replaced by a command T0 to T4, depending on the choice. This results - for the normal sequence of commands - in an attempt to cold load filament into the extruder.
A better behavior would be to (assuming n = SelectedExtruder-1 (so 0..4), and (n) the value of n:
Replace the Tx by: M701 E(n) Replace Tc by: T(n)
Perhaps these could be best made configurable, so the expression for T? Tx, Tc would become: Tx = M701 E(n) timing out to Tx T? = T(n) timing out to T? Tc = T(n) or Tc (depending on Tx choice) no timeout
In order for Tc to work properly, the user selection must be explicitly RESET when a print is started, so that also requires a hook. Otherwise the selection from a previous print might be used. (Or if that is not desirable, the fact that Tx timed out should be kept, so Tc will subsequently be issued without translation)
I am aware that the behavior of M701 E(n) differs from Tx, in the sense that the filament is not only selected, but also loaded to just before the extruder, but I do not know the GCODE for doing a load to before the extruder... and preventing a cold load seems better.
In this manner the octoprint GCODE behaviour with and without the plugin is the most similar, pending a way to load to before the extruder...