HI, This is my project, my mini-mill cnc conversion is almost complete but can get thru this problem and any help would be greatly appreciated. The equipment used: Smoothieboard 5xC V1.1, DQ542MA drivers, Nema 23 high torques series, 24V power supply. The latest firmware is loaded, cnc configuration file used, At this point I have good communication with the mill, the motors respond to the Pronterface X, Y, Z inputs but except for the following: - When I press the Z home button, the bed moves simultaneously in the X and Y axis for a short distance the stop. I have no motion in the Z axis. I installed the endstop switches on the Y and Z axis for now. Using the M119 command. the switches respond as intended for min and max (1 for pressed and 0 when not), but when pressing the home button the bed will still moving even when pressing the switches ( same behavior as mentioned above). Any suggestions? Thank you, Bruno
Apart from things i assume you already checked (proper wiring pinout, correct config on SD (ie alpha =x, beta =y, gamma =z)) - the one other culprit might be crosstalk on those long, unshielded cables you are running the low voltage 3.3v signals in?
Thank you Peter for responding, alpha, beta, and gamma are responding properly to their axis when tested individually in Pronterface, it is just when using the Z home button that the X and Y axis move a short distance, and always the same. I reflashed the CNC firmware (posted just about 7 days ago) and reloaded the latest configuration file, with no effect. Still the same issue with the endstop switches, does not matter is I enable or disable the function, no response when pressed. For the 3.3v signal, are you referring to the blue/green driver cables? What would be your suggestion as to set them up?
Pretty generic response, hard to troubleshoot without it in front of me. Just looking at the pics, the unshielded wires between the smoothieboard and the DQ542MAs struck my eye as "potentially problematic" - if not the cause here, at least very likely in the future with symptoms like skipped steps (higher currents from motor wires/drivers/psu -> radiates EMI -> relatively "long" wires (looks like around 400mm of wire between the board and drivers judging by size comparisons, (placing the drivers to the left of the Smoothieboard could shrink that to >150mm) which appear to be just sleeves over stranded wire (not proper shielded wires) - will act like antennas, pickup EMI from those radiators, and either not step when you want them to, or step when you dont want them to. Or you may be lucky and they work fine - i'm just always used to overfixing things so they dont become a problem, and low voltage, high pulse rate step signals, on unshielded wire, with that long a run, tied into a parallel bundle, sounds like trouble (; PS: pronterface wont play nice with the CNC Firmware build, and i think this is you issue. G28 in the CNC build "moves axes back to zero" - see g28-cnc [Smoothieware]. Especially "Note :Â This G-code currently only works for the X and Y axes, but ignores the Z axis. This might change in the future, if you are not sure, just try it out manually on your machine." Refer to supported-g-codes [Smoothieware] for more details. G28 has subcodes (G28.1, G28.2, G28.3, G28.4, etc - one of which has your need... but not sent by pronterface... (Pronterface being for 3DP sends "G28" which the reprappers adopted in error, thats the wrong command, according to the linuxcnc spec, it wont go and find the Endstops) (G28 is hardcoded in Pronterface too) Use a proper CNC host like Release v4.0.991-127 · LaserWeb/LaserWeb4-Binaries · GitHub (ignore the word laser, this works great will mills too and has free cam + machine host in one) - it allows you to customise homing commands etc Note Settings - LaserWeb / CNCWeb shows the use of G28.2 as Homing command (the CNC version of firmware.bin just has Grbl mode = true and different feedback strings: So refer the the previous Supported GCODEs link, where they describe $H or G28.2 as homing)
