How do you print multiple objects and change z height between moves?

[jemma-redmond 0]

Ok so I want into objects, namely well plates.

So I can make multiple objects, but when it makes one and moves to the next, it hits the well plate side. Is there any way to change the z height after the first object is printed and repeat for all of the other objects?

Thanks!

:-P

 

[gr5 2,069]

This is a more complicated subject than you might realize.

Are you aware that you can do "print all at once" or "one at a time"? It's under the "tools" menu.

I'm not sure what a "well plate side" is and how one would be in the way of the print head. There are also some settings on the "machine settings" used just for this type of thing. One of them is "gantry height" which means if you print something really tall and then go to print something else you might bang into it somehow with part of the printer. Is that the issue? Unfortunately (maybe) this just puts tall prints back into "all at once" mode so maybe you don't want that. Or maybe that's okay.

There are other settings "minx" that may help also.

You can certainly hand edit the gcode. It's easier than you may think. The move command is G1 or G0 (there's no diff in Marlin) and then you can specify X,Y,Z,E axes and you can leave off an axis if you don't need it to move. After a little practice with this you could adapt the "tweak at Z" plugin to do your Z move automatically. Plugins are easier to mess around with than you might think - they are pretty simple.

What kind of printer do you have? And please add your country to your Location in user preferences.

Maybe a drawing or photo of the "well" would help.

 

[stevegt 1]

Ah. I get it. After seeing her other posts talking about cell growth, I think Jemma's talking about well plates, the plastic trays with arrays of wells in them, used in cell cultures, DNA sequencing, etc. http://goo.gl/NjBQUL

Jemma, printing a well plate should be straightforward. Printing more than one well plate at a time should also work; you probably want to go into Cura, and select "Tools|Print all at once", like gr5's saying. That way it will do all of the objects' bottom layers first before moving up to the next layer, etc. to avoid collisions.

I'll post an idea about PLA alternatives over in your MSDS topic. (Short version -- try t-glase).

Steve

 

[jemma-redmond 0]

Hei! thanks for the replies guys. "well" what I have been doing is printing objects into 6 well plates and pitrie dishes. Sort of like osteoblasts (bone cells) etc

It works fine if the object is of a certain size... so when it reaches the top of the object (the top of the well) then it moves across into the next well, then drops and prints the same object again. However if the object is really teeny then it hits the side of the well dragging the plate.

There are a few solutions I can see, like 1. would be printing each object as a seperate gcode file (a real pain) or 2. editing each gcode file (again a pain) or 3. some sort of plugin that tells the printer to move up z amount (or rather move the platform down) after each object then proceed to the next one.

