Cannot use RAMPS configuration with my build...

[ccwtruck]

My trouble, @fra589 , is that you wrote grbl-Mega-5X exclusively for the RAMPS board.

I am not using RAMPS at all; I am using a Mega 2560 R3 in my rebuild/ upgrade of my CNC plasma table -- therefore, it is useless to me even though it offers features that I need.

My table was a regular 3-axis table, running GRBL-Mega. I have added a 2nd Y-axis which must be cloned with the 1st Y-axis and both Y-axis's must home together while auto-squaring. I also use a torch height controller of my own design that is fed from GRBL's Z-axis using an interrupt to intercept step/ direction signals from GRBL and either pass them through to the stepper driver unaltered or send its own pulses to the stepper driver while receiving the ARC OK signal from the plasma cutter (THC)

I am using external DMA860S drivers for X, Y, & Y2 axises & an external DM556 driver for Z-axis -- so I cannot use the RAMPS board at all. Would you possibly be willing & able to add a #define CPU_MAP_2560_INITIAL section to the cpu_map.h file with the following #defines that match my build? This code is from 4-Axis-Grbl which I was able to run but found out that it doesnt offer cloning/ dual-Y or auto-squaring.

`/* cpu_map.h - CPU and pin mapping configuration file Part of Grbl

Copyright (c) 2012-2016 Sungeun K. Jeon for Gnea Research LLC

Grbl is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

Grbl is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with Grbl. If not, see http://www.gnu.org/licenses/. */

/ The cpu_map.h files serve as a central pin mapping selection file for different processor types or alternative pin layouts. This version of Grbl supports only the Arduino Mega2560. /

ifndef cpu_map_h

define cpu_map_h

ifdef CPU_MAP_2560_INITIAL // (Arduino Mega 2560) Working @EliteEng

// Serial port interrupt vectors

define SERIAL_RX USART0_RX_vect

define SERIAL_UDRE USART0_UDRE_vect

// Define step pulse output pins. NOTE: All step bit pins must be on the same port.

define STEP_DDR DDRA

define STEP_PORT PORTA

define STEP_PIN PINA

define X_STEP_BIT 2 // MEGA2560 Digital Pin 24

define Y_STEP_BIT 3 // MEGA2560 Digital Pin 25

define Z_STEP_BIT 4 // MEGA2560 Digital Pin 26 -- Connected to THC Pin 2

define A_STEP_BIT 5 // MEGA2560 Digital Pin 27

define B_STEP_BIT 6 // MEGA2560 Digital Pin 28

define C_STEP_BIT 7 // MEGA2560 Digital Pin 29

define STEP_MASK ((1<<X_STEP_BIT)|(1<<Y_STEP_BIT)|(1<<Z_STEP_BIT)|(1<<A_STEP_BIT)|(1<<B_STEP_BIT)|(1<<C_STEP_BIT)) // All step bits

// Define step direction output pins. NOTE: All direction pins must be on the same port.

define DIRECTION_DDR DDRC

define DIRECTION_PORT PORTC

define DIRECTION_PIN PINC

define X_DIRECTION_BIT 7 // MEGA2560 Digital Pin 30

define Y_DIRECTION_BIT 6 // MEGA2560 Digital Pin 31

define Z_DIRECTION_BIT 5 // MEGA2560 Digital Pin 32 -- Connected to THC Pin 7

define A_DIRECTION_BIT 4 // MEGA2560 Digital Pin 33

define B_DIRECTION_BIT 3 // MEGA2560 Digital Pin 34

define C_DIRECTION_BIT 2 // MEGA2560 Digital Pin 35

define DIRECTION_MASK ((1<<X_DIRECTION_BIT)|(1<<Y_DIRECTION_BIT)|(1<<Z_DIRECTION_BIT)|(1<<A_DIRECTION_BIT)|(1<<B_DIRECTION_BIT)|(1<<C_DIRECTION_BIT)) // All direction bits

// Define stepper driver enable/disable output pin.

define STEPPERS_DISABLE_DDR DDRB

define STEPPERS_DISABLE_PORT PORTB

define STEPPERS_DISABLE_BIT 7 // MEGA2560 Digital Pin 13

define STEPPERS_DISABLE_MASK (1<<STEPPERS_DISABLE_BIT)

// Define homing/hard limit switch input pins and limit interrupt vectors. // NOTE: All limit bit pins must be on the same port

define LIMIT_DDR DDRB

define LIMIT_PORT PORTB

define LIMIT_PIN PINB

define X_LIMIT_BIT 4 // MEGA2560 Digital Pin 10

define Y_LIMIT_BIT 5 // MEGA2560 Digital Pin 11

define Z_LIMIT_BIT 6 // MEGA2560 Digital Pin 12

define A_LIMIT_BIT 0 // MEGA2560 Digital Pin 53

define B_LIMIT_BIT 1 // MEGA2560 Digital Pin 52

define C_LIMIT_BIT 2 // MEGA2560 Digital Pin 51

define LIMIT_INT PCIE0 // Pin change interrupt enable pin

define LIMIT_INT_vect PCINT0_vect

define LIMIT_PCMSK PCMSK0 // Pin change interrupt register

define LIMIT_MASK ((1<<X_LIMIT_BIT)|(1<<Y_LIMIT_BIT)|(1<<Z_LIMIT_BIT)|(1<<A_LIMIT_BIT)|(1<<B_LIMIT_BIT)|(1<<C_LIMIT_BIT)) // All limit bits

// Define spindle enable and spindle direction output pins.

define SPINDLE_ENABLE_DDR DDRH

define SPINDLE_ENABLE_PORT PORTH

define SPINDLE_ENABLE_BIT 3 // MEGA2560 Digital Pin 6

define SPINDLE_DIRECTION_DDR DDRE

define SPINDLE_DIRECTION_PORT PORTE

define SPINDLE_DIRECTION_BIT 3 // MEGA2560 Digital Pin 5

// Define flood and mist coolant enable output pins.

define COOLANT_FLOOD_DDR DDRH

define COOLANT_FLOOD_PORT PORTH

define COOLANT_FLOOD_BIT 5 // MEGA2560 Digital Pin 8

define COOLANT_MIST_DDR DDRH

define COOLANT_MIST_PORT PORTH

define COOLANT_MIST_BIT 6 // MEGA2560 Digital Pin 9

// Define user-control CONTROLs (cycle start, reset, feed hold) input pins. // NOTE: All CONTROLs pins must be on the same port and not on a port with other input pins (limits).

define CONTROL_DDR DDRK

define CONTROL_PIN PINK

define CONTROL_PORT PORTK

define CONTROL_RESET_BIT 0 // MEGA2560 Analog Pin 8

define CONTROL_FEED_HOLD_BIT 1 // MEGA2560 Analog Pin 9

define CONTROL_CYCLE_START_BIT 2 // MEGA2560 Analog Pin 10

define CONTROL_SAFETY_DOOR_BIT 3 // MEGA2560 Analog Pin 11

define CONTROL_INT PCIE2 // Pin change interrupt enable pin

define CONTROL_INT_vect PCINT2_vect

define CONTROL_PCMSK PCMSK2 // Pin change interrupt register

define CONTROL_MASK ((1<<CONTROL_RESET_BIT)|(1<<CONTROL_FEED_HOLD_BIT)|(1<<CONTROL_CYCLE_START_BIT)|(1<<CONTROL_SAFETY_DOOR_BIT))

// Define probe switch input pin.

define PROBE_DDR DDRK

define PROBE_PIN PINK

define PROBE_PORT PORTK

define PROBE_BIT 7 // MEGA2560 Analog Pin 15

define PROBE_MASK (1<<PROBE_BIT)

// Advanced Configuration Below You should not need to touch these variables // Set Timer up to use TIMER4B which is attached to Digital Pin 7

define SPINDLE_PWM_MAX_VALUE 1024.0 // Translates to about 1.9 kHz PWM frequency at 1/8 prescaler

ifndef SPINDLE_PWM_MIN_VALUE

define SPINDLE_PWM_MIN_VALUE 1 // Must be greater than zero.

endif

define SPINDLE_PWM_OFF_VALUE 0

define SPINDLE_PWM_RANGE (SPINDLE_PWM_MAX_VALUE-SPINDLE_PWM_MIN_VALUE)

define SPINDLE_TCCRA_REGISTER TCCR4A

define SPINDLE_TCCRB_REGISTER TCCR4B

define SPINDLE_OCR_REGISTER OCR4B

define SPINDLE_COMB_BIT COM4B1

// 1/8 Prescaler, 16-bit Fast PWM mode

define SPINDLE_TCCRA_INIT_MASK ((1<<WGM40) | (1<<WGM41))

define SPINDLE_TCCRB_INIT_MASK ((1<<WGM42) | (1<<WGM43) | (1<<CS41))

define SPINDLE_OCRA_REGISTER OCR4A // 16-bit Fast PWM mode requires top reset value stored here.

define SPINDLE_OCRA_TOP_VALUE 0x0400 // PWM counter reset value. Should be the same as PWM_MAX_VALUE in hex.

// Define spindle output pins.

define SPINDLE_PWM_DDR DDRH

define SPINDLE_PWM_PORT PORTH

define SPINDLE_PWM_BIT 4 // MEGA2560 Digital Pin 7

endif

/*

ifdef CPU_MAP_CUSTOM_PROC

// For a custom pin map or different processor, copy and edit one of the available cpu // map files and modify it to your needs. Make sure the defined name is also changed in // the config.h file.

endif

*/

endif

`

