Welcome to p2pp Discussions! #117
tomvandeneede
announced in
Announcements
Replies: 34 comments 25 replies
-
|
Hello, I have been 3d printing for a few years, and have experience of MMU2s, Palette 2 Pro and IDEX printers, G-Code customisation, scripting etc. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
if you cn get the printer work with PrusaSlicer send me a working file and I will have a look if there is anything to add
what specificaaly is different in term of GCODE wrt the IDEX printer
… On 7 Jan 2022, at 18:06, ukdavewood ***@***.***> wrote:
Hello, I have been 3d printing for a few years, and have experience of MMU2s, Palette 2 Pro and IDEX printers, G-Code customisation, scripting etc.
Haven't used my Palette for almost a year, so looking to get back into it. Am wondering in particular whether I can get the Palette 2 to work with an IDEX printer with perhaps some customisation of P2PP.
—
Reply to this email directly, view it on GitHub <#117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK6CHJMJ4GTDV2JT4YCVBFLUU4MRNANCNFSM5HPJHCYA>.
Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you authored the thread.
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
The IDEX printer has two extruders - and I am thinking I would like to setup the Palette2 on one of them, with the other one having the most common colour, or perhaps a different material (such as PETG for supporting PLA). Attached is the GCODE for a simple Demo rectangular model 20x10mm model, with 3 flat levels - 2mm high - the first and third being on physical extruder E0 and the middle one being on physical Extruder E1. The model is using a very small purge tower with sparse layers - with inter colour purging lengths of 15mm are working quite well for me - just to get the filament flowing nicely, and to deposit any stray stands of filament on the purge tower rather than the print, plus additionally I am purging 5 mm as part the tool change before the extruders get wiped and go off to the purge tower. Example G code file attached artistd 0.6 Dual BFT tower working v1-0.3 ArtistD.gcode.txt I can let you know the start, end and tool change G-Code settings I have setup too if required. I haven't tried P2PP yet - so probably my first step will be getting the palette connected up on one extruder on the IDEX printer first - to get familiar with how it works and what settings you need. I suspect I am going to have to tell Prusa Slicer I have got a single extruder Multi Material printer, with 5 rather than 4 extruders - and then have 1-4 allocated to the Palette connected to pE0, with 5 being allocated to pE1 on the printer. I guess if for example there is a sequence of E1x10mm, E2x10mm, E5x20mm, E2x10mm, E1x10mm - then the palette would only need to receive E1x10mm, E2x20mm, E1x10mm. i.e. The two E2s would need to be added together. Tool changing G-Code would also need to be customised to send different commands when switching between E5 and the other 4. I suspect this should be possible with some {if} statements. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
can you setup PS2.4 to work with 4 virtual and 2 real extruders (so 5 in total).
If that works I think I can make some modifications to take the alternative extruder out of the p2pp processing loop and get this working for you
where are you from? Maybe setting up a voice call may simplify comms
Tom
… On 7 Jan 2022, at 19:12, ukdavewood ***@***.***> wrote:
The IDEX printer has two extruders - and I am thinking I would like to setup the Palette2 on one of them, with the other one having the most common colour, or perhaps a different material (such as PETG for supporting PLA).
Attached is the GCODE for a simple Demo rectangular model 20x10mm model, with 3 flat levels - 2mm high - the first and third being on physical extruder E0 and the middle one being on physical Extruder E1.
The model is using a very small purge tower with sparse layers - with inter colour purging lengths of 15mm are working quite well for me - just to get the filament flowing nicely, and to deposit any stray stands of filament on the purge tower rather than the print, plus additionally I am purging 5 mm as part the tool change before the extruders get wiped and go off to the purge tower.
Example G code file attached
artistd 0.6 Dual BFT tower working v1-0.3 ArtistD.gcode.txt <https://github.com/tomvandeneede/p2pp/files/7830433/artistd.0.6.Dual.BFT.tower.working.v1-0.3.ArtistD.gcode.txt>
I can let you know the start, end and tool change G-Code settings I have setup too if required.
I haven't tried P2PP yet - so probably my first step will be getting the palette connected up on one extruder on the IDEX printer first - to get familiar with how it works and what settings you need.
I suspect I am going to have to tell Prusa Slicer I have got a single extruder Multi Material printer, with 5 rather than 4 extruders - and then have 1-4 allocated to the Palette connected to pE0, with 5 being allocated to pE1 on the printer.
The length of the filament going to Extruder5(pE1) would then need to be ignored by P2PP and any tool changes to E5 would not need to be passed to the Palette by P2PP.
I guess if for example there is a sequence of E1x10mm, E2x10mm, E5x20mm, E2x10mm, E1x10mm - then the palette would only need to receive E1x10mm, E2x20mm, E1x10mm. i.e. The two E2s would need to be added together.
Tool changing G-Code would also need to be customised to send different commands when switching between E5 and the other 4. I suspect this should be possible with some {if} statements.
I am guessing P2PP probably doesn't currently need any specific G Code in the tool changing - other than perhaps some delays for the palette to use for its pinging etc.
—
Reply to this email directly, view it on GitHub <#117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK6CHJJU4WU7DP5VU4O5MKTUU4UHLANCNFSM5HPJHCYA>.
Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you authored the thread.
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Thanks, I'm from the UK, so not too big a time difference to contend with and I would be happy to do a voice call. I think what I will do is first literally dust off the Palette - which is a 2 pro (I have the s upgrade kit too but haven't installed it yet). Whilst I like the idea of multi colour and multi material, in practice however apps: I have only used the palette a few times probably over 9 months ago, attached to a Prusa Mk3s, using Canvas, and a Raspberry Pi 3b based Canvas hub. I really liked it apart from the noise, and the time it takes to do each filament change. This was in place of an earlier MMU2s - which I disconnected due mainly to the unreliability, mess and also the practicalities of having to buffer the filament due to the long retractions. In the meantime I have been experimenting with IDEX printers, which are working pretty well for all of my two material/colour requirements using mainly PrusaSlicer, but I would like to get the Palette working again for my less common 3-5 filament requirements. Also, whilst the IDEX filament switch overs are much quicker and efficient than when using the palette, they are a fair bit more messy due to the purging and wiping prior to moving over to the purge block. Mosaic have said a couple of times that they may add IDEX printer support to the P2 - and I think the combination of a Palette, plus IDEX (or Tool changer)+Palette is probably the ultimate setup in terms of efficiency of filament switch over, reduced wastage, multi material, plus number of different colours available - but so far they don't seem to have progressed it, and I presume won't now on the P2 - due to the launch of the P3. I think however that P2PP may well end up being a better solution for me. I think the best first steps for me over the next few days are:
Additional later requirements I was thinking P2PP (or a separate post processed G Code script, or maybe a new Octoprint plugin) might be able to help me with are:
Option a. is the quickest and simplest - but I don't like the idea of an extruder sitting there cooking the filament for potentially hours if the filament changes are quite rare, so I only tend to use this for small prints. What I would to do ideally is to create a variation of option b, where some sort of post processing script that:
Dave Wood |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Maybe it is best to transfer this conversation to email ***@***.*** ***@***.***>)
Once you established a workflow we need to check how we can get the second extruder singled out (if possible automatically) so that code is printed without impact to the p2 code. It is a matter of just not accounting for that filament, but there are some pitfalls….
* the second physical extruder will be in-between 2 splices so there needs to be a way to make sure sufficient purge is applied during the print
* extra temp control needs to be maintained
* I really hope Prusaslicer allows for the combination of a Physical dual and then virtual multiple extruder, if not the second physical will needs to be added as another virtual (which is good because it will solve the point 1 solution (though you will purge more) BUT all code for the second extruder will need to be offset… not too difficult though…
* I assume some things like sidewipe etc will need to get a closer look, not impossible but tricky with the offsets
lots of stuff to think about
regards
Tom
… On 8 Jan 2022, at 06:41, ukdavewood ***@***.***> wrote:
Thanks, I'm from the UK, so not too big a time difference to contend with and I would be happy to do a voice call.
I think what I will do is first literally dust off the Palette - which is a 2 pro (I have the s upgrade kit too but haven't installed it yet).
Whilst I like the idea of multi colour and multi material, in practice however apps:
-70% of my prints are single colour no support.
-10% are only 2 colours (for text and logos etc),
-10% are only 2 material - either for PETG supports for PLA for example, or for TPU bonded into PLA or PETG.
-only about 10% needing more than 2 colours or materials, and therefore requiring the Palette2.
I have only used the palette a few times probably over 9 months ago, attached to a Prusa Mk3s, using Canvas, and a Raspberry Pi 3b based Canvas hub. I really liked it apart from the noise, and the time it takes to do each filament change.
This was in place of an earlier MMU2s - which I disconnected due mainly to the unreliability, mess and also the practicalities of having to buffer the filament due to the long retractions.
In the meantime I have been experimenting with IDEX printers, which are working pretty well for all of my two material/colour requirements using mainly PrusaSlicer, but I would like to get the Palette working again for my less common 3-5 filament requirements. Also, whilst the IDEX filament switch overs are much quicker and efficient than when using the palette, they are a fair bit more messy due to the purging and wiping prior to moving over to the purge block.
Mosaic have said a couple of times that they may add IDEX printer support to the P2 - and I think the combination of a Palette, plus IDEX (or Tool changer)+Palette is probably the ultimate setup in terms of efficiency of filament switch over, reduced wastage, multi material, plus number of different colours available - but so far they don't seem to have progressed it, and I presume won't now on the P2 - due to the launch of the P3.
I think however that P2PP may well end up being a better solution for me.
I think the best first steps for me over the next few days are:
Get the Palette physically connected up to the IDEX printer (a JGMaker ArtistD, with 0.6mm nozzles) - probably using Canvas initially to work out the best location for the Palette in relation to the printer, plus to get a suitably modelled extruder pipe connector working. One complication is the fact that I am thinking it may be most practical for me in terms of filament reel management to mount the Palette upside down.
Switch the Palette over to P2PP to get used to how it works on a single physical extruder.
Then once I have everything working ok, hopefully in the next couple of days, I would then like to try getting a 4 Virtual, 2 Physical extruder setup working, with your help if you are willing.
Additional later requirements I was thinking P2PP (or a separate post processed G Code script, or maybe a new Octoprint plugin) might be able to help me with are:
Temperature management of the idle extruder - at present with PrusaSlicer you seem to have two options - either
a. Keep both extruders at full temperature the whole print
b. Let the idle extruder drop down in temperature a bit when it goes idle, but you then have to wait for it to heat up again before you can start using it again - which easily doubles the tool change switch over time.
Option a. is the quickest and simplest - but I don't like the idea of an extruder sitting there cooking the filament for potentially hours if the filament changes are quite rare, so I only tend to use this for small prints.
Option b. works pretty well, but it is a fair bit slower as the heating back up takes a while, plus also it then takes a while longer for the printer to be happy that the temperature is stable before continuing with the print.
What I would to do ideally is to create a variation of option b, where some sort of post processing script that:
a. Detects short duration filament switches and strips out the cool down/reheating G-Code.
b. For longer duration or less frequent filament switches, inserts some pre-heat G-Code a few seconds ahead of the tool change heat up G-Code to remove most of the heat up delay.
Seeing if there is a way to detect and ideally recover from failed Palette 2 splices.
Better noise management for the Palette 2 - ideally switching off some of the fans when they are not needed.
Auto loading of filament from the Palette 2 into the printer at print start, as that is one of the nicest features of the MMU2s, and could be pretty useful even for single colour prints.
Dave Wood
—
Reply to this email directly, view it on GitHub <#117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK6CHJMYIWXHX57CNT3JLJTUU7FBVANCNFSM5HPJHCYA>.
Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you authored the thread.
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Tom - Have made some very good progress I think
1. Got Palette 2pro working ok with Canvas on one extruder of the IDEX printer - did the normal keyring, plus a 4 colour stacked model. Also got Octoprint/Canvas both working
2. Got P2PP installed ok on a Mac - a bit tricky with permissions, then do all of the configuration and got the same 4 colour stack model printing ok. Nice to see that the purge block was a fair bit smaller than the Canvas version.
Overall very impresses with P2PP and will definitely use it for all of my Palette printing.
3. Increased extruders up to 5 virtual - there doesn't seem to be a way to specify 4 virtual and 2 physical in prusa slicer.
Decided to allocate the 5th virtual (T4) as the 2nd Physical extruder (E2/T1)
Decided to then see if I could write a couple of python scripts to wrap around P2PP.
Script 1 - IDEX_pre - based on some Tags in the TOOL change GCODE, goes through the file commenting out all GCODE relating to T4,
P2PP - P2PP then processes the altered GCODE - never getting to know about T4 - and seems to work pretty well, including when for example the GCODE goes T0, T4, T0 - it just processes it as one lot of T0.
Script 2 - IDEX_post This takes the output of P2PP - and then removes the comments on the front of the T4 GCODE (apart from the T4 line - which doesn't exist on the physical printer).
Also as a by product of the Tool change Code which puts in commented out T0 and T1 - these get introduced too.
Ran a few test prints
The first failed with ping errors - I am assuming that this was due to the whole T0-T3 filament length being less than the length of the output tube
The second print worked - but there seem to be some sort of Z height problem as the 2nd Physical extruder printed a little bit high
The 3rd print was better - I reduced the Lift Z values down from 0.6 and 0.06 - As I think this may be the problem,
But the 3rd print is still not perfect between I think E2 on the wipe tower is still printing a little bit higher than E1.
Not sure though if pinging is working as I expect the palette will be wondering what is going on when E2 is printing
Have attached a few files and the scripts, in a separate email incase you are interested / would consider as discussed incorporating the logic from the two scripts into P2PP - perhaps in a more generic way than I have done.
Will in the meantime continue investigating, in particular whether there is a problem with the Z height when the printer transitions between Palette and Physical 2nd Extruder.
Also will try some longer prints to see whether the Palette manages to get some decent pings.
Dave Wood
… On 8 Jan 2022, at 07:58, Tom Van den Eede ***@***.***> wrote:
Maybe it is best to transfer this conversation to email ***@***.*** ***@***.***>)
Once you established a workflow we need to check how we can get the second extruder singled out (if possible automatically) so that code is printed without impact to the p2 code. It is a matter of just not accounting for that filament, but there are some pitfalls….
* the second physical extruder will be in-between 2 splices so there needs to be a way to make sure sufficient purge is applied during the print
* extra temp control needs to be maintained
* I really hope Prusaslicer allows for the combination of a Physical dual and then virtual multiple extruder, if not the second physical will needs to be added as another virtual (which is good because it will solve the point 1 solution (though you will purge more) BUT all code for the second extruder will need to be offset… not too difficult though…
* I assume some things like sidewipe etc will need to get a closer look, not impossible but tricky with the offsets
lots of stuff to think about
regards
Tom
> On 8 Jan 2022, at 06:41, ukdavewood ***@***.***> wrote:
>
>
> Thanks, I'm from the UK, so not too big a time difference to contend with and I would be happy to do a voice call.
>
> I think what I will do is first literally dust off the Palette - which is a 2 pro (I have the s upgrade kit too but haven't installed it yet).
>
> Whilst I like the idea of multi colour and multi material, in practice however apps:
> -70% of my prints are single colour no support.
> -10% are only 2 colours (for text and logos etc),
> -10% are only 2 material - either for PETG supports for PLA for example, or for TPU bonded into PLA or PETG.
> -only about 10% needing more than 2 colours or materials, and therefore requiring the Palette2.
>
> I have only used the palette a few times probably over 9 months ago, attached to a Prusa Mk3s, using Canvas, and a Raspberry Pi 3b based Canvas hub. I really liked it apart from the noise, and the time it takes to do each filament change.
>
> This was in place of an earlier MMU2s - which I disconnected due mainly to the unreliability, mess and also the practicalities of having to buffer the filament due to the long retractions.
>
> In the meantime I have been experimenting with IDEX printers, which are working pretty well for all of my two material/colour requirements using mainly PrusaSlicer, but I would like to get the Palette working again for my less common 3-5 filament requirements. Also, whilst the IDEX filament switch overs are much quicker and efficient than when using the palette, they are a fair bit more messy due to the purging and wiping prior to moving over to the purge block.
>
> Mosaic have said a couple of times that they may add IDEX printer support to the P2 - and I think the combination of a Palette, plus IDEX (or Tool changer)+Palette is probably the ultimate setup in terms of efficiency of filament switch over, reduced wastage, multi material, plus number of different colours available - but so far they don't seem to have progressed it, and I presume won't now on the P2 - due to the launch of the P3.
>
> I think however that P2PP may well end up being a better solution for me.
>
> I think the best first steps for me over the next few days are:
>
> Get the Palette physically connected up to the IDEX printer (a JGMaker ArtistD, with 0.6mm nozzles) - probably using Canvas initially to work out the best location for the Palette in relation to the printer, plus to get a suitably modelled extruder pipe connector working. One complication is the fact that I am thinking it may be most practical for me in terms of filament reel management to mount the Palette upside down.
>
> Switch the Palette over to P2PP to get used to how it works on a single physical extruder.
>
> Then once I have everything working ok, hopefully in the next couple of days, I would then like to try getting a 4 Virtual, 2 Physical extruder setup working, with your help if you are willing.
>
> Additional later requirements I was thinking P2PP (or a separate post processed G Code script, or maybe a new Octoprint plugin) might be able to help me with are:
>
> Temperature management of the idle extruder - at present with PrusaSlicer you seem to have two options - either
> a. Keep both extruders at full temperature the whole print
> b. Let the idle extruder drop down in temperature a bit when it goes idle, but you then have to wait for it to heat up again before you can start using it again - which easily doubles the tool change switch over time.
> Option a. is the quickest and simplest - but I don't like the idea of an extruder sitting there cooking the filament for potentially hours if the filament changes are quite rare, so I only tend to use this for small prints.
> Option b. works pretty well, but it is a fair bit slower as the heating back up takes a while, plus also it then takes a while longer for the printer to be happy that the temperature is stable before continuing with the print.
>
> What I would to do ideally is to create a variation of option b, where some sort of post processing script that:
> a. Detects short duration filament switches and strips out the cool down/reheating G-Code.
> b. For longer duration or less frequent filament switches, inserts some pre-heat G-Code a few seconds ahead of the tool change heat up G-Code to remove most of the heat up delay.
>
> Seeing if there is a way to detect and ideally recover from failed Palette 2 splices.
>
> Better noise management for the Palette 2 - ideally switching off some of the fans when they are not needed.
>
> Auto loading of filament from the Palette 2 into the printer at print start, as that is one of the nicest features of the MMU2s, and could be pretty useful even for single colour prints.
>
> Dave Wood
>
> —
> Reply to this email directly, view it on GitHub <#117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK6CHJMYIWXHX57CNT3JLJTUU7FBVANCNFSM5HPJHCYA>.
> Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
> You are receiving this because you authored the thread.
>
—
Reply to this email directly, view it on GitHub <#117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/API2M74XT25U5PYLOKG5OPDUU7VCVANCNFSM5HPJHCYA>.
Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you commented.
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Tom - Files as mentioned in other email
Dave Wood
… On 8 Jan 2022, at 07:58, Tom Van den Eede ***@***.***> wrote:
Maybe it is best to transfer this conversation to email ***@***.*** ***@***.***>)
Once you established a workflow we need to check how we can get the second extruder singled out (if possible automatically) so that code is printed without impact to the p2 code. It is a matter of just not accounting for that filament, but there are some pitfalls….
* the second physical extruder will be in-between 2 splices so there needs to be a way to make sure sufficient purge is applied during the print
* extra temp control needs to be maintained
* I really hope Prusaslicer allows for the combination of a Physical dual and then virtual multiple extruder, if not the second physical will needs to be added as another virtual (which is good because it will solve the point 1 solution (though you will purge more) BUT all code for the second extruder will need to be offset… not too difficult though…
* I assume some things like sidewipe etc will need to get a closer look, not impossible but tricky with the offsets
lots of stuff to think about
regards
Tom
> On 8 Jan 2022, at 06:41, ukdavewood ***@***.***> wrote:
>
>
> Thanks, I'm from the UK, so not too big a time difference to contend with and I would be happy to do a voice call.
>
> I think what I will do is first literally dust off the Palette - which is a 2 pro (I have the s upgrade kit too but haven't installed it yet).
>
> Whilst I like the idea of multi colour and multi material, in practice however apps:
> -70% of my prints are single colour no support.
> -10% are only 2 colours (for text and logos etc),
> -10% are only 2 material - either for PETG supports for PLA for example, or for TPU bonded into PLA or PETG.
> -only about 10% needing more than 2 colours or materials, and therefore requiring the Palette2.
>
> I have only used the palette a few times probably over 9 months ago, attached to a Prusa Mk3s, using Canvas, and a Raspberry Pi 3b based Canvas hub. I really liked it apart from the noise, and the time it takes to do each filament change.
>
> This was in place of an earlier MMU2s - which I disconnected due mainly to the unreliability, mess and also the practicalities of having to buffer the filament due to the long retractions.
>
> In the meantime I have been experimenting with IDEX printers, which are working pretty well for all of my two material/colour requirements using mainly PrusaSlicer, but I would like to get the Palette working again for my less common 3-5 filament requirements. Also, whilst the IDEX filament switch overs are much quicker and efficient than when using the palette, they are a fair bit more messy due to the purging and wiping prior to moving over to the purge block.
>
> Mosaic have said a couple of times that they may add IDEX printer support to the P2 - and I think the combination of a Palette, plus IDEX (or Tool changer)+Palette is probably the ultimate setup in terms of efficiency of filament switch over, reduced wastage, multi material, plus number of different colours available - but so far they don't seem to have progressed it, and I presume won't now on the P2 - due to the launch of the P3.
>
> I think however that P2PP may well end up being a better solution for me.
>
> I think the best first steps for me over the next few days are:
>
> Get the Palette physically connected up to the IDEX printer (a JGMaker ArtistD, with 0.6mm nozzles) - probably using Canvas initially to work out the best location for the Palette in relation to the printer, plus to get a suitably modelled extruder pipe connector working. One complication is the fact that I am thinking it may be most practical for me in terms of filament reel management to mount the Palette upside down.
>
> Switch the Palette over to P2PP to get used to how it works on a single physical extruder.
>
> Then once I have everything working ok, hopefully in the next couple of days, I would then like to try getting a 4 Virtual, 2 Physical extruder setup working, with your help if you are willing.
>
> Additional later requirements I was thinking P2PP (or a separate post processed G Code script, or maybe a new Octoprint plugin) might be able to help me with are:
>
> Temperature management of the idle extruder - at present with PrusaSlicer you seem to have two options - either
> a. Keep both extruders at full temperature the whole print
> b. Let the idle extruder drop down in temperature a bit when it goes idle, but you then have to wait for it to heat up again before you can start using it again - which easily doubles the tool change switch over time.
> Option a. is the quickest and simplest - but I don't like the idea of an extruder sitting there cooking the filament for potentially hours if the filament changes are quite rare, so I only tend to use this for small prints.
> Option b. works pretty well, but it is a fair bit slower as the heating back up takes a while, plus also it then takes a while longer for the printer to be happy that the temperature is stable before continuing with the print.
>
> What I would to do ideally is to create a variation of option b, where some sort of post processing script that:
> a. Detects short duration filament switches and strips out the cool down/reheating G-Code.
> b. For longer duration or less frequent filament switches, inserts some pre-heat G-Code a few seconds ahead of the tool change heat up G-Code to remove most of the heat up delay.
>
> Seeing if there is a way to detect and ideally recover from failed Palette 2 splices.
>
> Better noise management for the Palette 2 - ideally switching off some of the fans when they are not needed.
>
> Auto loading of filament from the Palette 2 into the printer at print start, as that is one of the nicest features of the MMU2s, and could be pretty useful even for single colour prints.
>
> Dave Wood
>
> —
> Reply to this email directly, view it on GitHub <#117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK6CHJMYIWXHX57CNT3JLJTUU7FBVANCNFSM5HPJHCYA>.
> Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
> You are receiving this because you authored the thread.
>
—
Reply to this email directly, view it on GitHub <#117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/API2M74XT25U5PYLOKG5OPDUU7VCVANCNFSM5HPJHCYA>.
Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you commented.
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Bit afraid though that the pre-post processing will throw the calculations for the P2/3 off
in theory the approach looks good and can be easily implemented in P2PP itself, the toolchange codes might not process correctly.
the Z-height might be related to this. reducing the Z-Hop is definitly not the right solution - it should work for any. 0.06 basically is still too high… this defitely requires some deeper looking into… I suspect this is due to part of the toolchange code going to oblivion
… On 9 Jan 2022, at 18:00, ukdavewood ***@***.***> wrote:
Tom - Have made some very good progress I think
1. Got Palette 2pro working ok with Canvas on one extruder of the IDEX printer - did the normal keyring, plus a 4 colour stacked model. Also got Octoprint/Canvas both working
2. Got P2PP installed ok on a Mac - a bit tricky with permissions, then do all of the configuration and got the same 4 colour stack model printing ok. Nice to see that the purge block was a fair bit smaller than the Canvas version.
Overall very impresses with P2PP and will definitely use it for all of my Palette printing.
3. Increased extruders up to 5 virtual - there doesn't seem to be a way to specify 4 virtual and 2 physical in prusa slicer.
Decided to allocate the 5th virtual (T4) as the 2nd Physical extruder (E2/T1)
Decided to then see if I could write a couple of python scripts to wrap around P2PP.
Script 1 - IDEX_pre - based on some Tags in the TOOL change GCODE, goes through the file commenting out all GCODE relating to T4,
P2PP - P2PP then processes the altered GCODE - never getting to know about T4 - and seems to work pretty well, including when for example the GCODE goes T0, T4, T0 - it just processes it as one lot of T0.
Script 2 - IDEX_post This takes the output of P2PP - and then removes the comments on the front of the T4 GCODE (apart from the T4 line - which doesn't exist on the physical printer).
Also as a by product of the Tool change Code which puts in commented out T0 and T1 - these get introduced too.
Ran a few test prints
The first failed with ping errors - I am assuming that this was due to the whole T0-T3 filament length being less than the length of the output tube
The second print worked - but there seem to be some sort of Z height problem as the 2nd Physical extruder printed a little bit high
The 3rd print was better - I reduced the Lift Z values down from 0.6 and 0.06 - As I think this may be the problem,
But the 3rd print is still not perfect between I think E2 on the wipe tower is still printing a little bit higher than E1.
Not sure though if pinging is working as I expect the palette will be wondering what is going on when E2 is printing
Have attached a few files and the scripts, in a separate email incase you are interested / would consider as discussed incorporating the logic from the two scripts into P2PP - perhaps in a more generic way than I have done.
Will in the meantime continue investigating, in particular whether there is a problem with the Z height when the printer transitions between Palette and Physical 2nd Extruder.
Also will try some longer prints to see whether the Palette manages to get some decent pings.
Dave Wood
> On 8 Jan 2022, at 07:58, Tom Van den Eede ***@***.***> wrote:
>
>
> Maybe it is best to transfer this conversation to email ***@***.*** ***@***.***>)
>
> Once you established a workflow we need to check how we can get the second extruder singled out (if possible automatically) so that code is printed without impact to the p2 code. It is a matter of just not accounting for that filament, but there are some pitfalls….
>
> * the second physical extruder will be in-between 2 splices so there needs to be a way to make sure sufficient purge is applied during the print
> * extra temp control needs to be maintained
> * I really hope Prusaslicer allows for the combination of a Physical dual and then virtual multiple extruder, if not the second physical will needs to be added as another virtual (which is good because it will solve the point 1 solution (though you will purge more) BUT all code for the second extruder will need to be offset… not too difficult though…
> * I assume some things like sidewipe etc will need to get a closer look, not impossible but tricky with the offsets
>
> lots of stuff to think about
>
> regards
> Tom
>
> > On 8 Jan 2022, at 06:41, ukdavewood ***@***.***> wrote:
> >
> >
> > Thanks, I'm from the UK, so not too big a time difference to contend with and I would be happy to do a voice call.
> >
> > I think what I will do is first literally dust off the Palette - which is a 2 pro (I have the s upgrade kit too but haven't installed it yet).
> >
> > Whilst I like the idea of multi colour and multi material, in practice however apps:
> > -70% of my prints are single colour no support.
> > -10% are only 2 colours (for text and logos etc),
> > -10% are only 2 material - either for PETG supports for PLA for example, or for TPU bonded into PLA or PETG.
> > -only about 10% needing more than 2 colours or materials, and therefore requiring the Palette2.
> >
> > I have only used the palette a few times probably over 9 months ago, attached to a Prusa Mk3s, using Canvas, and a Raspberry Pi 3b based Canvas hub. I really liked it apart from the noise, and the time it takes to do each filament change.
> >
> > This was in place of an earlier MMU2s - which I disconnected due mainly to the unreliability, mess and also the practicalities of having to buffer the filament due to the long retractions.
> >
> > In the meantime I have been experimenting with IDEX printers, which are working pretty well for all of my two material/colour requirements using mainly PrusaSlicer, but I would like to get the Palette working again for my less common 3-5 filament requirements. Also, whilst the IDEX filament switch overs are much quicker and efficient than when using the palette, they are a fair bit more messy due to the purging and wiping prior to moving over to the purge block.
> >
> > Mosaic have said a couple of times that they may add IDEX printer support to the P2 - and I think the combination of a Palette, plus IDEX (or Tool changer)+Palette is probably the ultimate setup in terms of efficiency of filament switch over, reduced wastage, multi material, plus number of different colours available - but so far they don't seem to have progressed it, and I presume won't now on the P2 - due to the launch of the P3.
> >
> > I think however that P2PP may well end up being a better solution for me.
> >
> > I think the best first steps for me over the next few days are:
> >
> > Get the Palette physically connected up to the IDEX printer (a JGMaker ArtistD, with 0.6mm nozzles) - probably using Canvas initially to work out the best location for the Palette in relation to the printer, plus to get a suitably modelled extruder pipe connector working. One complication is the fact that I am thinking it may be most practical for me in terms of filament reel management to mount the Palette upside down.
> >
> > Switch the Palette over to P2PP to get used to how it works on a single physical extruder.
> >
> > Then once I have everything working ok, hopefully in the next couple of days, I would then like to try getting a 4 Virtual, 2 Physical extruder setup working, with your help if you are willing.
> >
> > Additional later requirements I was thinking P2PP (or a separate post processed G Code script, or maybe a new Octoprint plugin) might be able to help me with are:
> >
> > Temperature management of the idle extruder - at present with PrusaSlicer you seem to have two options - either
> > a. Keep both extruders at full temperature the whole print
> > b. Let the idle extruder drop down in temperature a bit when it goes idle, but you then have to wait for it to heat up again before you can start using it again - which easily doubles the tool change switch over time.
> > Option a. is the quickest and simplest - but I don't like the idea of an extruder sitting there cooking the filament for potentially hours if the filament changes are quite rare, so I only tend to use this for small prints.
> > Option b. works pretty well, but it is a fair bit slower as the heating back up takes a while, plus also it then takes a while longer for the printer to be happy that the temperature is stable before continuing with the print.
> >
> > What I would to do ideally is to create a variation of option b, where some sort of post processing script that:
> > a. Detects short duration filament switches and strips out the cool down/reheating G-Code.
> > b. For longer duration or less frequent filament switches, inserts some pre-heat G-Code a few seconds ahead of the tool change heat up G-Code to remove most of the heat up delay.
> >
> > Seeing if there is a way to detect and ideally recover from failed Palette 2 splices.
> >
> > Better noise management for the Palette 2 - ideally switching off some of the fans when they are not needed.
> >
> > Auto loading of filament from the Palette 2 into the printer at print start, as that is one of the nicest features of the MMU2s, and could be pretty useful even for single colour prints.
> >
> > Dave Wood
> >
> > —
> > Reply to this email directly, view it on GitHub <#117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK6CHJMYIWXHX57CNT3JLJTUU7FBVANCNFSM5HPJHCYA>.
> > Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
> > You are receiving this because you authored the thread.
> >
>
> —
> Reply to this email directly, view it on GitHub <#117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/API2M74XT25U5PYLOKG5OPDUU7VCVANCNFSM5HPJHCYA>.
> Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
> You are receiving this because you commented.
>
—
Reply to this email directly, view it on GitHub <#117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK6CHJILUGCKB7Q5I4ZT5VDUVG5JVANCNFSM5HPJHCYA>.
Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you authored the thread.
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Tom,
thanks for replying. I have been working further on the Z Issue.
It does seem to relate the P2PP Z height adjustment stuff and hops etc,.
I think I have found a way of working around it without needing to set the hops really low - by making some adjustments to the two scripts - to allow P2PP to see the G1 Z lines in the ignored sections, which I can share if you want.
Next problem I am working on is sparse layer wipe towers.
For some reason prusasllicer seems to ignore the first layer height and just use the normal layer height when working out a what Z height to place the wipe tower layers - this seems to be irrespective of whether P2PP is in place.
I think this must just be a feature unless it is a result of one of the settings I can't find.
First layer heights seem to be fine for normal wipe towers.
So I am currently working on another script to adjust sparse wipe tower layer heights down a bit in the sparse wipe tower.
I notice you seem to have some wipe tower generation stuff in P2PP which I will probably investigate too - as maybe your delta tower has already sorted this issue.
One thing I am particularly interested in whether the P2PP tower generation code could help with is eliminating is unnecessary purging.
i.e. If. T0-T3 are the Palette2, and T4 is my second extruder - then in the following sequence:
T0, T4, T1 - then there will need to do normal purging between T0 and T1 - as they will both be coming from the Palette. However PrusaSlicer will use the T0-T4. And T4-T1 values when working out how much material to create, which isn't necessarily a big issue, but it would be nice if correct T0-T1 values could be used,
However a bigger problem is the sequence is T0, T4, T0 - then in this case you won't need any purging to happen between T0 and T0 - as they are both the same colour, However the T0-T4 sequence and T4-T0 sequence cause prusaslicer to generate a fair bit of unnecessary purge material.
Dave Wood
… On 10 Jan 2022, at 11:22, Tom Van den Eede ***@***.***> wrote:
Bit afraid though that the pre-post processing will throw the calculations for the P2/3 off
in theory the approach looks good and can be easily implemented in P2PP itself, the toolchange codes might not process correctly.
the Z-height might be related to this. reducing the Z-Hop is definitly not the right solution - it should work for any. 0.06 basically is still too high… this defitely requires some deeper looking into… I suspect this is due to part of the toolchange code going to oblivion
> On 9 Jan 2022, at 18:00, ukdavewood ***@***.***> wrote:
>
>
> Tom - Have made some very good progress I think
>
> 1. Got Palette 2pro working ok with Canvas on one extruder of the IDEX printer - did the normal keyring, plus a 4 colour stacked model. Also got Octoprint/Canvas both working
> 2. Got P2PP installed ok on a Mac - a bit tricky with permissions, then do all of the configuration and got the same 4 colour stack model printing ok. Nice to see that the purge block was a fair bit smaller than the Canvas version.
> Overall very impresses with P2PP and will definitely use it for all of my Palette printing.
> 3. Increased extruders up to 5 virtual - there doesn't seem to be a way to specify 4 virtual and 2 physical in prusa slicer.
>
> Decided to allocate the 5th virtual (T4) as the 2nd Physical extruder (E2/T1)
>
> Decided to then see if I could write a couple of python scripts to wrap around P2PP.
> Script 1 - IDEX_pre - based on some Tags in the TOOL change GCODE, goes through the file commenting out all GCODE relating to T4,
> P2PP - P2PP then processes the altered GCODE - never getting to know about T4 - and seems to work pretty well, including when for example the GCODE goes T0, T4, T0 - it just processes it as one lot of T0.
> Script 2 - IDEX_post This takes the output of P2PP - and then removes the comments on the front of the T4 GCODE (apart from the T4 line - which doesn't exist on the physical printer).
> Also as a by product of the Tool change Code which puts in commented out T0 and T1 - these get introduced too.
>
> Ran a few test prints
>
> The first failed with ping errors - I am assuming that this was due to the whole T0-T3 filament length being less than the length of the output tube
> The second print worked - but there seem to be some sort of Z height problem as the 2nd Physical extruder printed a little bit high
> The 3rd print was better - I reduced the Lift Z values down from 0.6 and 0.06 - As I think this may be the problem,
> But the 3rd print is still not perfect between I think E2 on the wipe tower is still printing a little bit higher than E1.
>
> Not sure though if pinging is working as I expect the palette will be wondering what is going on when E2 is printing
>
> Have attached a few files and the scripts, in a separate email incase you are interested / would consider as discussed incorporating the logic from the two scripts into P2PP - perhaps in a more generic way than I have done.
>
> Will in the meantime continue investigating, in particular whether there is a problem with the Z height when the printer transitions between Palette and Physical 2nd Extruder.
> Also will try some longer prints to see whether the Palette manages to get some decent pings.
>
>
>
> Dave Wood
>
>
>
>
>
> > On 8 Jan 2022, at 07:58, Tom Van den Eede ***@***.***> wrote:
> >
> >
> > Maybe it is best to transfer this conversation to email ***@***.*** ***@***.***>)
> >
> > Once you established a workflow we need to check how we can get the second extruder singled out (if possible automatically) so that code is printed without impact to the p2 code. It is a matter of just not accounting for that filament, but there are some pitfalls….
> >
> > * the second physical extruder will be in-between 2 splices so there needs to be a way to make sure sufficient purge is applied during the print
> > * extra temp control needs to be maintained
> > * I really hope Prusaslicer allows for the combination of a Physical dual and then virtual multiple extruder, if not the second physical will needs to be added as another virtual (which is good because it will solve the point 1 solution (though you will purge more) BUT all code for the second extruder will need to be offset… not too difficult though…
> > * I assume some things like sidewipe etc will need to get a closer look, not impossible but tricky with the offsets
> >
> > lots of stuff to think about
> >
> > regards
> > Tom
> >
> > > On 8 Jan 2022, at 06:41, ukdavewood ***@***.***> wrote:
> > >
> > >
> > > Thanks, I'm from the UK, so not too big a time difference to contend with and I would be happy to do a voice call.
> > >
> > > I think what I will do is first literally dust off the Palette - which is a 2 pro (I have the s upgrade kit too but haven't installed it yet).
> > >
> > > Whilst I like the idea of multi colour and multi material, in practice however apps:
> > > -70% of my prints are single colour no support.
> > > -10% are only 2 colours (for text and logos etc),
> > > -10% are only 2 material - either for PETG supports for PLA for example, or for TPU bonded into PLA or PETG.
> > > -only about 10% needing more than 2 colours or materials, and therefore requiring the Palette2.
> > >
> > > I have only used the palette a few times probably over 9 months ago, attached to a Prusa Mk3s, using Canvas, and a Raspberry Pi 3b based Canvas hub. I really liked it apart from the noise, and the time it takes to do each filament change.
> > >
> > > This was in place of an earlier MMU2s - which I disconnected due mainly to the unreliability, mess and also the practicalities of having to buffer the filament due to the long retractions.
> > >
> > > In the meantime I have been experimenting with IDEX printers, which are working pretty well for all of my two material/colour requirements using mainly PrusaSlicer, but I would like to get the Palette working again for my less common 3-5 filament requirements. Also, whilst the IDEX filament switch overs are much quicker and efficient than when using the palette, they are a fair bit more messy due to the purging and wiping prior to moving over to the purge block.
> > >
> > > Mosaic have said a couple of times that they may add IDEX printer support to the P2 - and I think the combination of a Palette, plus IDEX (or Tool changer)+Palette is probably the ultimate setup in terms of efficiency of filament switch over, reduced wastage, multi material, plus number of different colours available - but so far they don't seem to have progressed it, and I presume won't now on the P2 - due to the launch of the P3.
> > >
> > > I think however that P2PP may well end up being a better solution for me.
> > >
> > > I think the best first steps for me over the next few days are:
> > >
> > > Get the Palette physically connected up to the IDEX printer (a JGMaker ArtistD, with 0.6mm nozzles) - probably using Canvas initially to work out the best location for the Palette in relation to the printer, plus to get a suitably modelled extruder pipe connector working. One complication is the fact that I am thinking it may be most practical for me in terms of filament reel management to mount the Palette upside down.
> > >
> > > Switch the Palette over to P2PP to get used to how it works on a single physical extruder.
> > >
> > > Then once I have everything working ok, hopefully in the next couple of days, I would then like to try getting a 4 Virtual, 2 Physical extruder setup working, with your help if you are willing.
> > >
> > > Additional later requirements I was thinking P2PP (or a separate post processed G Code script, or maybe a new Octoprint plugin) might be able to help me with are:
> > >
> > > Temperature management of the idle extruder - at present with PrusaSlicer you seem to have two options - either
> > > a. Keep both extruders at full temperature the whole print
> > > b. Let the idle extruder drop down in temperature a bit when it goes idle, but you then have to wait for it to heat up again before you can start using it again - which easily doubles the tool change switch over time.
> > > Option a. is the quickest and simplest - but I don't like the idea of an extruder sitting there cooking the filament for potentially hours if the filament changes are quite rare, so I only tend to use this for small prints.
> > > Option b. works pretty well, but it is a fair bit slower as the heating back up takes a while, plus also it then takes a while longer for the printer to be happy that the temperature is stable before continuing with the print.
> > >
> > > What I would to do ideally is to create a variation of option b, where some sort of post processing script that:
> > > a. Detects short duration filament switches and strips out the cool down/reheating G-Code.
> > > b. For longer duration or less frequent filament switches, inserts some pre-heat G-Code a few seconds ahead of the tool change heat up G-Code to remove most of the heat up delay.
> > >
> > > Seeing if there is a way to detect and ideally recover from failed Palette 2 splices.
> > >
> > > Better noise management for the Palette 2 - ideally switching off some of the fans when they are not needed.
> > >
> > > Auto loading of filament from the Palette 2 into the printer at print start, as that is one of the nicest features of the MMU2s, and could be pretty useful even for single colour prints.
> > >
> > > Dave Wood
> > >
> > > —
> > > Reply to this email directly, view it on GitHub <#117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK6CHJMYIWXHX57CNT3JLJTUU7FBVANCNFSM5HPJHCYA>.
> > > Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
> > > You are receiving this because you authored the thread.
> > >
> >
> > —
> > Reply to this email directly, view it on GitHub <#117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/API2M74XT25U5PYLOKG5OPDUU7VCVANCNFSM5HPJHCYA>.
> > Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
> > You are receiving this because you commented.
> >
>
> —
> Reply to this email directly, view it on GitHub <#117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK6CHJILUGCKB7Q5I4ZT5VDUVG5JVANCNFSM5HPJHCYA>.
> Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
> You are receiving this because you authored the thread.
>
—
Reply to this email directly, view it on GitHub <#117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/API2M7YZ6QKHMXTGJM7F4VLUVK6RFANCNFSM5HPJHCYA>.
Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you commented.
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Tom,
Everything now working ok for me including on a bigger print, just need to try and get palette2 purge lengths and pings etc, properly dialled in - as colours seem to drift a bit (but hopefully that's just my setup, rather than a problem in the way that my scripts in conjunction with P2PP are handling the extra extruder).
Latest 4 stages of file attached, including the extra script I added to sort out sparse layers.
I suspect there may well be a better way than I have found to sort of the problems with Z height on the purge blocks - but the changes in the two scripts seem to work on the few models I have tried.
Files send in separate email again incase they cause problems with spam checkers.
Dave Wood
… On 10 Jan 2022, at 11:22, Tom Van den Eede ***@***.***> wrote:
Bit afraid though that the pre-post processing will throw the calculations for the P2/3 off
in theory the approach looks good and can be easily implemented in P2PP itself, the toolchange codes might not process correctly.
the Z-height might be related to this. reducing the Z-Hop is definitly not the right solution - it should work for any. 0.06 basically is still too high… this defitely requires some deeper looking into… I suspect this is due to part of the toolchange code going to oblivion
> On 9 Jan 2022, at 18:00, ukdavewood ***@***.***> wrote:
>
>
> Tom - Have made some very good progress I think
>
> 1. Got Palette 2pro working ok with Canvas on one extruder of the IDEX printer - did the normal keyring, plus a 4 colour stacked model. Also got Octoprint/Canvas both working
> 2. Got P2PP installed ok on a Mac - a bit tricky with permissions, then do all of the configuration and got the same 4 colour stack model printing ok. Nice to see that the purge block was a fair bit smaller than the Canvas version.
> Overall very impresses with P2PP and will definitely use it for all of my Palette printing.
> 3. Increased extruders up to 5 virtual - there doesn't seem to be a way to specify 4 virtual and 2 physical in prusa slicer.
>
> Decided to allocate the 5th virtual (T4) as the 2nd Physical extruder (E2/T1)
>
> Decided to then see if I could write a couple of python scripts to wrap around P2PP.
> Script 1 - IDEX_pre - based on some Tags in the TOOL change GCODE, goes through the file commenting out all GCODE relating to T4,
> P2PP - P2PP then processes the altered GCODE - never getting to know about T4 - and seems to work pretty well, including when for example the GCODE goes T0, T4, T0 - it just processes it as one lot of T0.
> Script 2 - IDEX_post This takes the output of P2PP - and then removes the comments on the front of the T4 GCODE (apart from the T4 line - which doesn't exist on the physical printer).
> Also as a by product of the Tool change Code which puts in commented out T0 and T1 - these get introduced too.
>
> Ran a few test prints
>
> The first failed with ping errors - I am assuming that this was due to the whole T0-T3 filament length being less than the length of the output tube
> The second print worked - but there seem to be some sort of Z height problem as the 2nd Physical extruder printed a little bit high
> The 3rd print was better - I reduced the Lift Z values down from 0.6 and 0.06 - As I think this may be the problem,
> But the 3rd print is still not perfect between I think E2 on the wipe tower is still printing a little bit higher than E1.
>
> Not sure though if pinging is working as I expect the palette will be wondering what is going on when E2 is printing
>
> Have attached a few files and the scripts, in a separate email incase you are interested / would consider as discussed incorporating the logic from the two scripts into P2PP - perhaps in a more generic way than I have done.
>
> Will in the meantime continue investigating, in particular whether there is a problem with the Z height when the printer transitions between Palette and Physical 2nd Extruder.
> Also will try some longer prints to see whether the Palette manages to get some decent pings.
>
>
>
> Dave Wood
>
>
>
>
>
> > On 8 Jan 2022, at 07:58, Tom Van den Eede ***@***.***> wrote:
> >
> >
> > Maybe it is best to transfer this conversation to email ***@***.*** ***@***.***>)
> >
> > Once you established a workflow we need to check how we can get the second extruder singled out (if possible automatically) so that code is printed without impact to the p2 code. It is a matter of just not accounting for that filament, but there are some pitfalls….
> >
> > * the second physical extruder will be in-between 2 splices so there needs to be a way to make sure sufficient purge is applied during the print
> > * extra temp control needs to be maintained
> > * I really hope Prusaslicer allows for the combination of a Physical dual and then virtual multiple extruder, if not the second physical will needs to be added as another virtual (which is good because it will solve the point 1 solution (though you will purge more) BUT all code for the second extruder will need to be offset… not too difficult though…
> > * I assume some things like sidewipe etc will need to get a closer look, not impossible but tricky with the offsets
> >
> > lots of stuff to think about
> >
> > regards
> > Tom
> >
> > > On 8 Jan 2022, at 06:41, ukdavewood ***@***.***> wrote:
> > >
> > >
> > > Thanks, I'm from the UK, so not too big a time difference to contend with and I would be happy to do a voice call.
> > >
> > > I think what I will do is first literally dust off the Palette - which is a 2 pro (I have the s upgrade kit too but haven't installed it yet).
> > >
> > > Whilst I like the idea of multi colour and multi material, in practice however apps:
> > > -70% of my prints are single colour no support.
> > > -10% are only 2 colours (for text and logos etc),
> > > -10% are only 2 material - either for PETG supports for PLA for example, or for TPU bonded into PLA or PETG.
> > > -only about 10% needing more than 2 colours or materials, and therefore requiring the Palette2.
> > >
> > > I have only used the palette a few times probably over 9 months ago, attached to a Prusa Mk3s, using Canvas, and a Raspberry Pi 3b based Canvas hub. I really liked it apart from the noise, and the time it takes to do each filament change.
> > >
> > > This was in place of an earlier MMU2s - which I disconnected due mainly to the unreliability, mess and also the practicalities of having to buffer the filament due to the long retractions.
> > >
> > > In the meantime I have been experimenting with IDEX printers, which are working pretty well for all of my two material/colour requirements using mainly PrusaSlicer, but I would like to get the Palette working again for my less common 3-5 filament requirements. Also, whilst the IDEX filament switch overs are much quicker and efficient than when using the palette, they are a fair bit more messy due to the purging and wiping prior to moving over to the purge block.
> > >
> > > Mosaic have said a couple of times that they may add IDEX printer support to the P2 - and I think the combination of a Palette, plus IDEX (or Tool changer)+Palette is probably the ultimate setup in terms of efficiency of filament switch over, reduced wastage, multi material, plus number of different colours available - but so far they don't seem to have progressed it, and I presume won't now on the P2 - due to the launch of the P3.
> > >
> > > I think however that P2PP may well end up being a better solution for me.
> > >
> > > I think the best first steps for me over the next few days are:
> > >
> > > Get the Palette physically connected up to the IDEX printer (a JGMaker ArtistD, with 0.6mm nozzles) - probably using Canvas initially to work out the best location for the Palette in relation to the printer, plus to get a suitably modelled extruder pipe connector working. One complication is the fact that I am thinking it may be most practical for me in terms of filament reel management to mount the Palette upside down.
> > >
> > > Switch the Palette over to P2PP to get used to how it works on a single physical extruder.
> > >
> > > Then once I have everything working ok, hopefully in the next couple of days, I would then like to try getting a 4 Virtual, 2 Physical extruder setup working, with your help if you are willing.
> > >
> > > Additional later requirements I was thinking P2PP (or a separate post processed G Code script, or maybe a new Octoprint plugin) might be able to help me with are:
> > >
> > > Temperature management of the idle extruder - at present with PrusaSlicer you seem to have two options - either
> > > a. Keep both extruders at full temperature the whole print
> > > b. Let the idle extruder drop down in temperature a bit when it goes idle, but you then have to wait for it to heat up again before you can start using it again - which easily doubles the tool change switch over time.
> > > Option a. is the quickest and simplest - but I don't like the idea of an extruder sitting there cooking the filament for potentially hours if the filament changes are quite rare, so I only tend to use this for small prints.
> > > Option b. works pretty well, but it is a fair bit slower as the heating back up takes a while, plus also it then takes a while longer for the printer to be happy that the temperature is stable before continuing with the print.
> > >
> > > What I would to do ideally is to create a variation of option b, where some sort of post processing script that:
> > > a. Detects short duration filament switches and strips out the cool down/reheating G-Code.
> > > b. For longer duration or less frequent filament switches, inserts some pre-heat G-Code a few seconds ahead of the tool change heat up G-Code to remove most of the heat up delay.
> > >
> > > Seeing if there is a way to detect and ideally recover from failed Palette 2 splices.
> > >
> > > Better noise management for the Palette 2 - ideally switching off some of the fans when they are not needed.
> > >
> > > Auto loading of filament from the Palette 2 into the printer at print start, as that is one of the nicest features of the MMU2s, and could be pretty useful even for single colour prints.
> > >
> > > Dave Wood
> > >
> > > —
> > > Reply to this email directly, view it on GitHub <#117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK6CHJMYIWXHX57CNT3JLJTUU7FBVANCNFSM5HPJHCYA>.
> > > Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
> > > You are receiving this because you authored the thread.
> > >
> >
> > —
> > Reply to this email directly, view it on GitHub <#117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/API2M74XT25U5PYLOKG5OPDUU7VCVANCNFSM5HPJHCYA>.
> > Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
> > You are receiving this because you commented.
> >
>
> —
> Reply to this email directly, view it on GitHub <#117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK6CHJILUGCKB7Q5I4ZT5VDUVG5JVANCNFSM5HPJHCYA>.
> Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
> You are receiving this because you authored the thread.
>
—
Reply to this email directly, view it on GitHub <#117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/API2M7YZ6QKHMXTGJM7F4VLUVK6RFANCNFSM5HPJHCYA>.
Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you commented.
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
As per email of 10th Jan 22:27 UK time - version 2 of my scripts/gcode files etc.
… On 10 Jan 2022, at 11:22, Tom Van den Eede ***@***.***> wrote:
Bit afraid though that the pre-post processing will throw the calculations for the P2/3 off
in theory the approach looks good and can be easily implemented in P2PP itself, the toolchange codes might not process correctly.
the Z-height might be related to this. reducing the Z-Hop is definitly not the right solution - it should work for any. 0.06 basically is still too high… this defitely requires some deeper looking into… I suspect this is due to part of the toolchange code going to oblivion
> On 9 Jan 2022, at 18:00, ukdavewood ***@***.***> wrote:
>
>
> Tom - Have made some very good progress I think
>
> 1. Got Palette 2pro working ok with Canvas on one extruder of the IDEX printer - did the normal keyring, plus a 4 colour stacked model. Also got Octoprint/Canvas both working
> 2. Got P2PP installed ok on a Mac - a bit tricky with permissions, then do all of the configuration and got the same 4 colour stack model printing ok. Nice to see that the purge block was a fair bit smaller than the Canvas version.
> Overall very impresses with P2PP and will definitely use it for all of my Palette printing.
> 3. Increased extruders up to 5 virtual - there doesn't seem to be a way to specify 4 virtual and 2 physical in prusa slicer.
>
> Decided to allocate the 5th virtual (T4) as the 2nd Physical extruder (E2/T1)
>
> Decided to then see if I could write a couple of python scripts to wrap around P2PP.
> Script 1 - IDEX_pre - based on some Tags in the TOOL change GCODE, goes through the file commenting out all GCODE relating to T4,
> P2PP - P2PP then processes the altered GCODE - never getting to know about T4 - and seems to work pretty well, including when for example the GCODE goes T0, T4, T0 - it just processes it as one lot of T0.
> Script 2 - IDEX_post This takes the output of P2PP - and then removes the comments on the front of the T4 GCODE (apart from the T4 line - which doesn't exist on the physical printer).
> Also as a by product of the Tool change Code which puts in commented out T0 and T1 - these get introduced too.
>
> Ran a few test prints
>
> The first failed with ping errors - I am assuming that this was due to the whole T0-T3 filament length being less than the length of the output tube
> The second print worked - but there seem to be some sort of Z height problem as the 2nd Physical extruder printed a little bit high
> The 3rd print was better - I reduced the Lift Z values down from 0.6 and 0.06 - As I think this may be the problem,
> But the 3rd print is still not perfect between I think E2 on the wipe tower is still printing a little bit higher than E1.
>
> Not sure though if pinging is working as I expect the palette will be wondering what is going on when E2 is printing
>
> Have attached a few files and the scripts, in a separate email incase you are interested / would consider as discussed incorporating the logic from the two scripts into P2PP - perhaps in a more generic way than I have done.
>
> Will in the meantime continue investigating, in particular whether there is a problem with the Z height when the printer transitions between Palette and Physical 2nd Extruder.
> Also will try some longer prints to see whether the Palette manages to get some decent pings.
>
>
>
> Dave Wood
>
>
>
>
>
> > On 8 Jan 2022, at 07:58, Tom Van den Eede ***@***.***> wrote:
> >
> >
> > Maybe it is best to transfer this conversation to email ***@***.*** ***@***.***>)
> >
> > Once you established a workflow we need to check how we can get the second extruder singled out (if possible automatically) so that code is printed without impact to the p2 code. It is a matter of just not accounting for that filament, but there are some pitfalls….
> >
> > * the second physical extruder will be in-between 2 splices so there needs to be a way to make sure sufficient purge is applied during the print
> > * extra temp control needs to be maintained
> > * I really hope Prusaslicer allows for the combination of a Physical dual and then virtual multiple extruder, if not the second physical will needs to be added as another virtual (which is good because it will solve the point 1 solution (though you will purge more) BUT all code for the second extruder will need to be offset… not too difficult though…
> > * I assume some things like sidewipe etc will need to get a closer look, not impossible but tricky with the offsets
> >
> > lots of stuff to think about
> >
> > regards
> > Tom
> >
> > > On 8 Jan 2022, at 06:41, ukdavewood ***@***.***> wrote:
> > >
> > >
> > > Thanks, I'm from the UK, so not too big a time difference to contend with and I would be happy to do a voice call.
> > >
> > > I think what I will do is first literally dust off the Palette - which is a 2 pro (I have the s upgrade kit too but haven't installed it yet).
> > >
> > > Whilst I like the idea of multi colour and multi material, in practice however apps:
> > > -70% of my prints are single colour no support.
> > > -10% are only 2 colours (for text and logos etc),
> > > -10% are only 2 material - either for PETG supports for PLA for example, or for TPU bonded into PLA or PETG.
> > > -only about 10% needing more than 2 colours or materials, and therefore requiring the Palette2.
> > >
> > > I have only used the palette a few times probably over 9 months ago, attached to a Prusa Mk3s, using Canvas, and a Raspberry Pi 3b based Canvas hub. I really liked it apart from the noise, and the time it takes to do each filament change.
> > >
> > > This was in place of an earlier MMU2s - which I disconnected due mainly to the unreliability, mess and also the practicalities of having to buffer the filament due to the long retractions.
> > >
> > > In the meantime I have been experimenting with IDEX printers, which are working pretty well for all of my two material/colour requirements using mainly PrusaSlicer, but I would like to get the Palette working again for my less common 3-5 filament requirements. Also, whilst the IDEX filament switch overs are much quicker and efficient than when using the palette, they are a fair bit more messy due to the purging and wiping prior to moving over to the purge block.
> > >
> > > Mosaic have said a couple of times that they may add IDEX printer support to the P2 - and I think the combination of a Palette, plus IDEX (or Tool changer)+Palette is probably the ultimate setup in terms of efficiency of filament switch over, reduced wastage, multi material, plus number of different colours available - but so far they don't seem to have progressed it, and I presume won't now on the P2 - due to the launch of the P3.
> > >
> > > I think however that P2PP may well end up being a better solution for me.
> > >
> > > I think the best first steps for me over the next few days are:
> > >
> > > Get the Palette physically connected up to the IDEX printer (a JGMaker ArtistD, with 0.6mm nozzles) - probably using Canvas initially to work out the best location for the Palette in relation to the printer, plus to get a suitably modelled extruder pipe connector working. One complication is the fact that I am thinking it may be most practical for me in terms of filament reel management to mount the Palette upside down.
> > >
> > > Switch the Palette over to P2PP to get used to how it works on a single physical extruder.
> > >
> > > Then once I have everything working ok, hopefully in the next couple of days, I would then like to try getting a 4 Virtual, 2 Physical extruder setup working, with your help if you are willing.
> > >
> > > Additional later requirements I was thinking P2PP (or a separate post processed G Code script, or maybe a new Octoprint plugin) might be able to help me with are:
> > >
> > > Temperature management of the idle extruder - at present with PrusaSlicer you seem to have two options - either
> > > a. Keep both extruders at full temperature the whole print
> > > b. Let the idle extruder drop down in temperature a bit when it goes idle, but you then have to wait for it to heat up again before you can start using it again - which easily doubles the tool change switch over time.
> > > Option a. is the quickest and simplest - but I don't like the idea of an extruder sitting there cooking the filament for potentially hours if the filament changes are quite rare, so I only tend to use this for small prints.
> > > Option b. works pretty well, but it is a fair bit slower as the heating back up takes a while, plus also it then takes a while longer for the printer to be happy that the temperature is stable before continuing with the print.
> > >
> > > What I would to do ideally is to create a variation of option b, where some sort of post processing script that:
> > > a. Detects short duration filament switches and strips out the cool down/reheating G-Code.
> > > b. For longer duration or less frequent filament switches, inserts some pre-heat G-Code a few seconds ahead of the tool change heat up G-Code to remove most of the heat up delay.
> > >
> > > Seeing if there is a way to detect and ideally recover from failed Palette 2 splices.
> > >
> > > Better noise management for the Palette 2 - ideally switching off some of the fans when they are not needed.
> > >
> > > Auto loading of filament from the Palette 2 into the printer at print start, as that is one of the nicest features of the MMU2s, and could be pretty useful even for single colour prints.
> > >
> > > Dave Wood
> > >
> > > —
> > > Reply to this email directly, view it on GitHub <#117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK6CHJMYIWXHX57CNT3JLJTUU7FBVANCNFSM5HPJHCYA>.
> > > Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
> > > You are receiving this because you authored the thread.
> > >
> >
> > —
> > Reply to this email directly, view it on GitHub <#117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/API2M74XT25U5PYLOKG5OPDUU7VCVANCNFSM5HPJHCYA>.
> > Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
> > You are receiving this because you commented.
> >
>
> —
> Reply to this email directly, view it on GitHub <#117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK6CHJILUGCKB7Q5I4ZT5VDUVG5JVANCNFSM5HPJHCYA>.
> Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
> You are receiving this because you authored the thread.
>
—
Reply to this email directly, view it on GitHub <#117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/API2M7YZ6QKHMXTGJM7F4VLUVK6RFANCNFSM5HPJHCYA>.
Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you commented.
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
will see how hard this is to include in the p2pp script itself.
should be fairly straightforward I think with possible extra’s to work if fully integrated in the process
… On 10 Jan 2022, at 23:27, ukdavewood ***@***.***> wrote:
Tom,
Everything now working ok for me including on a bigger print, just need to try and get palette2 purge lengths and pings etc, properly dialled in - as colours seem to drift a bit (but hopefully that's just my setup, rather than a problem in the way that my scripts in conjunction with P2PP are handling the extra extruder).
Latest 4 stages of file attached, including the extra script I added to sort out sparse layers.
I suspect there may well be a better way than I have found to sort of the problems with Z height on the purge blocks - but the changes in the two scripts seem to work on the few models I have tried.
Files send in separate email again incase they cause problems with spam checkers.
Dave Wood
> On 10 Jan 2022, at 11:22, Tom Van den Eede ***@***.***> wrote:
>
>
> Bit afraid though that the pre-post processing will throw the calculations for the P2/3 off
> in theory the approach looks good and can be easily implemented in P2PP itself, the toolchange codes might not process correctly.
> the Z-height might be related to this. reducing the Z-Hop is definitly not the right solution - it should work for any. 0.06 basically is still too high… this defitely requires some deeper looking into… I suspect this is due to part of the toolchange code going to oblivion
>
> > On 9 Jan 2022, at 18:00, ukdavewood ***@***.***> wrote:
> >
> >
> > Tom - Have made some very good progress I think
> >
> > 1. Got Palette 2pro working ok with Canvas on one extruder of the IDEX printer - did the normal keyring, plus a 4 colour stacked model. Also got Octoprint/Canvas both working
> > 2. Got P2PP installed ok on a Mac - a bit tricky with permissions, then do all of the configuration and got the same 4 colour stack model printing ok. Nice to see that the purge block was a fair bit smaller than the Canvas version.
> > Overall very impresses with P2PP and will definitely use it for all of my Palette printing.
> > 3. Increased extruders up to 5 virtual - there doesn't seem to be a way to specify 4 virtual and 2 physical in prusa slicer.
> >
> > Decided to allocate the 5th virtual (T4) as the 2nd Physical extruder (E2/T1)
> >
> > Decided to then see if I could write a couple of python scripts to wrap around P2PP.
> > Script 1 - IDEX_pre - based on some Tags in the TOOL change GCODE, goes through the file commenting out all GCODE relating to T4,
> > P2PP - P2PP then processes the altered GCODE - never getting to know about T4 - and seems to work pretty well, including when for example the GCODE goes T0, T4, T0 - it just processes it as one lot of T0.
> > Script 2 - IDEX_post This takes the output of P2PP - and then removes the comments on the front of the T4 GCODE (apart from the T4 line - which doesn't exist on the physical printer).
> > Also as a by product of the Tool change Code which puts in commented out T0 and T1 - these get introduced too.
> >
> > Ran a few test prints
> >
> > The first failed with ping errors - I am assuming that this was due to the whole T0-T3 filament length being less than the length of the output tube
> > The second print worked - but there seem to be some sort of Z height problem as the 2nd Physical extruder printed a little bit high
> > The 3rd print was better - I reduced the Lift Z values down from 0.6 and 0.06 - As I think this may be the problem,
> > But the 3rd print is still not perfect between I think E2 on the wipe tower is still printing a little bit higher than E1.
> >
> > Not sure though if pinging is working as I expect the palette will be wondering what is going on when E2 is printing
> >
> > Have attached a few files and the scripts, in a separate email incase you are interested / would consider as discussed incorporating the logic from the two scripts into P2PP - perhaps in a more generic way than I have done.
> >
> > Will in the meantime continue investigating, in particular whether there is a problem with the Z height when the printer transitions between Palette and Physical 2nd Extruder.
> > Also will try some longer prints to see whether the Palette manages to get some decent pings.
> >
> >
> >
> > Dave Wood
> >
> >
> >
> >
> >
> > > On 8 Jan 2022, at 07:58, Tom Van den Eede ***@***.***> wrote:
> > >
> > >
> > > Maybe it is best to transfer this conversation to email ***@***.*** ***@***.***>)
> > >
> > > Once you established a workflow we need to check how we can get the second extruder singled out (if possible automatically) so that code is printed without impact to the p2 code. It is a matter of just not accounting for that filament, but there are some pitfalls….
> > >
> > > * the second physical extruder will be in-between 2 splices so there needs to be a way to make sure sufficient purge is applied during the print
> > > * extra temp control needs to be maintained
> > > * I really hope Prusaslicer allows for the combination of a Physical dual and then virtual multiple extruder, if not the second physical will needs to be added as another virtual (which is good because it will solve the point 1 solution (though you will purge more) BUT all code for the second extruder will need to be offset… not too difficult though…
> > > * I assume some things like sidewipe etc will need to get a closer look, not impossible but tricky with the offsets
> > >
> > > lots of stuff to think about
> > >
> > > regards
> > > Tom
> > >
> > > > On 8 Jan 2022, at 06:41, ukdavewood ***@***.***> wrote:
> > > >
> > > >
> > > > Thanks, I'm from the UK, so not too big a time difference to contend with and I would be happy to do a voice call.
> > > >
> > > > I think what I will do is first literally dust off the Palette - which is a 2 pro (I have the s upgrade kit too but haven't installed it yet).
> > > >
> > > > Whilst I like the idea of multi colour and multi material, in practice however apps:
> > > > -70% of my prints are single colour no support.
> > > > -10% are only 2 colours (for text and logos etc),
> > > > -10% are only 2 material - either for PETG supports for PLA for example, or for TPU bonded into PLA or PETG.
> > > > -only about 10% needing more than 2 colours or materials, and therefore requiring the Palette2.
> > > >
> > > > I have only used the palette a few times probably over 9 months ago, attached to a Prusa Mk3s, using Canvas, and a Raspberry Pi 3b based Canvas hub. I really liked it apart from the noise, and the time it takes to do each filament change.
> > > >
> > > > This was in place of an earlier MMU2s - which I disconnected due mainly to the unreliability, mess and also the practicalities of having to buffer the filament due to the long retractions.
> > > >
> > > > In the meantime I have been experimenting with IDEX printers, which are working pretty well for all of my two material/colour requirements using mainly PrusaSlicer, but I would like to get the Palette working again for my less common 3-5 filament requirements. Also, whilst the IDEX filament switch overs are much quicker and efficient than when using the palette, they are a fair bit more messy due to the purging and wiping prior to moving over to the purge block.
> > > >
> > > > Mosaic have said a couple of times that they may add IDEX printer support to the P2 - and I think the combination of a Palette, plus IDEX (or Tool changer)+Palette is probably the ultimate setup in terms of efficiency of filament switch over, reduced wastage, multi material, plus number of different colours available - but so far they don't seem to have progressed it, and I presume won't now on the P2 - due to the launch of the P3.
> > > >
> > > > I think however that P2PP may well end up being a better solution for me.
> > > >
> > > > I think the best first steps for me over the next few days are:
> > > >
> > > > Get the Palette physically connected up to the IDEX printer (a JGMaker ArtistD, with 0.6mm nozzles) - probably using Canvas initially to work out the best location for the Palette in relation to the printer, plus to get a suitably modelled extruder pipe connector working. One complication is the fact that I am thinking it may be most practical for me in terms of filament reel management to mount the Palette upside down.
> > > >
> > > > Switch the Palette over to P2PP to get used to how it works on a single physical extruder.
> > > >
> > > > Then once I have everything working ok, hopefully in the next couple of days, I would then like to try getting a 4 Virtual, 2 Physical extruder setup working, with your help if you are willing.
> > > >
> > > > Additional later requirements I was thinking P2PP (or a separate post processed G Code script, or maybe a new Octoprint plugin) might be able to help me with are:
> > > >
> > > > Temperature management of the idle extruder - at present with PrusaSlicer you seem to have two options - either
> > > > a. Keep both extruders at full temperature the whole print
> > > > b. Let the idle extruder drop down in temperature a bit when it goes idle, but you then have to wait for it to heat up again before you can start using it again - which easily doubles the tool change switch over time.
> > > > Option a. is the quickest and simplest - but I don't like the idea of an extruder sitting there cooking the filament for potentially hours if the filament changes are quite rare, so I only tend to use this for small prints.
> > > > Option b. works pretty well, but it is a fair bit slower as the heating back up takes a while, plus also it then takes a while longer for the printer to be happy that the temperature is stable before continuing with the print.
> > > >
> > > > What I would to do ideally is to create a variation of option b, where some sort of post processing script that:
> > > > a. Detects short duration filament switches and strips out the cool down/reheating G-Code.
> > > > b. For longer duration or less frequent filament switches, inserts some pre-heat G-Code a few seconds ahead of the tool change heat up G-Code to remove most of the heat up delay.
> > > >
> > > > Seeing if there is a way to detect and ideally recover from failed Palette 2 splices.
> > > >
> > > > Better noise management for the Palette 2 - ideally switching off some of the fans when they are not needed.
> > > >
> > > > Auto loading of filament from the Palette 2 into the printer at print start, as that is one of the nicest features of the MMU2s, and could be pretty useful even for single colour prints.
> > > >
> > > > Dave Wood
> > > >
> > > > —
> > > > Reply to this email directly, view it on GitHub <#117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK6CHJMYIWXHX57CNT3JLJTUU7FBVANCNFSM5HPJHCYA>.
> > > > Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
> > > > You are receiving this because you authored the thread.
> > > >
> > >
> > > —
> > > Reply to this email directly, view it on GitHub <#117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/API2M74XT25U5PYLOKG5OPDUU7VCVANCNFSM5HPJHCYA>.
> > > Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
> > > You are receiving this because you commented.
> > >
> >
> > —
> > Reply to this email directly, view it on GitHub <#117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK6CHJILUGCKB7Q5I4ZT5VDUVG5JVANCNFSM5HPJHCYA>.
> > Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
> > You are receiving this because you authored the thread.
> >
>
> —
> Reply to this email directly, view it on GitHub <#117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/API2M7YZ6QKHMXTGJM7F4VLUVK6RFANCNFSM5HPJHCYA>.
> Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
> You are receiving this because you commented.
>
—
Reply to this email directly, view it on GitHub <#117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK6CHJJE6F4KVL7TCADLSYLUVNMO3ANCNFSM5HPJHCYA>.
Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you authored the thread.
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Great thanks.
Am switching over Palette to E2 today as easier for me to see - as I think part of my colour bleed problem is using auto load and extruding too much of the first filament first, plus using too shorter purges.
Had an idea about how I could solve my T0,T4,T0. Vs T0,T4,T1 wasted purge problem, where T0-T3 are the Palette, and T4 is the 2nd physical extruder on the IDEX printer.
Think I will set up the purge lengths very short between T4 and the other extruders - as in the case of T0,T4,T0 no extrusion other than a bit of priming is required.
Then what I think I could do is some logic that detects things like T0,T4,T1 in the PreP2PP script - that then introduces some extra purging on the palette extruder using the T0-T1 value in this case.
In the first place I think I will just dump the extra purging off to the side so that it is wiped off when the palette extruder returns to the bed, although ideally I think I would like this extra extrusion to go onto some sort of purge tower on the bed if I can work out how your custom purge tower works.
Dave
… On 11 Jan 2022, at 06:29, Tom Van den Eede ***@***.***> wrote:
will see how hard this is to include in the p2pp script itself.
should be fairly straightforward I think with possible extra’s to work if fully integrated in the process
> On 10 Jan 2022, at 23:27, ukdavewood ***@***.***> wrote:
>
>
> Tom,
>
> Everything now working ok for me including on a bigger print, just need to try and get palette2 purge lengths and pings etc, properly dialled in - as colours seem to drift a bit (but hopefully that's just my setup, rather than a problem in the way that my scripts in conjunction with P2PP are handling the extra extruder).
>
> Latest 4 stages of file attached, including the extra script I added to sort out sparse layers.
>
> I suspect there may well be a better way than I have found to sort of the problems with Z height on the purge blocks - but the changes in the two scripts seem to work on the few models I have tried.
>
> Files send in separate email again incase they cause problems with spam checkers.
>
>
>
> Dave Wood
>
>
>
> > On 10 Jan 2022, at 11:22, Tom Van den Eede ***@***.***> wrote:
> >
> >
> > Bit afraid though that the pre-post processing will throw the calculations for the P2/3 off
> > in theory the approach looks good and can be easily implemented in P2PP itself, the toolchange codes might not process correctly.
> > the Z-height might be related to this. reducing the Z-Hop is definitly not the right solution - it should work for any. 0.06 basically is still too high… this defitely requires some deeper looking into… I suspect this is due to part of the toolchange code going to oblivion
> >
> > > On 9 Jan 2022, at 18:00, ukdavewood ***@***.***> wrote:
> > >
> > >
> > > Tom - Have made some very good progress I think
> > >
> > > 1. Got Palette 2pro working ok with Canvas on one extruder of the IDEX printer - did the normal keyring, plus a 4 colour stacked model. Also got Octoprint/Canvas both working
> > > 2. Got P2PP installed ok on a Mac - a bit tricky with permissions, then do all of the configuration and got the same 4 colour stack model printing ok. Nice to see that the purge block was a fair bit smaller than the Canvas version.
> > > Overall very impresses with P2PP and will definitely use it for all of my Palette printing.
> > > 3. Increased extruders up to 5 virtual - there doesn't seem to be a way to specify 4 virtual and 2 physical in prusa slicer.
> > >
> > > Decided to allocate the 5th virtual (T4) as the 2nd Physical extruder (E2/T1)
> > >
> > > Decided to then see if I could write a couple of python scripts to wrap around P2PP.
> > > Script 1 - IDEX_pre - based on some Tags in the TOOL change GCODE, goes through the file commenting out all GCODE relating to T4,
> > > P2PP - P2PP then processes the altered GCODE - never getting to know about T4 - and seems to work pretty well, including when for example the GCODE goes T0, T4, T0 - it just processes it as one lot of T0.
> > > Script 2 - IDEX_post This takes the output of P2PP - and then removes the comments on the front of the T4 GCODE (apart from the T4 line - which doesn't exist on the physical printer).
> > > Also as a by product of the Tool change Code which puts in commented out T0 and T1 - these get introduced too.
> > >
> > > Ran a few test prints
> > >
> > > The first failed with ping errors - I am assuming that this was due to the whole T0-T3 filament length being less than the length of the output tube
> > > The second print worked - but there seem to be some sort of Z height problem as the 2nd Physical extruder printed a little bit high
> > > The 3rd print was better - I reduced the Lift Z values down from 0.6 and 0.06 - As I think this may be the problem,
> > > But the 3rd print is still not perfect between I think E2 on the wipe tower is still printing a little bit higher than E1.
> > >
> > > Not sure though if pinging is working as I expect the palette will be wondering what is going on when E2 is printing
> > >
> > > Have attached a few files and the scripts, in a separate email incase you are interested / would consider as discussed incorporating the logic from the two scripts into P2PP - perhaps in a more generic way than I have done.
> > >
> > > Will in the meantime continue investigating, in particular whether there is a problem with the Z height when the printer transitions between Palette and Physical 2nd Extruder.
> > > Also will try some longer prints to see whether the Palette manages to get some decent pings.
> > >
> > >
> > >
> > > Dave Wood
> > >
> > >
> > >
> > >
> > >
> > > > On 8 Jan 2022, at 07:58, Tom Van den Eede ***@***.***> wrote:
> > > >
> > > >
> > > > Maybe it is best to transfer this conversation to email ***@***.*** ***@***.***>)
> > > >
> > > > Once you established a workflow we need to check how we can get the second extruder singled out (if possible automatically) so that code is printed without impact to the p2 code. It is a matter of just not accounting for that filament, but there are some pitfalls….
> > > >
> > > > * the second physical extruder will be in-between 2 splices so there needs to be a way to make sure sufficient purge is applied during the print
> > > > * extra temp control needs to be maintained
> > > > * I really hope Prusaslicer allows for the combination of a Physical dual and then virtual multiple extruder, if not the second physical will needs to be added as another virtual (which is good because it will solve the point 1 solution (though you will purge more) BUT all code for the second extruder will need to be offset… not too difficult though…
> > > > * I assume some things like sidewipe etc will need to get a closer look, not impossible but tricky with the offsets
> > > >
> > > > lots of stuff to think about
> > > >
> > > > regards
> > > > Tom
> > > >
> > > > > On 8 Jan 2022, at 06:41, ukdavewood ***@***.***> wrote:
> > > > >
> > > > >
> > > > > Thanks, I'm from the UK, so not too big a time difference to contend with and I would be happy to do a voice call.
> > > > >
> > > > > I think what I will do is first literally dust off the Palette - which is a 2 pro (I have the s upgrade kit too but haven't installed it yet).
> > > > >
> > > > > Whilst I like the idea of multi colour and multi material, in practice however apps:
> > > > > -70% of my prints are single colour no support.
> > > > > -10% are only 2 colours (for text and logos etc),
> > > > > -10% are only 2 material - either for PETG supports for PLA for example, or for TPU bonded into PLA or PETG.
> > > > > -only about 10% needing more than 2 colours or materials, and therefore requiring the Palette2.
> > > > >
> > > > > I have only used the palette a few times probably over 9 months ago, attached to a Prusa Mk3s, using Canvas, and a Raspberry Pi 3b based Canvas hub. I really liked it apart from the noise, and the time it takes to do each filament change.
> > > > >
> > > > > This was in place of an earlier MMU2s - which I disconnected due mainly to the unreliability, mess and also the practicalities of having to buffer the filament due to the long retractions.
> > > > >
> > > > > In the meantime I have been experimenting with IDEX printers, which are working pretty well for all of my two material/colour requirements using mainly PrusaSlicer, but I would like to get the Palette working again for my less common 3-5 filament requirements. Also, whilst the IDEX filament switch overs are much quicker and efficient than when using the palette, they are a fair bit more messy due to the purging and wiping prior to moving over to the purge block.
> > > > >
> > > > > Mosaic have said a couple of times that they may add IDEX printer support to the P2 - and I think the combination of a Palette, plus IDEX (or Tool changer)+Palette is probably the ultimate setup in terms of efficiency of filament switch over, reduced wastage, multi material, plus number of different colours available - but so far they don't seem to have progressed it, and I presume won't now on the P2 - due to the launch of the P3.
> > > > >
> > > > > I think however that P2PP may well end up being a better solution for me.
> > > > >
> > > > > I think the best first steps for me over the next few days are:
> > > > >
> > > > > Get the Palette physically connected up to the IDEX printer (a JGMaker ArtistD, with 0.6mm nozzles) - probably using Canvas initially to work out the best location for the Palette in relation to the printer, plus to get a suitably modelled extruder pipe connector working. One complication is the fact that I am thinking it may be most practical for me in terms of filament reel management to mount the Palette upside down.
> > > > >
> > > > > Switch the Palette over to P2PP to get used to how it works on a single physical extruder.
> > > > >
> > > > > Then once I have everything working ok, hopefully in the next couple of days, I would then like to try getting a 4 Virtual, 2 Physical extruder setup working, with your help if you are willing.
> > > > >
> > > > > Additional later requirements I was thinking P2PP (or a separate post processed G Code script, or maybe a new Octoprint plugin) might be able to help me with are:
> > > > >
> > > > > Temperature management of the idle extruder - at present with PrusaSlicer you seem to have two options - either
> > > > > a. Keep both extruders at full temperature the whole print
> > > > > b. Let the idle extruder drop down in temperature a bit when it goes idle, but you then have to wait for it to heat up again before you can start using it again - which easily doubles the tool change switch over time.
> > > > > Option a. is the quickest and simplest - but I don't like the idea of an extruder sitting there cooking the filament for potentially hours if the filament changes are quite rare, so I only tend to use this for small prints.
> > > > > Option b. works pretty well, but it is a fair bit slower as the heating back up takes a while, plus also it then takes a while longer for the printer to be happy that the temperature is stable before continuing with the print.
> > > > >
> > > > > What I would to do ideally is to create a variation of option b, where some sort of post processing script that:
> > > > > a. Detects short duration filament switches and strips out the cool down/reheating G-Code.
> > > > > b. For longer duration or less frequent filament switches, inserts some pre-heat G-Code a few seconds ahead of the tool change heat up G-Code to remove most of the heat up delay.
> > > > >
> > > > > Seeing if there is a way to detect and ideally recover from failed Palette 2 splices.
> > > > >
> > > > > Better noise management for the Palette 2 - ideally switching off some of the fans when they are not needed.
> > > > >
> > > > > Auto loading of filament from the Palette 2 into the printer at print start, as that is one of the nicest features of the MMU2s, and could be pretty useful even for single colour prints.
> > > > >
> > > > > Dave Wood
> > > > >
> > > > > —
> > > > > Reply to this email directly, view it on GitHub <#117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK6CHJMYIWXHX57CNT3JLJTUU7FBVANCNFSM5HPJHCYA>.
> > > > > Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
> > > > > You are receiving this because you authored the thread.
> > > > >
> > > >
> > > > —
> > > > Reply to this email directly, view it on GitHub <#117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/API2M74XT25U5PYLOKG5OPDUU7VCVANCNFSM5HPJHCYA>.
> > > > Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
> > > > You are receiving this because you commented.
> > > >
> > >
> > > —
> > > Reply to this email directly, view it on GitHub <#117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK6CHJILUGCKB7Q5I4ZT5VDUVG5JVANCNFSM5HPJHCYA>.
> > > Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
> > > You are receiving this because you authored the thread.
> > >
> >
> > —
> > Reply to this email directly, view it on GitHub <#117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/API2M7YZ6QKHMXTGJM7F4VLUVK6RFANCNFSM5HPJHCYA>.
> > Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
> > You are receiving this because you commented.
> >
>
> —
> Reply to this email directly, view it on GitHub <#117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK6CHJJE6F4KVL7TCADLSYLUVNMO3ANCNFSM5HPJHCYA>.
> Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
> You are receiving this because you authored the thread.
>
—
Reply to this email directly, view it on GitHub <#117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/API2M75CSGZJJCRWG2QD2DDUVPE3PANCNFSM5HPJHCYA>.
Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you commented.
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
well that is the problem…
I would say Tx -> T4 and T4 -> Tx (physical to virtual) should be set to the max purge and print all the purge to the tower. This way you should get good transitions. In case of full tower reduction/side wipe there could be a proper calculation and regeneration of the amount of purge so the extra purge is not needed.
In the former case you actually get an extra extruder but you still do the purge. In case of side wipe mechanisms, the purge could be adapted more easily of course
… On 11 Jan 2022, at 09:16, ukdavewood ***@***.***> wrote:
Great thanks.
Am switching over Palette to E2 today as easier for me to see - as I think part of my colour bleed problem is using auto load and extruding too much of the first filament first, plus using too shorter purges.
Had an idea about how I could solve my T0,T4,T0. Vs T0,T4,T1 wasted purge problem, where T0-T3 are the Palette, and T4 is the 2nd physical extruder on the IDEX printer.
Think I will set up the purge lengths very short between T4 and the other extruders - as in the case of T0,T4,T0 no extrusion other than a bit of priming is required.
Then what I think I could do is some logic that detects things like T0,T4,T1 in the PreP2PP script - that then introduces some extra purging on the palette extruder using the T0-T1 value in this case.
In the first place I think I will just dump the extra purging off to the side so that it is wiped off when the palette extruder returns to the bed, although ideally I think I would like this extra extrusion to go onto some sort of purge tower on the bed if I can work out how your custom purge tower works.
Dave
> On 11 Jan 2022, at 06:29, Tom Van den Eede ***@***.***> wrote:
>
>
> will see how hard this is to include in the p2pp script itself.
>
> should be fairly straightforward I think with possible extra’s to work if fully integrated in the process
>
>
> > On 10 Jan 2022, at 23:27, ukdavewood ***@***.***> wrote:
> >
> >
> > Tom,
> >
> > Everything now working ok for me including on a bigger print, just need to try and get palette2 purge lengths and pings etc, properly dialled in - as colours seem to drift a bit (but hopefully that's just my setup, rather than a problem in the way that my scripts in conjunction with P2PP are handling the extra extruder).
> >
> > Latest 4 stages of file attached, including the extra script I added to sort out sparse layers.
> >
> > I suspect there may well be a better way than I have found to sort of the problems with Z height on the purge blocks - but the changes in the two scripts seem to work on the few models I have tried.
> >
> > Files send in separate email again incase they cause problems with spam checkers.
> >
> >
> >
> > Dave Wood
> >
> >
> >
> > > On 10 Jan 2022, at 11:22, Tom Van den Eede ***@***.***> wrote:
> > >
> > >
> > > Bit afraid though that the pre-post processing will throw the calculations for the P2/3 off
> > > in theory the approach looks good and can be easily implemented in P2PP itself, the toolchange codes might not process correctly.
> > > the Z-height might be related to this. reducing the Z-Hop is definitly not the right solution - it should work for any. 0.06 basically is still too high… this defitely requires some deeper looking into… I suspect this is due to part of the toolchange code going to oblivion
> > >
> > > > On 9 Jan 2022, at 18:00, ukdavewood ***@***.***> wrote:
> > > >
> > > >
> > > > Tom - Have made some very good progress I think
> > > >
> > > > 1. Got Palette 2pro working ok with Canvas on one extruder of the IDEX printer - did the normal keyring, plus a 4 colour stacked model. Also got Octoprint/Canvas both working
> > > > 2. Got P2PP installed ok on a Mac - a bit tricky with permissions, then do all of the configuration and got the same 4 colour stack model printing ok. Nice to see that the purge block was a fair bit smaller than the Canvas version.
> > > > Overall very impresses with P2PP and will definitely use it for all of my Palette printing.
> > > > 3. Increased extruders up to 5 virtual - there doesn't seem to be a way to specify 4 virtual and 2 physical in prusa slicer.
> > > >
> > > > Decided to allocate the 5th virtual (T4) as the 2nd Physical extruder (E2/T1)
> > > >
> > > > Decided to then see if I could write a couple of python scripts to wrap around P2PP.
> > > > Script 1 - IDEX_pre - based on some Tags in the TOOL change GCODE, goes through the file commenting out all GCODE relating to T4,
> > > > P2PP - P2PP then processes the altered GCODE - never getting to know about T4 - and seems to work pretty well, including when for example the GCODE goes T0, T4, T0 - it just processes it as one lot of T0.
> > > > Script 2 - IDEX_post This takes the output of P2PP - and then removes the comments on the front of the T4 GCODE (apart from the T4 line - which doesn't exist on the physical printer).
> > > > Also as a by product of the Tool change Code which puts in commented out T0 and T1 - these get introduced too.
> > > >
> > > > Ran a few test prints
> > > >
> > > > The first failed with ping errors - I am assuming that this was due to the whole T0-T3 filament length being less than the length of the output tube
> > > > The second print worked - but there seem to be some sort of Z height problem as the 2nd Physical extruder printed a little bit high
> > > > The 3rd print was better - I reduced the Lift Z values down from 0.6 and 0.06 - As I think this may be the problem,
> > > > But the 3rd print is still not perfect between I think E2 on the wipe tower is still printing a little bit higher than E1.
> > > >
> > > > Not sure though if pinging is working as I expect the palette will be wondering what is going on when E2 is printing
> > > >
> > > > Have attached a few files and the scripts, in a separate email incase you are interested / would consider as discussed incorporating the logic from the two scripts into P2PP - perhaps in a more generic way than I have done.
> > > >
> > > > Will in the meantime continue investigating, in particular whether there is a problem with the Z height when the printer transitions between Palette and Physical 2nd Extruder.
> > > > Also will try some longer prints to see whether the Palette manages to get some decent pings.
> > > >
> > > >
> > > >
> > > > Dave Wood
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > > On 8 Jan 2022, at 07:58, Tom Van den Eede ***@***.***> wrote:
> > > > >
> > > > >
> > > > > Maybe it is best to transfer this conversation to email ***@***.*** ***@***.***>)
> > > > >
> > > > > Once you established a workflow we need to check how we can get the second extruder singled out (if possible automatically) so that code is printed without impact to the p2 code. It is a matter of just not accounting for that filament, but there are some pitfalls….
> > > > >
> > > > > * the second physical extruder will be in-between 2 splices so there needs to be a way to make sure sufficient purge is applied during the print
> > > > > * extra temp control needs to be maintained
> > > > > * I really hope Prusaslicer allows for the combination of a Physical dual and then virtual multiple extruder, if not the second physical will needs to be added as another virtual (which is good because it will solve the point 1 solution (though you will purge more) BUT all code for the second extruder will need to be offset… not too difficult though…
> > > > > * I assume some things like sidewipe etc will need to get a closer look, not impossible but tricky with the offsets
> > > > >
> > > > > lots of stuff to think about
> > > > >
> > > > > regards
> > > > > Tom
> > > > >
> > > > > > On 8 Jan 2022, at 06:41, ukdavewood ***@***.***> wrote:
> > > > > >
> > > > > >
> > > > > > Thanks, I'm from the UK, so not too big a time difference to contend with and I would be happy to do a voice call.
> > > > > >
> > > > > > I think what I will do is first literally dust off the Palette - which is a 2 pro (I have the s upgrade kit too but haven't installed it yet).
> > > > > >
> > > > > > Whilst I like the idea of multi colour and multi material, in practice however apps:
> > > > > > -70% of my prints are single colour no support.
> > > > > > -10% are only 2 colours (for text and logos etc),
> > > > > > -10% are only 2 material - either for PETG supports for PLA for example, or for TPU bonded into PLA or PETG.
> > > > > > -only about 10% needing more than 2 colours or materials, and therefore requiring the Palette2.
> > > > > >
> > > > > > I have only used the palette a few times probably over 9 months ago, attached to a Prusa Mk3s, using Canvas, and a Raspberry Pi 3b based Canvas hub. I really liked it apart from the noise, and the time it takes to do each filament change.
> > > > > >
> > > > > > This was in place of an earlier MMU2s - which I disconnected due mainly to the unreliability, mess and also the practicalities of having to buffer the filament due to the long retractions.
> > > > > >
> > > > > > In the meantime I have been experimenting with IDEX printers, which are working pretty well for all of my two material/colour requirements using mainly PrusaSlicer, but I would like to get the Palette working again for my less common 3-5 filament requirements. Also, whilst the IDEX filament switch overs are much quicker and efficient than when using the palette, they are a fair bit more messy due to the purging and wiping prior to moving over to the purge block.
> > > > > >
> > > > > > Mosaic have said a couple of times that they may add IDEX printer support to the P2 - and I think the combination of a Palette, plus IDEX (or Tool changer)+Palette is probably the ultimate setup in terms of efficiency of filament switch over, reduced wastage, multi material, plus number of different colours available - but so far they don't seem to have progressed it, and I presume won't now on the P2 - due to the launch of the P3.
> > > > > >
> > > > > > I think however that P2PP may well end up being a better solution for me.
> > > > > >
> > > > > > I think the best first steps for me over the next few days are:
> > > > > >
> > > > > > Get the Palette physically connected up to the IDEX printer (a JGMaker ArtistD, with 0.6mm nozzles) - probably using Canvas initially to work out the best location for the Palette in relation to the printer, plus to get a suitably modelled extruder pipe connector working. One complication is the fact that I am thinking it may be most practical for me in terms of filament reel management to mount the Palette upside down.
> > > > > >
> > > > > > Switch the Palette over to P2PP to get used to how it works on a single physical extruder.
> > > > > >
> > > > > > Then once I have everything working ok, hopefully in the next couple of days, I would then like to try getting a 4 Virtual, 2 Physical extruder setup working, with your help if you are willing.
> > > > > >
> > > > > > Additional later requirements I was thinking P2PP (or a separate post processed G Code script, or maybe a new Octoprint plugin) might be able to help me with are:
> > > > > >
> > > > > > Temperature management of the idle extruder - at present with PrusaSlicer you seem to have two options - either
> > > > > > a. Keep both extruders at full temperature the whole print
> > > > > > b. Let the idle extruder drop down in temperature a bit when it goes idle, but you then have to wait for it to heat up again before you can start using it again - which easily doubles the tool change switch over time.
> > > > > > Option a. is the quickest and simplest - but I don't like the idea of an extruder sitting there cooking the filament for potentially hours if the filament changes are quite rare, so I only tend to use this for small prints.
> > > > > > Option b. works pretty well, but it is a fair bit slower as the heating back up takes a while, plus also it then takes a while longer for the printer to be happy that the temperature is stable before continuing with the print.
> > > > > >
> > > > > > What I would to do ideally is to create a variation of option b, where some sort of post processing script that:
> > > > > > a. Detects short duration filament switches and strips out the cool down/reheating G-Code.
> > > > > > b. For longer duration or less frequent filament switches, inserts some pre-heat G-Code a few seconds ahead of the tool change heat up G-Code to remove most of the heat up delay.
> > > > > >
> > > > > > Seeing if there is a way to detect and ideally recover from failed Palette 2 splices.
> > > > > >
> > > > > > Better noise management for the Palette 2 - ideally switching off some of the fans when they are not needed.
> > > > > >
> > > > > > Auto loading of filament from the Palette 2 into the printer at print start, as that is one of the nicest features of the MMU2s, and could be pretty useful even for single colour prints.
> > > > > >
> > > > > > Dave Wood
> > > > > >
> > > > > > —
> > > > > > Reply to this email directly, view it on GitHub <#117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK6CHJMYIWXHX57CNT3JLJTUU7FBVANCNFSM5HPJHCYA>.
> > > > > > Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
> > > > > > You are receiving this because you authored the thread.
> > > > > >
> > > > >
> > > > > —
> > > > > Reply to this email directly, view it on GitHub <#117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/API2M74XT25U5PYLOKG5OPDUU7VCVANCNFSM5HPJHCYA>.
> > > > > Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
> > > > > You are receiving this because you commented.
> > > > >
> > > >
> > > > —
> > > > Reply to this email directly, view it on GitHub <#117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK6CHJILUGCKB7Q5I4ZT5VDUVG5JVANCNFSM5HPJHCYA>.
> > > > Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
> > > > You are receiving this because you authored the thread.
> > > >
> > >
> > > —
> > > Reply to this email directly, view it on GitHub <#117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/API2M7YZ6QKHMXTGJM7F4VLUVK6RFANCNFSM5HPJHCYA>.
> > > Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
> > > You are receiving this because you commented.
> > >
> >
> > —
> > Reply to this email directly, view it on GitHub <#117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK6CHJJE6F4KVL7TCADLSYLUVNMO3ANCNFSM5HPJHCYA>.
> > Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
> > You are receiving this because you authored the thread.
> >
>
> —
> Reply to this email directly, view it on GitHub <#117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/API2M75CSGZJJCRWG2QD2DDUVPE3PANCNFSM5HPJHCYA>.
> Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
> You are receiving this because you commented.
>
—
Reply to this email directly, view it on GitHub <#117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK6CHJJYDCZU5LALG62MO6DUVPRPPANCNFSM5HPJHCYA>.
Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you authored the thread.
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Hi, Im attempting to setup P2PP having lost the will to live with Canvas. I've followed the instructions, however im having issues with the post-processing script ' The configured post-processing script does not exist'. Now i've copied the direct address from the P2PP file location and tried the suggested link from your instructions however im having no luck with either. Can you please advise what im missing? Im not on facebook to look up the community help, Cheers David |
Beta Was this translation helpful? Give feedback.
4 replies
-
|
Can you please provide screenshots of your post processing script setting and of it in the file explorer of your operating system. More information is required to be able to assist. |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
Tom - hope you are well. Was just looking at this Bambu Lab 'purge to object' YouTube video https://www.youtube.com/watch?v=AsokgzDYBBY and it reminded me of some of the stuff you did with P2PP. Not sure how much benefit there really is in getting purge to object to work properly for 3+ colour swaps - but it occurred to me that it might be along the same lines as some of the stuff you did in P2PP with the purge tower overrides. I presume from the fact I see mention of RFID Bambu Labs stuff on your GITHUB that you have BL experience too. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Yep running a X1C here as well… they are using the same prusaslicer as a basis for their processing so it would be logical that things are implemented in a very similar way. Most of the purge to object stuff is actually done in Prusa Slicer directly…
I have looked at the RFID as I have a lot of old filament and the concept of remote printing is definitely something where the raid could play a nice role. They have closed this down to a level that it is easier to hack an RFID prison cell than the spool tags… I like Bambu a lot but this is putting focus where a lot less focus is due...
I am happy about the release of the MK4 by purse as this guarantees that at least the 3d printing community goes on. Bambu seems to take a lot and return basically nothing to the community. They are likely very good engineers but I doubt if they have made all form scratch hence maybe the fully closed system.
I also hope MK4 will have a cloudless local direct communication between the printer and the slicer that bambu can adopt … printing through the cloud is nice but I have been having issues now several times where I had to resend a file multiple times before it arrived.
For me my MK3S was end of life and X1C seems the most logical replacement at the beginning of this year… MK4 will offer a decent alternative with long term support, open source hardware and software.
… On 1 Apr 2023, at 18:03, ukdavewood ***@***.***> wrote:
Tom - hope you are well. Was just looking at this Bambu Lab 'purge to object' YouTube video https://www.youtube.com/watch?v=AsokgzDYBBY and it reminded me of some of the stuff you did with P2PP. Not sure how much benefit there really is in getting purge to object to work properly for 3+ colour swaps - but it occurred to me that it might be along the same lines as some of the stuff you did in P2PP with the purge tower overrides. I presume from the fact I see mention of RFID Bambu Labs stuff on your GITHUB that you have BL experience too.
—
Reply to this email directly, view it on GitHub <#117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK6CHJL6B7JAG6TCYG73ZL3W7BGT7ANCNFSM5HPJHCYA>.
You are receiving this because you authored the thread.
|
Beta Was this translation helpful? Give feedback.
1 reply
-
|
Yep - I agree that it would be nice if the RFIDs could be available for other filaments. My solution is having several AMS's mostly left loaded up. However I have found some of my older filaments don't like being left for a few days without use and go brittle in the first few metres - despite the sealed nature of the AMS and the desiccant etc. Re printing through the cloud - when the Bambu cloud has been down a few times I thought you were printing when you signing off the printer and bambu slicer. However that stops Bambu Handy from working, and in particular the camera - so I have tended to sign back in as soon as I can. I like the look of the MK4 too - and am considering maybe a 3.9 upgrade just to support PRUSA - I like the look of the NextTruder in particular. Would like to justify an XL too - but I'm finding I've gone beyond 5 colours already - plus think the 5 colour version is much too expensive. Was disappointed that the MMU3 seems to have moved on so little from the MMU2 - as Im finding the AMS very good - particularly the filament cutter and auto rewinding. Personally though I am really happy with the X1C - prints even single colour prints far more reliably than either my Prusa MK3s or IDEX printer - and of course much quicker too. Plus the AMS I think is much better than either MMU2 or Palette2. Ive done more printing hours in the last two months than probably the last 3-4 years since I've has the X1C. |
Beta Was this translation helpful? Give feedback.
-
|
yupbout palette there is of course the idea of it working with different printers… AMS and mmu are single printer which obviously simplifies things a lot. The filament cut is a big advantage over the mmu though in theory it should yield 3 or 4cm of extra purge on eacht transitionOp 1 apr. 2023 om 18:46 heeft ukdavewood ***@***.***> het volgende geschreven:
Yep - I agree that it would be nice if the RFIDs could be available for other filaments. My solution is having several AMS's mostly left loaded up. However I have found some of my older filaments don't like being left for a few days without use and go brittle in the first few metres - despite the sealed nature of the AMS and the desiccant etc.
Re printing through the cloud - when the Bambu cloud has been down a few times I thought you were printing when you signing off the printer and bambu slicer. However that stops Bambu Handy from working, and in particular the camera - so I have tended to sign back in as soon as I can.
I like the look of the MK4 too - and am considering maybe a 3.9 upgrade just to support PRUSA - I like the look of the NextTruder in particular. Would like to justify an XL too - but I'm finding I've gone beyond 5 colours already - plus think the 5 colour version is much too expensive.
Was disappointed that the MMU3 seems to have moved on so little from the MMU2 - as Im finding the AMS very good - particularly the filament cutter and auto rewinding.
Personally though I am really happy with the X1C - prints even single colour prints far more reliably than either my Prusa MK3s or IDEX printer - and of course much quicker too. Plus the AMS I think is much better than either MMU2 or Palette2. Ive done more printing hours in the last two months than probably the last 3-4 years since I've has the X1C.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Try removing the space in the folder name (or replace it by an underscore).
There is a way around this but I don’t remember by heart
… On 2 Apr 2023, at 14:50, dareid82 ***@***.***> wrote:
<https://user-images.githubusercontent.com/125828644/229353871-17bdb49e-378f-4b54-99fe-c1dec6bf230b.png>
—
Reply to this email directly, view it on GitHub <#117 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK6CHJNSE3A573XOVZTYJNTW7FY2BANCNFSM5HPJHCYA>.
You are receiving this because you authored the thread.
|
Beta Was this translation helpful? Give feedback.
4 replies
-
|
Removing the space didnt work, nor did replacing with an underscrore, very frustrating |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
You can see the P2PP line doesnt quite match the file explorer file path with the addition of the exclamation mark, ive tried including and excluding this, with and without the space, tried removing the duplicated p2pp within the line, nothing makes a difference |
Beta Was this translation helpful? Give feedback.
-
|
Hi Tom, Any further assistance available here? |
Beta Was this translation helpful? Give feedback.
-
|
Have not been able to reproduce this issue yet
did you try to move the installation to a location without spaces in the path name and retry again?
regards
… On 17 Apr 2023, at 17:12, dareid82 ***@***.***> wrote:
Hi Tom,
Any further assistance available here?
—
Reply to this email directly, view it on GitHub <#117 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK6CHJKH25JXZMVSKZZOSCTXBVMW5ANCNFSM5HPJHCYA>.
You are receiving this because you authored the thread.
|
Beta Was this translation helpful? Give feedback.
1 reply
-
|
Hi Tom, I've relocated the files to several alternative locations and removed spaces etc. I have uninstalled and re-installed with similar results. Between Canvas being lousy and this setup just not working i may as well sell the Palette 3 Pro |
Beta Was this translation helpful? Give feedback.
-
|
sorry to hear… I have not been able to replicate the issue so not sure what more help I can offer only thing that comes to mind is running ps as admin but rhat shouldnot be necessaryOp 14 jul. 2023 om 17:03 heeft dareid82 ***@***.***> het volgende geschreven:
Hi Tom,
I've relocated the files to several alternative locations and removed spaces etc. I have uninstalled and re-installed with similar results. Between Canvas being lousy and this setup just not working i may as well sell the Palette 3 Pro
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
1 reply
-
|
Do you know where would be a good place to sell the Palette 3 Pro btw? |
Beta Was this translation helpful? Give feedback.
-
|
As this is likely entirely PS2.6 stuff you can also check the information on postprocessing scripts there
https://manual.slic3r.org/advanced/post-processinghttps://help.prusa3d.com/article/post-processing-scripts_283913
… On 14 Jul 2023, at 17:02, dareid82 ***@***.***> wrote:
Hi Tom,
I've relocated the files to several alternative locations and removed spaces etc. I have uninstalled and re-installed with similar results. Between Canvas being lousy and this setup just not working i may as well sell the Palette 3 Pro
—
Reply to this email directly, view it on GitHub <#117 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK6CHJIYCZUTPCDF4Q73YKTXQFNR3ANCNFSM5HPJHCYA>.
You are receiving this because you authored the thread.
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Link doesnt work |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
just look for prusa slicer post processing script quote good docs thereOp 14 jul. 2023 om 17:56 heeft dareid82 ***@***.***> het volgende geschreven:
Link doesnt work
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Hello everybody, I have followed the discussion regarding the IDX topic and was wondering what the current status of this is. I have a MK4 now and hopefully the MMU3 will also be shipped soon (after solving the open issues for MK4). I have been using the P3P some time with P2PP now successful but was not able to spice e.g. PLA with PETG or vice versa. I was thinking the combination between MMU3 (TPU, PVA + PLA for supports) and P3P (for normal PETG color splicing) could be great. Any ideas how to realize or configure such kind of setup? Regards Joerg |
Beta Was this translation helpful? Give feedback.
3 replies
-
|
I did create a couple of scripts documented in the readme file here to make IDEX printers work with the Palette (2p in my case) https://github.com/ukdavewood/p2pp/tree/colour?fbclid=IwAR1XlfBQ84waNw2sPULf6K1_6maomAhP3zZAxd4OPBliS7zJlcJX6fisqwM What they do is allow for example Virtual Extruder 5 (T4) to be allocated as an IDEX secondary tool. The first script goes through the GCODE and comments out all of the Extruder 5 commands - so that P2PP doesn't have to worry about them. P2PP then runs, then after that a 2nd script is run that then re-introduces the Extruder 5 GCOde - but to the IDEX T1. I think it would also be able to work with the MMU2/3 Palette2/3 too in a fairly similar way - which just some slightly different tool change GCODE overrides. i.e. If your P3P is 8 channel - then Virtual Extruder 1-8 as the P3P, which is connect to slot 1 of the MMU2/3 - with 9-12 going to the MMU slots 2-5. (The tool change GCODE would then need to pick out extruders 9-12 (T8-T11) and translate them in T1-T4, plus add the stuff for my scripts to know what to comment out and re-add after P2PP. In practice though I have never really used the scripts as my IDEX printer have been gathering dust for quite a while now. Plus there didn't seem to be much interest when I published my scripts on the P2PP Facebook - which is I guess why this functionality was never rolled into P2PP. I did re-raise the idea again on the P2PP Facebook a few months ago - as I think the idea could well work with the Bambu Lab A1 mini which is limited to only 4 colours - but there didn't seem to be much interest again. PS/ To print TPU with PLA supports recently I took a slightly different approach which worked quite well - which was to print the PLA support part separately first, then print the TPU, with the print paused at the right layer to allow the pre-printed PLA part to be slotted in. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the explanation - I will have a look at your repo the next days and try to understand what it is doing. I saw above that you tried setting it up on the first and second tool head on the machine - any issues when using the last input instead of the first? (Wanted to keep the MMU attached and just insert the P3P to the past input when needed) @tomvandeneede I saw that PS 2.7-beta1 has an experimental option "Wipe tower with no sparse layers" - will this interfere with P2PP somehow then? Are there still any noteworthy restrictions for accessory mode or is it finalized now. |
Beta Was this translation helpful? Give feedback.
-
|
Unclej84 - No it doesn't really matter what nozzles or channels you use - you just need to write the appropriate Gcode. - I was just quoting channel 1 as an example. I guess one of the biggest challenges could be starting off the P3 in the right place and not upsetting the pings and pongs etc - so probably worth ensuring that whatever it is printing comes first in the print if possible. Also rather than having a direct PTFE constrained path to the extruder - having to have a buffer before the MMU2/3 to cope with the MMU retractions will also make things a bit more tricky for the P2/P3 to keep track of its timing. I think I just had a bit of trouble with Sparse_Z adjust so tweaked the GCODE slightly - I guess you could try it with and without. Was thinking of ditching my MK3s/MMU2 - but this thread inspires me to keep it for a while longer and a some point have a go at doing an MMU2/P2P combined 8 colour print - what I would really like to see though is an at extruder filament cutter on the MK3 or MK4 as I think that is the key to why the BL AMS is so much more reliable |
Beta Was this translation helpful? Give feedback.
-
|
I have been thinking about supporting a secondary extruder but lacking sample code itnis hard to knownwhat IdeX is expecting in terms of extruder swapping codeOp 11 nov. 2023 om 16:14 heeft ukdavewood ***@***.***> het volgende geschreven:
I did create a couple of scripts documented in the readme file here to make IDEX printers work with the Palette (2p in my case) https://github.com/ukdavewood/p2pp/tree/colour?fbclid=IwAR1XlfBQ84waNw2sPULf6K1_6maomAhP3zZAxd4OPBliS7zJlcJX6fisqwM
What they do is allow for example Virtual Extruder 5 (T4) to be allocated as an IDEX secondary tool. The first script goes through the GCODE and comments out all of the Extruder 5 commands - so that P2PP doesn't have to worry about them. P2PP then runs, then after that a 2nd script is run that then re-introduces the Extruder 5 GCOde - but to the IDEX T1.
I think it would also be able to work with the MMU2/3 Palette2/3 too in a fairly similar way - which just some slightly different tool change GCODE overrides. i.e. If your P3P is 8 channel - then Virtual Extruder 1-8 as the P3P, which is connect to slot 1 of the MMU2/3 - with 9-12 going to the MMU slots 2-5. (The tool change GCODE would then need to pick out extruders 9-12 (T8-T11) and translate them in T1-T4, plus add the stuff for my scripts to know what to comment out and re-add after P2PP.
In practice though I have never really used the scripts as my IDEX printer have been gathering dust for quite a while now. Plus there didn't seem to be much interest when I published my scripts on the P2PP Facebook - which is I guess why this functionality was never rolled into P2PP.
I did re-raise the idea again on the P2PP Facebook a few months ago - as I think the idea could well work with the Bambu Lab A1 mini which is limited to only 4 colours - but there didn't seem to be much interest again.
PS/ To print TPU with PLA supports recently I took a slightly different approach which worked quite well - which was to print the PLA support part separately first, then print the TPU, with the print paused at the right layer to allow the pre-printed PLA part to be slotted in.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
3 replies
-
|
The two IDEX's I had were never that well supported - so the Tool change code was a bit roll your own - and you needed quite a few different variations dependent on whether you wanted to do things like mirror printing etc. I guess the MMU2/3 tool change GCODE though is pretty well settled in the current Prusa printer profiles. Inspired by you P2PP I have been working on another couple of things though which I might release at some point
|
Beta Was this translation helpful? Give feedback.
-
|
Regarding the first point - I normally use the functions "Purge to infill" or "Purge to object" in PrusaSlicer directly as they did a great job so far. Or did you have more special intentions? |
Beta Was this translation helpful? Give feedback.
-
|
Unclej84 - No - The main problem though I find with purge-to object though as a) Remembering to use it, b) Keeping a list of suitable 'colour doesn't matter' objects, and c) Then selecting the best objects to match the print in question - i.e. Those with nice big layers at the heights of the colour changes. d) Then actually merging all of the objects into one build plate - taking account of things like different infill / shell requirements between the multi coloured objects and the purge-to objects. The aim of the work I have been doing to reduce the purge lengths down to practically zero - which I have almost achieved for a few example multi coloured prints. |
Beta Was this translation helpful? Give feedback.
-
|
adding g2 and g3 should not be too difficult. will see if 8 can get that going Op 28 jan 2024 om 11:36 heeft WillWiggle ***@***.***> het volgende geschreven:
Hello
Just upgraded set-up to Mk4 and got fed up waiting for MMU so without an awful lot of thought purchased PP3.
Steep learning curve but working with Canvas and mk3s profile but not that well.
Trying to configure p2pp for mk4 has proved tricky. Basically using a standard configuration from Slicr and adding the relevant bits from the configuration guide does not work. Get an error straight up.
Working assumption is that bunch of code in Mk4 is not parsed by P2PP such as if and else.
Clearly folk have got this working but just wondering how. Assume using a MK3s profile will do it but that seems to defeat the object of having a Mk4.
Sincere apologies if I have missed something obvious!
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
3 replies
-
|
Thanks so much Tom. Another issue as above. Load of filament falls short of home drive! Is there an offset setting I’m missing as this not happening in Canvas |
Beta Was this translation helpful? Give feedback.
-
|
Solved…offset need 5 more. Thanks to everyone - very kind. |
Beta Was this translation helpful? Give feedback.
-
|
So I have another issue!! Fidget Star sliced with Prusa Slicer Not clear why the retraction is stopping as there is no retraction calibration in the P3 settings and assumed this would be hard coded to avoid the junction. Filament does not appear to be slipping in CAM and load to splicer is good. Assuming nothing in G Code or P2PP that impacts filament CAM retraction distance. |
Beta Was this translation helpful? Give feedback.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
👋 Welcome!
We’re using Discussions as a place to connect with other members of our community. We hope that you:
build together 💪.
To get started, comment below with an introduction of yourself and tell us about what you do with this community.
Beta Was this translation helpful? Give feedback.
All reactions