Wondering if anyone ever solved the soft limit issue?
Love my Longmill. I’ve been running for a year with no real issues at all. I’ve read about many glitches others have had but been fortunate to not been affected. I personally think many of these are a result of static due to dust collection. Can’t prove that, but I don’t use a dust collector or really feel I need it, and have been largely insulated from glitches or stopping issues.
Recently installed the inductive sensors before Christmas. Merry Christmas to me. After I installed the limit switches I can’t believe I ever lived without them. They work great, I always know where I am and started working with the different work off sets. I highly recommend using them, huge time saver. Cut in some removable dowels to locate my work and haven’t had to locate x, y since. I have one offset for the laser and one for the router so setting x, y zero literally takes about 5 seconds.
My problem. Initially I had the soft limits set and they worked flawlessly. I’m not exactly sure where things went south but I’m relatively sure it’s after I set up my laser and upgraded GSender. I noticed that continuous jog won’t work because it keeps tripping on soft limits. I’ve checked everything I possibly can and still have the problem. I’ve resorted to turning off soft limits to be able to jog properly but would very much like to enable them again.
Longmill experts, any ideas? Help please.
Looks like they set the default move to 1000mm which will always move you beyond your soft limit.
In the gSender code, if you have soft limits enabled, they’re attempting to calculate the maximum move you can make based on the $130-$132 values (your machine size). Then they subtract a very small amount to ensure you don’t reach those limits.
It seems like that part of the code is not working. I’m sure @KGN will fix it.
@CraigN are you always homing on machine startup? I can say that in that particular case it’ll cause issues with soft limits.
Perhaps if you home, try jogging, and then are still seeing soft limits being triggered then you can post the console output so we can see what’s going wrong
Chris, I always home at start-up. It’s an awesome feature and I use the work offsets which saves me a ton of set up time. Love the sensors.
One part I may not have been clear about or didn’t notice until I tried again tonight. If I single click the jog it doesn’t throw an error. It’s when I press and hold the manual feed to quickly move a longer distance I get the limit error. As requested I have some pictures of the error code. It’s the same on all three axis.
The jogging on all versions that I’ve tried has problems with “sticking” when its looping/repeating. I’ve jammed bits and housings in the Z direction several times by holding down a bit too long. They’ve said it is fixed, but it isn’t in the latest release.
This may explain the difference between …
To be clear my issue is not sticking of the jog button, I’ve seen that before with other programs but I have no jogging issues in GSender as long as I have soft limits disabled.
My issue is I can single block jog without “hitting” a soft limit. If I try to hold button and jog it throws a soft limit error even though I’m no where near a limit.
@CraigN this thinking more about this it sounds a lot like a similar issue I’ve been emailing another LMer about and I actually called him up since I wasn’t able to recreate the issue and wanted to see exactly what he was doing. Even after calling him up I wasn’t able to recreate the problem but the consensus was that it was indeed an issue.
We made some other changes to the behaviour of soft limits in 1.0.6, would you by change have updated and found this issue solved or are you still experiencing it?
I downloaded the latest update and turned soft limits back on. Still does not work, I don’t get a soft limit error any longer but cannot do a continuous jog. It will only do an incremental jog at the specified interval for each jog mode (i.e. rapid = 0.100”). When I disabled soft limits again I was able to do continuous jogging with no issues.
What output do you get in the console when attempting a continuous jog? Is there no command sent at all or is there any kind of output?
I should have checked that before. I am getting a travel exceeded message.
@CraigN @KGN @NeilFerreri @chrismakesstuff @CrookedWoodTex I’m having the same issue with v1.1.2 after installing the induction sensors. Turned off soft limits and it will jog normally.
@RickW For completeness of your report, do you have homing enabled? Where are you in your machine space when you initiate that jog command?
@NeilFerreri yes, homing is enabled. Machine space didn’t seem to matter, corner of the jig is well over 12" away from the hard limits in X and Y and probably 2" away from the Z hard limit. I will turn soft limits back on when the current file is done and try in some farther away random spots.
@NeilFerreri Just tested in a bunch of random spots with the same results. A single click jog with soft limits enabled works just fine. Click and hold throws the travel exceeded error and the machine will not move. From 1-4 single clicks will get it going again. This error code happens with XYZ click and hold moves no matter where the router happens to be. Does not happen with single click moves. Using a mouse and clicking on the on-screen buttons in both normal and precise modes.
FWIW I am having exactly the same issue.
Hi guys. I had the same problem. The jogging was also always making negative moves no matter if I tried + or - continuous jogs!
I have found bug(s) in the jogging code , at least when using soft limits and homing in the back right of the machine…
Why is it always doing negative moves?
The jogging code will only move towards the positive direction when it receives a value of “1” for the “direction” parameter… thus any other number will calculate a negative move. The problem is that the code receives the value of the specified steps (for instance, -5 and 5, for 5mm XY moves settings) instead of a “+1 or -1 direction”.
Why is it overshooting the max limits and throwing an error?
There are actually 2 different reasons for this:
1- The first reason is related to the previous bug… The distance is “mutiplied by the direction”. So it is supposed to be multiplied by 1 or -1 (which is correct)… But it is instead multiplied by the “value of the steps” instead… so by 5 in the previous example!
2- Also in this case where homing is “back right”, there is no offset applied to the maximum travel… So sometimes the value of the calculation will be a tad higher than the maximum allowed move and will trigger error 15 (soft limit exceeded).
I did modifications to the code. It now works as expected for me! I hope it will be corrected soon by sienci labs.
PS : I did not try it, but you could try putting “1” in the value of the jogging steps… It should fix the 1st bug (workaround).
@kilroy thanks for spotting that error, one of those situations where variables go amiss. The most recent build should have a fix put in with those tweaks so y’all let us know if you’re looking good now or if there are still some gremlins floating around
Thanks Chris. I’m the one who did the pull request It is indeed fixed in the last version. Keep up the excellent work!