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.
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
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.
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?
@chrismakesstuff
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.
@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.
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
It is indeed fixed in the last version. Keep up the excellent work!