[SOLVED] - G-Code move doesn't match manual move

Now my endstop problem is solved, I calibrated all axes and extruder with success.

I also adapted PID factors thanks to the automated calibration, that trick is awesome.

Yet now I'm facing a strange problem, I can't fix, reason of this topic.

I sliced the thin wall, what I get in Repetier looks good.

But when I launch the job, the printer head is moving out of the bed for the first X Y positioning. So I stopped it.

This first position in G-Code is G1 X109.510 Y109.600.

Manually moving the head to X109 Y109 is ok, I'm nearly the middle of the bed.

But executing G1 X109.510 Y109.600 command, even manually give the same result than when launching the job, the head going out of the bed.

I don't understand why. I also tried relative positioning, but I get the same result.


If someone has an idea how to fix that...

Edited 1 time(s). Last edit at 03/03/2013 03:31PM by VDX.

The problem is on X-axis.

It seems to be due to my homing position being on the right side of the plate, X max.

I think I've set it correctly both in firmware and in host, but I may be missing one.

In host I've defined homing being X max, 190.

In firmware I've defined the good side for homing, axis reversing etc... and swapped in pin.h Xmax and Xmin pins.

All is working fine for manual operations, homing and moves.


But when entering a G-Code position, the result is wrong.
It's behaving like if there were a shift on X axis, the size of the bed.
To be nearly the middle of X-Axis, the G-Code is G1 X300.

Did I miss to set something, or is there a bug somewhere ?

Why did you "and swapped in pin.h Xmax and Xmin pins. "? You have to activate the xmax endstop if you use xmax, set

#define MIN_HARDWARE_ENDSTOP_X false
#define MAX_HARDWARE_ENDSTOP_X true
#define X_MIN_POS 0
#define X_MAX_LENGTH 190
#define X_HOME_DIR 1

I think that should be all you need to set in the firmware. And of course use the xmax pin or toggle pin numbers in pin.h.

After homing you can ask the firmware where it thinks it is with M114, which should be x=190 in your case. If not that is the reason for the wrong positioning.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

Hi Repetier,

Thank you for your answer.

To answer your first question, as you say yourself later in your post, something is to be done with pins else the endstop simply doesn't work.

I made exactly the settings you gave.
On pin.h side here is what I did :

    #define X_MIN_PIN       -1
    #define X_MAX_PIN       20

In fact I did the same settings using sprinter firmware (and repetier-host), and it was working fine, both in manual and g-code positioning.


Again the position and moves are good using manual commands (with repetier-host arrows). It is when using g-code position the printer wants to move a plate x-beside the real one.

I'll check the behavior redefining the x-endstop as min one. It will give mirrored object but I'll see if there is still a same problem.

The manual move buttons use relative coordinates, which is why they seem to work. Please check with M114 what the firmware thinks where it is after homing.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

Defining back endstop as x-min doesn't give a better result. Same problem with g-code move.

I tried M114 command and effectively it's giving something strange.

Staying with endstop as x-min, I made a 40mm manual move. Repetier host tells x position as being 40 for X. After launching M114 command, the information is changing and I have position X 230.
There is somewhere an offset, the size of the plate (190)...

Will dig again in settings...

Back with my settings with x endstop as max endstop.

After homing command, I launch M114 and X=190 becomes X=380.

After setting X home pos as 0 (instead of 190) in EEPROM, it seems to be solved.

I confirm the problem is solved (I can't edit first message of the topic) .

Thank you again Repetier. The M114 command was really helpful to understand what was happening.