We have been toying with the latter but having no luck so far. :-(

While we could print a well plate, considering it needs to contain a liquid medium this isn't really practicle.

Thanks,

Jem

 

[stevegt 1]

Ohhhh.... Placing an existing well plate on the glass, and then printing objects down in the little wells? Wow, I'm surprised that works at all... :wink:

Hm. You could do it, but unless someone who knows Cura's internals better jumps in here with a magic setting, I think it would need either post-processing on the G-code (probably with a python script) or a plugin.

A python script to do this looks easy -- look for each ";LAYER:0", then find the next "G0 ...", and insert something like a "G0 Z100" before it, then insert a copy of the "G0 ..." without the "Z..." parameter, then print the original "G0 ...".

EDIT: Whups, hang on, it's not so easy -- there's an X/Y move before that LAYER line that sets you up for the next object. Looking, hang on...

 

[gr5 2,069]

Now I get it! Your build plate basically has walls and you need to hope over the wall before printing the next.

What you should definitely do is hand edit a few of these files so you really understand exactly what edits to do.

Then write a plugin to do it if you will be doing this a lot. Please publish the plugin for others to use on the plugin page.

Plugins are pretty simple - you can take an existing one and rewrite it. They look for strings in the gcode (such as "skirt" or "layer:0" )and add a few lines before or after that. You can have it move up after one print, then over before the next print. You can steal the XY locations from the first point on the next object to print or you might not have to do that.

If in the past it has simply worked fine by having the part "tall enough" then you could just add a Z move at the end of every sub-part. Such as G1 Z50 (move so bed is 50mm from print head). I'm not sure if that will always work as there is probably a diagonal move after that and going XY only over to the next part might be best.

 

[stevegt 1]

Okay, here's a Quick Hack: Print a tall tower, outside of the well plate, that is higher than the well plate. Make sure to arrange things so that the tower prints first. Here's why: Cura always writes a Z move at the end of each part that is as high as the highest part.

There's still no high Z move before the first part, which is why that tower needs to be the first part printed; that will keep you from crashing into the well plate when approaching the first well.

Related code is at https://github.com/Ultimaker/CuraEngine/blob/b27a51e031c9dce3055f8931403d544b892b93df/src/fffProcessor.h#L509

(Note to self and lurkers: maxObjectHeight really should be settable in the UI and passed through from Cura/util/sliceEngine.py to fffProcessor, to allow users to solve this sort of problem without printing a tower. Right now it's hardcoded to 0 in fffProcessor, then increased via max() as each part is generated.)

Steve

 

[stevegt 1]

George, the head moves to the X/Y position of the next part before the LAYER:0 line. This means the regex fu that would be needed in a plugin is nontrivial, because it has to find that LAYER:0 and then backtrack to find the first G0 relating to the next part.

My first attempt, trying to match all of the "G0 ... LAYER:0 ...G0' part delimiters while extracting the relevant X/Y/Z numbers, never was able to complete. I finally killed it after several minutes:

 

re.finditer('(.+?)\n(G0.+?)\n;LAYER:0\n(G0.+?)Z(\S+)\n(.+?)', gcode, re.DOTALL)

Note to self and lurkers: We need a well-defined PART:n line emitted by fffProcessor, to cleanly delimit between the gcode of one part and the next. This hinting and others like it would enable easier plugin authoring.

 

[stevegt 1]

...looks like maybe we can use either the "G92 E0" or "G10" lines as a delimiter in the meantime... Fragile.

 

[stevegt 1]

Okay, this python script might work -- not tested much, so be careful until you know it works:

https://github.com/stevegt/UltimakerUtils/blob/master/well-plate-z.py

...someone might use that as the basis for a plugin to do the same thing.

 

[gr5 2,069]

Your code should work (mostly) with the current version of cura except Cura has a feature that the E setting never goes over a certain value (something like 9.99 meters?). When it gets close it does a M92 E0 again. This is because some versions of Marlin or maybe other firmware can't handle really large values for the E axis (extruder). However I doubt Jemma is printing more than 10 meters of filament per part so it should work fine for her.

 

[stevegt 1]

What about delimiting on the G10 then?

EDIT: Whups, and we also need to add a high Z move at the end, or else we do a perfect print of everything and then knock the well plate silly when we go home. (I think everyone who owns a CNC machine has made that mistake at least once. It's a great way to break a bit while destroying a perfect, finished part...)

 

[stevegt 1]

Okay, now delimiting on G10, and added the Z move at end. (Helped to delimit on G10 to get the latter anyway.)

Pushed to github, but completely untested...

 

[stevegt 1]

Heh. I just saw that Jemma updated her profile -- she's got a UM1, and I have no idea how compatible it will be with my script -- I have a UM2 and the script assumes UltiGcode. It should be a start, at least. I wanted to tackle this anyway, not for well plates, but for similar situations I've found myself thinking about -- at least I have a good feeling now that it's doable.

If I ever have to touch Cura for anything else, though, I'm probably going to add some better hints in the gcode comments to make life easier for plugin authors.

Steve

 

[Dim3nsioneer 557]

In most cases, plugins which work with UltiGCode also work fine on standard RepRap GCode. The other way round it is much more difficult due to missing information such as print temperature.

 

[gr5 2,069]

Yikes - no, G10 is "retract" and if you have retraction enabled, it occurs all over the place. G92 E0 was a much better choice.

Also G10 only works on UM2 as it is "ultigcode". You had it fine before. It's just that it wouldn't have worked on really massive prints that need many meters of filament for a single part. Which seems unlikely if you are printing at least 2 objects and both are shorter than the gantry height.

 

[stevegt 1]

Yikes - no, G10 is "retract" and if you have retraction enabled, it occurs all over the place. G92 E0 was a much better choice.

 

Whups, it was late. Reverted back to G92, now triggering end Z move on M25, pushed to github.

 

[jemma-redmond 0]

ok I have a "simples" solution and this allows an interesting possibility. Lets say you print object 1, you create the gcode and save the file, you then reload the same stl file again, you change the profile settings, but this time you move the object x distance on the platform, again you save the object as a different gcode.

Now all you need to do is copy and paste the gcode from the second file into the first. It works! Once it finishes printing the first object it goes back to the start and then starts to print the next object.

So its almost like creating one big batch file. :-P