We don't yet support different size nozzles in the same print but it is in the road-map. We just shipped 1.7.0 with lots of updates to path planing in the slicer and our focus is going to be on editing tools as the next big feature. Once that is in we are looking to do lots more with multi material printing including various nozzle sizes.
Yup, that M107 must be it. It's the only difference between the two codes. Even if I put it at the very end of the start code it changes everything. No bed heating, slow homing...
So, a little clarification, at the risk of making myself look stupid. The info I had about the M190, M104, M109 codes was coming from the RepRap wiki g-code page. My memory told me it was 3D printer g-code in general. I guess there are still inconsistencies between the 3D printer manufacturers. In fact, the M107 fan off command is deprecated in RepRap; maybe that's the problem. I believe the FlashForge control is based on RepRap.
For now I am going to have to translate all my files through Replicatorg to clean out the M107, unless there is another way to get it out of there.
Unless, of course, I am still doing something wrong...
Still, nice piece of software! I've tried a few so far and this is my favorite.
Getting good results with 3D printing is all about experimentation. This is especially true for support material. The default settings give you a starting point to work from, but you will always have to tune things for your specific situation. Don't be afraid to make large alterations. This is the only way you will learn exactly what effect each setting has. Remember that you can preview what will happen using the Layer View. MatterControl also makes it easy to go back to the defaults if you mess things up.
This seems like an issue with the way MatterControl is communicating with your printer. After MatterControl sends a command, it waits to receive an ok back from the printer before sending the next command. If MatterControl does not receive the ok after a certain amount of time, it tries sending the command again. Your printer is taking a long time to complete the G29 command, so MatterControl is sending it again. Normally this is fine, since the repeated command is simply ignored. The line number error you are seeing is the printer telling MatterControl that it ignored the second G29. However in your case it seems to be causing a hiccup as the printer receives the redundant command and figures out how to deal with it.
We've opened a bug report regarding this issue. It may be some time before this can be addressed. In the mean time, I'd suggest upgrading your printer's firmware if possible. We have not seen this happening other versions of Marlin.
That line is the starting/stopping point of the perimeter loops. It cannot be avoided. The loop has to start and stop somewhere. You can see this in the Layer View. Use the slider at the bottom to scroll through a particular layer and see how the print head will move.
MatterControl does it's best to put that seam in a place where it will be well hidden. However in the case of a cylinder there are no good places to do that, so it opts for a single line running down one side of the print. Other slice engines (like Slic3r) give you the option to randomize the starting points of the loops. This creates small blemishes distributed randomly through the print. In some cases this might be preferable.
In some cases it might also be appropriate to use Spiral Vase Mode. In this mode, only the outer perimeter is printed, making the object completely hollow. The print head moves up continuously as it goes, laying down plastic in a helical shape. This means there is no starting/stopping point for each layer and the seam is eliminated.
Oh I finally understand. It's not that multi-extrusion is not supported for third party slicers... well yes, but technically, it's with the printers with more than 1 extruder that Mattercontrol removes that option. I usually single material prints though.
Thanks for your input. We've added some extra language to the warning message/prompt before Print Recovery runs on restart to give the user an opportunity to review the intended moves and to only proceed if they deem it safe.
I personally think there is a high degree of danger employing any form of print recovery where the end-stop is at z min as the size and location of the print is a variable and thus unpredictable.
It can be hazardous, and the feature is disabled by default for any Z min printer when using a stock MatterControl profile. Once enabled, it works, but things can still go wrong if not configured properly. The ideal solution would be to take values for the size of the hot end/carriage, part, and code in a way to automatically detect a good location to home the Z min. These improvements are possible, but will take some time to create if they are deemed important enough by the development team.