Starting with MKS DLC32

Software / Firmware GRBL
20

Okay, I’m using the file MKS_DLC32_v21_laser.yaml as a reference to create my own file.

1- I make a copy: MKS_DLC328v21_Laser_Plotter.yaml
2- I try to make the necessary modifications block by block
a)

board: MKS-DLC32 V2.1
name: eSloch Laser_Plotter
meta: eSloch 17/01/2024

Doesn’t it look nicer like this?

b)

kinematics:
Cartesian:

I don’t modify … apparently, that’s my situation.

c)

stepping:
engine: I2S_STATIC
idle_ms: 255
pulse_us: 4
dir_delay_us: 1
disable_delay_us: 0

I think the only thing to change is the ‘idle_ms.’ If I understood correctly, a value of 255 implies that the motors are always powered, which is better for precision in movements.

I don’t know about the others. I believe they are fine and shouldn’t be modified, even if I don’t fully understand them.

d) The serious stuff begins here:

axes:
shared_stepper_disable_pin: I2SO.0
x:
steps_per_mm: 100
max_rate_mm_per_min: 16000
acceleration_mm_per_sec2: 1500
max_travel_mm: 895
soft_limits: true
homing:
cycle: 0
positive_direction: false
mpos_mm: 0.000
feed_mm_per_min: 300.000
seek_mm_per_min: 8000.000
settle_ms: 500
seek_scaler: 1.100
feed_scaler: 1.100

motor0:
  limit_neg_pin: gpio.36:low
  hard_limits: false
  pulloff_mm: 2.000
  stepstick:
    step_pin: I2SO.1
    direction_pin: I2SO.2:low

So, the “steps_per_mm”… how should I define it? … Also, the “max_rate_mm_per_min” and “acceleration_mm_per_sec2”?
I’ll calculate the “max_travel_mm” precisely once I finish the CNC design (in progress, almost done).

For “soft_limits,” I set it to “true” since I only have two mechanical limits on my CNC. I think it’s interesting.

Now, the “homing” section: is a cycle of 0 correct? What about the other parameters? Are these values correct to start with, or could they potentially harm my machine?

In the “motor0” section, for “limit_neg_pin,” is it “gpio.36” or “gpio.36:low”? And for “hard_limits,” is it false or true?

Alright, my head is already aching. I need to understand this in more detail.

:dizzy_face: :dizzy_face: :dizzy_face:

I noticed in some config files there’s an indication of the stepper used. In my case, it’s TMC2208. Should I specify this somewhere in this section?

21

Alright …

In the end, I thought about stopping bothering myself with these settings. I’m focusing on finalizing my CNC. After that, I’ll just make minimal modifications to the YAML file and test as I make changes.

That’s it.

22

I am testing the servo with my MKS DLC32 control board. I am using this type of servo, the ‘MG90S … 360 Degree’.

image

In the YAML file, I have placed these parameters:

besc:
pwm_hz: 50
output_pin: gpio.22
enable_pin: NO_PIN
direction_pin: NO_PIN
disable_with_s0: false
s0_with_disable: true
spinup_ms: 200
spindown_ms: 200
tool_num: 0
speed_map: 0=0.000% 100=100.000%
min_pulse_us: 900
max_pulse_us: 2200

I am testing in the web console with these commands:

m6 t0
[MSG:INFO: Tool No: 100]
[MSG:INFO: Using spindle BESC]
ok
M3
ok
M5
ok

But I have nothing at the servo … no reaction … Is this normal??

Are the ‘pulse’ and other parameters correct?

Thank you.

edit :

Good… I retested it… with adding S100 in command

Result:

With M3 S100, it rotates in one direction without stopping.

With M5 S0, it rotates in the other direction without stopping.

I think it’s a bad choice of a “360°” servo."

edit 2 :
work fine with 180° servo :roll_eyes:

23

