Advanced Search

Did you notice i edited the post?
I saw you clicked on thank you after i posted so probably not.

No.
Several things will cause that:
-not enough air pressure
-worn nozzle
-to slow cut speed
-
I would also say to much current, but not exactly the same result, so i will just throw a stab in the dark at very, very low accelerations set in the config.
Edit:
I did not read the settings when i replied, i just browsed over them, so yes it is low acceleration, but probably there is not much more you can do, that is very small for plasma cutting and would in the end require very small nozzles or "fine cut" as Hypertherm calls them.
Now i would say it might be improved a bit, but not "earth shattering" changes.
Try something thicker, at least 2mm or 3mm then some 5 or 6mm.
There is a procedure i do with my machines to tune the cutting and i can not recall if i posted those here, so here it goes in short:
-tune the cut speed and THC roughly with 3mm material
-tune the air pressure till you get the best cut, does not have to be perfect
-tune the THC by raising or lowering the voltage
-tune the feed rate/cut speed
rinse and repeat for other material thicknesses and nozzles.
This is something you have to do for anything that changes, sometimes even moisture in the air will affect the cut quality, and we do get a lot of moisture despite no sea in site. All mild steels are not the same, etc.
Also, after all that you can test with lower or higher cut current and how it effects the cut speed.

How is the drive connected to LinuxCNC?

@Julian,

Thanks for the interesting file.

The first problem is solved :
1. Buffer overflow.
-> cause :  tcqFull() function was not used.
-> solution : tcqFull() function now uses a max buffer size to prevent buffer overflow. Default = 1000.

The second problem is not solved today:
2. It run's up to ca 1000 lines. Then it hang's.
-> cause : tiny segment length's : 0.007mm.
-> solution : review, recode the abc, uvw part of the planner step by step.


 

I would expect speed changes to change the sync start point.
There is another post about non syncing threads with speed changes.
In linuxcnc, you can't change the spindle speed and track the same thread, the sync point moves.

Linuxcnc moves the axis as fast as possible till it is moving at the approximate correct 'pitch' speed. It then works to get the exact pitch and maintain it. This distance to get up to speed is kept track of for use of calculating position and position error.

IIRC linuxcnc allows 10 rotations past target before deciding there is an error.

Now it's getting weird.

New discovery - I can get G33.1 to repeat during the same session, but the distance Z rapids is dependent on the spindle speed.

(Starting from G54 Z0.5)
G33.1 Z-0.5 K0.05 $0

• 60rpm: Z-rapids to ~Z0.1 before waiting for the index signal
• 100rpm: Z-rapids to ~Z-0.2 before waiting for index
• 200rpm: Z-rapids to ~Z-0.6 and immediately reverses spindle and moves Z-pos

The above is repeatable as many times as I want within the same LCNC session.

I think my earlier observation about Z-rapiding down and then synchronized movement up was correct... but the 'only works once per session' was incorrect.  I didn't realize that spindle speed was driving the Z-axis 'start' point to different locations.

Why is the Z-axis moving at all - much less a rapid - before the index signal triggers the start of synch'd motion?