We use cookies to personalize content, interact with our analytics companies, advertising networks and cooperatives, and demographic companies, provide social media features, and to analyze our traffic. Our social media, advertising and analytics partners may combine it with other information that you’ve provided to them or that they’ve collected from your use of their services. Learn more.
After homing the machine, it should be impossible to raise the Z-Axis past the machine home point, and to jog the X/Y axis out of bounds.
The jog requests would be parsed as follows before sending gCode jogging commands to the CNC:
## Z-Axis (Positive Limit Only) ##
if( Requested Z+ Jog > ABS(Machine Z Position) )
{
New Z+ Jog Distance = ABS(Machine Z Position);
}
## X/Y-Axis Positive Limit ##
if( Requested X/Y+ Jog > ABS(Machine X/Y Position) )
{
New X/Y+ Jog Distance = ABS(Machine X/Y Position);
}
## X/Y-Axis Negative Limit ##
if( ( Requested X/Y- Jog + Current Machine X/Y ) < Machine (X/Y) Defined Negative Work Area Bound )
{
New X/Y- Jog Distance = Machine X/Y Defined Negative Work Area Bound - Current Machine X/Y ;
}
However, I’m not quite looking for soft limits, though they are useful. Soft limits trigger Alarm 2 in GRBL which require a reset.
I’m looking for Easel itself to prevent the user from casual over-jogging primarily before even sending gCode. That way, when you are jogging near the soft/hard limits, you are able to jog right up to 0, or to the max defined work area bound without worry.
For example:
Z-Axis is .4in below the top 0 limit. I hit 1in. Z+ in Easel…
Spindle travels up to 0 and stops.
X-Axis is .04in to the right of home X-boundary…I jog X 1in. left…
CNC travels to -750mm X exactly and stops.
Again, the primary use case I have in mind is inadvertent over-jogging and the ability to easily jog right up to the edge of the machine workspace on all axis in all directions except the negative Z direction.
it would be nice as option, but not as default. Slight over-jogging wont actually damage the machine, it just sounds ugly.
Over-jogging the carriage by definition is damaging to the motors, as well as takes the machine out of a homed state.
I’ll remove “Safety Feature” from the post title to make it more clear: My feature request is to easily provide and improved user experience to prevent over-jogging the carriage (without triggering an alarm) to enable the user to approach and interact with the boundries of the workspace while maintaining a homed state.
Edit: Looks like I can’t edit the original post title
Not really, they are actually in a stall just being energized in normal operation, that is why they are warm even if you are not cutting. I think soft limits option is good idea, just not: because the motors are going to die.
Thank you sir! Yes, avoiding re-homing is the main issue.
Fair enough, I don’t know the technical specifications of the Nema motors in particular. My assumption was that they would either over-torque themselves or, (what it sounds like when I personally go to far up on the Z-Axis) that some sort of internal gearing might start to slip. If that’s not really an issue due to the small size of the X-Carve/NEMAs, then there you go.
Again, I’m coming at this from mostly a User Experience / Workflow perspective: prevent over-jogging the carriage (without triggering an alarm) to enable the user to approach and interact with the boundaries of the workspace while maintaining a homed state.
Nema is a form factor Nema23 means that the width of the stepper (and height as they are square) is 2,3" Nema17 / Nema 24 / Nema 34 are 1,7"/ 2,4" / 3,4" wide
The stepper consist of one solid rotating part, around an array of magnetic gaps (detents) and is only connected by ball bearings. There are no inside gears and the stepper is in practical terms a brushless motor that step (detents) Most steppers are 200 full steps / revolution.
When a stepper stall it simply is prevented to step over to the next detent, and return to the past detent position. That is what is making the grinding noise, nothing mechanical just physical resonance from a rotor “bouncing” against magnetic forces
This would be a nice feature. I am using a tablet running windows 10 and there have been a couple times that I have accidentally tapped the wrong direction on the screen with a distance to travel being too far for that direction. Mostly “down Y” instead of “up Z” or the other way around. It would be very easy to add the code you describe to prevent these oops moments from causing the “crash” and need to reset/rehome.
