LAOS Laser

I just compiled your github repository. My machine crashes into the right side after setting origin. Maybe a difference in our config.text? Mine attached here.

Also, the boundaries function does not show the size any more after these changes. And it didn't move along the boundaries.

I see my mistake, I was assuming the home position is always top left but obviously it's not.
I'll work on this later.

Here's a new firmware. ORIGIN should now work.

As a prerequisite the firmware needs to know the 'laser bed height' as set in Visicuts properties. 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.

Also, bed limits can be enforced if
enforcelimits 1
is set in config.txt.

For more information please see
https://github.com/LaosLaser/Firmware/pull/42

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)

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 but by pointing fingers at the user (the proper way to avoid this would be to make it possible for Visicut to read the machine size from the mbed).

Boundary checks and limit enforcing work now on my machine. Since the current patch shouldn't break existing configurations, I merged it as is. Still, I think we can clean up the patch by removing these new variables. Bedheight is a know variable already and enforcelimits is useless, since it should not be optional (limits are there to be enforced).

Fine with me. I just didn't want to be responsible for breaking existing configurations ;-)

Another thing: when jogging the Y axis is reversed. Is there any reason for this, or can this be changed?

Mmm. something fishy is happening...

When I run the attached SVG file from Visicut, the job loops forever. It didn't do that with the previous firmware version.

To compare: git checkout ade5ccd works fine.

Any ideas why this would happen?

Indeed, I'll fix that..

Ok, should be fixed.
See https://github.com/LaosLaser/Firmware/pull/43

Attached is a new firmware.

With this firmware, jogging doesn't work properly. It seems to lose position.

Maybe it's better if you just send a message to the forum instead of issuing a pull request for every test version. I can download the test version from your forked repository too.

Then we can discuss issues on the forum before the next pull request, because now we're doubling on each discussion...

Jaap

What exactly is the problem with jogging?

when I jog, it will work a bit, then fail. Sometimes it says x=0 while it's not.

Sorry, no idea what that might be. Working fine here.
Could it be you are touching the Origin button (bottom left) while jogging?

Some other things you could try:
- remove x.min and x.max, see if it has anything to do with the limit checking. Your home switch is out of bounds, maybe that's causing an issue.
- set a printf in LaosMotion::MakeCurrentPositionOrigin() and see if it gets executed accidentally. If x becomes zero this might be causing that.

A home switch is always out of bounds, otherwise your machine configuration is wrong. The point of a home switch is that it is the limit of your machine, it should be touched only when homing and not while running a job. So if your homeswitch is in the upper left corner, it should be defined as X=-1000, Y>Y.max or something like that.

I'm not touching the origin button, and even if I did, it shouldn't kill jogging.

As I said I have no idea what's causing the problem, it's working fine here. Perhaps you can debug it yourself?

I could maybe, but not today. I will revert the master github to a working version for now then.

I tested part 1 of these changes, implementing only the boundary functions:

http://redmine.laoslaser.org/boards/3/topics/761

They work for me, hope they don't break stuff for others now!

Hi Jaap,

Great, thanks for that.

Would love to see my other patches go in mainstream as well, as the origin feature is very useful to me and I'd hate to need to fork the repo to get that feature.

If you have time could you go through the commits at https://github.com/joostn/Firmware/commits/joost22aug and see at which one does the Jogging start to fail on your machine? As I said I can't replicate the problem. I've made a few cuts today using my firmware, using jogging and ORIGIN to place them on different positions and it was running smoothly.

That is: jogging does have hiccups, but I'm seeing exactly the same thing in the original firmware as well, not worse not better. Not a show stopper though, my machine doesn't loose its coordinates.

And again I understand you'd prefer a clean and simple patch but I wasn't able to implement ORIGIN without doing some refactoring.

Joost

Tonight I have tested the 'laser.bin' firmware. I added the two lines to the config.txt file
All is working OK on My K40 LaOS machine, well nearly, when I was jogging on a couple of occasions the jog stopped working, Homing worked, but the laser head remained at the home position, where it normally moves to the start position after homing.
I'm fairly sure that this only happened after I had used the 'origin' function a number of times. The only way to get things working correctly was to reboot the Mbed. This happened twice over about 2 hours of testing, so not a major issue.
I do like the fact that the Y jog now works in the correct direction (will take some getting used too as my brain now instructs finger to work the opposite way around), the 'Origin' functions is great and was one of the main reasons that I decided to go LaOS in the first place. The 'Boundary' function is nice, but as Gordon as already stated it would be better if the laser head was taken back to the start position.
Many thanks for a great set of improvements LaOS just keeps getting better and better.
Best regards,
Paul

I think I've fixed most of the issues now. I've found 3 bugs in the original firmware which seemed to be responsible for most of the problems:

https://github.com/joostn/Firmware/commit/32b32a30ef5085646d269e104d118759f65947a1#diff-d41d8cd98f00b204e9800998ecf8427e
https://github.com/joostn/Firmware/commit/a25bd0bb59a6d0940ab254ac31264baa4f0902f7#diff-d41d8cd98f00b204e9800998ecf8427e

