LAOS Laser

Hi Peter,

I suspected interfering libraries to be causing errors like these, that's why I updated the mbed libraries today. Unfortunately, that did not fix the issue.

On my machine, this file gives truely "random" crashes, it stops at a different position each time.

• The file contains many very small line pieces. The crashes might have to do with some buffer not cleaning up correctly, thus causing a memory overflow with files like these. I would expect the crash to happen at exactly the same spot though (at least when I reboot the laser before starting this file).
• Some issue in the GBRL implementation, memory or interrupt related?

Interestesting. Which libraries did you update?
I'm not really familiar with the MBED dependencies workflow, are the libraries added to the source, like MODI2C?
Which other libraries do we use? I can find:
- MODI2C
- SDFileSystem
- FATFileSystem
Would enabling the nodisplay option in the config file disable the use of MODI2C? Would that be an interesting test?

The LaOS firmware depends on the mbed libraries: https://github.com/mbedmicro/mbed

A fixed commit is grabbed when you do git clone --recursive https://github.com/LaosLaser/Firmware. This is necessary to avoid changes in the mbed libs messing up our compile process. Sometimes we update the linked version of the mbed libs, and sometimes that solves some problems or adds some new :-)

To confuse you even more: SDFileSystem/FatFileSystem are libraries that are part of this mbed collection of libraries, but we use our own versions (they are inside our source code). MODI2C only exists inside the LaOS project.

Alright.

Would enabling the nodisplay option in the config file disable the use of MODI2C? Would that be an interesting test?

If you set nodisplay, it will still try to output things on the LCD.

And: To really disable libraries, you would need something like #ifdef in the source code, so that cannot be activated from the config file.

My guess is it's grbl. There are some problems with the current grbl version in Laos:

planner.cpp adds items to the stepper queue in the main thread
stepper.cpp consumes items from the stepper queue in interrupt context
When planner.cpp adds a new item to the queue it recalculates and modifies the acceleration profile of previous moves. This is not safe because the setpper interrupt may occur while this is happening.

Problems are less likely to occur with long moves: the queue will be nearly full, and recalculation generally only affects the last or the last couple of items in the queue, not the move which is currently being executed.
With many small moves the file system is the limiting factor and the queue is not full. Recalculation may affect the frontmost item of the queue and that's when things go wrong.

I've looked at the latest rgbl sources some time ago and it seems they have fixed this issue. Unfortunately I don't have time at the moment otherwise I'd give it a shot.