Advanced Search

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?

Further update

G33.1 sort-of works after discovering an M03 command must preceed the G33.1 line.  Simply turning on the spindle doesn't work.

Starting a Z0.5, when G33.1 is commanded (via MDI) the Z-axis rapids to Z0 and then starts the synchronized move to K-value.  I didn't think that rapid move is correct behavior, but at least it was 'tapping' in and out.

However... G33.1 only works properly once per session.  Subsequent attempts still have the Z-axis diving past Z0 to the K-value at rapid speed, reversing the spindle, and then a synchronized move back to the Z-start location.  Spindle reverses again at that point, ending the sequence.

Restarting LCNC doesn't change the 'works once, then never again' behavior.

I've gone over all the spindle, encoder, c-axis, and PID settings & connections with a fine-toothed comb and can't see a problem.

• encoder velocity: S200 M03 $0 results in 200rpm, verified with a tach
• encoder position: 1 revolution of the spindle increases position by 1
  • encoder position is connected to spindle.0.revs per the manual
• encoder sign: rotating the spindle forward (i.e. M03 direction) increases the encoder counts & position, and rotating it backwards decreases counts and position
• encoder scale: 1 turn of the spindle increases counts by 40000 (10kppr encoder)
• index: manually set signal index-enable HIGH and rotate the spindle.  Signal goes LOW when the index pin is triggered, and it happens at the same place every time.
  • encoder, spindle, and both velocity & axis PID index-enable pins are all connected and react together.
• spindle-at-speed works as expected, and is connected to spindle.0.at-speed

At no point can I see the index-enable signal go high and then low when G33.1 is commanded.  If I set the spindle speed very low (30rpm), I would expect to see the index-enable signal/pins all get set HIGH by LCNC prior to starting the synchronized move.  But no change in state, even in halscope.

I'm at a loss here.

EDIT 2024-01-28: Brevity for clarity

This is a plea for an x86 Mac owner with Parallels to make a fresh LinuxCNC VM available for testing x86 emulation in Parallels on an M-series "Apple Silicon" Mac.

Below is the original text of the question:

RE: kb.parallels.com/130217

I already assume this will not be productive or useful for running a CNC machine; I just want to satisfy my curiosity.

Parallels 20.2 (pro edition) newly includes an x86 emulator, so the prepared ISO of LinuxCNC available here on linuxcnc.org should theoretically function. The catch is that the VM must have been created on an Intel Mac, which I no longer have. So, this is a plea for an x86 Mac user with Parallels to make a fresh VM available for the current version of Linuxcnc.

I have zero plans to use it for anything except learning more about Linux and LinuxCNC. My N100 mini-PC has one job, which is to run LinuxCNC and my CNC router (once I wrap my head around it better). I would prefer to tinker around in Linux at my actual desk, rather than being tethered to a CNC router. That's why I'd like to try running the VM; some degree of separation is safer.

I have already successfully created an ARM64 VM, installed PREEMPT-RT and LinuxCNC, and the results were uninspiring. It satisfied my curiosity, which was the point, but now I would like to explore using the x86 emulation feature and the LinuxCNC prepared x86 ISO. But without an Intel Mac, I can't create a VM to test it.

Alternatively, instructions for creating a Parallels 20.2-compatible LinuxCNC x86 VM on an Intel PC would also be helpful (I have an HP Z2 mini G5 i7 workstation PC). This article suggests it's not possible, but it was published before 20.2 was released with x86 emulation: kb.parallels.com/115305/. Maybe I don't even need the Intel Mac? IDK - that just seems like the shortest path.

Ok, I do have a Fusion 360 subscription that requires internet...

But I knew about that ahead of time as well as forced updates.  Eyes wide open on that one.

Here's my take on the situation...

I refused to get a Bambu until I could confirm the following:

• It will operate without internet.  I refuse to own anything that doesn't function unless connected to the internet.
  • I was less concerned about losing some features which require internet (Handy app, etc.), but basic printing must work
• It will operate with Orca (or other slider)
  • Stop-start prints from local network PC
  • Adjust some settings (AMS, etc.)

Once I figured out Bambu's LAN mode and Orca's plug-in worked as I required, I got an X1.  I can use it, and my warranty - for what it's worth - was still valid. 

The new lockdown-firmware doesn't affect my existing printer.  It works just like it did, and I will never update the firmware - nor will it 'auto-update' as it's in LAN mode.  I don't get any updates or new features, but I don't care about those - so far, so good.

However, I am now reluctant to purchase another printer from Bambu.  To achieve what I want - that is, duplication of my existing printer - I would need to use 'Developer' mode.  I will not be able to downgrade my firmware to a pre-lockdown version to duplicate my existing printer's behavior.  I would have to use Developer mode and hope that Bambu's hasn't incorporated some sort of 'not-LAN-mode' backdoor in to the firmware.

And, as I understand it, Developer mode affects the warranty, or at least some support from Bambu.  Deal breaker for me?  Maybe not, as long as Orca still works and the thing generally behaves like my first one does.

My speculation about the uproar is that those users who wish to use the features provided by being in internet-connected mode are no longer able to do things the way they used to.  Bambu's update will break their workflow and arguably degrade the user experience.

I can understand irritation with this situation; feels like a bait-and-switch.  Like if your phone manufacturer pushed an update that required you to use some annoying process to use your phone without having an option to decline the update.  "We know you had when you bought the phone, but Wifi tethering is no longer available, sorry.  We did it for the children."

If you buy a new printer (with lock-down firmware) from Bambu you know what you're getting in to.  But I think the valid complaints are from existing owners who don't want the printers' behavior changed after they purchased them.