Flow

[natdan]

I've been thinking walking to work this morning: I think I have clear(er) idea what the code/control flow could be. Let me know if I am closer to what you had in mind.

• CuraEngine (CuraEngine.exe) is a script that invokes our jar file passing all program arguments to it.
• the jar file captures arguments (and parses them?) and stores them for later
• the jar file reads config file .roboxslicerextension file from ~/CEL Robox - file stored by our separate control program (which, BTW I started shaping in UI - will submit something over following days)
• that config file describes which slicer to start - just by naming it. Those names will correspond to Java classes with more in-depth implementation of transformation of program arguments, knowledge which config file's entry to read to find where's appropriate executable (Slic3r for instance) and will have implementation of gcode transformation so it confirms current Cura's format needed for AM post-processor
• also config file describes if there is a script (*) to be called after invoking slicer
• it will then invoke gcode transformation so it conforms to Cura's format for AM post processor
• further check config if we want/need gcode preview (and which kind)
• and again check if config has stored another script (*) to be called before returning control back to AM

(*) by script I see any scripting language allowed by Java Scripting framework (JSR 223) or executable on the target system (i.e. shell script of batch file or anything else).

All above to be defined in presets in Robox Slicer Control program (Default AM Cura, Slic3r, Cura 3.0, Simplify 3D, Custom) - where any will allow you to amend default and add your stuff in. With all of that - we'll be able to add any scripting needed for existing AM flow + preview, too, (but not of post-processed code - not in this way!) without going to 'uncharted' territory of other slicers.

Does that make sense to you guys? I don't mind going with it and add more 'skeletal' code which will confirm to above algorithm...

[nebbian]

That sounds really good. It certainly matches what I had in mind for this system.
The only issue I have is that you need to remember where to find the "separate control program", or where the config file is, when you want to change slicer. I still like the idea of a popup window that asks you if you want to configure it or change slicer. If a popup window was implemented then it's just one more click to say "Go", optionally there could be a checkbox to say "Don't show this window again".

[natdan]

Hm. Why not adding it to the config as well? Originally I thought that having extra popup each time I start printing is a bit of a drag and I wouldn't want to click continue just to have ability of changing things. But, when config entry is true it will ensure that 'Control Window' is open (if not already opened) but it won't stop the flow anyhow. You'll have your visibility that you can change things (at any time not only when you start printing!). If that annoys you - you can just tick one box off and it won't be doing it automatically.

Also, I don't think one should directly tinker with the config file - it should be configured with that extra program...

Oh, something else occurred to me as well: how does this fare when AM starts slicing things in parallel for calculating time and material costs? Is same flow invoked as well? Is there anything we can do to detect it vs 'real' print?

[nebbian]

I guess I don't understand how the Control Window will open. Is this a separate program that you have to start manually, or does it start when you first start slicing?

Regarding calculating times, right now if the path contains "PrintJobs" then it will open the choice of slicer, otherwise it uses the default Cura slicer. This lets Automaker calculate print times without showing the slicer window to the user. This check is done inside the CuraEngine bash script.

[natdan]

"I guess I don't understand how the Control Window will open. Is this a separate program that you have to start manually, or does it start when you first start slicing?"

Sorry for the confusion. I see it as separate program you can open at any time you want and set up what you would normally want to happen when you slice stl(s). But for ease of use it can be opened (and is by default) when slicing starts - just to give you idea that you can change parameters. In my mind it shouldn't affect 'current' slicing nor stop it from happening, but set up parameters for any subsequent (given you changed them and pressed 'Save' button).

I would really like, if that's OK with you guys, to avoid the pause in the flow when we hit CuraEngine - the pause just to make user press 'continue' (if he likes the setup). Reason for it is that when you selected 'Default AM Cura Slicer' and not preview - you have AM operating exactly like it is now - without any stopping for extra confirmation or otherwise. Even if you select post-processing script (of some kind) you can just go through it. Same goes if you want to do a few prints with same settings with Slic3r, but command line version of it and not bring up whole setup/preview - UI app of Slc3r but just go and print stuff...

As I said - I don't mind such 'Control Window' opening up but not affecting slicing and original AM flow. You can always 'switch' (Alt-Tab) to it and amend stuff if you want, but it won't be holding up slicing if you didn't press (again) 'Continue' button - if you see what I mean! :)

[nebbian]

Yep that's fine. No problems. I just don't want the user to have to remember where that program is if they want to make changes. If it opens automatically when slicing then that's fine.

[natdan]

If you want to see a preview of simple UI - here's the jar file I come up today: https://www.dropbox.com/pri/get/robox-slicer-control-1.0-SNAPSHOT.jar?_subject_uid=318687283&w=AADBPJ1PiYgUtBb6J-iwONTlDkIJK6IYjXSX5Bx24HeOLg I'll make PR at some point but I've been playing with UI only for now...