[fra589]

Hi @ccwtruck,

My trouble, @fra589 , is that you wrote grbl-Mega-5X exclusively for the RAMPS board.

No, grbl-Mega-5X is not only for RAMPS board, and it can work very well without it.

In grbl-Mega-5X, I had to delete the elements corresponding to #define CPU_MAP_2560_INITIAL because this was incompatible with the management of additional axes (4, 5 and even 6) and with the axis cloning system that I have added.

To use grbl-Mega-5X without the RAMPS card, simply connect the drivers and other inputs/outputs to the correct pins for it to work (see: https://github.com/fra589/grbl-Mega-5X/wiki/grbl-Mega-5X-pinout). Or, you can change the mapping in cpu_map.h so that it corresponds to the connection of your machine, the documentation which explains how to do this is here in the 5X's wiki: https://github.com/fra589/grbl-Mega-5X/wiki/Pinout-mapping-in-cpu_map.h

As I'm retired, I'm totally overbooked :-) and I don't really have time to do it for you, but I'm here to answer your questions if you don't understand everything when you will do it.

@++; Gauthier.

[ccwtruck]

Hi @ccwtruck,

My trouble, @fra589 , is that you wrote grbl-Mega-5X exclusively for the RAMPS board.

No, grbl-Mega-5X is not only for RAMPS board, and it can work very well without it.

