Advanced Search

Gmoccapy simply counts the lines of the loaded file:

@Lcvette

Fingers crossed, in 2 to 4 weekends.

Not sure how much "commissioning" will be required, this is my first time setting up a cnc-lathe.

I am planing to make the Z limits movable so they can be adjusted to the type of chuck being used and where the tailstock is positioned.

Timeline depends a bit on the weather, it's currently very hot here in West London, UK.

Thanks.

I dont have an answer, but i know its possible - there are interfaces with progress bars.

It worked, THANKS! )))

I changed the scale as well, the speed is not so precise, probably it depends on the milling machine board as well. I will add an encoder in the future, but for now, it's ok!

Thanks, have a nice day!

Examining the linuxcnc.stat() module I see that there is "current_line"  method. Is there a way to get the total number of lines in a loaded gcode file to drive a progress meter?

@Lcvette:

It's a DIY XZC slant-bed gang-tool configuration

• Based on a Dunham 5C spindle headstock w/Hardinge taper
  • Step-dir AC servos on all axes, plus 1 micron scales on X & Z
  • Main spindle motor is 3.7kw 8kRPM 'servo-spindle' from SZGH
  • 10kPPR encoder on spindle (40k post-quad) for decent C-axis resolution
• It has a scratch-built 5C sub-spindle mounted to the main XZ slide
  • Both the main and sub have pneumatic collet closers
  • Sub driven by 1kw 5kRPM servo
• Parting slide mounted to headstock (think Omniturn-style)
  • Can be controlled/programmed as a V-axis or X-axis (to permit CSS)
  • Permits main to sub hand-off for back-work
• Main XZ mounted live tool (24k VFD-powered spindle w/ER11)
  • Suitable only for light work, 1/4" or smaller cutters

Regarding the GUI & Probe Basic, here's my wishlist

• Extremely large DRO for XZ, smaller for V/C. Gmoccapy's DRO style is nice.
• On-screen parts counter of some sort.
• Large G-code window, with adjustable font size
  • Don't need/want large preview screen, but do want easy buttons to 'flip' the preview between front tool, back tool, and sub-spindle front/back tools.
• 3 spindles displayed (RPM & load), or at least two at once.
  • I won't have the main and sub turning at different speeds at the same time, but I do want live-tool speed/status at the same time as main/sub spindle
• No on-screen machine controls, or ability to disable
  • No jogging buttons, cycle-start, stop, etc.
  • No on-screen sliders, up/down spin-box buttons, etc.
  • No way to move the machine except via MDI, probing macros, or external physical controls
  • No keyboard control of machine, period.  Keyboard is for data input only.
• Need some GUI real estate for a number of LED indicators (or similar)
  • Main-sub synch active/off
  • Parting slide in V-axis or X-axis mode
  • I have three 'mist/air blast' sources, plus 4 spare air valves for clamps or future automation fixturing/loading.  Need indicators for what's on/off.

Everything is working now, but I haven't built the back-working tools or mount - nor am I 'fluent' with the lathe.  Can't quite figure out how or where to mount more than one tool without causing massive interference with main-slide tools.  I was starting to work on a design with I got side-tracked switching my mill over to Ethercat servos a month or so ago.
 

While the 5i22 is marked as "obsolete" on Mesa's web site. I think that has more to do with the fact that they can no longer be purchased new, and that new one's can't be made due to components being out of production. Functionally I think they are still supported by Linuxcnc, and the most difficult part of using one would be finding a motherboard with a PCI slot (not that hard). I don't know that the 5i22 was ever very popular with Linuxcnc due to the fact that they were rather expensive, a bit overkill, and there were/are much cheaper options from Mesa. (I never used one.)

If you want to draw a line on a pipe, it does not matter if you rotate the pipe or rotate the pen.

