Hi guy’s!
I’m using a wanhao duplicator 4s and astroprint thru raspberry pi and im using the replicator 1 profile for my printer and my problem is that im loosing ~5% on the xy axis when im printing.
Any one have the same problem?
1 Like
Hey Jonas we are aware of this bug with sailfish based printers and are working on a fix.
That would explain why some things have not been working…
which Sailfish version are you finding the problem with?
I’m running 7.7 wish is kick-ass expet for this bug 
Mine is running the stock CTC Firmware 1.0 (yes I know I should update).
Glad to find this topic. I’m also on duplicator 4s with sailfish 7.7. I use the flashforge dreamer profile. Couldn’t figure out why my cloud sliced parts where to small and didn’t fit.
Hope there is a quick fix!
5% shrinkage in the XY plane? Sounds like the gcode to x3g converter (GPX) is defaulting to a Replicator 2 profile and not a Replicator 1. The 1 series has 6% more steps/mm for the X and Y axes. Thus, if you use the profile of a Rep 2 (or 2X), then everything is 6% smaller in the XY plane.
Rep 2/2X: 88.88889 steps/mm
Rep 1: 94.11764 steps/mm
So a 1mm long line in gcode will translate to 89 steps for a Rep 2/2X. If you then print that on a Rep 1, you get 89 steps or 89/94.11764 = 0.945 mm. Sound like the 5% loss you were speaking of?
1 Like
Same result for a flashforge creator on sailfish. I’ve read about the steps per mm issue before, and used the creator rather than the creator pro profile, but the results are still the same. Workaround for now is to scale xy by 1.05 before exporting, but that’s really hacky. What’s the proper solution?
As this has been going on for a while and re-sizing STL files is painfull, I have looked into using Cura I can get a gpx converter to run gode from Makerbot Desktop OK (note gcode not gpx) but using gcode from Cura ends up with it printing in mid air or doing other weird things. is it possible to get a copy of the cure profile you are using? So i can fix my prints until astroprint works at the correct size.
Any fix in sight for this? I just discovered this bug the hard way and it’s a problem.
I use makerbot desktop to generate the x3g file and then upload the x3g to astroprint.
This works for me.
Yah, that’s an option, but a fix would be nice. Nothing seems to work well with Sailfish. I have octoprint up, but I have to upload G code to that one. Small difference I guess.
Just discovered this post. That means that half the parts that I’ve printed for a 30 part prop are off by 5% in size than the other half that I’ve printed BEFORE I got Astroprint installed.
Well, it would have been nice to known that somehow… without having to accidentally come across this on the forums. Wasted a lot of time. 
Mine is also running the stock CTC Firmware 1.0 - and I do NOT plan to update this because it works really fine for me!
Yesterday I started printing with Astroprint. Works fine if I use my replicatorg-generated x3g. The I tried slicing online in Artoprint - and the first result is: -5% xy :-(. Thank you all for this thread so I don’t have to search MY fault…
So now I will wait for the fix, hope that will not be so far in the future, until then I have to slice the “old” way… (without much information on the status screen - missing time to finish, max. layers … ) …
Yes, i COULD change the stl dimensions, or I COULD change my scad-sources, but no, … noooo …
I really wouldn’t wait for a fix. Not sure this is maintained.
@323GO This is certainly maintained 
Just have other things that we’re doing right now. This bug is very much in our plans to fix. Thanks for your patience guys, we’re a small team with lots of users 
1 Like
Should the Taz5 impacted by this? I am having issues with printed pieces not fitting together and am curious if this is the cause. I’ve tried a handful of other calibration procedures, e-step, etc. to no avail.