In grbl-Mega-5X, I had to delete the elements corresponding to #define CPU_MAP_2560_INITIAL because this was incompatible with the management of additional axes (4, 5 and even 6) and with the axis cloning system that I have added.

To use grbl-Mega-5X without the RAMPS card, simply connect the drivers and other inputs/outputs to the correct pins for it to work (see: https://github.com/fra589/grbl-Mega-5X/wiki/grbl-Mega-5X-pinout). Or, you can change the mapping in cpu_map.h so that it corresponds to the connection of your machine, the documentation which explains how to do this is here in the 5X's wiki: https://github.com/fra589/grbl-Mega-5X/wiki/Pinout-mapping-in-cpu_map.h

As I'm retired, I'm totally overbooked :-) and I don't really have time to do it for you, but I'm here to answer your questions if you don't understand everything when you will do it.

@++; Gauthier.

Thank you for your help!

However, after weighing the time required for me to re-write even small sections of code versus the time required to re-wire my Mega for the RAMPS pin configuration, I opted for the re-wiring; It took me all of an hour to complete.

I am now configuring the settings in config.h, and I have a question:

My machine has both MIN & MAX switches (NC NPN proximity switches) running through an opto-isolated 8-channel relay board that gives me the full compliment of MIN & MAX limit switches on all 4 axis's -- but they are not in parallel. Since Mega-5X takes inputs from both MIN & MAX limit switches natively, do I still need to enable/ un-comment "// #define LIMITS_TWO_SWITCHES_ON_AXES"?