[Benraay]

Hi, I found an issue in the slic3r_postprocess.pl and want to start the java thing but how do I merge the nebbian master inside my fork ? is there any option in github ?

[nebbian]

@natdan, Thanks for that but I can't see the file, I get a 403: forbidden error.

[Benraay]

Me too !

Le jeu. 1 juin 2017 à 04:35, Ben Hitchcock notifications@github.com a écrit :

@natdan https://github.com/natdan, Thanks for that but I can't see the file, I get a 403: forbidden error.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/nebbian/RoboxSlicerExtension/issues/6#issuecomment-305372702, or mute the thread https://github.com/notifications/unsubscribe-auth/AAs1WTNRSwIPceHQ7CkM7UaegRTksZSKks5r_iN5gaJpZM4NrOvd .

--

Benjamin Raaymakers

CONFIDENTIALITY NOTICE:

The contents of this email message and any attachments are intended solely for the addressee(s) and may contain confidential and/or privileged information and may be legally protected from disclosure. If you are not the intended recipient of this message or their agent, or if this message has been addressed to you in error, please immediately alert the sender by reply email and thendelete this message and any attachments. If you are not the intended recipient, you are hereby notified that any use, dissemination, copying, or storage of this message or its attachments is strictly prohibited.

[natdan]

Let's try again: https://www.dropbox.com/s/5pgplg7gqufic6n/robox-slicer-control-1.0-SNAPSHOT.jar?dl=0

[nebbian]

That looks really good. I was going to suggest greying out options for slicers that aren't installed, but it looks like you beat me to it :)

What is your intention with the pre- and post- processor scripts? I assume that these hook in before and after our special code that transforms normal gcode into Robox postprocessor compatible code?

[natdan]

@Benraay you should do it in command line using git. Two links I shared in your pull request explain in: https://help.github.com/articles/configuring-a-remote-for-a-fork/ https://help.github.com/articles/syncing-a-fork/

If you don't have command line git then you can set one with brew (brew install git) - if you don't have brew then you can easily add one: https://brew.sh/

Flow should really be (presuming that you're on your fork's master branch):

git merge upstream/master
git checkout -b new_pull_request_branch_name
-- do your code
git gui (to commit - or if you prefer command line git add ... ; git commit -m ...
-- create pull request
git checkout master
git merge upstream/master
-- and maybe when PR is happily accepted 
git merge upstream/master
git branch -d new_pull_request_branch_name

Do fix what you've done so far - just go with git checkout -b new_pull_request_branch_name and make new PR. Rest should settle itself. If you get stuck with git - just drop a short note here - I'll help you fix it. And don't worry - there's maybe only another one or two git things you should learn. And it will 'click' into the place over time. We've all been through this in past! :)

[natdan]

Plus - I don't mind explaining each step separately so you know what you're doing! :)

[nebbian]

Also, a really good git client is SmartGit by Syntevo, I've been using it for years, it is by far the best one that I've found. As @natdan says, we've all been through this. It seems a bit hard to understand at first, but once you figure out how branches and pull requests work, it should all click into place.

[Benraay]

Yes I did it with command line I found no way to do it with Sourcetree.

Thanks for these tips.

I also got stuck compiling the java source in Jar I did it with command line also but when I try to launch it I have a "no main or something" error How do you compile the jar ? Should be easy as there is only one class. My pure java tests are a bit far from me about 7 years

But I merged the master update to the safetomerge branch and cause nebbia Le jeu. 1 juin 2017 à 08:46, natdan notifications@github.com a écrit :

Plus - I don't mind explaining each step separately so you know what you're doing! :)

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/nebbian/RoboxSlicerExtension/issues/6#issuecomment-305403869, or mute the thread https://github.com/notifications/unsubscribe-auth/AAs1WXhHvU23GeVrrdeRWvrK_XNKAzokks5r_l4sgaJpZM4NrOvd .

--

Benjamin Raaymakers

CONFIDENTIALITY NOTICE:

The contents of this email message and any attachments are intended solely for the addressee(s) and may contain confidential and/or privileged information and may be legally protected from disclosure. If you are not the intended recipient of this message or their agent, or if this message has been addressed to you in error, please immediately alert the sender by reply email and thendelete this message and any attachments. If you are not the intended recipient, you are hereby notified that any use, dissemination, copying, or storage of this message or its attachments is strictly prohibited.

[natdan]

