I noticed this same bug when running 1.4.0 on Windows 10. I don't know if there is a fix for it, but it was one of the reasons I decided to download the code and see if I can help make this great program even better.
We've seen some intermittent issues with the Mac version of MatterControl, and while we've got a new build in the works it's not reliable enough for release just yet. As in my post on this topic on the old forum (4th from the top), you can copy the terminal text and send it to us so we can debug. If you have another operating system you can use (Windows) to use in the meantime that will probably be the best way to get you up and running the quickest.
Besides telling MatterControl is was a MakerBot Replicator 2 printer what other settings did you change from looking at the Maker Architect manual? I have heard people say this but no one elaborates on what the settings from the manual are. I have this exact printer and I am running into some issues with it not using the whole print bed and some stuff being to small in size. Any help on getting the settings down right would be much appreciated.Thanks,Adam
@tellingmachine said:> Is it as easy as installing MatterControl onto the new computer and move all files from the old AppData folder into the AppData folder of the new computer?Yes, it is. > is it possible to share MatterControl files and data between computers via a file synchronization service like Dropbox?I see no reason this wouldn't work, but have not tested.
Yes, we have seen this lately as well.When you edit a file in the queue, it gets saved in the same directory the original file was in. If your original file was an STL, the edited version will get saved as an AMF instead. If your file was already an AMF, it simply gets overwritten.Unfortunately, right now MatterControl suppresses any errors encountered when saving files. If, for instance, you do not have permission to write to that directory, or there is no space left on the drive, then MatterControl will continue as if nothing went wrong and won't inform you of the issue. This is something we are investigating and will hopefully have fixed in the next version.
Assuming you're referring to something like Slic3r's XY Size Compensation feature, MatterControl does not have a built-in feature that will perform the same function. You'll need to either edit the steps per mm in your printer's firmware or EEProm Settings, or manually change the model's size to compensate for the inaccuracy.
Thank you Ryan. Ya, I understand now that there would need to be a sensor for the filament in order for any g-code to work...The print did stop, but it was still in the last location where the filament ran out... printer was not paused, it just stopped.
@smithtec said:> I don't get a very nice surface anywhere I have support. What settings do I need to be looking at?The ones I mentioned in my previous reply are a good place to start. The interface layer tends to create problems, so I typically just leave that out. The X, Y, and Z distances create a gap between the model and the support which can affect aesthetics, so adjust those as needed. Just don't make them too big, or the model's overhang will droop.
What's changed from when you were able to print and when you weren't? There's got to be some variable that will explain it.
Try printing a different, smaller model with the same settings. If it prints, it's just the model. If you have the same issue with the smaller model, then there's one or more settings causing the problem.
You say it is able to extrude manually using the controls. That narrows it down a bit. It means its not an electrical or mechanical issue.
First thing you should do is check the gcode terminal while printing to see if any errors are being reported by the printer. For example <-echo: cold extrusion prevented. If nothing shows up in there, then lets make sure that MatterControl is actually telling your printer to extrude. Export both the gcode file and your slice settings and post them.