Again, thank you for your assistance!

[fra589]

Hi @ccwtruck,

There is no #define LIMITS_TWO_SWITCHES_ON_AXES in the grbl-Mega-5X code, nor in the original grbl or grbl-Mega code.
Be careful not to mix with configuration files from versions other than grbl-Mega-5X.

Simply connect your MIN and MAX switches on the relevant pins and it should work.

@++;
Gauthier.

[ccwtruck]

Hi @ccwtruck,

There is no #define LIMITS_TWO_SWITCHES_ON_AXES in the grbl-Mega-5X code, nor in the original grbl or grbl-Mega code. Be careful not to mix with configuration files from versions other than grbl-Mega-5X.

Simply connect your MIN and MAX switches on the relevant pins and it should work.

@++; Gauthier

@fra589 ,

Actually, there is -- Line 315 in the latest Mega 5x config.h, and Line 165 in the config.h file for gnea/grbl-Mega-edge. In gnea/grbl-Mega-edge, it is used when the machine has dual limit switches wired in parallel to emulate a min & max limit functionality; in Mega 5x, it serves no purpose, because the code already offers the option of actual min & max limit switches.

I have Mega 5x up & running, after a fashion... but it has a serious problem: the Y and cloned Y axis-es don't move identically and the X-axis gantry gets out of square quickly. My Y-axis is a 1550 mm 1605 ballscrew, and the cloned Y-axis is a 1500 mm 1605 ballscrew; motors are identical NEMA 23 425 oz in/ 4.2 amp, and the stepper drivers are identical DMA860S drivers with identical dip switch settings. Steps/ mm are all set to 320. Both axis-es are rolling on a Openbuilds double-wide gantry plate with upper & lower Openbuilds "Extreme V" wheels riding on Openbuilds 40x80 mm C-Beam. I can see no reason, mechanically or electronically, for this behavior -- unless it is related or caused by my second issue.

My second issue is that, no matter what, the cloned Y axis is being seen as a rotary axis in Openbuilds Control and UGCS when the version string is "1.2h". Since recompiling with "1.1g" as you suggested in another topic, Openbuilds Control no longer shows the cloned Y axis in the axis position portion of the screen, but reports it's position in the serial monitor. When viewing the GRBL settings, it shows degrees for all of the cloned Y-axis settings -- it's almost as if Openbuilds Control is enforcing an unwritten rule that if it's a 4th axis, it has to be rotary. I haven't tried UGCS since recompiling with the "1.1g" version string. I have also tried your sender, cn5x v0.9, with no luck -- it's behavior is erratic, crashing frequently with no warning on my Windows 10 computer. I also get sporadic grblCommBuffer error, too.

Do you have any idea of what could be causing these difficulties, and possibly how to correct them?

[fra589]

Hi @ccwtruck,

Actually, there is -- Line 315 in the latest Mega 5x config.h

Oops ! my mistake. I didn't search well, sorry. But this option is of no use in your case.

For your second issue, if in config.h, you have configured correctly as I think:

#define N_AXIS 4
#define N_AXIS_LINEAR 3
#define AXIS_1_NAME 'X'
#define AXIS_2_NAME 'Y'
#define AXIS_3_NAME 'Z'
#define AXIS_4_NAME 'Y'

It seems to me that the problem of taking into account the 4th axis as a rotary axis comes from Openbuile or UGS... So, you can activate the #define REPORT_VALUE_FOR_AXIS_NAME_ONCE (line 102 in config.h) to disable the report of the second Y axis in the serial monitor. The config report $$ output will not be changed, but in my opinion, the problem does not come from there.

