Added boundary function & fix ORIGIN function

[joostn]

I've added a BOUNDARIES menu between RUN and DELETE. This scans the file to determine the bounding rectangle, moves the laser head around the bounding rectangle and displays the dimensions.

[joostn]

And this second patch (d7ae54c) fixes the other problem I'm encountering with the current firmware: the ORIGIN function did not work. After setting the origin, the head would crash into the top when running a file or during subsequent MOVEs.

Now I'm aware this is a large patch, and it's never funny if anyone completely messes up your own code. But I had to do some refactorings in order to get this to work and make the code understandable:

In LaosMotion I've made a clear distinction between relative and absolute coordinates. For example, moveTo() has been split into two functions: moveToAbsolute(x,y,z) moves to an absolute coordinate and moveToRelativeToOrigin(x,y,z) moves to a coordinate relative to the set origin.

Similarly I've added getCurrentPositionRelativeToOrigin() and getCurrentPositionAbsolute(), getPlannedPositionRelativeToOrigin() and getPlannedPositionAbsolute().

Initially home coordinate and origin are the same. Pressing the ORIGIN button changes this, as if the current position is the home position. This effectively means that the current position becomes the top left coordinate of the workpiece, i.e. (0,0) in VisiCut.

Secondly, LaosMotion::write() no longer directly calls into the planner to make moves, but rather uses the above moveToRelativeToOrigin(). In other words all simplecode is now interpreted relative to the set origin.

Finally I couldn't resist to do a bit of cleanup by removing some static/global variables. For example, LaosMenu maintained its own x,y,z variables to keep the position of the head during MOVE. I've changed this into calls to LaosMotion to get the current position and then move to the new position, thus no longer maintaining its own state.

[joostn]

I'm sorry, I meant to create two separate pull requests but somehow they merged into one.

Patch 205d832 adds the boundary function Patch d7ae54c fixes the origin problem

[peteruithoven]

Just checking, did you also add soft/hard axis limits? (see: https://github.com/LaosLaser/Firmware/issues/34) When users begin a file somewhere else this becomes much more important. There is a big change that currently only VisiCut checks if the designs fits, and when you change the origin on the lasercutter that won't work anymore.

In the future it would be nice to communicate to something like VisiCut that the origin has changed, because there also a set origin feature in VisiCut.

Great that you're contributing to LaOS!

[joostn]

Yes I was planning to add the limit checks later. It's relatively easy because LaosExtent can process the file first, so we know beforehand if the job will run into the limits.

Anyway there's still a bug in the Origin feature, it's only working if the home switches are at the top left. I will fix that later.

[joostn]

Ok, I hope these latest patches fix the bugs:

• ORIGIN now works with the home switches in any location. Because of the discrepancy in y coordinates between Visicut and Laos (Visicut has y=0 at top, in Laos this is the bottom), Visicut applies an offset ('laser bed height' in Visicuts properties). The firmware needs to know this offset in order to set the origin. Add the following to config.txt (for example if laser bed height is set to 200 mm in Visicut): bedheight 200000 ; bed height as configured in VisiCut (um) If this is not set, ORIGIN will not work and 'bedheight unknown' will be displayed.
• Bed limits can be enforced. As documented already, limits are set using x.min and x.max, etc. By default my firmware doesn't enforce these limits, as not everyone may have set these correctly in config.txt. Once you've set the limits correctly, add this to config.txt: enforcelimits 1 Now it's impossible to jog past the limits. Also when a job is launched, first the extents are determined and an error is displayed if the job would run into the limits. All of this should work even if the origin has been changed.
• Jaap mentioned he didn't see the boundaries indicated. This may have been fixed but I'm not sure.

[jrv]

Correct me if I'm wrong, but the bed height should be deductable from existing variables: x.min (left minimum of the work field) x.max (right maximum of the work field) x.home is not relevant for size: position where the endstop is, is usually negative if the endstop is on the left and bigger then x.max if the endstop is on the right. bed length = x.max - x.min and bed height = y.max - y.min

Visicut and config.txt sizes should be identical. If not, that's a configuration mistake, which should not be fixed by introducing new variables.

[jrv]

Boundary checks work now on my machine and so does limit enforcing. Still I think there is no need to introduce new config variables. Bedheight is a know variable already and enforcelimits is useless, since it should not be optional (limits are there to be enforced).

Since the current patch shouldn't break existing configurations, I will merge it as is, with the above points still to be fixed in code.