I had the maslow near the corner of my 4x8 spoilboard… I accidently clicked one of the directional arrows… I heard a clunk sound… looked back and the maslow had busted one of the belts ( the opposite side of the direction maslow was pulling from. ) I presume because it ran out of belt on that side.
Seems like a good idea to have the machine that knows how much belt is has out with reasonable precision to not allow it to go beyond a certain point. Especially since it requires a partial disassembly to fix it.
Yes, Bar has done some work on setting soft limits, but it caused other problems, preventing the Maslow from jogging in some directions I think. I did something similar just after I got my machine. If it’s busted out from the spool you will probably need a spool. Spools come with a new belt.
I’ve had something similar happen and I it’s surely a software fix that is being worked on.
I may have also found a bug where after the machine finishes a gcode file, if I had the dashboard set to MM, it suddenly becomes inches. I nearly destroyed everything because I told the machine to jog 100 inches instead of 100MM which is were I’d left it before starting the cut. Strangely, it was super willing to go 100 inches even though that violates the trigonometry of the anchor points.
What also is an issue is that the pause / stop / panic buttons don’t seem to be able to halt a machine that is jogging 100 inches. My only recourse was to pull power after I realized it was unwinding belts from the arms to try and move after pulling the two edge belts so incredibly tight I was worried it would break something. It seems that it may not be using the encoders on a jog, or is not listening frequently enough to realize that it’s unspooling belts and no longer under tension. Either way- It would be nice to outright reject a jog if that puts the sled outside of the geometry of the anchor points.
I’ve seen that too. FluidNC is supposed to support soft limits, but when I tried to implement them it was pretty buggy so I think that we need to create our own system.
I don’t think that it should be too hard to do, we just need to define what the right behavior is.
Should we be limiting the machine to a 4x8 work area? What if someone has their machine set up in portrait mode so they want 8’ on the Y axis? I guess maybe we could have a setting for the work area size that is user settable which defaults to 4’x8’
Is it possible to change the setting on the front screen to whatever is set under file control? So, if there is a G20 command the jog menu reflects ‘in’ or G21 it goes to ‘mm’. Preferably converting the value as well. E.g. 0.25 in becomes 6.35 mm
Yes, this is exactly how it should work now, but I have seen cases where the web browser will not catch the change. Communication to the browser is pretty browser dependent so sometimes it will behave in somewhat unpredictable ways.
In theory right now when the units are switched at the end of the file the jog distance should also be scaled, but I think it would be nice to have a backup in case that fails.
I’ve also been thinking we have a similar issue where the automatically generated calibration grid could be bigger than the work area (leading the machine to fall off the edge of the plywood) so having a maximum work area setting could be useful there too. It would default to 4’x8’ which is right for most people, but it could be pretty easy to change for custom builds.
Just to complicate things a bit, it maybe we want to offset the work area a bit, e.g. on a vertical set up it is possible that we would want to lower the work area by a 100mm to reduce the force required to lift the Maslow at the top of the work area where the top belts are nearing horizontal. So limiting the to a centered 2200 x 1200 work area maybe an artificial, undesirable limitation.
I’ll dive deeper into this over the weekend. It’s probably something silly like the Gcode file altering parameters in a way I didn’t intend. The front screen control panel does convert the values the machine is currently reporting, but the jog values do not convert. So If i started the cut with the page in MM mode where the jog value was 100 (mm) when the file finishes (and it may be a gcode thing) suddenly it tells the page to use inches (as if I pressed the unit button under the jog buttons) it doesn’t convert the jog value to inches, and then tries to jog 100 inches. If there’s a way to also convert the jog value when the units are switched that would be super ideal.
@bar, I love the flexibility of being able to define any size frame for any size of application, there should just be some kind of check to where the machine can’t go to impossible coordinates, like say the machine tries to jog off the edge of the Y axis, the angles of the anchor points as referenced against the sled if defined as triangles would go to zero or a negative value or something mathematically obvious that would throw an error and prevent the jog from happening.
The problem is that it seems like we can’t rely on every web browser handling the change right all the time. Sometimes we send commands to the browser and it just ignores them or decides that it’s going to like process them, but not for 10 seconds or something. We have pretty much total control over the software running on the machine, but the browser side of things can be it a bit inconsistent.
I really want it to work like that, but it seems like we can’t trust it.
That is a great point. Maybe we need settings for width, height, offset X and offset Y? That’s getting a bit complicated
They can default to ‘normal’ values for the majority of setups. It’s only people who want to push boundaries that need access to ‘weird’ setups (like me). I expect it would be settings in the yaml file, not broken out to configuration menu.
Should we be limiting the machine to a 4x8 work area?
No, besides the 8x4 there are people working with 5x5 sheets of plywood
I guess maybe we could have a setting for the work area size that is user
settable which defaults to 4’x8’
note that it may not be centered on the machine 0,0 (you don’t center your
vertical machine on 0,0 for example)
I would suggest supporting something like ‘jog to a place, hit a button and set
that to the max in that direction’
the fluidnc/grbl soft limits assume that the axis are x/y and don’t work well
with our cable driven robot approach, they also assume that an axis can never go
negative.
In theory right now when the units are switched at the end of the file the jog
distance should also be scaled, but I think it would be nice to have a backup
in case that fails.
one of the dozens of PRs in 1.13 was to have the browser watch for unit changes
and make sure that the UI and the firmware match, and to switch back to what the
user expected after a cut.
If you have a file that can reliably reproduce the problem, please make a thread
for it and we can work on it.
I’ve also been thinking we have a similar issue where the automatically
generated calibration grid could be bigger than the work area (leading the
machine to fall off the edge of the plywood) so having a maximum work area
setting could be useful there too. It would default to 4’x8’ which is right
for most people, but it could be pretty easy to change for custom builds.
YES, especially for people who make very large frames.