Regarding cn5X, I have been using it on Linux for several years without serious problems... But indeed, the latest version is a major migration to use QT6 to replace QT5 and this required a lot of changes in the code and perhaps that this version is not yet well stabilized on Windows... Maybe you can try version 0.8 of cn5X, which still uses QT5 but which I think is more stable currently (very few bugs reported). https://github.com/fra589/cn5X/releases/tag/v0.8.10_qt5

@++; Gauthier.

[fra589]

By the way... Do you have issued the $RST=* grbl command to reset the flash EEPROM after each configuration change? If no, Grbl may have unpredictable behavior. After each configuration change, it's important to issue the $RST=* command and re-send your $$ configs parameters. You can adjust the defaults parameters in default.h, so the parameters will be at the right values immediately after the $RST=* command.

@++; Gauthier.

[ccwtruck]

Good morning, @fra589 !

Well, I now have the table functional, and am now installing my min/max limit switches. I have come across an "issue" that -- while not a serious one, and one that has already been worked around -- is still puzzling.

In fine tuning my GRBL settings, I have found that, in order to make both Y axises move identically, I have to set $101 to 320 and $103 to 800. If I set both to 320 -- which one would think would be correct with identical stepper drivers/ dip switch settings/ motors set for 1/8 micro-stepping -- the first Y axis moves 1/2" while the second Y axis moves 1". When I doubled the $103 setting to 640, then the first Y axis moved 3/4" while the second Y axis still moved 1". Setting $103 to 960 resulted in the first Y axis moving 1-1/4" to 1" for the second Y axis. Finally, setting $103 to 800 resulted in a 1" movement for both Y axises and the gantry remaining square.

As I have said, both axises are completely identical in all respects -- I re-vamped the ball screw layout from what I told you before, and now both Y axises are using 1500mm 1605 ball screws (the X axis is now the 1550mm ball screw) with both Y axises being set to identical starting positions in the mounting.

Can you think of any reason for this "quirk"?

John

[fra589]

Hi @ccwtruck!

OUPS! probably my mistake... Last week, when I wrote the right config for your need, I give a wrong value for the N_AXIS_LINEAR parameter.

With 4 axes X, Y, Z and Y, you should have #define N_AXIS_LINEAR 4 and not 3 like I wrote!

Indeed, internally, Grbl uses millimeters as a unit. In grbl-Mega-5X, the axes are not managed by their letters, but by their numbers (index of the value tables). In G20 mode (length unit = inches) the N_AXIS_LINEAR parameter is used to convert between inches and millimeters for axes whose index is less than N_AXIS_LINEAR. I programmed this this way so that I could not do the conversions for non-linear (rotating) axes.

With N_AXIS_LINEAR = 3, the conversion is done for the first Y (axis[1]) and not for the second (axis[3]). This can explain the differences in travel of your 2 Y axes. In normal operation, with cloned axes, you must have the same parameters for $101 and $103 In normal operation, with cloned axes, you must have the same parameters for $101 and $103. And as well as all the parameters $111 and $113, $121 and $123, $131 and $133 .

@++; Gauthier.

[ccwtruck]

Hi @ccwtruck!

OUPS! probably my mistake... Last week, when I wrote the right config for your need, I give a wrong value for the N_AXIS_LINEAR parameter.

With 4 axes X, Y, Z and Y, you should have #define N_AXIS_LINEAR 4 and not 3 like I wrote!

Indeed, internally, Grbl uses millimeters as a unit. In grbl-Mega-5X, the axes are not managed by their letters, but by their numbers (index of the value tables). In G20 mode (length unit = inches) the N_AXIS_LINEAR parameter is used to convert between inches and millimeters for axes whose index is less than N_AXIS_LINEAR. I programmed this this way so that I could not do the conversions for non-linear (rotating) axes.

With N_AXIS_LINEAR = 3, the conversion is done for the first Y (axis[1]) and not for the second (axis[3]). This can explain the differences in travel of your 2 Y axes. In normal operation, with cloned axes, you must have the same parameters for $101 and $103 In normal operation, with cloned axes, you must have the same parameters for $101 and $103. And as well as all the parameters $111 and $113, $121 and $123, $131 and $133 .

