Slic3r sequential printing

I’m having difficulty getting Slic3r to properly do sequential printing. It finishes the first object fine, but when it begins the second print, it doesn’t Z home the hot end and just starts printing in space at the level of the top of the last print.
I’m using Slic3r 9.9b and starting with the Lulzbot default settings for highquality and then selecting Sequential prints properly spaced. Any help is appreciated.

We touch on this topic briefly in the user manual found here: http://devel.lulzbot.com/TAZ/2.1/documentation/2013Q4/LulzBot_TAZ_2.1-User_Manual-ebook.pdf on page 117.

So I’ve clicked the box for sequential printing and kept the default settings as is. After finishing the first one the head doesn’t z-home. Has anyone had luck with it working with the latest version of Slic3r? If it’s worked for you, then how can I troubleshoot through this?

I’ve contacted Slic3r directly and the problem isn’t their software. Somehow TAZ is not responding to the gcode correctly. It is being told to z home inbetween the individual prints, but it is ignoring the command. How can that be? How do I troubleshoot this?

Can you post the g-code file that you are specifically having issues with?

Here’s an example. I have separate .stl’s that are dropped into Slic3r, then made into gcode using the Lulzbot high_quality.ini. The first one prints entirely, but when it gets to the second one it moves over and just prints, rather than returning to the plate. I’ve now upgraded to the latest Slic3r and the latest Printrun without any difference in output. I haven’t done anything to the firmware at all.
JetQuakeBadge.gcode (1 MB)

Looks like that file has 2 parts in it, and the Z axis should move down according to the code.
I wonder what is up with the firmware that is making this not work. Are you using the stock configuration for marlin that lulzbot distributes?
You might want to enable verbose mode in pronterface to try to catch any unexpected info.

Firmware is as it was configured at the LulzBot factory. No electrons have been harmed.

I’ll enable the verbose with my next multi-print. Thx!

I’m not sure if marlin or pronterface directly support this, but you could also do a dry run that would just do x/y/z movements and not extrude anything. More useful than having a failed print every time you test this.