Cura 2.7 support about roboxslicerextension HOT 27 OPEN

👍 roger! :)

from roboxslicerextension.

Good idea I was stuck with the way of solving this problem.

I will give it a check this week.

from roboxslicerextension.

I made a branch Cura2.5-support and pushed a fix for this the cura file ending with "-0.gcode" will be renamed with ".slicer.gcode" at the end and continue the process.

I tested the rename it went ok and generated the files did'nt take time to make a real printing test
I let you make a test with this if it's ok we can merge this on the master.

from roboxslicerextension.

I am sorry to be so slow these days - I am really struggling to do anything computer based for months now! :( Printer as well...

Anyway - I have cleaned the code in the branch a bit and moved non-common (Cura specific code) back to Cura class. If other slicers are to do the same we can make it more generic then.

Also, @Benraay - did you mean endsWith("-0.gcode") or endsWith("-0.slicer.gcode") or maybe both? :) I left it as "-0.gcode" for now.

Another option is like @nebbian said - just scan it for the latest ".gcode" file (or should it be ".slicer.gcode"?). I don't mind doing it now if you want...

from roboxslicerextension.

No it was only endsWith("-0.gcode") because the stl file provided ends his name with that -0 at the end and cura adds a prefix depending on the name of your settings but this zero stays at the end and it is the only file in that folder with the -0 at the end so I bet this is always the good one.
It will work in most cases i don't know if sometimes the stl file ends with a -1 if it's the case we need to make also a test on that possible ending but for now it seems to work as is.

from roboxslicerextension.

Thanks. It will do for now, then! :)

from roboxslicerextension.

Thanks for doing this work @Benraay. I think that it shouldn't be tied into Cura though, as this is a general case solution that should work for all slicers. If you just scan the folder for the last modified file in there, and ensure that it ends in .gcode, then that's the file we should be parsing.
I don't know how the other slicers (Simplify3D, MakerWare, etc) handle command line arguments, but it may well be possible that they don't allow you to specify the output file either.

I'm also not sure that all slicers (or even Cura) would name the output file the same (ie, with a '-0' suffix). What is known is that a file that is produced by a slicer will always have a .gcode suffix, and will also be the last modified file in that folder.

What are your thoughts?

from roboxslicerextension.

I agree with this global solution it's why I had put the code in the global Slicer class.
looks ok but I don't know if it's easy to get last modified date from a file in java I need to give it a try tonight

from roboxslicerextension.

ok there is a File.lastModified() timestamp easy to do I will do it tonight

from roboxslicerextension.

Looking at '-0' is Cura's specific.

Looking for last modified date is not sufficient. What would happen if users have ability to save .gcode and they don't? Or save file somewhere else? Maybe we need to identify a file in our printjob specific folder (or even create one ourselves!) with appropriate timestamp (files can be 'touched' in Java) and then make search based on that date - anything that is later (and has '.gcode' extension)?

@Benraay Fetching last modified .gcode should go to Slicer and we can even combine searching for '*-0.gcode' and last modified file somehow in Cura20 file, too.

from roboxslicerextension.

looking for the last .gcode file is only in the specific PrintJob Folder with the robox hash for that printing so there are few chances that there would be another gcode file that was modified just after the one from the slicer the check is done just after we close the slicer.

from roboxslicerextension.

But is there a chance that .gcode won't be saved by the Cura (user action in Cura) and we'll pick wrong .gcode file? I propose we 'touch' all .stl file in that dir and find the latest .gcode that has timestamp after .stl files. I don't mind give it a go this evening if you want. Otherwise - its all yours! :D

from roboxslicerextension.

not bad checking the stl date is a good idea I let you do it (I have a new Assassin's creed to test also tonight !!!)

from roboxslicerextension.

Film or game? :)

from roboxslicerextension.

Game the "Syndicate" opus

from roboxslicerextension.

Cool! :)

BTW I've typed something in - didn't get chance to test it yet. If you have chance have a look and let me know if it is on the right path...

from roboxslicerextension.

OK - here is reasoning behind what I've done:

