Open Grex3D opened 8 months ago
I can report the same exact behaviour: it is quite dangerous as at the next command the machine resume its motion despite the hard stop being triggered.
When the limit switch is triggered, the mc_reset() method in MotionControl.cpp is called from isr_limit_switches() in Limits.cpp
mc_reset() (see line 526 in MotionControl.cpp ) does many sensible things (stopping spindle, coolant, steppers) and forces flag sys_rt_exec_state.bit.reset = true; this flag tripping causes the global reset that clears the alarm in the reset process.
I can see that in standard Arduino atmega grbl code, things are done pretty much in a similar way, HOWEVER a standard grbl 1.1 on arduino atmega or other DOES NOT reset the alarm state ensued by the limit switch tripping.
Resetting the alarm is particularly dangerous because any following commands coming from the host can force the axis beyond the hard stop.
I have also tried to force flag FORCE_INITIALIZATION_ALARM in Config.h (line 280) in the hope that after a reset an alarm is forced but that only impacts hard reset and not soft reset (which is 100% logic otherwise one could never manually soft reset an alarm state)
Can the developers at Makerbvase please provide feedback on this problem?
Ah thank you, so I'm not crazy :D There must be somewhere in the firmware source the possibility to modify that? It looks like a macro sent by the firmware when the limit switch is triggered. I'm searching through the files but without knowing where to look, it's complicated
Any feedback or help from MAKERBASE developers?
I think I found the reason why DLC32 doesn't stay in alarm state when hard limits are hit.
In Protocol.cpp makerbase has commented lines 362, 363 and 369 perhaps for some UI or web app reasons. These lines include a while(..) block that is intended to hold the machine in alarm state until a manual reset. I do not use the touch screen or the web ui so for me it is not a problem to reinstate the nominal grbl behaviour of expecting a MANUAl reset to unlock the machine, therefore I removed the comments to allow the while(..) to work correctly as intended
@lorenzo535 Thanks you :) I'm gonna try ! (same as you, i don't use screen/webui) Another solution, is install Grblhal, wrk perfectly for me.
Let me know if you want me to send you a compiled version if you have trouble compiling the project,All the best On Sunday, 10 March 2024 at 12:58:44 CET, Grex3D @.***> wrote:
@lorenzo535 Thanks you :) I'm gonna try ! (same as you, i don't use screen/webui) Another solution, is install Grblhal, wrk perfectly for me.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
Let me know if you want me to send you a compiled version if you have trouble compiling the project,All the best On Sunday, 10 March 2024 at 12:58:44 CET, Grex3D @.> wrote: @lorenzo535 Thanks you :) I'm gonna try ! (same as you, i don't use screen/webui) Another solution, is install Grblhal, wrk perfectly for me. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.>
Thanks :)
Hello, I managed to compile using Vscode/platformio but encountered many problems while flashing. I encountered flash read errors with MKS tool and esp download tool; the only way to flash correctly was to use VSCODE.
However, I have another issue: everything works fine except for my Z and Y limit switches.
When a limit switch is triggered in the X axis, I can unlock the alarm and perform a home, for example. However, when a limit switch is triggered in the Y or Z axis, I can't unlock the alarm; it immediately returns, and I'm forced to manually release my switches to unlock.
I can't identify where this issue might originate from in the firmware.
Hi there, I don't think I have the same behaviour but I'll check. FIY I use inductive sensors instead of switches, but from a software point of view, nothing changes. In the code , the same behaviour applies to all hard limits: basically the same interrupt function is associated to all the GPIO that read the limit switches (see line 282 in limits.cpp ) therefore nothing should change in the way the event is handled.Could it be that the configuration of your the specific X and Z axes (acceleration, steps per mm, ...) is such that the way you "enter" the limit switches is different from Y ?
On Tuesday, 12 March 2024 at 03:40:03 CET, Grex3D ***@***.***> wrote:
Let me know if you want me to send you a compiled version if you have trouble compiling the project,All the best On Sunday, 10 March 2024 at 12:58:44 CET, Grex3D @.> wrote: @lorenzo535 Thanks you :) I'm gonna try ! (same as you, i don't use screen/webui) Another solution, is install Grblhal, wrk perfectly for me. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.>
Thanks :)
Hello, I managed to compile using Vscode/platformio but encountered many problems while flashing. I encountered flash read errors with MKS tool and esp download tool; the only way to flash correctly was to use VSCODE.
However, I have another issue: everything works fine except for my Z and Y limit switches.
When a limit switch is triggered in the X axis, I can unlock the alarm and perform a home, for example. However, when a limit switch is triggered in the Y or Z axis, I can't unlock the alarm; it immediately returns, and I'm forced to manually release my switches to unlock.
I can't identify where this issue might originate from in the firmware.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
I just found a better solution, I reflashed with grblhal, and everything works wonderfully :D
Grblhal Webuilder > flash download tool (oldversion needed like 3.6.6)
Hello, I just installed my Mks dlc32 v2.1 on a mini CNC. (Firmware : V2.1.0_H35_20220526_02_N_CNC.bin ) Everything seems to be working fine except for the alarm. I have 3-pin limit switches, they work correctly, they stop the movement, but the alarm doesn't stay activated. So when a limit switch is reached, the alarm triggers, and I get a message indicating that it unlocks automatically: $x: Caution: Unlocked.
Furthermore, I get the message when the limit switch is pressed and when it is released.
To summarize, my machine unlocks by itself, causing safety, homing, etc...
if someone can help me ...
Thanks.