Alarm?

[Betcmrekoapl]

Lately with t2laser every other engraving i do ends up stopping halfway through because the software says some sort of alarm has been triggered? What is causing this? Its ruining my materials because once this happens its impossible to realign the laser and restart where it left off

[Zax]

This is caused when Grbl sends an error code back to T2Laser. In earlier version I didn't "watch" for them and it would just continue, in most cases they aren't significant and everything looks OK except maybe the odd dark spot. The problem comes if Grbl stops completely and the laser stays on but it doesn't move, so I added Fail Safe mode which causes it to abort and disable the laser.

The actual cause can be one of these:
Power saving on the USB port or computer
Another USB device causing interference on the internal USB hub
Backup or Anti-virus software causing a transmission delay due to CPU usage
Bad or poorly screened cable (electrical noise is causing Grbl code to get corrupted)
Machine needs to be grounded
Disable DTR
Disable Fast Status
Enable Low Buffer Mode
Disable Fail Safe Mode (last resort)

[Zax]

Can you also answer these questions:

What board do you have?

What firmware are you using?

I test with L7 and Mana SE boards both using my Grbl 1.1e on EleksLaser's and a Mana SE with mana.hex running an EleksDraw. I also test with Windows 7 and 10, including 64-bit. My test files include the 7.5 million G-code lines image, a couple of smaller files, the grey scale test and some vector files.

[wild.bill]

It can also be caused by to small a power supply. I had this problem and at least one other person in the forum solved the problem by going to a larger power supply.

[Zax]

Thanks wild.bill, I've also noticed the Eleks Mana style Nano's have more problems - that may be because they've switched to clone Atmel AVR chips.

[Guzzi]

I'm having the same problem with some big A3 Engravings. About one third trough the print (after 5h) I always get an error according to the pic attached. I tried to continue the print with adjusting the gcode. But the laser did not stop at the exact location it was visible on the t2 interface but moved slightly off when stopping due to error. I also noticed that when trying to continue from the stuck position the laser is cool in the beinning and emitts alot more power before it reaches it's running temperature.

I'm using:
EleksMaker A3 2.5W Diode
Firmware: 1.1e
Win7 64 Bit
T2 Laser v1.4q

Settings:
Speed: 800
Laser Pwr: 40 - 180

Findings:
PWR Supply seams fine with the load
Laser is just warm
COM Port is still active

Any possibility to debug the error reply from the Arduino?

[Zax]

Have you tried the steps I suggested above?

If you have a good quality USB cable, disable power saving, avoid other devices on the same hub and eliminate electrical noise (it is a good idea to have both PC and laser on the same ground) and still have problems, then disable DTR and enable Low Buffer Mode.

Those changes should help and as a last resort (although not recommend) disabling Fail Safe Mode will prevent the errors from stopping T2Laser. Of course the error may cause some unwanted movement or dark spot - even crash Grbl or halt the machine with laser on so you must be careful.

The earlier Eleks boards used a clone Nano but still had an Atmel processor, now they have changed to the Mana SE board which uses a Chinese copy. In addition to the Chinese version of the UART chip, these seem to have more Grbl errors. I have 2 that I use for testing and both run my test files and have never had errors so it's not every one.

[wild.bill]

Something to keep in mind, the Alarm comes from GRBL. When this happens T2 or any other software has no idea if the last move command was executed or not so I would never assume that you can never just continue and expect it to still be aligned with what had already been done.

[fvuichard]

I have the same problem, and despite all the tests I have been able to do I can not find a solution ...

Finally, I generate my G-code with T2 laser (which is in my opinion the software with the most option for engraving),
and I send them on my laser with another soft (currently RobotLaser) Which does not return any error message during the burning process..

[Zax]

It probably just ignores any errors, which would be the same result as disabling fail safe mode.

[Guzzi]

Yeah I partially tried the suggested fixes. I did not have time to check them all yet. I do have a common ground on the laser and laptop. I did adjust the power saving profile on the laptop but just found an option under the advanced tab for "selective usb pwr saving" which was active in the profile. I adjusted that and will report back with my findings. I seem to have an original ATMEL Nano processor.

What exactly does the DTR Option change?

Thanks for your inputs.

Have you tried the steps I suggested above?

If you have a good quality USB cable, disable power saving, avoid other devices on the same hub and eliminate electrical noise (it is a good idea to have both PC and laser on the same ground) and still have problems, then disable DTR and enable Low Buffer Mode.

Those changes should help and as a last resort (although not recommend) disabling Fail Safe Mode will prevent the errors from stopping T2Laser. Of course the error may cause some unwanted movement or dark spot - even crash Grbl or halt the machine with laser on so you must be careful.

The earlier Eleks boards used a clone Nano but still had an Atmel processor, now they have changed to the Mana SE board which uses a Chinese copy. In addition to the Chinese version of the UART chip, these seem to have more Grbl errors. I have 2 that I use for testing and both run my test files and have never had errors so it's not every one.

[Zax]

DTR = Data Terminal Ready.

Depending on your UART chipset and the driver it is either used as intended for data flow control or to trigger a remote reset. You must disconnect and reconnect for it to have any effect.

[fvuichard]

I have try with disabeling Fail Safe Mode, but the burning still stops and the laser stays ON.

[nehal]

I used to encounter similar error with mana se board randomly. It was so ennoying. Only solution worked for me was replacing nano with new one. No error since then.

[Zax]

I optimized the G-code sender in T2Laser for speed. It can handle millions of small lines of G-code without starving the Grbl buffers.

In most cases this works perfectly and results in the smoothest possible motion, but it appears some clone Nano's have problems (probably internal memory issues). So in the next version I am going to add the option to reduce this "force feeding" and send data line by line.

Since I do not have any Nano's which exhibit this issue I would like to ask for some help in testing it, would you be willing to help @fvuichard?