Cura: Change Filament Script second color

[fiddlekrazy]

Application Version
4.0

Platform
windows 10

Printer
Ender 3

Steps to Reproduce
'Add Filament Change' script with coma separating the two changes

Actual Results
Only the first change occurs (M600 inserted at proper location). No other M600 produced

Expected results
Expect change to occur at second layer location but nothing happens

Additional Information
After examining the gcode I found M600 occured only once. When I manually insert a 2nd M600 at the proper location I can change the filament. I also tried adding a second script line but that didn't work either.

[Ghostkeeper]

I'm not able to reproduce this issue. I added the Filament Change script and changed the Layer parameter to be 1, 3, 5. This is the result: test.gcode.zip

You can see that there are 3 FilamentChange entries in there.

[fiddlekrazy]

This is very strange. When I try it as you did (1, 3, 5) it worked but when I tried it with my original (5,11) it did not.

[fiddlekrazy]

Further update, my layer count is 16. I tried it with 1, 5, 11 and it only produced the first 2 changes but not layer 11 :(

[Ghostkeeper]

1, 5, 11 also works fine here: test.gcode.zip

Maybe it's not deterministic and only happens sometimes? Though the code is so simple, I can't imagine that this goes wrong.

I added a log entry to see that it goes wrong a bit more easily: https://github.com/Ultimaker/Cura/commit/fdc629de32c46f5d3bd103aaa4ac99b93e4b114f

[fiddlekrazy]

I have tried it several times. I have rebooted the program, rebooted the computer, tried changing the variables (5, 12), still no luck. I notice that you have code after the M600 (M600 E30.00 L300.00 X0.00 Y0.00 ; Generated by FilamentChange plugin), my code does not (M600 ; Generated by FilamentChange plugin).
I have to use negative values for extraction (-30, -300) so I tried positive values to see what would happen. I still get only 1 change but the code that does generate now shows data after the M600 (M600 E30.00 L300.00 ; Generated by FilamentChange plugin) but it is still different than your code.
I am going to see if there is an update to the plugin

[fiddlekrazy]

I was just reading the log file and see that the error has been sent to Ultimaker stats (https://stats.ultimaker.com/api/cura).

[Ghostkeeper]

The post-processing plug-in is not updated via the marketplace. It's built in Cura by default so we only distribute it with new Cura releases (for now). If you're on Windows you could replace the file in Program Files by this new file: https://github.com/Ultimaker/Cura/blob/master/plugins/PostProcessingPlugin/scripts/FilamentChange.py However that should only add the log entry there if it failed to find the ;LAYER: comment.

There should be no log entry in your version of Cura yet. At least, unless you've built Cura yourself from latest master.

[ljbeng]

Cura 3.6.0 works perfectly to give us multiple filament changes. 4.0 is faulty as described above. Only one filament change M600 is put into the gcode and unfortunately, my Ender 5 has the one stop (out of 3) in gcode and does not even stop at that first filament change line. It continues to print.

[ljbeng]

I tried a bunch of iterations. If I put 24,30,33 into the filament change box, I get M600 on layer 23 and 32 but not 29(30). If I put 2,4,6,8,10,12,14 I get all but layer 13(14).. There is some bug in there.

Her are all the examples I tried:

1,3,5,7,9,21,23,24,27,30 all layers got M600 except 30
20,21,22,23,24,25 all layers got M600 except 25
1,16,23 Layers 1 and 23 got M600 and 16 was skipped.
BUTTT....
If I put 1,3,5 in there all 3 lines get M600.

[Ghostkeeper]

Yeah this is very confusing. I have a suspicion that something nondeterministic might be going on.

For those of you who are on Windows, could you replace the file C:\Program Files\Ultimaker Cura 4.0\plugins\PostProcessingPlugin\scripts\FilamentChange.py with this file here: https://raw.githubusercontent.com/Ultimaker/Cura/master/plugins/PostProcessingPlugin/scripts/FilamentChange.py

Then (re)start Cura, try it, and post the Cura log here?

[ljbeng]

So far that plug in seems to work better. I tried a few iterations. I will print something later and report back :) I did an ExamDiff and you only added the X,Y parameter and some logging if the layer wasn't found. Not sure why it worked better that time. Where is the log file you want to look at?

[fiddlekrazy]

This site will not let me download a file larger than 10MB. The cura.log file is ~42MB. I have since sliced the log file to include the latest entry. There is an error statement "Could not find the layer 11" on line 72
cura.log. I did change the FilamentChange.py file as suggested and the results are no different. (This is the log AFTER the change.)

[fiddlekrazy]

ljbeng> Where is the log file you want to look at?

Do a search for "cura.log" in the users directory in the main drive (C?) ... The log records oldest to newest so the entry you will be looking for will be near the end. Hope this helps.

[Ghostkeeper]

Yeah the readme here in the repository says that you can find the log at %APPDATA%\cura\<Cura version>\cura.log, but there is actually a different file at %APPDATA%\cura\stderr.log which is usually more useful since it only contains the latest run of Cura. It'll be small enough to upload here.

[Ghostkeeper]

Could you try again with this file: https://raw.githubusercontent.com/Ultimaker/Cura/4.1/plugins/PostProcessingPlugin/scripts/FilamentChange.py

I've simplified the algorithm a bit. Still couldn't reproduce the bug though. I think it's dependent on the g-code.

[fiddlekrazy]

I used 2 iterations (6, 11) which is what originally started this thread. This latest file worked (almost). It put the code just before ;Layer:5 which is where it is supposed to be but it put the second code just before ;Layer:11 which is 1 layer after the proper placement. I suspect that your latest code does not allow for the layers starting at 0 for future iterations.

stderr.log

[fiddlekrazy]

Update: Now I am about to confuse matters worse. I decided to try another file with the following iterations: 6, 11, 16, 21, 23, 32. It worked flawlessly. I then put in the original iterations: 6, 11 and again it worked flawlessly.
I then reloaded in the original file and used the iterations: 6, 11 and it almost worked as in previous post with last layer being place 1 layer too late. I then tried: 6, 11, 14 with the last 2 iterations being placed 1 layer too late.

BTW the file that I am using for the latest test is not the same (but similar (both 3 mm high)) to the file that started it all. The file that I used when the code worked perfectly is 72 mm tall. That should not make a difference but .....

[fiddlekrazy]

After I wrote the last comment, I tried something else. I increased the original file to 4 mm and all worked fine with the 6, 11 iterations. I then added a new iteration at 16 and it put the new one at layer 16 (not 15 where it should be). It looks to me as if the problem occurs when the code is within the last mm (last 5 layers).

[Ghostkeeper]

Maybe if the Z hop exceeds the maximum printed height? What's your Z hop setting?

[fiddlekrazy]

For this print I do not use Z Hop.

[fiddlekrazy]

I have found a work around for the problem but not a solution. With my latest print (still 3 mm high) I have 3 color changes: 5, 9, 12. When I save the gcode it still puts the last change at the wrong layer so I changed the iterations to: 5, 9, 11 and it wrote the code where it is supposed to be. Not the best solution but ........

[fiddlekrazy]

I have tried Cura 4.1 and the problem still exists ...

[Ghostkeeper]

Still unable to reproduce the problem. I have no idea why it's different on your computer.

[fiddlekrazy]

I am including the .stl and .gcode files. It is not the original file that produced the problem but the result is the same. The iteration was for the 11th layer and should have been placed at layer 10 in the code but as you can see it is at the 11th layer. I am trying to create a barn board effect without having to paint the wall :(

Wall Blank.zip

[Ghostkeeper]

That model, when sliced at 0.1mm layer height, has only 10 layers. But I am indeed seeing some inconsistencies. For one, the script is prone to breaking if you enter non-integer values or layer numbers out of range (like -4 or 1000000). Fixed that here: https://github.com/Ultimaker/Cura/commit/e1bb783bcd98accfa1da75ad264b0a6cbb1be881

I think I've got the bug now. It's not related to your model, but something in CuraEngine not grouping the layer g-code correctly. Two layers are grouped together as if they are one.

[Ghostkeeper]

Got it. CuraEngine was flushing two layers to the front-end at the same time. This caused the front-end to think that layers 5 and 6 (in my case) were just one layer, causing an off-by-one error for every layer afterwards. It did this when its layer buffer was full, making this dependent on your computer's performance and thread handling. That made it hard to reproduce.

Since the fix is in C++ code, you'd need to compile CuraEngine to get the fix, which is a hassle. The fix will get published with Cura 4.2.