$settings

[gibrie]

Project: cartesian line-up of two Y-axis/2NEMA - one X-axis/1NEMA - Z=servo S90 - Arduino Uno + CNC shield V3 - NC limit switches on X + Y - limit switch Z by jumper on SpnEn/GND - machine size X=70cm/Y=100cm - drawing area X=60cm/Y=70cm. Download GRBL-Plotter + XLoader perfect. Baud 115200.

Problem: alarm immediately after connecting - jogging not possible, no reaction for servo pen up/pen down. Homing works uncomplete and limit switches don't react even manually. As I am an Anfänger need some help. I think the problem is the $settings.

[svenhb]

alarm immediately after connecting

this normal behavior, when first use. The button "Kill Alarm" should blink - just press.

[gibrie]

Alarm erased, still homing continues against limit switch without stoppping and only Y-axis, perhaps in config.h selected in such order?

[gibrie]

Do you see any abnormal settings in my configuration?

[svenhb]

With cartesian line up you mean regular X and Y axis? Perhaps end-switches mixed up, or wrong type (normaly open / normaly closed)? You can watch the marked area to check if switches are working

[gibrie]

Pn: mentions XYZ Changed end stops X+Y to NC as I get an alarm not putting a jumper on SpnEn/GND for Z end stop

[svenhb]

Do you see any abnormal settings in my configuration?

You set $5 invert all limit switches... https://github.com/gnea/grbl/wiki/Set-up-the-Homing-Cycle

[gibrie]

Yes as I thought the default line-up works with NO switches

[svenhb]

If you have no Z, You need to change your config.h and compile grbl again. Regular order is Z,X,Y for homing

[gibrie]

So I remove the jumper? Will give it a try...

[svenhb]

So I remove the jumper? Will give it a try...

this is not enough. grbl triggers and untriggers each switch during homing.

[svenhb]

From the config.h:

// Define the homing cycle patterns with bitmasks. The homing cycle first performs a search mode
// to quickly engage the limit switches, followed by a slower locate mode, and finished by a short
// pull-off motion to disengage the limit switches. The following HOMING_CYCLE_x defines are executed
// in order starting with suffix 0 and completes the homing routine for the specified-axes only. If
// an axis is omitted from the defines, it will not home, nor will the system update its position.
// Meaning that this allows for users with non-standard cartesian machines, such as a lathe (x then z,
// with no y), to configure the homing cycle behavior to their needs.
// NOTE: The homing cycle is designed to allow sharing of limit pins, if the axes are not in the same
// cycle, but this requires some pin settings changes in cpu_map.h file. For example, the default homing
// cycle can share the Z limit pin with either X or Y limit pins, since they are on different cycles.
// By sharing a pin, this frees up a precious IO pin for other purposes. In theory, all axes limit pins
// may be reduced to one pin, if all axes are homed with seperate cycles, or vice versa, all three axes
// on separate pin, but homed in one cycle. Also, it should be noted that the function of hard limits
// will not be affected by pin sharing.
// NOTE: Defaults are set for a traditional 3-axis CNC machine. Z-axis first to clear, followed by X & Y.
#define HOMING_CYCLE_0 (1<<Z_AXIS)                // REQUIRED: First move Z to clear workspace.
#define HOMING_CYCLE_1 ((1<<X_AXIS)|(1<<Y_AXIS))  // OPTIONAL: Then move X,Y at the same time.
// #define HOMING_CYCLE_2                         // OPTIONAL: Uncomment and add axes mask to enable

[gibrie]

As I have no Z I do comment in config.h "#define HOMING_CYCLE_0 ((1>>X_AXIS)|(1>>Y_AXIS)) // NOT COMPATIBLE WITH COREXY and uncomment the previous setting with the Z-axis

[gibrie]

Sorry, reacted too fast and missed last message. That is the original setting still with a Z-axis no?

[svenhb]