Further, when changing jogging direction my firmware now waits for the motion to stop before moving in the new direction.

It seems to mostly work now, although I've still had one lockup where the mbed appears to hang completely. Haven't been able to fix that but I suspect there may be synchronisation problems between the main thread and the timer interrupts, not anything caused by my changes.

Attached is a new firmware. Source is at https://github.com/joostn/Firmware/tree/joost29aug

[edit: updated laser.bin, disabled READ_FILE_DEBUG_VERBOSE, this may have caused problems with engraving]

Both firmwares lock up while jogging on my machine. The first locks up faster then the second.

The MBED can be a PITA with stuff like this, it's very difficult to find out why some combinations of code crash and others don't.

Hi Joostn,

The second file works well on my machine, the movement under jog is much smoother than before, it accelerates to the movement speed then maintains this speed until jog is released or the axis limit is reached, at which time it decelerates smoothly (no more jerky movements).
I played with the jog for 10 minutes solidly without getting a single lockup, in this time I set the 'origin' a number of times then continued to jog, MAchine held position correctly throughout.

I have however been able to get it to 'sort of lock up', the laser head appears to stop moving or almost stop moving, the display is 'hunting' for the correct position (the number on the display scrolls without the jog being pressed), indeed pressing the jog does not do anything, I assume because the selected position has not been reached. I thought that it had locked up, however I left it searching for about 10 seconds and eventually it caught up, the head moved and the display digits stopped scrolling. At this point the machine would respond to the jog command again. I moved the head (using jog) back to the 'home' position using the move and display to manually position the head on the home coordinates, a visual check confirmed that the head was indeed in the correct position. I therefore conclude that whilst the machine was searching for position it did not loose position.

I have had one hard lock, the display was frozen with X and Y numbers and no numbers where moving, left the machine for 60 seconds or more and it would not respond to anything, the Air assist and Exhaust normally switch off after 30 seconds of inactivity, but they did not switch off, I had to reboot the mbed to gain control again.

One thing that I have noticed and don't think is quite right is the bottom left button (origin button) sometimes when pressed ask for a confirmation to set origin 'Set Origin ? [ok]', pressing the Origin button again sets the origin at that point and returns you to the Move menu (I believe this is the correct behavior), however sometimes you don't get the 'Set Origin ? [ok]' confirmation message, but the origin is still set. This is a little nasty as it is possible to accidentally catch the 'origin' button and without the confirmation (second press of the button) can result in a wrongly set origin.

This is certainly moving in the right direction, and on My machine is very very usable, I will accept the occasional lockup and associated reboot.

Thanks for the good work Joostn
Cheers,
Paul

You're welcome Paul.

Fixing the remaining issues will probably require updating to the latest grbl code. The current planner_recalculate() is highly suspect as there is no synchronisation at all with the stepper interrupt. It looks like this has been taken care of in the latest grbl code (see comments at st_prep_buffer()). But that would be opening a new can of worms I guess, not something I'm going to do now.

Joostn,
Any chance of an updated version of your excellent firmware, but including the working cancel function ?
I've been using your firmware for around a month or so now and really can't live without the boundary/origin functions and the jog all working the correct way round

Best regards,
Paul

Hi all,

I've updated my firmware (with working Origin and machine limit checking) with the latest changes from the master branch LaosLaser/Firmware.

Also jogging is no longer crashing the mbed. To achieve this each jogging move is scheduled after the previous jogging move has been completed. This results in somewhat sloppy jogging but at least it is stable now. Since the current stable firmware also does sloppy jogging this should not be a big deal.

For details see my comment in LaosMenu.cpp:

                       Currently (Jan 2015) an old version of grbl is used in Laos. This version is buggy
                       in the sense that there is no proper synchronization between the stepper interrupt and the
                       main thread. When adding a new move to the queue through plan_buffer_line(), planner_recalculate()
                       is called. This updates the acceleration profile of existing moves in the queue,
                       potentially including the move which is currently being executed by the stepper interrupt.
                       Due to the lack of synchronization this will lead to problems, including potential crashes or
                       hanging. This problem in particular manifests itself during jogging, because the queue is nearly
                       emtpy and there's a big chance the frontmost item in the stepper queue will be updated.
                       During regular laser cutting the problem is less likely to occur since the queue will continuously
                       be kept nearly full. Recalculation will only affect some of the last moves in the queue.

                       The real fix for this bug would be to update grbl to the latest version, this seems to include
                       proper synchronization. For now we work around the problem by wating for the queue to empty
                       before adding new jog moves. This results in sloppy jogging (continuous stops & moves) but at
                       least it doesn't crash the machine.

My changes are at https://github.com/joostn/LaosFirmware/tree/joost2015_01_02.
Attached is a compiled laser.bin.

Jaap (or other maintainers) please review; if you're happy I'll send you a pull request.

Joost