Laser wont cut - Bad Gcode? [SOLVED]

Hello,
Please check the attached project. sent from 0.9.11, win10/64, controller: Smoothie.
two designs derived from same dxf file.
In the GREEN design two drill holes are segmented as in the dxf file.
In the RED design i replaced the two drill holes with LB circles.

Both were sent to cutter seperatly - One at a time.
the green one comes out a total mess - the laser power is erratic and job failed. not only the drill holes - the entire design.

the red one is OK.

How come these two circles effects the entire job?
4LB.lbrn (555.0 KB)

Can you include the Gcode from them? I see nothing wrong with the design. The green layer is set to run at 30mm/sec instead of 10, like everything else, and you have lead-in / out specified on both the green and red layers, though with different lengths.

Attached is a file which looks OK in preview but cutter does not like it.
I have removed the holes and left only 4 corner drill holes and even though preview looks ok the outcome is - center rectangle comes out only half cut and two holes are missing.

I hate thinking something happened to my smoothie but any other design i run comes out ok. its something with this design. i am still investigating what goes on.

PURPLE20MMS.txt (2.9 KB)

Preview showing this:

Outcome is this:

I am lost.
I have no idea what goes on. feels like a HV PSU issue or something related to the machine itself.
it’s bed time. will continue tomorrow.

An online gcode simulator produces this:
image

I don’t think it’s the code - I’ve looked at it and don’t see anything wrong.

I just took this whole damn thing apart - all looks to be connected and secured. when i send a job from lightburn mechanics works just fine, the laser does not - power is way off and erratic, like a loose wire or so, But - when i test fire using the on-psu test button laser is stady and follows the K40 control panel power settings which means psu/hv/tube are ok. so something out of the blue and wihtout prior notice sneaked into my controller’s guts and started messing things up.

Next, I will reflash the firmeware and check smoothieboard hardware.
Since communications and motion control works just fine, This can well be a bad fet on the board which is hooked up to psu’s input port.

Life is like a box of chocolates.

CSI update:
Allow me to introduce you all to… The culprit.


following all other options eliminated one by one, for last I suspected my lid switch since i narrowed it down to laser power related issue. so, since i have few of these switches lying around i decided to replace it with a brand new one. to my big disappointment this did not solve my issue. so i have decided to bypass the entire lid loop and just use a jumper instead directly on the psu plug and voila - problem solved. this is crazy since it seems like this well made 3 wire cabled that is bundled with these switches is the culprit, more precisely - its not the switch itself or the wires but the black connector that connected to the PSU. the question is: how come this issue arose just when cutting a dxf file which includes many line segments and my theory is that this might have been the straw that broke the camel’s back - vibration made this plug come loose, just enough to loose connection and the erratic power i notices was actually the vibrating connector in its socket. i will now replace this black connector with a more suitable one that fits better in the socket and secure it down with hot glue or duct tape.

Well, I guess we’ve found our man.

1 Like

Puzzled with why one design was running ok and the other did not remind me this story which I’m guessing most of you are already familiar with. Anyway, here goes:


The Pontiac Division of General Motors once received the following complaint: “This is the second time I have written you, and I don’t blame you for not answering, because I kind of sounded crazy. We have a tradition in our family of ice cream for dessert after dinner each night.

But the kind of ice cream varies so, every night, after we’ve eaten, the whole family votes on which kind of ice cream we should have and I drive down to the store to get it. It’s also a fact that I recently purchased a new Pontiac and since then my trips to the store have created a problem.

You see, every time I buy vanilla ice cream when I start back from the store my car won’t start. If I get any other kind of ice cream, the car starts just fine. I want you to know I’m serious about this question, no matter how silly it sounds: ‘Why does my car seem allergic to vanilla ice cream?’”

The team at Pontiac was understandably skeptical about the letter but sent an engineer to check it out anyway. The latter was surprised to be greeted by a successful, obviously well-educated man in a good neighborhood. He had arranged to meet the man just after dinner so they could go together to the ice cream store. It was the vanilla ice cream that night and, sure enough, after they came back to the car, it wouldn’t start. The engineer returned for three more nights.

The first night, the man got chocolate. The car started. The second night, he got strawberry. The car started. The third night he ordered vanilla. The car failed to start. Now the engineer, being a logical man, refused to believe that this man’s car was allergic to vanilla ice cream. He arranged, therefore, to continue his visits for as long as it took to solve the problem. He also started to test and measure – he collected all sorts of data, time of day, type of gas used, time to drive back and forth, etc. Soon he got his first clue: the man took less time to buy vanilla than any other flavor.

**Vanilla, being the most popular flavor, was in a separate case at the front of the store for quick pick up. All the other flavors were kept in the back of the store at a different counter where it took considerably longer to find the flavor and check out. The power of this data-driven insight was to immediately change the question from – “Why is my car allergic to vanilla ice cream?” to a more sensible, “Why does the car not re-start when it takes less time?” Once time became the problem – not the vanilla ice cream – the engineer quickly understood the answer: vapor lock. It was happening every night, but the extra time taken to get the other flavors allowed the engine to cool down sufficiently to start - It was still too hot for the vapor lock to dissipate.

My version (yes, this is me):
http://www.techtales.com/tftechs.php?m=199712#66

“Weird sh-tuff… happens, but there’s always a reason.”

The number of problems I (we) get blamed for that have absolutely nothing to do with software is far too high to count. ‘You touched it last’ plays a big part, and most people have no idea where the lines are between the operating system, software, and firmware, and hardware.

Every once in a while I will lead someone down a path to discovery where they say, “Oh! So it wasn’t the software after all!” and I reply, “I already knew that, I just needed you to know it too.”

The vibration theory makes sense if the connection was loose. That little extra shake could easily do that.

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