Here is your homework. I've already done this. Google coping calculator and review the maths and graphics for a notch in a pipe to be butt joined to another tube. print it on light card and cut the outline out. Wrap it around your tube, trace it with a felt pen and cut that notch out with an angle grinder. 90 deg join is easy to cut. 45 deg is a bit harder (as its deeper) with the angle grinder but it can be done fairly easilly. The maths creates the desired outline and won't care how you cut it! Options 1 & 2 are identical.

If you are cutting a length of RHS, it still has a standard profile defined in an engineering standard so you can still follow the surface to cut it with similar maths.

I think Its predominately a CAM problem but when you want to angle the torch, some kinematics might help. Not sure if it will help but 2.10 now includes some tangential headings which may assist. I think the full 6 axes may let you cut I beams

I'll get the EMI power line filter tomorrow and hopefully have it all back up and running over the weekend. Will also go over all the grounding wires to make sure nothing has come off (what i'm thinking as this has slowly crept in).

Thanks for all your support and ideas to get me back on track.

@spumco,
what's your configuration? is it not XZ? and what is your eta on being up and running?

@susan-parker
how close are you to being up and running?

 
Hey everyone,

I am retrofitting a CNC Plasma Pipe Cutting with 6-axis. XYZABC. I am wondering what Kinematics module to use. I have encountered two types of pipe cutting machines.

1. The pipe is placed in a chuck and rotates the a-axis
2. Plasma torch head navigates around the pipe.

These to me are totally different calculations and I would assume would be handled by the CAM software? Would i just use genhexkins and the rest is just mapping each axis and joint?

What I am trying to understand is who is in control of the machine path, the CAM software or the linuxcnc kins module. 
I want to cut a line in the pipe at point x1=0 a1= 300deg to x2=100 a2=300deg, who calculates that trajectory?
 

I am - for an EMCO Compact-5 CNC Lathe, with 6-position Auto Tool Changer (3 + 3 tools).
I am still setting up the hardware, getting close though.
The 4-quadrant variable speed thyristor DC motor controller is built and tested. I am now working on mounting the box and fitting for the ATC controller. Then it's just the limit, home, and emergency stop switches.
My setup is based around using Probe Basic Lathe... especially being able to make parts using the conversational mode - which for me is a game-changer!

Please follow these steps for tuning:
1. Set C00.04=0 to switch to manual mode.
2. Confirm the inertia ratio (using the drive's automatic inertia identification function).
3. Fine-tune the speed loop (C01.01, C01.02):
Gradually increase C01.01 until slight noise or vibration occurs, then back it off by 15–20%;
Gradually decrease C01.02 to eliminate steady-state speed error, but do not set it too low, or low-speed creeping/oscillation may occur.
4. Fine-tune the position loop (C01.00):
Gradually increase the value to shorten positioning time and reduce tracking error; if overshoot occurs, back it off by 10–15%.
5. Acceleration feedforward + velocity feedforward.
6. Adjust friction compensation:
Measure the friction torque in both the forward and reverse directions separately, then input the values.
However, at the 0.001mm (1μm) level, mechanical factors often limit precision more than electrical parameters—such as leadscrew backlash, thermal expansion, structural rigidity, and uneven guideway friction. If the steady-state accuracy remains stuck at a certain value after manual fine-tuning, it is likely a mechanical bottleneck that cannot be resolved by gain adjustments.

PCW wrote:

Does sound like an EMI issue.

Have you tried debouncing the limit switch signals?
 ( This can be done with the hal debounce component or with some
hardware, a hal parameter )

This seems the most likely problem and a simple solution. I did go through your Hal and ini files shared earlier and could not see anything obvious wrong.

I probably wouldn't add a max limit signal if I was sharing a single home/limit switch but I don't think that will make any difference. Are you using proximity sensors or switches? normally open or closed? if prox sensors, are they pnp or npn?

See if you can install a wifi dongle on your garage pc and get it on your network. Then you should be able to create a network share of your home folder you can reach from your main PC to configure and share Gcode files