Z-axis manual command inverted in Windows 10

diegudio

Hi all,

I was running my reprap 1.4 based 3D printer (prusa i3 type) in Windows 7 with Marlin 1.1 firmware using Repetier without any problem. In fact, this hardware it's been with me for a while and I never had problems with it.
Some days ago I decided to migrate the old computer I was using to feed the printer (the one that was running Win 7) to Windows 10, and since then something weird started to happen in within Repetier: the manual commands to move the Z axis seems to feed the motors in the wrong direction.
I clarify: when I send the printer to go to find the 0,0,0 position, all steppers are moving correctly, the opto-endstops are also working fine... but then when I use the manual commands in Repetir to increase the Z height, it feeds the stepper in the wrong direction, pushing the hot-end against the hotbed.
It's very estrange, because I was using the same firmware in Win 7 and I had no problems.
This doesn't happen only with the manual feed. By trying to print a part, it happens the same, each new Z-step will be done against the hotbed instead of away of it.
But as I said, the return-to-home seems to be working fine.
I've tried changing some parameters in the firmware, but nothing seems to solve it.
I will appreciate any help.
Thanks,

Diego

Repetier

If you home to bed check
M119
it should show z min triggered or at least have z min end stop and most likely no z max.
If you send
G1 Z10 F600
it should separate 10mm from bed away.

If M119 show z max endstop instead also it homed to correct direction you have direction pin configured wrong and told firmware that you are homing to z max (direction 1) with z max end stop to fix wrong direction setting in firmware.

diegudio

Hi, sorry for the late reply.
When I home, all motors spin in the right direction and all axis home properly.
When I send M119 I become all endstops triggered.

12:01:08.324 : Reporting endstop status

12:01:08.324 : x_min: TRIGGERED

12:01:08.324 : y_min: TRIGGERED

12:01:08.324 : z_min: TRIGGERED

When I send G1 Z10 F600 it doesn't separate, it pushes against the bed. And that's the curious thing. Somehow the firmware is reading properly the Repetier inputs for homing, but not for other Z inputs (either manually or through code).

And as I said, this happened when I changed from Windows 7 to Windows 10. I haven't changed the firmware.

I'm running Repetier v2.2.4 on Windows 10 with Marlin 1.1 firmware on a Ramps 1.4 setup.

Repetier

Ok, so homing did move z to z min meaning M114 would show 0,0,0 for all axis. At that stage sende G1 Z10 must move head up regardless if it was absolute or relative position. Only reason might be if it was changed by G92 or z homing position is not stored internally as z=0 (maybe change in eeprom). So all I can say is run

G28
M114

to see what firmware thinks where Z is before sending G1 Z10. You might also try
G92 Z0
G1 Z10 F600

This enforces firmware to assume z=0 so Z10 must move up. This is independent from host if you see in log that that command gots send. If you see in log a different command being send it might explain things, but we don't change outgoing commands in host. Repetier-Server can do that, but doesn't do it in our settings for g0/G1.