Blocking for no reason but works well on lasergrbl :-/

Hello,

so here I made a drawing on lb nothing complicated, a text a frame and a circle.

the simulation is going well. but when cutting everything blocks at the start of the round. I also rounded the corners of the frame and also blocked. I generated the gcode and tested with laserGrbl. same origin and no worries. laserGrbl goes all the way.

bonjour,

alors voila j’ai fait un dessin sur lb rien de compliqué, un text un cadre et un rond.

la simulation ce passe bien. mais au moment de la decoupe tout ce bloque au debut du rond. j’avais aussi arrondi les angles du cadre et blocage également. j’ai généré le gcode et testé avec laserGrbl. meme origine et la aucun soucis. laserGrbl va jusqu au bout.

Hello

I have a similar problem : everything stops after a few movements (text engraving + JPG pictures). If I remove text, it works with any problem.
I’ll try text alone in a few minutes

I tried not doing the text (output disabled) and also deleting the text purely but it doesn’t change anything :-/

I did several tries with just the circle for example and it still didn’t work. I recreated the document step by step. by testing each time: frame then circle then text and everything works: - / I did not find what was wrong.

I also tried with and without optimization.

therefore unresolved problem because can reproduce anytime.

What laser controller are you using? If you type $i on the console, what does the controller say?

hello,

[AUTHOR: RenShen]
[BUILD: Ortur Laser v1.2]
[DATE:22:23:00 - Feb 6 2020]
[VER:1.1f.20170801:]
[OPT:VZD,35,254]

as I wrote above, the g code generated by LB works perfectly on Grbl laser, but it does not work directly on LB :-/

I’m beginning to think Ortur doesn’t like the way we send data to that controller. I suspect you’re using ‘Synchronous’ transmission mode in LaserGRBL, instead of ‘Buffered’, and if you changed it there you would have the same locking behavior.

http://lasergrbl.com/configuration/#streaming-mode

well, I checked and I am well buffered on LaserGrbl and I have no worries. on LB appear the problem occurs when I put text. and whatever the engraving order from the moment there is the text.

LaserGrbl serial speed 921600

problem solved !
I changed a setting, I went from M8 to M7
going back to M8 solved the problem.

When I looked carefully at the LaserGrbl log, I noticed that it was the only error.

the Orthur’s card therefore has no problem with LB, especially since the transfer speed is much higher in my case with LaserGrbl.

M7 is not supported on most versions of GRBL - they screwed it up, so it’s actually an invalid command if it’s not enabled. I’m surprised that the Ortur board doesn’t like M8 - Are you sure you didn’t go the other way?

sorry if my english is bad, i’m french and i’m using a translator. if that’s what i said M7 doesn’t work but M8 yes and that solves the problem. the concern comes from the explanation in ligthburn. when we put the mouse on the option, the help bubble indicates that by default M8 is not checked. So I switched to M7 and my problems therefore came from there.
back to M8 solved my problem

That tool tip is from when it was a check-box, so it is misleading. I have changed the help tip.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.