I would like to add an emergency stop button to my setup. Someone advised me (I don’t remember in which discussion) to cut the power to the board, but I’m afraid it might cause damage to the board and the stepper motors. I’m wondering if it’s possible to use the Z-axis limit switch as the emergency stop button. Thank you.

24

Is it a case of the motors dropping fast when underpowered? If the motors don’t send too much current back to the drivers, it should be fine. There have been a few cases of blown hardware, but it is rare, and because a very heavy thing was falling fast, without much leverage on the motor.

25

Yep …

this connexion can’t be the solution ??? I noo see it …

image
image789×358 21 KB

26

That J5 connector is the MCU reset line, if you short it out it will simply reset the ESP32 which will stop the steppers, drop the serial connection and kill the PWM output. It will also lose the position in the running program, lose the position of the axis’, lose the inputted operation file and de-power the stepper drivers allowing the Z to drop under gravity.

There are no spare pins on this board that would allow you to configure a feed hold function which is what you really need to pause the job without losing its position and preventing the Z from dropping.(there is another thread discussing just this on this forum here
The same info applies to FluidNC, you could re-purpose the Z limit switch pin to be a feed hold pin by changing Z:motor0:

   limit_neg_pin: gpio.34

to

  limit_neg_pin: NO_PIN

and

 safety_door_pin: NO_PIN

to

 safety_door_pin: gpio.34
27

Aren’t the I2C pins GPIO if you remove the I2C definition? That gives potentially 2 free pins.

28

They are output pins only, you cannot use them for inputs.

Having said that… I read it somewhere but I cannot find the reference again to check its context. Perhaps it is worth a try.

SDA is IO0 and is used during boot to toggle RTS/DTR so probably best to steer clear of that one, SCL is IO4 …hold on… I’ll give it a go… :slight_smile:

OK…so I was wrong (again). I guess the reference I read was referring to a specific processor or something.
It does work on the DLC32 but there is a bit extra editing required, first comment out the following linesin i2s_out_xyz_mks_dlc32.h -

//#define IIC_SCL                     GPIO_NUM_4
//#define IIC_SDA                     GPIO_NUM_0

//#define COOLANT_FLOOD_PIN           IIC_SCL

then make the following changes to mks_test.cpp line 148

  // pinMode(IIC_SCL, INPUT_PULLUP);
   // pinMode(IIC_SDA, INPUT_PULLUP);
    pinMode(GPIO_NUM_4, INPUT_PULLUP);
    pinMode(GPIO_NUM_0, INPUT_PULLUP);

and line 192 - 207

/*
    if(pin_check(IIC_SCL) == 1) {
        test_i2c_bit |= TEST_I2C_SCL_BIT;
    }

    if(pin_check(IIC_SDA) == 1) {
        test_i2c_bit |= TEST_I2C_SDA_BIT;
    }

    if(test_i2c_bit == 0x11) {
        memset(dis_str, 0, sizeof(dis_str));
        strcpy(dis_str, test_I2C_str);
        strcat(dis_str, test_OK);  
        lv_label_set_text(test_page.label_i2c, dis_str);
    }
*/

Then connect your door between GPIO4 and ground (at the i2c connector is easiest)

firmware.zip (758.7 KB)

Nothing is free in this life and doing this will mean you lose the flood/mist cooling as well as your air assist switching as they all used to use the re-purposed SCL pin

1 Like
29

But you get a very good value when you ask for help in these forums.

1 Like
30

Kick-butt response!

So true!

On the V1 Jackpot (and maybe the Bart Dring six pack that is its’ ancestor), IO0 is used for TX to the UARTs on the TMC2209s, so there are plenty of examples of using that pin post-boot. Jackpot combines IO4 as the RX- so this pair on ESP32 is widely used. Jackpot design shown below:

image
image1670×852 129 KB

31

The problem is what use you put the GPIO to. In the example shown on the Jackpot board the UART will be dormant during boot and so will (should) not interfere with the RTS/DTR ‘shuffle’, however, using it as a door open sensor input the pin could be held at ground potential if the door was left open during boot, which would mess with the correct operation of booting. Hence my ‘best to steer clear of that one’ comment.

I believe Ryan has already seen some problems with boot sequence variability between esp32 modules and there is an interesting thread about what the function of this arrangement is here.

32

That’s a great example of a poor choice for IO0 assignment.

Yes, it turns out that there is a very weak pullup for IO0 inside the ESP32s.

The TMC2209 UARTs when not yet enabled and initialized can sink a bit of current through the UART pin.

Having two in a chain is OK, three is marginal, and more than three will often cause enough of a pulldown efect to make booting fail intermittently. This was not understood initially. It also appears to be why three of those TMC22909s in the UART chain have a gate in front of them, which eats some GPIO as well.

The fix on Jackpot was adding a stronger pullup to the jackpot board. After that, boot reliability issues on Jackpot are solved.

There is a thread here on the forums where that troubleshooting took place.

33

I like the idea of someone having trouble starting it, and then remembering that it won’t boot unless the door is closed.

34

I continue my learning with this wonderful MKS DLC32 board… regarding the emergency stop button… for now, I’m sticking to using the board’s power button… I’ll see later if there’s a need to add a stop button with the commands feed_hold_pin, safety_door_pin, or reset_pin…

:roll_eyes:

Otherwise, I’m currently working on configuring the motors. In the config.yaml file, I have this code:

axes:
shared_stepper_disable_pin: I2SO.0
x:
steps_per_mm: 100
max_rate_mm_per_min: 8000
acceleration_mm_per_sec2: 500
max_travel_mm: 350
soft_limits: true
homing:
cycle: 1
positive_direction: false
mpos_mm: 0.000
feed_mm_per_min: 300
seek_mm_per_min: 1000
settle_ms: 500
seek_scaler: 1.100
feed_scaler: 1.100

motor0:
limit_neg_pin: gpio.36:low
hard_limits: false
pulloff_mm: 2.000
stepstick:
step_pin: I2SO.1
direction_pin: I2SO.2:low

I would like to know which lines are important and how to configure them as correctly as possible.
also I would like to start small and gradually increase the speed to avoid damaging my CNC

Thanks

35

Looks like you’ve slowed down max speed and acceleration about 50% from the reference DLC32 laser config.
It should be workable. Give it a test and report how it behaves…

1 Like
36

OK …
I have finished wiring my CNC machine… two X and Y axes… two X and Y limit switches… I would like to start by configuring the CNC’s movement speed, properly setting the travel distances… and successfully perform homing. The speed I have set seems too low, I think… but I can move correctly… and in the right direction (I initially had one X axis reversed and I corrected that). For homing, I already have an error message…

$H
[MSG:INFO: ALARM: Homing Fail Pulloff]
ALARM:8
Homing fail. Pull off travel failed to clear limit switch. Try increasing pull-off setting or check wiring.
ok

maybe the absence of a Z-axis limit switch is preventing homing… what should I do?

edit …

I tested this… I press the limit switch and I send $HX… the axis moves towards the direction of the limit switch… but when I release it, I get an error message:

$HX
[MSG:INFO: ALARM: Homing Fail Pulloff]
ALARM:8
Homing fail. Pull off travel failed to clear limit switch. Try increasing pull-off setting or check wiring.
ok

:dizzy_face: :dizzy_face: :dizzy_face: :dizzy_face:

37

As the failure message says really…try increasing your $27 setting to 3. (type $27=3 in the console window and press return) The default setting of 1mm is sometimes not enough for the limit switch to release if the switch lever is too long.

If you are trying to operate the limit switches manually there is specific sequence and timing the controller needs to pass the test…not always easy to achieve.

38

Did you give up on your pen plotter with this board ? I have almost same setups but can’t figure it out!

39

No, I haven’t given up… it’s working fine… do you have a problem on your end?