For some reason, when sending home the X or Y axes of the controller from the menu item “Motion” → “Home X” or “Motion” → “Home Y”, the controller stops with the message “Printer HALTED”? When using the specialized menu “Home X & Y” behaves normally. Arduino Mega2560, Ramps 1.4, A4988, NEMA 17HS4401.
Usually this happens when you try and home your machine from a distance further away from home than is bed size set in the firmware. The value is set in these two defines in configuration.h:
// The size of the printable area #define X_BED_SIZE 600 #define Y_BED_SIZE 600
If this is your problem, you can either 1) change these values to be equal or greater than the sizes of your two axes, or 2) you can make a habit of dragging your router close enough to home.
I just checked, and assuming you are using a Primo, a third option is to upgrade your firmware to version 515. These values have been substantially increased:
// The size of the printable area #define X_BED_SIZE 1220 #define Y_BED_SIZE 2440
Robert you are pretty amazing!
Yes, I looked, 600 is indicated in our firmware. But the size of our table is 500x500 mm. And this happens even when we move the axes close to home.
I don’t know much about Marlin source, but I spent a few minutes chasing both the kill message and homing in the source. Near as I can determine, all the menu item does is insert a G28 in the queue:
Where the custom menu also just used a g-code command that is added to the queue:
#define MAIN_MENU_ITEM_3_GCODE "G28 X Y"
So, both pathways operate by putting a text G28 in the queue. There is nothing special about either menu execution. Since I never use it, I tried Motion/Home X on my machine, and it worked fine. Some ideas to collect more information:
- Give us the version string that appears on the screen when you boot the control board.
- Do a factory reset (M502) followed by an M500 and then test.
- If you can connect a laptop or computer, send Marlin a “G28X” string and see if the issue occurs on that pathway. While I doubt it is the problem, I would do it exactly that way without a space between the ‘8’ and the ‘X’.
- If you don’t have a computer connected, you could also try and execute a “G28X” from a file on the SD card.
Do you have endstops plugged in?
Home does not mean go to 0,0,0, it means search for the minimum endstop/s. It will not work without endstops or endstops that are plugged in incorrectly.
I know I’m making some assumptions here, but according to his original question, the “Home X&Y” from the V1 custom menu homes correctly. If true, the behavior is strange.
So I understand this as… g28 y doesn’t move and just throws an error, but g28 xy works, correct?
I had a similar issue in fluidnc where I incorrectly configured a “zmin” endstop, with z home configured as “positive direction”. The firmware didn’t catch that obvious error, and I crashed the z endstop as a result. Funny part is I ran many successful cuts for over a year like this, since I always sent just G28. I was playing with esp3d buttons recently when I found this out.
I wonder if something similar is going on here?
In the case of fluidnc, I am guessing homing all it is changing how it reads max/min limits… reading the switch as both so a min switch will stop it at z max. When homing individual it then seems to honor the actual endstop config… so zmin is ingored going up. If the same thing is happining here, maybe there a ymax switch configured to NO, or y homing direction set reversed?
yes, there are limit switches on X and Y, closed in normal condition.
During further tests and through this menu, I found this error. It doesn’t always show up, but it’s unpleasant. Of course, I can adjust any zero to any axis by simply turning the arduino on and off, but it takes a lot of time.
G92 X0 Y0 Z0. And I should have a custom button for that in there as well. That zero’s each axis.
What happened with your homing issue?
Now we are getting into weird territory. Turing the machine on and off will set the current position to (0,0,0), but that is not what homing is for. If all homing is doing is resetting your coordinates to (0,0), then something is wrong. In terms of menus, setting the current position as (0,0,0) is using the “Reset All Coordinates” on the V1 custom menu. In addition, sending (or running from an SD card) a G92 will reset the current position.
G92 X0 Y0 ; Set current position as X=0 Y=0
Hi, sorry I didn’t answer for a long time. Only today it turned out to connect a computer and a machine.
- The version displayed on the screen during boot: 513S 126.96.36.199
- I took the firmware from here: https://github.com/V1EngineeringInc/MarlinBuilder/releases/download/515/V1CNC_Ramps-2.1.1.zip
- In the firmware, I changed only the direction of rotation of the encoder and the screen used. Everything else is by default
- When moving manually or using the G01 command, everything is fine
- When setting X and Y home using the menu or the G28 command, the printer stops with the message “Printer HALTED”. Not always and more often with the Y axis
- Generally incomprehensible behavior with the Y-axis, if the X-axis normally goes to the limit switches, then the Y-axis goes some way (always different), then somewhere where it wanted to make a small backward movement and stops the printer
- It is also not clear with the Z axis - it can start moving down, or it can start moving up, more often up. The movement is short, no more than a centimeter. Although the wires of the Z terminal are not connected.
- When learning the M119 command. When the limit switches are not activated, the answer in the console is X: open; Y: open; Z open. When one way or another to set the axes home, then X: triggered; Y: triggered. When the end wires are closed Z - Z: triggered
- I tried the work of g-code from a USB flash drive. Everything works.
- And also, in order for the movements to be accurate in length, it was necessary for X and Y to reduce the number of steps in mm from 200 to 99, and for Z to increase from 800 to 1630
Thank you for your answers.
This is the serial firmware (513S) so homing behaviour isn’t stricktly defined, as this version wasn’t intended to have endstops for autosquaring.
Those numbers seem weird. 200 steps/mm for X and Y is from the DRV8825 deivers set to 32X microstepping, it seems your drivers are set to 16X (normal for A4988 drivers) but then the correct steps/mm should be 100. Similarly 800 is normal for 32X microstepping for a 4 start leadscrew. 16X microstepping should be 400 steps/mm. For a 1 start (2mm pitch) leadscrew, it should be 1600. I can’t imagine a setup where 1630 would be correct.
With correct belt tension, I think you should be able to use 100 for your steps for X and Y, and I’m reasonably sure that 1600 is the correct value for Z.
Thanks for the answer.
Tell me what settings in the firmware I need to look at and fix to install limit switches.
These figures are derived empirically. By installing and running and measuring with a caliper
That tends to be a very small sample, ie, not a large distance. I’d put money on 1600 being correct for Z, and a well set up machine with 16T pulleys on GT2 timing belt, with 1.8° stepper motors and 16X microstepping should come to 100 steps/mm
I would restart with the “D” series firmware which is set up for 5 drivers, one per motor, with the endstops defined for use as is. Change the steps/mm baked into the firmware. I would use the 100, 100, 1600, (whatever for E) setup, you can tune it later, but those default values should be right.
That is, each engine is connected to its own driver. And it will be necessary to use 5 stepper motor drivers. Will local E0 and E1 be involved? Do I understand correctly?
The controller stops with the message “Printer halted” when the carriage is longer than 1 centimeter from the limit switch. If you try to send it home at a distance of less than 1 cm, then everything is fine, the coordinates are reset to zero. When further than 1 cm, first there is a slight forward movement, then a slight backward movement and the message “Printer halted” comes out.
And in this case, the same thing:
Otherwise, everything works without problems.
This happens regardless of the command from the monitor screen of the control board or from the Repeater-server console on the computer (G28 X H).
Before that, there was another arduino, where the same firmware worked normally when going home. With the new control board, the same firmware on the same machine does not work as it should when sending the X and Y axes to 0.
What could be the problem.
In general, I commented out a line in the Configuration.h file:
Now the printer does not stop, but if you only turn it on (or reset it) when X and Y are far from home, and send the command G28 X0 or G28 Y0, then you need to do this several times. But then when it is reset to zero, everything works fine.
In the new firmware I have set the limits much further away. This should not show up any more unless you made a very large build. It also move home in one click.
If you are going to make firmware changes you should just change the bed size.