What is your intention with the pre- and post- processor scripts? I assume that these hook in before and after our special code that transforms normal gcode into Robox postprocessor compatible code? I don't know - I am experimenting at the moment. 'Pre' script, as I explained in the first post here, is supposed to happen after slicer has created gcode but before that gcode is shaped to suite AM post processor. 'Post' script is script that is supposed to happen after slicer's resulting code is shaped for AM post-processor but before control is returned back to AM. Some hooks people can add their code to do something 'different'. Like adding pause commands for capture nut at particular layer... In general those could stay empty and nothing would happen.

What I wasn't 100% sure about another step - do we expose another step where we change slicer's code to AM post processor compatible or keep it hidden and defined only by top drop down. Or expose it and make it greyed out if you select known slicer and selectable if you select 'custom' slicer...

Also, where would preview go? In my mind - before 'post' script (so post script can get some data you manually read from the browsing the gcode... It is going to be a tick box - 'Show GCode preview'.

Plus I'll add a few tool tips to explain above to everyone just by hovering mouse over labels, etc...

[Benraay]

@nebbian I will look smartGit I tried GitHub' desktop app but there are a lot of things missing like merging and some other stuff. For now I was using Sourcetree successfully But it does not pull the installer submodule

I'm always a bit young on git I used svn for years but Git is really much better, more flexible and safe.

I was using one or two branches and merging sometimes but all that pull requests on other repositories is new for me.

It's good to know more about how to use it. Thanks guys.

Le jeu. 1 juin 2017 à 08:55, Ben Hitchcock notifications@github.com a écrit :

Also, a really good git client is SmartGit by Syntevo, I've been using it for years, it is by far the best one that I've found. As @natdan https://github.com/natdan says, we've all been through this. It seems a bit hard to understand at first, but once you figure out how branches and pull requests work, it should all click into place.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/nebbian/RoboxSlicerExtension/issues/6#issuecomment-305405495, or mute the thread https://github.com/notifications/unsubscribe-auth/AAs1WSiDrFKnT7OcDlz41jOv-fDmKt6Yks5r_mBVgaJpZM4NrOvd .

--

Benjamin Raaymakers

CONFIDENTIALITY NOTICE:

The contents of this email message and any attachments are intended solely for the addressee(s) and may contain confidential and/or privileged information and may be legally protected from disclosure. If you are not the intended recipient of this message or their agent, or if this message has been addressed to you in error, please immediately alert the sender by reply email and thendelete this message and any attachments. If you are not the intended recipient, you are hereby notified that any use, dissemination, copying, or storage of this message or its attachments is strictly prohibited.

[natdan]

BTW - any preference for .roboxslicerextension config file? Java prefers 'properties' file

key=value

with 'structure' defined with dots in key names:

section.subsection.key=value

Anything else someone would rather like to see?

So far I can see only following config keys:

slicer=[DefaultAMCura,Slic3r,..,Custom] ; not sure about Custom as yet...
pre_processor_script=<path> ; optional - empty means no script to be run
post_processor_script=<path> ; optional - empty means no script to be run
show_gcode_preview=[true|false] ; self expanational
slic3r.path=<path> ; path to Slic3r executable to be run in case key slicer=Slic3r. Non optional in that case

Later simplify3d.path=<path> would do the same.

[nebbian]

As standard as possible works for me. What you propose sounds great!

[natdan]

:) - I must say that if I was very sure of it I would have proposed it in code, but I am not. And as for standard - there isn't such thing and I am open to suggestion and even refactoring if needed!

But, thanks - I'm happy to start that way for now.

[nebbian]

Another option that seems reasonably common is json, it's easy to parse, although harder to edit manually. Just an idea.

[natdan]

