This topic contains 10 replies, has 2 voices, and was last updated by Mike 6 months ago.
-
Posts
-
@benraay Cura3.2 has been released, and the reason why I am giving you a shout, is the drawing of the tool paths, and filament extrusion is very good, plus the animation is much improved. You can’t get any realtime monitoring, as far as I know, as the Robox is not connected via USB.
Ultimaker Cura-3.2.0-Darwin.dmg
I’ve been dropping the saved files into the transfer and execute code window within AutoMaker Preferences.
For any others the whole definitions have changed and been reorganised, so it’s a little harder to set things up with a non-supported printer, but the slicing and laggy behaviour is much faster than I remember. It’s also got their implementation of variable layer height amongst other things.
Anybody else trying this?, as it’s got some very fast print speeds by default, and I seem to have a bed temperature issue, which will be a noob mistake somewhere, but I’ve checked the “Heated Bed” option, and got temps in Materials and in the Profile. 😕
Thanks mike @17bt I will give it a look I love the amount of parameters you can tweak in cura
if they have added a tool path this is very good I love this feature in S3D
C# .Net, PHP, Angular JS, Fullstack and mobile développer and CO-Founder of www.crossshopper.com
@benraay They have created a very good tool path animation, with very good drawing and it’s very clear to see how the object is being sliced and extruded. Obviously, it’s not real time communication, as I can’t talk to the Robox through this interface…yet. 🙂
You can also load gcode into it, but this is no different to other slicer tools in that respect. I just can’t get the bed temperature to start, without manually editing the gcode at the moment, and still looking at their printer profiles to see how to get around it.
I sorted out the bed heating and the gcode is working fine now. I got the syntax of the variable wrong. M140 S{material_bed_temperature_layer_0}
Values are getting converted OK now. 🙂
A little side tracked today with other projects, but the Cura 3.2 test print is stabilising now as the settings get dialled in, with all done using the DEV1 head, using PET-G and 0.2mm layer heights
Cura 3.2 top left and a later version bottom right. AutoMaker top right with best guess settings, and Simplify3D early days settings bottom left. The latest Cura is done with a 20% fill & 6mm apart, and it shows, whereas the AutoMaker print is 33% fill and 1.5mm apart, The latest Cura is the best quality so far, bar the blistering on the top surface caused by the lower fill percentage.
Ok, so this is going better now, and I understand the Ultimaker Cura tokens more, as well as how the calls are made and which files it is looking at, so I could write. definition for the Robox printers I have here, but for now, there is zero interest, and my curiosity is satisfied I can get it to work with the Robox DEV1 head very easily, and already bettering the results from the current AutoMaker 3 settings.
It just needs a little more refinement on the retractions, or some of the “Check all” defaults need switching off, but I’ve done no work on the bridging or support settings yet, plus I might make a tweak to the start code again and use some of new material selections, you cannot make in AutoMaker to improve the bed levelling layer routine, but that will lengthen my shorter start print routine.
Another area that can be improved, and definitely could be made better, as the picture explains with the status messages… 🙂
Well, an interesting start to the day, and Cura 3.2.2 (macOS) fixes the font issue in the sidebar, but more importantly, a tweak to a script within the Cura PlugIns folder, and I now have this option.
Another tweak later, you get live temperature updates
Picture, using DEV1 head, 0.6mm nozzle PET-G and 0.2 mm layer heights all at default settings, and looks like too much flow, maybe too hot and not enough retraction, but this is the first small object I have tried, aka the door latch hold off clip (approx. 25mm x 6mm x 9mm and 2mm thick)
So that’s the lot for Cura 3.2 today, and the “torture little test” at 100%, as it’s hard to optimise for PET-G with such small shapes.
Picture for reference, middle front two are the better in reality…and don’t forget it is a 0.6mm nozzle at 0.2mm layer heights too, with no needle valves. I’m pretty sure a smaller nozzle would help with this test.
I have got a lot further with this, but when it comes to the Dual Material, Cura 3.2.2 (the screen font bug update of 3.2) is stumped, as they don’t have a means of doing conditionals in their post processing like Simplify3D does at this time. It can be done externally with a Python script, and that might be a direction to go in.
Another stumbling block for anybody using Cura 3.2 to slice and format gcode suitable for the Robox is at the moment, and unlike early versions of Cura, and Simplify3D, Slic3r and others, you cannot save these specific post processing scripts with your profile, so that means they have to be manually entered every time you make a print, which is a big flaw. I have been informed the post processing save function might make it into 3.3, as there is a pull request being looked at. 🙂
However, Cura 3.2 is able to work with the DEV1 head, and the QuickFill heads if you know what to add.
It’s rather embarrassing that I can get this far with just my knowledge levels, but the work I’ve seen @nebbian @benraay @click do with Robox Slicer Extension, getting this to work further is just a small step away. If you can write a Python script to do the equivalent post processing conditionals to the output file, like I’ve seen, it’s small beer to add these currently unsaved post processing scripts into this as well, so one “program” will effectively convert the Cura 3.2 sliced output into Robox acceptable gcode.
It is also not beyond someone with access to AutoMaker to create an Advanced User workflow, and take this latest SteamEngine variables and parse these like the Robox post processor does already, and create the files needed that AutoMaker drops in the Print Jobs folder at the moment. 🙂
The real work is making sure these fudges cannot be undone by messing with the settings within Cura, or choosing odd material combinations in your part for support, infill, etc, that might do something not foreseen, which means testing the software by doing this and checking the gcode.
Anyway for the picture bunnies… Cura 3.2 in action, showing support generation (excellent by the way) and their take on variable layer height aka Adaptive Layer Control, which is fast, automatically varies the layer height in incremental steps, and works best with larger diameter nozzles.
It can be caught out, as I found out trying to do a 0.3mm outer layer with 0.8mm for infill and support, and starting with a 0.3mm layer height the yellow portion in the picture was set by the defaults ( I didn’t spot it) at 0.4mm layer height, which is beyond the capabilities of a 0.3mm nozzle.
I also didn’t optimise the material settings with small test prints, and I did notice afterwards their defaults were quite different from the Simplify3D optimised ones I used with those prints.
The persistent saving issue still remains, but the post process steps have been refined, and made more flexible, in the last few days. At the moment the QuickFill and SingleX heads are catered for and analysing the gcode is producing more failsafe results.
There is more scope with using “regular expressions” within the Post Processing Scripts options, especially with Search and Replace, to catch more of the Cura specific syntaxes, and flip them into a Robox firmware format.
Somebody else is looking at this too, so in a few days, there might be a more refined Python fudge to get this working. The idea is to use grouping of all these settings, and combine them into a Robox Specific Script, until the persistent post processing saving issue is resolved by the Cura development team. This way, you select the printer type, and apply a drop down post process each time to convert the gcode, which is a lot easier than adding 6-8 Search and Replace scripts each time, you open Cura and start a new print.
Onwards and upwards 🙂
Definitely an onwards moment last night for the Dual Material head, as I reviewed the latest post processing script that @click has been “Pythonising” over the last three weeks. He’s probably sick of the emails & annotated pics & gcode attachments, and the back and forwards comments when things weren’t going right, BUT perserverance has been rewarded. 😀
Last night I analysed the post processed gcode and this morning looked at some trickier ones, and the RoboxPostProcessing script is working exceedingly well.
Just finished a test print, just a little work to refine (first layer height - green), but no “graunching” on the extruders, no poor needle valve events, so that works for me.
You must be logged in to reply to this topic.
