Afinibot A3 upgrade problems
I have 2 A3's running 92.9 firmware and both have auto level issues. I decided to upgrade 1 printer to 1.0.4 and the printer works but I have problems.
1 - Z axis is off using steps/mm from previous config
2 - I can't move Z axis until I home it, X & Y I can move before homing
3 - If I kill print job I can't move Z unless I do a home (2&3 likely related)
4 - In my display i will get a flashing ???? for my Z axis
5 - I now have to put offsets in the repetier software for my bed to be centered, it was centered w/o them before. Can this be done in firmware instead?
Motherboard is ZONESTAR and I have 5 button display
1 - Z axis is off using steps/mm from previous config
2 - I can't move Z axis until I home it, X & Y I can move before homing
3 - If I kill print job I can't move Z unless I do a home (2&3 likely related)
4 - In my display i will get a flashing ???? for my Z axis
5 - I now have to put offsets in the repetier software for my bed to be centered, it was centered w/o them before. Can this be done in firmware instead?
Motherboard is ZONESTAR and I have 5 button display
Comments
Blinking ??? in display means axis is not homed.
#define MOVE_Z_WHEN_HOMED 1 would say to only move after homing. Guess yours is 1.
Don't know the printer but what do you mean with centered? Extruder is in center if you send right positions. x min/y min and x length/y length define coordinates. Normally left front is 0,0 for cartesian printers.
Why would it "un home" on a kill print?
I left only move after homing unchecked but I will verify.
Let's say I run a file I ran previously. It prints over to to the left and off the bed where before it'd be centered on the bed. I had to change these values. before 0,0 worked fine like these offsets were stored in the firmware.
#define MOVE_Z_WHEN_HOMED 1 would say to only move after homing. Guess yours is 1
#define MOVE_Z_WHEN_HOMED 0 CONFIRMED
This happens after I kill print. It seems to throw Z home out the window.
The Z axis won't rise now. It will lay the first layer perfect (auto level disabled of course) and then Z doesn't go up correctly. Almost like its missing steps.
Back to the auto level issue, why does it drive into my bed? Changing z-probe height does not help.
You defined in host that bed size is 200x200x100mm with left front edge being 0,0,0. If that differs from coordinates defined in firmware center in host is not center for printer! Both must match.
Check host scripts to see what it does on print kill etc. If it moves out of Z firmware might loose homing info, also I'd think it rather does not move.
Regarding z probe - what does M119 return when open and what when being hit? If it does not change you might have wrong pin configured.
Regarding the M119, where would I find this value in host?
My sensor triggers around 4mm from the bed. When i use 4mm as Z probe height and do a G32 S2 I see values in the log while probing around 16.xxx mm and my extruder digs into the bed while printing. I've adjusted Z probe heights from 4 to -15 but nothing fixes it. What am I missing?
Now a separate issue I'm having is skipped steps on the Y axis due to rapid direction changes on my model. Please help
For Y you need to reduce force to y motor or increase current to y motor if it is not already at limit. Don't want driver too get hot (which also makes you looks steps). You can reduce acceleration (800-1500 is normal, also many can run even 3000 if you do not need to move a bed). Direction switches is also critical, here lower jerk xy values reduce the speed at corners and forces. Also make sure bed moves freely without much force except motor. If rods are not parallel you might need more force.
Acceleration changes made no difference in the issue.
This thing printed fine before so don't think the stepper current is an issue.
I've lowered the jerk to 0 and no change. It's not mechanical issue because the first few layers print good. It bangs the stepper hard when it starts the letter detail on the cube.
I've given up on getting auto level to work, I'm just trying to get it back to where it was before the update.
When you can isolate the layer and run that in dry run and hear the bang I could test same layer as well, also I guess I'd not hear anything. But I've seen that very small moves can allow a faster direction change without deceleration, so maybe you have one of these cases here. Limits are per line switch so 5 20° changes on 0.1mm would make it move fast through that circle if you understand what I mean.
I also isolated each axis by removing belts an doing dry runs. It does this banging on both X and Y.
I also ran the same g code on my other printer and it runs flawless. The issue has to be in the firmware.
You can try
which uses alternative solution I had written to solve a similar thing.
This made no change and the problem still exists.
is better. With 1 you add extra moves which is a bad idea anyway. That might also cause the problem.
This made no change and the problem still exists.