MKS DLC32 v2.1 issue with external DM542T external drivers

Ich bin gerade diesem Forum beigetreten, nachdem ich eine Nachricht auf dem YT-Kanal von Plottmania gepostet habe. Ich bin ein CNC-Enthusiast und bin auf Ihren Kanal gestoßen, als ich nach einem Video zur Verbindung des MKS DLC32 v2.1 mit externen Motortreibern gesucht habe. Ich habe Probleme mit der Testentfernung im Vergleich zur tatsächlichen Entfernung und kann sie anscheinend nicht beheben

Danke für Ihre Antwort. Ich komme aus England und benutze einen Übersetzer, um zu antworten.

DM542T-Treiber eingestellt auf 10 Mikroschritte (200 * 10)/5 mm (Kugelumlaufspindelsteigung) = 400

100 $ = 400.000 (Wegauflösung der X-Achse, Schritt/mm)
$101=400.000 (Y-Achsen-Verfahrauflösung, Schritt/mm)
$102=500.000 (Z-Achsen-Verfahrauflösung, Schritt/mm)

Wenn ich mein Arduino verwende, funktioniert es genau.

Das Problem, das ich habe, ist das folgende mit der Diskrepanz zwischen der zurückgelegten Testdistanz und der tatsächlich zurückgelegten Distanz.

Tatsächliche Differenz der Testentfernung
10 mm ------------> 6,6 mm = -3,4 mm
20 mm ------------> 16,6 mm = -3,4 mm
30 mm -------------> 26,6 mm = -3,4 mm
50 mm -------------> 46,4 mm = -3,6 mm
100 mm -----------> 96,5 mm = -3,5 mm

Ich verwende gerne CNC.js, habe aber UGS und sogar Openbuild-Controller-Software ausprobiert.

When I built my cnc i started with a Arduino controller and it worked flawlessley when connected to DM542T external controller. Homing cycle everything worked perfectly. So I thought now it is time to find a good priced offline controller and decided to go with the MKS DLC32 v2.1 with the smaller TS24 display.

You are right! Yes, I also thought it should be a straight forward swap. But turned out to be problematic. I have checked the wiring and tried different stepper settings on the driver but same result. The movements are off by about -3.4mm.

What is confusing is it is moving the axis but it is about 3.4mm short of the desired movement.

If I reconnect the Arduino back it works perfectly. So I am of the belief the pulses being sent from the MKS are not correct. But I don't have an oscilloscope otherwise I could compare the two outputs to see if there is a difference.

I am connecting directly to the external driver pins as opposed to using the plugin motor converter board. pasted-from-clipboard.pngpasted-from-clipboard.png

I have a suspicion that this controller only supports the TB6600/TMC2160 external drivers.

Zitat von ichbinsnur

Are you sure you wired the step/pul and dir pins to the drivers correctly?

(all GND Pins on the driver terminal interconnected and connected to ground on the controller?)

Thank you for your reply. I have checked the wiring is correct and the GND pins from the driver terminals all ground to the controller.

In my Arduino setup I had ENA+ connected although in the DM542T (v.4.0) manual it states default is no-connection. I disconnected it from the drivers and it seems to have solved the -3.4mm discrepancy, but when I power ON I can hear the steppers making a sound similar to a fan. With the ENA+ connected they remained silent until there was a command for movement -- I don't fully understand the significance of the ENA. I take it the noise is due to the steppers are continuously energised although SW4 is set to OFF which reduces the current draw to only 50%. I guess I can live with the noise.

I have now got the issue with the homing - in my Gbrl I have the below settings and I am homing -X +Y +Z and my limit switches are configured as NC. (Homing works fine with the Arduino)

Now when I home the X moves +4mm and Y moves -4mm (pull-off distance) but Z does not move at all and it throws up an Alarm.

I have checked the (contact) limits switches all trigger an alarm when pressed manually so I take it the MKS controller is aware of it and the switches are correctly connected to the 3 pins on the MKS board. But I am not using the 5V pin. So not sure why this is broken.

$22=1 (Homing cycle enable, boolean)

$23=1 (Homing direction invert, mask)

$24=100.000 (Homing locate feed rate, mm/min)

$25=1000.000 (Homing search seek rate, mm/min)

$26=250 (Homing switch debounce delay, ms)

$27=4.000 (Homing switch pull-off distance, mm)

Zitat von ichbinsnur

Maybe your GRBL Version doesn't support Homing for z or the Homing cycle isn't set correctly.

Good point! In the console the MKS DLC32 v2.1 controller is reporting v1.1 but not sure if is most current v1.1h - the firmware is V2.1.0_H24_20220511_01_N_CNC and I haven't been able to figure out a way to updating just the Gbrl.

I will investigate further and report back. In the meantime I want to thank everyone on this Forum for the assistance I have received.

Zitat von melvin

If you use the original MKS firmware, it is based on 1.1h, but the configuration is partially custom. So I guess the z homing is disabled, as Christian suspected. The drawback with the MKS board is, you either use their “proprietary” firmware and have the display working, or use “next generation” firmware like FluidNC, but those do not support the display. So it's a tradeoff.

Though, the sources of the MKS firmware have been released, so you can take a look there.

I have a strong feeling the homing issue I am experiencing is due to the fact my limit switches are wired in a 2 wire NC configuration. The MKS is not detecting any presence of limit switches being connected. So it is moving 4mm and stopping and goes into Alarm mode.

The MKS came with 3pin limit switches, I will connect them up temporarily and test if it behaves differently.

With regards to the issue I was having with the ENA connected and getting a -3.4mm discrepancy on all axis is because the MKS uses 3.3v while the motor driver requires a min of 4.5-5v or 24v. It was working fine with the Arduino because it uses 5v.

Zitat von melvin

Ah, didn't think of that. I will try to keep this in mind. I was about to test using external drivers with an MKS board as well

That's weird because a two-wire connection is usually standard. Some strange limit switch circuit boards even require the VCC line to be cut to work properly. Did you test them using the ?-command? With this command, you can test if switches are recognized or not (there is some output that should include Pn:XY or similar if switches are activated. If those are working inverted, you need to toggle $5 setting.

$5 is set to 1 for Normall Connected. I have used UGS and the MKS controller is reporting the detection of the 3 switches correctly when I press them manually. If I reconnect the Arduino it works perfectly but with this MKS DLC32 v2.1 it seems to have different behaviour.

I managed to get the MKS DLC32 v2.1 working the same as when I was using Arduino.

When using external drivers - Do not connect the ENA pin to the motor drivers. The Stepperonline drivers I am using they have mentioned in their technical sheet by default it is not connected.

What I found is without the ENA connected the steppers will remain energized continuously, in my case I hear a noise similar to a small fan running in the background. Whereas if you connect the ENA pin the Steppers are only energized when a command is sent - but for some strange reason the after homing the machine and with my $27=4 (pull-off distance). What it appears to be doing is - it uses this value (3.6mm) to add/subtract to the machine position and therefore when you move say 100mm it will move 96.4 and I tried every setting in Gbrl but could not overcome this issue. So in the end I resorted to disconnecting the ENA cable on all 4 steppers and it has resolved the issue.

With regards to the Homing not working there appears to be some issue in the firmware. I found the solution here https://github.com/makerbase-mks/MKS-DLC32/issues/164

And typing the below command in the console worked for CNC use which requires the Z to home first.

$Homing/Cycle0=Z

$Homing/Cycle1=XY

Hope the above helps others who might be looking to using this offline controller with ESP32 with external drivers.