Z axis movement not limited by M203

LS,
This is my first Topic, so be no nice.;-))
I tried to figure it out by myself for weeks so far no luck.
I can use some advise...

Marlin Rumba setup with drv8825.
My coreXY machine is homing just fine. X, Y and Z.
I have to use M203 X400 Y400 Z0.6
Pronterface is working fine with the X,Y(100mm) and even the Z movement of 10mm is no problem.

My typical setup difference is that;
My z table is moved by 2x nema17 which are on a gearbox with a 1:100 ratio. ( 4x 8mmx1mm thread spindles hold the table, connected by GT2 belts)
X0, Y0, Z0 homing position
X600, Y1000, Z-600 ( Ztable is dropping down from 0 to -600)

G90
G28 X Y Z; OK
G1 Z-50 ; OK
G1 X100 Y100 F6000 ; OK
G1 Z-60 ; Here the trouble starts... The feedrate given for G1 is influencing my Z movement and instantly stalling the motors..because they should be using.. the M203 setting (M203 Z0.6)

Marlin 1.1.9 and the bug fix...was already tested no luck.

[github.com]
Z axis using X and Y feed rate when traveling #8549 , could be of some help

thinkyhead has a solution....but were do I drop this code..without having a compilation error.

// Calculate and limit speed in mm/sec for each axis
float current_speed[NUM_AXIS], speed_factor = 1.0; // factor <1 decreases speed
LOOP_XYZE(i) {
const float cs = FABS(current_speed = delta_mm * inverse_mm_s);
#if ENABLED(DISTINCT_E_FACTORS)
if (i == E_AXIS) i += extruder;
#endif
if (cs > max_feedrate_mm_s) NOMORE(speed_factor, max_feedrate_mm_s / cs);
}

For the one providing me the solution, so my printer starts moving the correct way... I will buy you a beer.. or a soda, that's for sure.

Regards,
wydowaw

First of all, as the bed drops, Z is increasing, so Zmax should be +600, not -600.

Type in M503 and see what comes back. If you have EEPROM settings enabled, there may be a value there that is overriding the config file.

---

Ultra MegaMax Dominator 3D printer: [drmrehorst.blogspot.com]

I would also consider that you will not override max speed with M203 but set it in Marlin. While testing to fond those values it may be fine, but once you done test write values to configuration.h and flash the board. And as @the_digital_dentist said use positive numbers, it is highly possible that there is bug in Marlin for moving in negative space. Get positive

Thanks for taking the time to Read and reply. ( I appreciate the help very much)

M503 shows that my M203 is set to X400 Y400 Z0.6 in the eeprom.
I don't use M203 any more in the gcode, because it's in marlin (as piper3d was suggesting)
Still there is the problem of stalling Z motors as soon as I move them in the gcode after X and/or Y movement.
# problem not solved.

Maybe we should start another thread for the negative numbers? But it might be related to this problem...

You are so right, the bed drops and the numbers should increasing.
That's also what Simplify3d (S3D) shows me in the gcode.
I configured it now from -500 to 0 so now it is increasing and consistant with the gcode S3D is writing out and the machine i configured in the fff setup. (attached pictures and current setup S3D)

I am a possitive person...
An the suggestion to go to the positive numbers.. is something I tried, it was moving 600 to 0.
But the my S3D confg was not willing to create correct gcodes. now with the -500 to 0 it works ok.

My printer is homing (fact)
and moving with this negative setup. (fact) Just G90 and Z0 drops it to the lower position. (taking 17 minutes)
Marlin doesn't like the negative numbers on the LCD. it's missing a digit because of the minus sign.

Negative numbers is not the problem...It's the printing speed on Xand Y forcing my Z movements to stall.
Was anybody able to understand the piece of program I posted earlier, that might be a solution.

regards,
wydowaw

As the bed moves down, Z is increasing. If it isn't set up that way, it's a problem that should be fixed along with the other problem(s). The fact that Z isn't set up correctly leads me to suspect that maybe you have some other basic configuration errors. I suggest reviewing motion and homing set up and make sure everything moves correctly before proceeding. Your other problem(s) may disappear once the motion is set up correctly.

---

Ultra MegaMax Dominator 3D printer: [drmrehorst.blogspot.com]

@Dentist
The bed moves down and the the z is increasing from -500 to 0.
Is this OK in your opinion?
If not I will load up my files and i am willing to try every suggestion you give me.