I posted the original config.h from here: https://github.com/gnea/grbl/blob/master/grbl/config.h with Z enabled. You need to change like this, I assume (2nd line changed to CYCLE_0):

//#define HOMING_CYCLE_0 (1<<Z_AXIS) // REQUIRED: First move Z to clear workspace.
#define HOMING_CYCLE_0 ((1<<X_AXIS)|(1<<Y_AXIS)) // OPTIONAL: Then move X,Y at the same time.

[gibrie]

The comment mentiones that if an axis is erased homing isn't executed. In the cpu_map.h is mentioned that the pin swap of the Z end stop and SpnEn is made to get the PWM on pin 11. This is why I had put a jumper on SpnEn to have a Z limit switch activated. When I took the jumper away I got an alarm on the UGS platform.

[svenhb]

You need to disable Z. Just putting a jumper is not enough, because during homing, the software checks if the switch triggers, when move against the switch and untriggers, when move away.

[svenhb]

because of $5=1, grbl expects a NC switch, but you removed the jumper, so grbl thinks the Z axis triggers the switch, which causes alarm.

[gibrie]

For now I have X and Y end stops NC and Z end stop NC with the jumper and homing isn't stopped by any of the switches with $5=1. Am I right or does it need now $5=0. Getting confused...

[svenhb]

As long as you have not a Z-switch which will be triggered by the Z axis, or changing the config.h (remove z from homing) homing will not work.

[svenhb]

https://github.com/gnea/grbl/wiki/Set-up-the-Homing-Cycle#homing-cycle-steps

[gibrie]

Okay, I will start over again controlling my grbl with your advise. Before ending this do you approve my $-settings above?

[svenhb]

I think the $-settings are ok for now... Does the X-axis move to right if you increase the X value? And the Y to the back, when increasing Y?

[gibrie]

I had to change $3 to value 3 to get both axis in the corner down at the left side to make a homing possible with the end stops.

[svenhb]

It depends where your axis end-switch is located: at the beginning or at the end of the axis. Before, be sure the general directions are correct: increasing X-value moves the tool to the right, (or the workpiece to the left) etc.

[gibrie]

I changed all of the settings to NO end stops, eliminated the jumper of the X-axis (SpnEn), besides that I am going to do a try out with ceramic capacitors to see if my x-axis doesn’t get disturbed by interference by the NEMA of the X-axis. Today the plotter has drawn a perfect drawing, but still the servo didn’t work. Will still do some searching… thanks for your patience!

Op 25 aug. 2023, om 12:41 heeft Sven @.***> het volgende geschreven:

It depends where your axis end-switch is located: at the beginning or at the end of the axis. Before, be sure the general directions are correct: increasing X-value moves the tool to the right, (or the workpiece to the left) etc.

— Reply to this email directly, view it on GitHub https://github.com/svenhb/GRBL-Plotter/issues/351#issuecomment-1693158940, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOWE5T3XLICY3Q4WGLCNEQDXXB6OBANCNFSM6AAAAAA33NBBCQ. You are receiving this because you authored the thread.

[svenhb]

Good to hear.

but still the servo didn’t work

You know, that you need a special grbl version to get PWM for a RC-servo? https://grbl-plotter.de/index.php?id=quick-guide&setlang=en#pwm

[svenhb]

Any update here?

[gibrie]

Hi Sven,

For the moment everything is okay and the plotter is working now. For the moment it doesn’t do anything in printing as I am studying Python to get into generative art. My aim is to print humans in a certain way as for example scribbling or another procedure.

Keep up the good things!!! Guillaume

Op 6 okt. 2023, om 10:16 heeft Sven @.***> het volgende geschreven:

Any update here?

— Reply to this email directly, view it on GitHub https://github.com/svenhb/GRBL-Plotter/issues/351#issuecomment-1750173879, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOWE5TZOVXHGLOUXZXVGFF3X5645NAVCNFSM6AAAAAA33NBBCSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONJQGE3TGOBXHE. You are receiving this because you authored the thread.