• good I looked more deeply into searching for the gcode file as it definitively does not belong to Slicer class, but Processor
• also, setting up stl files' timestamp is completely unnecessary as processor 'knows' what time it invoked slicer (of a choice) and will look for files with timestamp after that time
• and only if expected file is not there
• beside that, if only one gcode file is found it will be used straight away
• if none are found we'll just drop out with error message written in the log and exit code (result/rc code) set to some value
• but, if more files are found we can then ask (selected) slicer to decide which is the best (as in Cura one with ending with '*-0.gcode'.

I feel far better now as I think we've here covered all cases. What do you think?

from roboxslicerextension.

very nice it's really strong like that !

from roboxslicerextension.

@natdan, that sounds like an excellent solution. Well done! I won't be able to test it for almost a week though, so if someone else can test it then I'll move it live.

from roboxslicerextension.

@nebbian I did 'test' it and part where appropriate gcode is found works (see the log) but got exception:

18:56:11.648 CONFIG  [com.roboxing.slicerextension.flow.Arguments ensureArgumentsValid] Assumed AM installation dir as /Applications/CEL3.00.00 
18:56:11.657 FINE    [com.roboxing.slicerextension.flow.Controller process] Selecting Cura20 - current dir contains 'PrintJobs'; /Users/daniel/CEL Robox/PrintJobs/73effcffc76d47b0 
18:56:11.662 FINE    [com.roboxing.slicerextension.flow.Controller process] Invoking Cura20 
18:56:11.662 FINE    [com.roboxing.slicerextension.flow.Cura20 invoke] Invoking Cura20 with args:  
18:56:11.663 FINE    [com.roboxing.slicerextension.flow.Cura20 invoke]   /Applications/Cura.app/Contents/MacOS/cura 
18:56:11.663 FINE    [com.roboxing.slicerextension.flow.Cura20 invoke]   file 
18:56:11.663 FINE    [com.roboxing.slicerextension.flow.Cura20 invoke]   /Users/daniel/CEL Robox/PrintJobs/73effcffc76d47b0/73effcffc76d47b0-0.stl 
18:57:10.475 FINE    [com.roboxing.slicerextension.flow.Cura20 invoke] Successfully executed Cura20 with args: /Applications/Cura.app/Contents/MacOS/cura,file,/Users/daniel/CEL Robox/PrintJobs/73effcffc76d47b0/73effcffc76d47b0-0.stl 
18:57:10.478 FINE    [com.roboxing.slicerextension.flow.Controller process] Finished slicing with Cura20 
18:57:10.479 WARNING [com.roboxing.slicerextension.flow.Controller process] Cannot find resulting gcode file named 73effcffc76d47b0.slicer.gcode 
18:57:10.481 FINE    [com.roboxing.slicerextension.flow.Controller process] Searching for gcode... 
18:57:10.482 INFO    [com.roboxing.slicerextension.flow.Controller process] Found another later gcode file named 73effcffc76d47b0.slicer.gcode 
18:57:10.484 FINE    [com.roboxing.slicerextension.flow.Controller process] Invoking post processing Cura20... 
18:57:11.413 SEVERE  [com.roboxing.slicerextension.flow.Main main] Error processing :  
java.util.IllegalFormatConversionException: d != java.lang.String
        at java.util.Formatter$FormatSpecifier.failConversion(Formatter.java:4302)
        at java.util.Formatter$FormatSpecifier.printInteger(Formatter.java:2793)
        at java.util.Formatter$FormatSpecifier.print(Formatter.java:2747)
        at java.util.Formatter.format(Formatter.java:2520)
        at java.util.Formatter.format(Formatter.java:2455)
        at java.lang.String.format(String.java:2940)
        at com.roboxing.slicerextension.flow.Slicer.postProcess(Slicer.java:194)

It seems that this branch is not really working. @Benraay - what other changes does the branch contain? Is it worth rebasing it on master (I started, got to conflicts and real life kicked in so I didn't return to it last night). Now I am not 100% sure what to do:

• continue with rebasing of this branch fixing conflicts and above exception or
• reapply commits at top of master (in a separate branch)

Unfortunately I won't be able to do anything tonight (tomorrow evening is far better for me). If I get chance to analyse commit history of both master and cura-2.7 branch I'll do so...

from roboxslicerextension.

I did'nt change any other part of the code, do you have the same bug with the same file with master version ?

from roboxslicerextension.

I didn't get to try it out. Good point. I'll do so before doing anything else.

from roboxslicerextension.

I just added a gitIgnore for .idea folder

from roboxslicerextension.

👍

from roboxslicerextension.

OK - I've managed to finally wrestle with rebasing/differences between branches and exception I've got. It seems that all is fine regarding changes in master vs cura2.7-support branches (I've been rebasing it on wrong 'master' branch - my fault). Exception happens to me in both master and branch and is probably due to old version of Cura I've been using (2.3.4 rather than 2.7).

So, if someone can be so kind (@Benraay or @nebbian :) ) to test it out so we can merge it back to master... Shell we make a PR?

from roboxslicerextension.

BTW in the mean time I'll try to sort out my Robox (clean my extruder as it seems to be jammed) and install Cura 2.7 to give it a go myself, too.

from roboxslicerextension.

If it's compiled I'll give a go..I'm stupid enough to own two Robox printers ;)

from roboxslicerextension.