@++; Gauthier.

No, @fra589 , I don't think so... here are my axis definitions: `#define N_AXIS 4 // Number of axes (3 to 6)

define N_AXIS_LINEAR 4 // Number of linears axis, must be <= N_AXIS

// Axis indexing and names

define AXIS_1 0 // Axis indexing value. Must start with 0 and be continuous.

define AXIS_1_NAME 'X' // Axis names must be in X, Y, Z, A, B, C, U, V, W, D, E & H.

define AXIS_2 1

define AXIS_2_NAME 'Y'

define AXIS_3 2

define AXIS_3_NAME 'Z'

define AXIS_4 3

define AXIS_4_NAME 'Y' // Letter of axis number 4

`

So that doesn't seem to be the trouble. Perhaps a misplaced binary operator in stepper.c? As I said, it is not a problem -- just a curiosity.

John

[fra589]

As I said, it is not a problem -- just a curiosity.

No, it's really a problem! It's probably a bug and I need to find it.

@++; Gauthier.

[fra589]

Please, can you post the results of the $G and $$ command on your machine?

[ccwtruck]

But of course, my friend!

>>> $G
[GC:G0 G54 G17 G21 G90 G94 M5 M9 T0 F0 S0]
ok
*** Connected to GRBL 1.2h

>>> $$
$0 = 10    (Step pulse time, microseconds)
$1 = 255    (Step idle delay, milliseconds)
$2 = 0    (Step pulse invert, mask)
$3 = 1    (Step direction invert, mask)
$4 = 0    (Invert step enable pin, boolean)
$5 = 0    (Invert limit pins, boolean)
$6 = 0    (Invert probe pin, boolean)
$10 = 254    (Status report options, mask)
$11 = 0.020    (Junction deviation, millimeters)
$12 = 0.002    (Arc tolerance, millimeters)
$13 = 0    (Report in inches, boolean)
$20 = 0    (Soft limits enable, boolean)
$21 = 0    (Hard limits enable, boolean)
$22 = 0    (Homing cycle enable, boolean)
$23 = 0    (Homing direction invert, mask)
$24 = 25.000    (Homing locate feed rate, mm/min)
$25 = 250.000    (Homing search seek rate, mm/min)
$26 = 250    (Homing switch debounce delay, milliseconds)
$27 = 5.000    (Homing switch pull-off distance, millimeters)
$30 = 12000    (Maximum spindle speed, RPM)
$31 = 550    (Minimum spindle speed, RPM)
$32 = 0    (Laser-mode enable, boolean)
$100 = 320.000    (X-axis travel resolution, step/mm)
$101 = 800.000    (Y-axis travel resolution, step/mm)
$102 = 320.000    (Z-axis travel resolution, step/mm)
$103 = 320.000   
$110 = 2000.000    (X-axis maximum rate, mm/min)
$111 = 2000.000    (Y-axis maximum rate, mm/min)
$112 = 2000.000    (Z-axis maximum rate, mm/min)
$113 = 2000.000   
$120 = 1000.000    (X-axis acceleration, mm/sec^2)
$121 = 1000.000    (Y-axis acceleration, mm/sec^2)
$122 = 1000.000    (Z-axis acceleration, mm/sec^2)
$123 = 1000.000   
$130 = 1400.000    (X-axis maximum travel, millimeters)
$131 = 1400.000    (Y-axis maximum travel, millimeters)
$132 = 100.000    (Z-axis maximum travel, millimeters)
$133 = 1400.000   
ok

I hope this helps you track down your bug!

John

[RaphaelDives]

Hey there, just read your post very roughly, but since you are cloning the Y axis... I think your $xx1 and $xx3 parameters should be the same! (e.g. $101 == $103!)

Cheers Raphael

[ccwtruck]

Hey there, just read your post very roughly, but since you are cloning the Y axis... I think your $xx1 and $xx3 parameters should be the same! (e.g. $101 == $103!)

Cheers Raphael

Perhaps you should read the whole thread...

Cheers!

[RaphaelDives]

Hey there, just read your post very roughly, but since you are cloning the Y axis... I think your $xx1 and $xx3 parameters should be the same! (e.g. $101 == $103!) Cheers Raphael

Perhaps you should read the whole thread...

Cheers!

Haha… okay sorry! You are right, I should have read it carefully before. Now I have! Nice machine by the way!!

But very strange… I have cloned x and y axis and a rotary as well, but never encountered such problems. 😕 Good luck! 😊

[fra589]

Hi @ccwtruck,

I suspect a bug in the conversion between millimeters (Grbl's internal units) and inches (the units you work in), but I haven't found it yet.

From what I read, it's the first Y axis ($101) and not the 2nd ($103) for which you had to modify the movement parameter to 800 instead of 320... That is to say that you multiplied the correct value by 2.5 to obtain the correct displacement of first Y axis (probably a value of 2.54 would be more precise).

Can you do a test of axis movement using millimeters?

G21
G91G0Y25.4

And check and report the movement of the two axes...

@RaphaelDives, Hello my friend!

Have you ever used inches as a unit? Can you do the test with inches as the unit on your machine?

G20
G91G0Y1

And check and report the movement of the two axes...

T.I.A. @++; Gauthier.

[ccwtruck]

My apologies for confusing the two axis in my earlier description; the grbl settings enumeration is accurate, of course. Actually, Gauthier, I do work in millimeters - I just happened to take the actual travel measurement with my micrometer set on inches; the actual jog increment used in Grbl was 25 mm. And you’re probably correct about it being a factor of 2.54, because the precise travel measurement was actually 1.0247 inches.I won’t be able to take any measurements for a day or two — the machine had a little mishap today involving a loose screw that caused one side of the y-axis to bind up. The machine is apart right now for repairs — nothing too serious, though.JohnSent from my iPhoneOn Jun 28, 2024, at 00:04, Gauthier Brière @.***> wrote: Hi @ccwtruck, I suspect a bug in the conversion between millimeters (Grbl's internal units) and inches (the units you work in), but I haven't found it yet. From what I read, it's the first Y axis ($101) and not the 2nd ($103) for which you had to modify the movement parameter to 800 instead of 320... That is to say that you multiplied the correct value by 2.5 to obtain the correct displacement of first Y axis (probably a value of 2.54 would be more precise). Can you do a test of axis movement using millimeters? G21 G91G0Y25.4

And check and report the movement of the two axes... @RaphaelDives, Hello my friend! Have you ever used inches as a unit? Can you do the test with inches as the unit on your machine? G20 G91G0Y1

And check and report the movement of the two axes... T.I.A. @++; Gauthier.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

[ccwtruck]

Good morning, @fra589 !

I have some very good news for you today. After going back over my stepper motor driver dip switch settings, uploading a completely fresh copy of Mega-5X, changing ONLY my axis settings, doing a $RST=*, and then storing the proper GRBL settings for 1/8 stepping, I believe that I have found the problem. And your code was completely blameless -- there seems to be no bug.

I am VERY sorry for raising a false alarm!

When I checked the dip switch settings, I found that I was driving the motors with over 6 amps (the motors are only 4.2 amp rated), and that the micro-stepping was set incorrectly (these DMA860S drivers don't have much in the way of documentation, and there are some conflicts in the explanation of dip switch settings between the data plate on the driver and the data sheet from RattMotor). I believe that this is the root cause of my troubles -- the motors were being over-driven, and occasionally missed/ added pulses that were or were not actually sent, to the point of randomly shutting themselves down at some point.

Now that I have ironed out the dip switch settings, the machine performs flawlessly -- I completed a dry-run on a rather intricate G-code file last night, and Mega-5X never missed a beat.

Today, I plan to complete installation of my limit switches, set homing to "ON", and attempt to home the machine. I will keep you updated with my results.

John

[RaphaelDives]

Hey there, good news to hear! I think it does not matter anymore but I tested the inch setting today and it worked flawless on both axes as expected. 😉 Cheers!