I picked up one of these printers for $50 the easythreed k7, after some fiddling I got it goin pretty good and been havein fun.
I have been usein the Cura slicer as the printer came with a profile for it, I played around with Prusa Slicer and found some advantages with it. The issue is I attempted to manually create a profile for my printer for Prusha by copying the setting from Cura and this resulted in the printer not moving after going through its startup routine and extruding plastic while stationary.
I tested this by raising the z offset to over a mm to make sure it was not crashed into the bed and stuck, it is for sure just not moving.
Here is a screenshot of my cura settings along with a link to the config file for cura that came with the printer. K7.zip (60.1 KB)
let’s look and the G code produced by both software now it seems the movements are the part of the code that does not function in Prusha, primarily they both use G1 commands a “linear movement”
cura outputs something like this and works
G1 X33.014 Y70.256 E0.01391
Prusha outputs something like this
G1 X-31.706 Y-64.706 E.01655
so obviously the formatting is just a little off in the prusha how do I set prusha to output a formatting like in the cura example?
I could likely edit it myself or even write a script that could do it automatically, really find all type in - and delete would likely do it but ide rather not resort to this.
edit: well I can’t check it right now but maybe that’s negative coordinates, there should be no negative since it’s home location is the corner of the bed it’s possible it may be setup to home some place else I’ll check that later.
I don’t have a lot of experience with prusaslicer, but in general here are a couple settings that may be causing your problem:
Absolute vs Relative coordinates
There is a gcode command to define which is being used. A way out there command in the wrong format would probably cause the head to crash against the end stop, not freeze in place, but it’s worth a look.
Origin
Since we’re comparing two configurations, I would move the bed origin to the same corner.
Motor Disable
There is a gcode command to disable motors. It’s possible that the end of the homing procedure disables the x and y steppers, but they are not re-enabled when the print section of the code starts. I would avoid disabling steppers at the end of the homing procedure because it’s possible for the head to move without the machine knowing about it.
So as you pointed out if you take a look at your outputs Prusha is sending a negative value. I’m assuming your printer also doesn’t home correctly? when you set your custom settings did you set your gcode flavor to match?
i am not at home ATM but just curious is is common for 3d printers to have a machine zero and a program zero?
I can’t see many use cases you would need to define your own zero location in an application like this, maybe one with a very large bed.
Machine zero would generally be your home position where Program zero is the position your print starts. Obviously you’d want to be able to home your printer so you can define its printable area and to define where your print starts within that area.
Also if you’re using the stock firmware on that printer its using Marlin 2 so make sure you have your firmware type set correctly.
I believe I found my mistake, somehow I had the origin set to 100 for both x and y it seems I must have fat-fingered that when setting the bed size so that would basically make the program zero machine coordinates100 for both x and y. This is not a CNC mill but yeah it basically is so I understand the concepts well it’s just the software on them is so idiot-proof these days I have grown complacent.