Just picked up my file.
This is the configuration file,currently in use and homing to my desired location (top right in topview)
#define DEFAULT_MAX_FEEDRATE { 400, 400, 0.55, 80 } ; 0.55 is max otherwise the z motors stall during homing.
Z configuration is geared with a ratio of 1;100.

Please any advice is welcome.
just tested the follow file with pronterface
G28 X Y Z; OK homing
G90
G1 Z-495 ; OK dropping 5mm with homing speed.
G1 X100 Y100 ; OK but moving very slow (no feed defined, F6000 will move with the defined feedrate no problem.)
G1 Z-490; Instant stall with or without Feedrate

Any idea what to try next?

Z=0 is when the nozzle is touching the bed. As the bed moves away from the nozzle (or, from the point of view of the print on the bed, and the nozzle moves up), Z is increasing. The highest positive Z value will be where the bed is at the bottom of the Z axis (the extruder nozzle will be at the highest point above the bed).

You also have to get X and Y configured correctly for right hand rule coordinates, because that's what CAD uses. If you don't correctly set up RHR coordinates, prints will be mirrored. The home position is established by the positions of the endstop switches and is not necessarily at (0,0,0). When you set up endstops correctly and then set up motor directions, sending a home command should cause all the motors to move the extruder nozzle toward the endstop switches (again, not necessarily at (0,0,0). I have found that setting the origin (0,0,0) at the center of the bed is a good idea because slicers like it that way and you don't have to use any custom gcode to ensure that prints land at the center of the bed.

You should not have to do any special programming to get the thing to work. Thousands of people run printer with the same sort of hardware and don't need custom programs to make it work. The problem is most likely in your configuration.

Edited 1 time(s). Last edit at 07/22/2019 05:19PM by the_digital_dentist.

---

Ultra MegaMax Dominator 3D printer: [drmrehorst.blogspot.com]

@Dentist
Thank you for the advice... I will start from scratch... setting the origin in the middle of the bed.

Will be back as soon as I have my setup tested.
For now I did it on paper. Is this what you are telling me.
Mechanical testing will be done Thursday 1900CET.

Get positive
Just changed to positive for the Z axis as advised. (thanks dentist and piper3d)
So now the machines homes OK... Z moves from 0 to 500
Movement with pronterface X Y with the 6000 and Z 33 feedrate No problem!! (see picture)
Tested XY working range is 6000-24000 for Z the current working range is 23-33.

The problem of this thread still occurs when running the "same" in gcode format.
G28 X Y
G28 Z
G90
G1 Z5 F33
G1 X100 Y100 F6000
G1 Z10 F33 ;Now my z motor stalls instantly

ANY help is appreciated.

Does it work at lower speeds?

---

Ultra MegaMax Dominator 3D printer: [drmrehorst.blogspot.com]

No. (that is the short answer)

I uploaded 6 variations of Gcodes I tested.
For all 6 Gcode the G1 Z10 movement after the G1 X100 Y100 with/without Feedrate... the Z motor stalls.
Movement with pronterface , homing AND stepping 10mm with Z33 speedsetting as shown previous... works full speed.

I also reinstalled Marlin 1.1.9. (again) adding the bugfix patch, is still work in progress.
Maybe this is Rumba related.. so I am preparing a DUET to take over.

Please take a look at the first post I did:
(Z axis using X and Y feed rate when traveling #8549) and the thinkyhead solution. What do you think of this.

Again thanks for all the help.

Sorry the files are missing

Hi all,

It looks like that this problem is not easily solved. It might even be a Marlin bug.
My next step is to report this bug. ( i will report to the forum as soon as I found the solution to this weird rare problem)

If there is anybody out there able to help me implement the following code;

// Calculate and limit speed in mm/sec for each axis
float current_speed[NUM_AXIS], speed_factor = 1.0; // factor <1 decreases speed
LOOP_XYZE(i) {
const float cs = FABS(current_speed = delta_mm * inverse_mm_s);
#if ENABLED(DISTINCT_E_FACTORS)
if (i == E_AXIS) i += extruder;
#endif
if (cs > max_feedrate_mm_s) NOMORE(speed_factor, max_feedrate_mm_s / cs);
}

My programming skills are not sufficient, to get this to a compile-able Marlin version I can test on my corexy machine.
Again any help is appreciated.