Yes. That was another option I was thinking of. See! It is not easy! :( There's XML, too, but I wouldn't go with it in this day and age... And maybe some other formats, too. Slic3r and AM (update part) use .ini files (which add extra complexity for parsing). AM uses .properties file and json (or json-alike) structure for preferences...

[Benraay]

My preferred is JSON as it is easy to read for a developer and easy to parse. But for non developer people maybe the .ini approach is the best as it is more difficult to make mistakes

[natdan]

if you guys think that's the good way forward - json it is :)

[Benraay]

guys I was trying to test the latest version with the jars but how do we call the jar instead of the bash / perl script.

did you make something with the installer ?

[natdan]

I'm going to do it now in the branch! Give me a moment...

[natdan]

OK. Branch now uses CuraEngine script that invokes jar. Also, branch now has updated installer that uses the branch to install from. So, if you use installer from the branch it will update AM from itself. Later, when check out the branch, you can always overwrite flow jar with freshly built one to test stuff further. ~/CEL Robox/ now has ~/CEL Robox/robox-slicer-extension.log log file to debug stuff...

All, kind of, works but it doesn't as AM post processor fails with

ERROR celtech.roboxbase.postprocessor.nouveau.o.a(PostProcessor.java:479) - Fatal postprocessing error on layer -1

I suspect it has something to do with current state of the Java post processor. When invoked in different dir than PrintJobs it invkes DefaultAMCura and it should work now (was for me). Do give it a go and let me know if there's anything else that's failing.

BTW I did have a good two hours adding log statements and scratching my head (read: debugging) to find out why AM is not sending parameters - just to find out that I forgot '$@' in the script! Doh...

[nebbian]

Regarding the error, this is usually because there is a printing move (or retraction?) before sending the layer numbers. It's most likely that you haven't installed, or selected, the slic3r profiles. The critical part for this error is to ensure that you have selected the Robox as your printer, and set this in the "Layer change" GCode: ;LAYER:[layer_num] I've done a couple of prints tonight using the java stuff, it's working for me at least.

[natdan]

You were right - I just didn't do it. But now I saw two more problems:

• slic3r_postprocess.pl needs to be made executable
• Robox_slic3r_config_bundle.ini needs to be updated with installation directory (path to slic3r_postprocess.pl). Currently it is hardcoded to /Application/CEL which is wrong. I'll see to it - but first I need to sort out Robox :( - something got stuck in, I think, extruder - so I need to take it apart and clean it...

[natdan]

BTW installed is supposed to make slic3r_postprocess.pl and CuraEngine executable files on OSX and Linux. When I test it I'll update our branch's jar file with the latest version. Still didn't add template processing for Robox_slic3r_config_bundle.ini ...

[nebbian]

@natdan I thought that we didn't need the perl script at all any more? I'm certainly not using it. So this means that the perl script can be removed, and also any references to it. It can be removed from the slic3r_config_bundle.ini as far as I am concerned. This might mean a bit less work :)

[natdan]

Oh, ... I see. My bad. I'll remove it from the config file.

[Benraay]

Exactly the perl script was doing the postprocess, it was not visible in the code because it was linked in the Slic3r advanced settings, maybe we need to update these settings and remove any reference to the script.

[natdan]

I've removed perl script from the branch and update both jar files. Feel free to install all from the 'scratch' and see if it works :)

[Benraay]

works for me !

[Benraay]

I just added Cura 2.5 support and spend some time to find good parameters, but it looks like the Extrusion values are too low, with Slic3r it's around 0,25 mm and with Cura they are about the half 0,16 mm. this needs some more tests. also Cura is freezing sometimes when launched with java I don't know why, also there is no parameter to specify the output gcode name !

[nebbian]

@Benraay, check the filament diameter. For some reason AM expects a filament diameter of 1.18 or something ridiculous. This means you need to set the filament diameter in Cura to 1.18 and yhen you'll get the right extrusion rate. Check the print profile sent from AM for the exact number.

[nebbian]

Sorry, the required filament diameter is 1.128mm. Check the .roboxprofile files. Why it's set to that baffles me, but it's required for good extrusion.

[natdan]

Shell we slowly wrap it up and move this to main branch? That way we would be able to work on improvements in separate branches and create PRs...

[nebbian]

Definitely.

I think that for now we should put a freeze on new features, and just get what we’ve got reliable for newbies.

Items that might need attention before going live:

• How does upgrading work? If someone is to upgrade later on, will all the right files get upgraded?
• What is required to switch from the old methods (perl postprocessing script) to the new methods (java)?
• How easy is it for a newbie to get the control window up?
• Has the documentation been updated to match our new system?

[natdan]

@nebbian :+1: One further thing we can immediately start investigating is making it work on Windows. There are so many people with Windows machines it would be shame lock them out. Oh, and someone needs to write up big disclaimer + licence for the first page of installer. I'm going to add it to installer (in a style of an wizard) - but I'll let one of you guys write up the text! ;)

[Benraay]

Sorry for the late answer, I was busy at work. Yes I tried already to change the filament to 1.128 but it's still underextruded.

Like @natdan said it would be good to make a stable release on the work already done, It would take some time before the prints are ok with Cura 2.5

Maybe we should make some tests with the Slic3r original version to know if it's ok for now with that version also.

And make it work on PC ! of corse.

[Benraay]

Is it possible to give a special path to the slicer if it's not installed in the usual place ? It's specially more the case on PC

[natdan]

@Benraay that was my thought as well. I'll do it as soon as we push this as working version. Those small 'issues' can be, then tracked to their own github issue + branch + PR - much easier to handle. Similar goes with your Cura 2.5 stuff, extra scripts for pre/post processing, etc... And Windows version, too.

[nebbian]

This branch has been merged with master.