Controller: Using Blackbox X32, running Openbuilds CONTROL software v1.0.377 Limit Switches: OpenBuilds COPPER POUR (tm) Xtension Limit Switches, (6) set up in Parallel as shown in documentation. Machine: 1515 Notable information: All the Shielded Cable is Grounded. Motors and Limits All grounded to same buss bar Wiring was THOUGHLY Checked to make sure there are no crossed leads and each wire in cable (GRD/+V/SIG) checked for continuity from the controller connector to the limit switch connector New machine and just tuning all the bits before actually cutting something and the following issue has started to occur while adjusting the limit switches. One can trip any of the Limit Switches multiple times before ethe ALARM Routine finally runs. The danger is the LIMIT is tripped and it WILL NOT STOP the machine!!! The Messages in the log are as follows: LIMIT TRIPPED 2x without Stopping Machine [16:23:52] [ ] GrblHAL 1.1f ['$' or '$HELP' for help] - LIMIT DEPRESSED [16:23:53] [ ] GrblHAL 1.1f ['$' or '$HELP' for help] - LIMIT RELEASED [16:23:54] [ ] GrblHAL 1.1f ['$' or '$HELP' for help] - LIMIT DEPRESSED [16:23:56] [ ] GrblHAL 1.1f ['$' or '$HELP' for help] - LIMIT RELEASED LIMIT TRIPPED a 3rd time and Finally initiates the ALARM Routine Stopping the Machine. [16:23:57] [ ALARM ] ALARM: 1 - Hard limit triggered. Machine position is likely lost due to sudden and immediate halt. Re-homing is highly recommended. [ undefined ] [16:23:57] [ ] ALARM: 1 - Hard limit triggered. Machine position is likely lost due to sudden and immediate halt. Re-homing is highly recommended. [ undefined ] [16:23:57] [ ] ALARM:1 [16:23:57] [ ] [MSG:Reset to continue] [16:23:57] [ ] GrblHAL 1.1f ['$' or '$HELP' for help] [16:23:57] [ ] [MSG:'$H'|'$X' to unlock] [16:24:04] [ [clear alarm] ] Operator clicked Clear Alarm: Cleared Lockout and Emptied Queue [16:24:04] [ ] GrblHAL 1.1f ['$' or '$HELP' for help] [16:24:04] [ ] [MSG:'$H'|'$X' to unlock] [16:24:04] [ ] [MSG:Caution: Unlocked] [16:24:04] [ ] ok Help, Please. Regards, RonM
All the extra shielding/earthing might be messing with it.. Wire it as shows in the docs. Nothing extra Shielding can cause more problems than it fixes, if done incorrectly (Earthing vs DC GND seperation etc) Those startup messages in the log looks like a V+ to GND short causing a reboot... Wiring most likely. Can also cause permanent damage so recheck wiring/mounting carefully. The times it didn't alarm, it just reset due to the short before the message could make it across. Times it does, its just that split second of enough power on the power rails left to make the message come across before it reboots, but directly afterwards you still see the reboot. Might be a faulty switch too, unplug one by one to test
Well its been a while before I got back into this. But I re-wired the WHOLE machine. No crossed leads. Removed all grounded wire shielding. Wired EXACTLY like my 1010 Machine and the Connections are all verified via continuity from the connector blocks on the X32 Controller to the limit switch connectors. I also unplugged all limit switches and checked each one, one by one ... and the problem still happens. BTW, I am running the latest Controller Firmware V1.0387/388 too. Interestingly enough, if I trip a limit switch when the spindle and coolant pump is running and the machine is in motion, it kills everything ... Motors stop, Coolant pump shuts off, and Spindle shuts down as one would suspect, but there is a difference. If the limit is tripped and I get the Message "GrblHAL 1.1f ['$' or '$HELP' for help] - LIMIT DEPRESSED", Everything shuts down as noted, I do not get the Alarm, and then I can jog the machine because the Alarm did not go off. When the Alarm trips properly, I get the normal Alarm Message, where I have to clear the Alarm before I can do anything. Any new guidance or suggestions on the Limit Switch issue? It should be straight forward and literally plug and play which is the whole reason why I utilized the Openbuilds X32 Controller. This getting frustrating.
Firmware up to date? docs:blackbox-x32:firmware [OpenBuilds Documentation] CONTROL is v1.0.388. Firmware has a 2024xxxxxx format. The reset message is still a bit weird through
I upgraded the FIRMWARE to whatever was the latest 20240402? I think ... and for what ever reason the issue has stopped. Every time a limit is tripped, it works normally now. If anyone reads the post on this issue a word of caution on machine wiring. Not sure if this is specific to Openbuilds Controllers or is probably a great standard practice. I had to use electrical tape or a bit of heat shrink tube and seal the trimmed cable sheath on the Limit Switch Cables and for fun I did it on the Motor Cables Too. The reason was to insure that the trimmed braided wire shielding did not touch anything, especially the shielding on the cable next to it or the metal components of the CNC. This will greatly retard signals through the control wiring from possibly finding a path to anything else other than its intended target. For this build, I methodically isolated every cable which made a difference. I get the reasons for doing so, just did not expect the system to be so sensitive. Thanks for your help Peter ... HNY!!
Sweet, sorry I didn't mention it earlier - because firmware update is in the docs, its an expected setup step, assumed it was already done Glad that sorted it! There was a bug back in I think 2023xxxx builds of the firmware somewhere, where some Wifi config (also rarely enabled, you might have had yours on) messed with limits (but symptom didn't use to include the reset too, that looked more like wiring - so I didn't even really put that one to mind until you rewired) Tying the shielding down to prevent shorts is good insurance! Happy New year as well!
