Ok, thanks for clearing that up. It would be nice to not have to restart freecad every time I make a little change in one of the python files. I'll play around and see how it works.

This a python design issue. The normal way to work around this, is to import the module once again, to make sure to have a reference to them in the local namespace. Then one can issue the "reload" command with the reference (name) of the module. Thanks for the tip shoogen. Can you point m...

Yes, 14.03 seems to be working well. Made a couple of prints and the speed is now completely under control. One thing I should have mentioned before is that every time you run git pull, you should restart freecad. For some reason it does not reload some of the macro files automatically. Anyway, I j...

Err https://dl.dropboxusercontent.com ./ Sources      AFAIK, 'Sources' means that you have the repository set to deb-src, which is a debian source code archive. I am only providing a binary package so make sure your entry looks like this: deb https://dl.dropboxusercontent.com/u/63300398/deb-package...

I went back and tested with the CuraEngine shipped with Cura 14 along with the latest CuraEngine from git and the print speed is working as it should. If you can, check the report view (or the log) for the "inset0Speed" and "insetXSpeed" settings and verify that they are the same...

Strange, its working ok for me.

When do you get the 404? Is it during apt-get update? If so please post the error.

Ok I added a quick fix. Basically the issue was that the newer version of CuraEngine has the parameters "inset0Speed" and "insetXSpeed" which control the print speed when doing the perimeter and are both set to 50 mm/s by default. In the macro I set them both to be the same as th...

quick61 wrote:One note, I think it happened with the push before this one - the linear speed problem seems to be back. It's printing the perimeters at full tilt once again. Maybe the old code sneaked it's way back in there some how?

Thats strange. Please post your settings file and I'll take a look.

kwahoo wrote:Works fine for me.

ulrich1a wrote:It may be a Debian wheezy issue. I got the same message with a Radeon HD4670.

Since kwahoo has no problems running a much more recent version of mesa I'm guessing that is the problem.

Maybe someone else can confirm this but none of the MSAA types seem to work on my Ivy Bridge HD4000 chipset. The console gives this warning when I switch between them: Coin warning in SoQtGLWidgetP::buildGLWidget(): wanted sample buffers, but that is not supported by the OpenGL driver OS: Debian GNU...