Cura work-around

jens55

@bot, I thought through your suggestion but decided that it isn't feasible for me. It's been probably a decade since I had a quick look at Visual C and am currently running Linux so I'd have to find some build environment under Linux. I am also anything but fluent in C or C++ or anything else for that matter. Last but not least, I would have to re-learn the whole mess every three or so months when a new version of Cura is released. Unfortunately at my age, my brain does not retain knowledge like this over 3 months of not touching things.
Thank you for your input though, it is an interesting idea and I wish I was able to implement it.

resam

@jens55 did you see my post above? no recompile needed, no difficult C knowledge either, just a bit of simple Python that should be easily google-able if you ever have seen a programming language.

Cura even has a built-in Search-Replace PostProcessing plugin script, though I'm not sure if it can access the very early setup commands.

fcwilt

@resam said in Cura work-around:

Cura even has a built-in Search-Replace PostProcessing plugin script, though I'm not sure if it can access the very early setup commands.

Yes it works for that.

Frederick

jay_s_uk

@jens55 on my toolchanger, i run all the prep stuff as part of start.g
So G32 etc,
Then who cares what tool cura picks as the printer is ready

jens55

@resam, yes I did see your post but to be honest I don't know how the DuetRRF plugin (which I use) could be used to help. At first I thought you meant to tell me about the search and replace post processing plugin which I could probably use somehow but again I would have substantial difficulty trying to limit the search/replace to just the very few lines at the beginning of the Cura print code. I am no wizard with regular expressions so I would be looking for a single code block of multiple lines and replacing that. Since the block is likely to change based on slicer settings, it would probably be easier to just edit the code manually which is certainly doable but would be very annoying to do with every re-slice of the model.
It is something I want to try to see just what is involved with it but I am still trying to sort out the filament system and what it can do for me.

fcwilt

@jay_s_uk said in Cura work-around:

@jens55 on my toolchanger, i run all the prep stuff as part of start.g
So G32 etc,
Then who cares what tool cura picks as the printer is ready

Do you include anything in your start.g that Cura's code may override, such as a temperature setting?

Just curious.

Frederick

jens55

This post is deleted!

jay_s_uk

@fcwilt On the toolchanger no. On my Delta, yes

fcwilt

@jay_s_uk said in Cura work-around:

@fcwilt On the toolchanger no. On my Delta, yes

Thanks.

jens55

@jay_s_uk said in Cura work-around:

@jens55 on my toolchanger, i run all the prep stuff as part of start.g
So G32 etc,
Then who cares what tool cura picks as the printer is ready

I currently have a single G28 in my start.g.
Suppose I want to put in a command to heat the very first extruder that Cura calls. How is that possible? I can only see heating up all 4 tools to cover every possibility. If I choose 210C for the nozzle temperature I have PLA and PETG covered but will likely be too cold for ABS.
Would it be possible to post your start.g? Do you switch between different start.g versions based on the filament you are running? I am having difficulty envisioning just how this would be done so that you set it up once and then it just works after that.

jay_s_uk

@jens55 this is what I have

T-1
if !move.axes[0].homed || !move.axes[1].homed|| !move.axes[2].homed	; If the printer hasn't been homed, home it
	M98 P"0:/sys/homeall.g"	; home y and x
G32
G1 X0 Y0
G29 S1

Once I've homed, levelled and loaded my height map its pretty much over to cura to do what it likes

fcwilt

@jay_s_uk said in Cura work-around:

M98 P"0:/sys/homeall.g" ; home y and x

This is just a bit of information you may not have but it may be good to know.

G28 will invoke homeall.g as does your M98 command but there is a least one difference, G28 first marks all the axes as un-homed.

In some cases that might be important.

Frederick

jens55

@jay_s_uk, thanks ... so if I can compare that to what I have, the single G28, it is very similar. I have T-1 in my Cura start code, you test for un-homed conditions and I just blanket home. I don't bother with mesh bed probes.

There is no setting of any hot end temperatures so Cura will run just fine but at least the way I have things, there is no priming happening on the first tool and any subsequent tools are retrieved and then primed rather than primed and retrieved to wipe the nozzle tip clean.

Do you maybe have a separate nozzle wiping routine (pebble extruder maybe?) .... maybe that is a better way of approaching it rather than to utilize the standard wiping action that is part of the park/un-park action.
As I am thinking about this, this seems like it could take care of all the issues .... some more thinking is required.

Where do you call for your wiping routines and what do you have in your wiping macro?

jay_s_uk

@jens55 I have a little steel brush mounted in front of the hotend so when it's picked up from the tool holder it's also wiped clean.

jens55

@jay_s_uk, but how is it cleaned if the tool is picked up when it is still cold? Do you prime the nozzles anywhere ?

jens55

Specifically, when Cura picks up the very first tool in the print file (Tn), it hasn't been heated yet so whatever is hanging on to the tip will stay on the tip. This isn't a problem in subsequent pickup and drop off routines.

jens55

@jay_s_uk, the other tools get primed in Tpostn.g where I first wait for the temperatures to reach the designated setting and then do a short extrusion and a short wait. That extrusion always ends up being done AFTER the tool is picked up and wiped ... so I wipe, extrude and then drag crap hanging off the nozzle into the print.

jens55

@fcwilt said in Cura work-around:

@jay_s_uk said in Cura work-around:
M98 P"0:/sys/homeall.g"	; home y and x
This is just a bit of information you may not have but it may be good to know.

G28 will invoke homeall.g as does your M98 command but there is a least one difference, G28 first marks all the axes as un-homed.

In some cases that might be important.

Frederick

That is an interesting tidbit and one that I am sure will bite me in the bum sooner or later. Hopefully I will recall this post when it does catch me !

dc42

@jens55 why not set default temperatures for the tools in start.g using G10 or M568 ? Then use M116 in the tpost.g file to wait for temperature before doing the purge.

jens55

@dc42, I already use M116 in the tpost.g files. The reason I am reluctant to set default temperatures is because those change. PLA and PETG could be covered with 210C but what about higher melting filaments?
I would have to change the defaults based on what material I am printing.
I am not saying it wouldn't work ... but I would end up having to mess with the defaults.
I would also have to set defaults for all 4 extruders even though I might just use one extruder .... and I would have three extruders sitting there cooking filament.
Unless I can somehow grab the data from the Cura print file about which extruders are used and at what temperatures, it doesn' really look like a good solution.