Macrobase-tech / MKS-DLC32

MKS DLC32 is 32bit MCU powerful controller for CNC machine.
https://www.aliexpress.com/item/4000828878233.html?spm=a2g0o.store_pc_topSellerIng.8148356.7.6ab922a9BYVuPh
42 stars 21 forks source link

M5 or M30 at end of file stops machine before job done #31

Open Wiki-the-Tinkerer opened 1 year ago

Wiki-the-Tinkerer commented 1 year ago

GRLB1.1 MKS DLC32 v2 pc, W11- bCNC, laserGRBL 5.01, Candle, grblControl etc.

Sending Gcode with M5 or M30 at end of file stops cnc machine before the job done. Tested with several different senders. Seems like controller would stop execution of the other still running commands when either M5 or M30 is confirmed with OK = program stops executing, and sends "idle", while sender keeps saying something like "98% completed".

When commenting out only the M5 and M30 the programs work without problem.

Macrobase-tech commented 1 year ago

hello,how the value you set on travel resolution step/mm?

------------------ Original ------------------ From: "Macrobase-tech/MKS-DLC32" @.>; Date: Sat, Jul 29, 2023 10:30 PM @.>; @.***>; Subject: [Macrobase-tech/MKS-DLC32] M5 or M30 at end of file stops machine before job done (Issue #31)

GRLB1.1 MKS DLC32 v2 pc, W11- bCNC, laserGRBL 5.01, Candle, grblControl etc.

Sending Gcode with M5 or M30 at end of file stops cnc machine before the job done. Tested with several different senders. Seems like controller would stop execution of the other still running commands when either M5 or M30 is confirmed with OK = program stops executing, and sends "idle", while sender keeps saying something like "98% completed".

When commenting out only the M5 and M30 the programs work without problem.

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

Wiki-the-Tinkerer commented 1 year ago

Hi, Travel resolution : X1602, Y1245, Z809.5. However, these were altered many times, while calibrating the machine, and changes do not affect the issue of execution stopping when the M30 is reached in the sending to the que.

This is not the sameas the "normal" random connection stops that happends all the time (possibly due to emi/power fluctuations - this clearly happens when the code up to end is recieved by the board. But.. not every time. Have not been able to identify any specific trigger.

Macrobase-tech commented 1 year ago

Hello,we don't really understand this issueyet. could you explain more detail?

1005918473 @.***

 

------------------ Original ------------------ From: "Macrobase-tech/MKS-DLC32" @.>; Date: Sun, Sep 3, 2023 08:00 PM @.>; @.**@.>; Subject: Re: [Macrobase-tech/MKS-DLC32] M5 or M30 at end of file stops machine before job done (Issue #31)

Hi, Travel resolution : X1602, Y1245, Z809.5. However, these were altered many times, while calibrating the machine, and changes do not affect the issue of execution stopping when the M30 is reached in the sending to the que.

This is not the sameas the "normal" random connection stops that happends all the time (possibly due to emi/power fluctuations - this clearly happens when the code up to end is recieved by the board. But.. not every time. Have not been able to identify any specific trigger.

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

met-japan commented 1 year ago

First, thanks Wiki-The-Tinkerer for figuring this out, yes, this happens if there is an M5 (Spindle Stop) command issued, has been very annoying as it's fairly standard in the footer. Deleting it from the footer seems to solve the problem but other versions of GRBL have had no problem. The temporary fix is to not issue spindle commands but MKS should fix this.

Wiki-the-Tinkerer commented 1 year ago

Yes, it's a pretty normal thing to turn the spindle off, when the job is done. Besides, it saves a nice amount of fingers if you are able to turn off the spindle if you e.g. need to change tool... Or, then you'd either need to have a separate program for each tool, or a hardwired switch.

My uneducated guess is that this is a matter of buffered sending of the commands VS syncronized sending. And spindle commands for some reason being priorized.

met-japan commented 1 year ago

Yes, not being able to use M5 and M30 is a serious problem with the firmware of this board that severely restricts its usefulness, unfortunate as is's otherwise a nice little board. Unless MKS fixes this issue I'll be switching to either another board or seeing if FluidNC grbl firmware is compatible with MKS DLC32 as it seems to be better supported. I would prefer that Macrobase-tech itself addresses this serious issue and offers updated firmware.

met-japan commented 1 year ago

Wiki-the-Tinkerer, I agree with your synopsis. Standard G-Code is buffered (as is should be for read ahead computation), however M commands are executed as they are read instead of being added to the queue.

met-japan commented 1 year ago

Potential Fix: Set grbl $10=3 Have only tested with M3 and M5 but it worked fine running the whole programs both long and short. Will test tool changes over the next few days.

met-japan commented 1 year ago

Tool changes also working fine. using TTL signal to control external relay for motor. So far so good.

Macrobase-tech commented 1 year ago

Excellent

1005918473 @.***

 

------------------ Original ------------------ From: "Macrobase-tech/MKS-DLC32" @.>; Date: Sat, Sep 16, 2023 10:53 AM @.>; @.**@.>; Subject: Re: [Macrobase-tech/MKS-DLC32] M5 or M30 at end of file stops machine before job done (Issue #31)

Tool changes also working fine. using TTL signal to control external relay for motor. So far so good.

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

Macrobase-tech commented 1 year ago

turn off spindle by commend. also can do it on display

1005918473 @.***

 

------------------ Original ------------------ From: "Macrobase-tech/MKS-DLC32" @.>; Date: Tue, Sep 12, 2023 05:51 AM @.>; @.**@.>; Subject: Re: [Macrobase-tech/MKS-DLC32] M5 or M30 at end of file stops machine before job done (Issue #31)

Yes, it's a pretty normal thing to turn the spindle off, when the job is done. Besides, it saves a nice amount of fingers if you are able to turn off the spindle if you e.g. need to change tool... Or, then you'd either need to have a separate program for each tool, or a hardwired switch.

My uneducated guess is that this is a matter of buffered sending of the commands VS syncronized sending. And spindle commands for some reason being priorized.

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

met-japan commented 1 year ago

Things have been working well for about a week. So far all the programs I've run (about 50) have all run to completion including spindle control (on/off) and proper tool changes through M06. Using bCNC as a front end. I'm finding that the MKS-DLC32 firmware uses a hybrid of certain grblhal commands that are poorly documented. This morning I had the controller freeze while issuing some simple codes via the MDI interface of bCNC which is worrying. I still do not have confidence in this board. I've downloaded the firmware source and will see if anything stands out. I feel I'm taking two steps forward and one step back. In CNC "almost working" is not good enough!

Wiki-the-Tinkerer commented 1 year ago

Met-japan - thats strange.. Why would the status report options affect the execution of e.g. M5?

In senders where its possible to affect - sort of "separate" - the sending and execution process the easiest dirty fix may be to avoiding buffering of the stream. (Sure as heck wont be removing the spindle stops from proper code, haven't got enough fingers ;)

E.g. in LaserGrbl, in the Settings / first tab Protocol / Streaming Mode has to be set to "Syncronous" instead of the "Buffered" which otherwise would make more sense. You lose the whole fast buffer benefit, but it at least works.

Also noticed that some senders have inbuilt "Program End" code removal by default (M2,M30) - apparently to avoid resetting G92 offsets. Not saying what I think about that, stripping planned code without notification.. but it can mean that this error escapes without being noticed in some senders.

General note: the board has become much more stable, when NOTHING except octocoupled endstop signals, and the stepper outs (to separate drivers) are connected.

It seems that a major issue is the old usb chip (purely deducting here) that takes disturbance from anything, making usb very close to un-usable on a ny even slighlty dirty power lines. It also works good from SD, you just need to find some ancient FAT32able small enough card. (managed to get a 256mb card formatted after a couple hours of frustrating program downloads and tests. NOT as easy as you'd expect in newer Windows. WIN - There is a free edition of "EaseUS Partition master Free edition" - that can throw away the space of the card, to leave only 4GB, so that windows accepts to format it to FAT 32 that the card needs. Uh and Duh.)

Wiki-the-Tinkerer commented 1 year ago

In CNC "almost working" is not good enough! Yep, with bigger spindle motors (and lasers too i guess), not good enough can be really bad. I've downloaded the firmware source and will see if anything stands out. Looking forward to any findings :)

ps met-japan, have you got the S speeds to work? (separate issue thread). If you look at the ingredients, and happen to cross the S speed calculation, maybe you could have quick a look if you have time?.. Methinks there is some major math error in there, in the translation/division of speed X to whatever resolution makes 1-100% in the board... Should be simple maths, so probably just a mistake where no-one had considered spindles with higher speed. (eg. my small one has 24000r as optimal)

met-japan commented 1 year ago

I think you've hit on something regarding the USB connection. After a "freeze" occurs the syslog shows a disconnect error of the ch341-uart (I use Linux). Going to chase this down first as it could be crux of the problem. I'll get back to you on the other issues you've mentioned.

met-japan commented 1 year ago

Just confirmed, 45 minutes into a run syslog shows error USB disconnect, will try a different computer but if this problem persists because of the on board USB UART chip I'm going to donate the board to the local skeet range.

Macrobase-tech commented 1 year ago

May try different GRBL software with different gcode

1005918473 @.***

 

------------------ Original ------------------ From: "Macrobase-tech/MKS-DLC32" @.>; Date: Tue, Sep 19, 2023 02:22 PM @.>; @.**@.>; Subject: Re: [Macrobase-tech/MKS-DLC32] M5 or M30 at end of file stops machine before job done (Issue #31)

Just confirmed, 45 minutes into a run syslog shows error USB disconnect, will try a different computer but if this problem persists because of the on board USB UART chip I'm going to donate the board to the local skeet range.

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

met-japan commented 1 year ago

Maybe try shipping with a proper and fully tested version of Grbl.

met-japan commented 1 year ago

Which version of GRBLhal do you recommend? This is for a standard CNC 3 axis mill. Please supply links to both source code and binary. Thank you.

met-japan commented 1 year ago

The main problem is with the USB connection, switching to a different computer with a known good powered USB port has solved the "freeze" issue. Ran an overnight test program monitoring the USB line without issue. I had initially been using an RPI4 but the USB port does not have enough current for the MKS on board chip,switched to a laptop that I now has well powered ports and the issue went away. My other choice would be to use a powered hub but that just starts to get crowded. The $10=3 is recommended in a few forums, doesn't make a lot of sense to me either but it works. All grbl supported M commands now work as expected. I'm currently not using the PWM controller just M3 and M5 for motor control through the signal line of the TTL port with an external relay. I do have a few different heads including a laser so will need to look into the PWM controller soon. Next step is a day or two of regression testing to make sure all changes this far are truly working as intended. My level of confidence in this board is now high enough to continue tweaking it. Thanks for noting your suspicion of the USB being a possible problem, helped greatly in debugging. FWIT I'm now connecting to the USB port with the original cable plus a high quality 2 meter extension to reach the laptop with no sign of signal leakage. I'm also thinking of switching from a 12v power supply to 24. I use external drivers for the stepper so probably not needed. I need 24v 6a for the laser which I don't think the board can handle so will need to come up with a cunning plan.

Wiki-the-Tinkerer commented 1 year ago

I need 24v 6a for the laser which I don't think the board can handle so will need to come up with a cunning plan.

That should not be any problem, providing there is a working "right scaled" output - i.e. ttl 0v-5v. Apparently this works if S max setting is 1000. Then you connect the ttl to your laser drivers ttl input (sharing ground with laser power). May need a simple logic level shifter, or a fast transistor/octocoupler fix in between, if your laser drivers ttl input would not be 0-5v. With this board it seems a good idea to not run anything through the board, and octocouple everything possible, to minimize disturbances.

Macrobase-tech commented 1 year ago

6a is high.please plug additional power to laser/spindle

1005918473 @.***

 

------------------ Original ------------------ From: "Macrobase-tech/MKS-DLC32" @.>; Date: Thu, Sep 28, 2023 08:51 PM @.>; @.**@.>; Subject: Re: [Macrobase-tech/MKS-DLC32] M5 or M30 at end of file stops machine before job done (Issue #31)

I need 24v 6a for the laser which I don't think the board can handle so will need to come up with a cunning plan.

That should not be any problem, providing there is a working "right scaled" output - i.e. ttl 0v-5v. Apparently this works if S max setting is 1000. Then you connect the ttl to your laser drivers ttl input (sharing ground with laser power). May need a simple logic level shifter, or a fast transistor/octocoupler fix in between, if your laser drivers ttl input would not be 0-5v. With this board it seems a good idea to not run anything through the board, and octocouple everything possible, to minimize disturbances.

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