Advanced Search

Small update: the Archimedean spiral cycle (face spiral groove/thread) is now verified by a real cut on my lathe, not just an air run. Cut-tested so far: turning, facing, taper, sphere, threading, boring, chamfer/radius and the spiral.

I also wrote a few articles that may be useful even if you never use the program:

- Threading in LinuxCNC: G33 vs G76 - turngcode.com/en/blog/threading-in-linuxcnc-g33-g76/
- G7/G8: diameter or radius mode - turngcode.com/en/blog/g7-g8-diameter-or-radius-linuxcnc/
- Tapered threads on a CNC lathe - turngcode.com/en/blog/tapered-threads-on-cnc-lathe/
- Using the generated code on other controls - turngcode.com/en/blog/turn-gcode-on-different-cnc-controls/

Questions and bug reports are welcome here.

I have decided to try another computer my plasma.
I tried to update to 2.10 on my old setup, but somehow failed.
Since my linux skills are so bad, I decided I should have a linux expert at my side with my newest attempt.
Problem is, I don't have the words to explain to them what exactly I need help with, so I'm asking for help I what directions I should give them.
First off, since it's a fresh install, am I better off installing linuxcnc 2.9.8 and then updating to 2.10, or just start with 2.10?
I assume I use the linuxcnc github to source the correct files?
Basically, what should I tell someone familiar with linux, but not linuxcnc, to get them started on the right path to helping me get linuxcnc 2.10?

In case your curious, I want to use 2.10 for some of the plasmac updates and so I can use pnccomf for my 7i97t.

Thanks in advance, I know there is a lot of information on how to do this on this forum, but when I tried, lunuxcnc would still open to the previous version. Hopefully with a little help, I'll get it this time.

My initial plan was to create an "All In One" setup/GUI interface. I did a similar wire diagram as yo did. I was toying around with Unreal Engine years ago and got the graphical idea from that. under the hood it's goal was to simulate actual physical machine wiring.

I got bogged down in just trying to get the UI buttons to do what they should. lot's of safety concern logic, graphical rendering issues..

Along the way I learned that there is an "API." So here I am rewriting it.

I can kind of read C++ and do some coding in other languages as well, but AI is just so much faster than me at writing the actual code. Basically with a couple clicks a users with mesa cards should have a working tunable setup. That was the hope anyway. I've been working on this for the better part of 6 months or so. multiple Debian reinstallations. I am now trying to learn linux terminal (gross).

I had an old I5 pc that I am repurposing. I have an old GTX1070 I was trying to get to work with the RT kernel (fail), so the gcode preview wouldn't take so long to load with 5MB+ file sizes.. I get that users can run linuxcnc on PI and other micro controllers, but I thought I could just repurpose this old pc to do the job, and have some cool bigger "out of left field" features. haha

Yes got some mixed responses, G93 works for some. The ones who'd like to try, seem to want it as a G-code, which makes sense...

+1 for new  the motors and drivers. In my opinion, it is quite possible that the error is caused by a defective servo motor. Is there a flexible coupling between the servo motor and the ball screw assembly?

G93 is fine.

I just wanted to post a little update - I got to the point where lcec HAL pins reflect parameters saved in VFD drive (min and max velocity) which makes me think that EtherCAT communiction is actually working, but I cannot get the VFD to switch its modes. I was switching cia402.enable pin on and off, controlword value was changing (I had connected cia402.controlword with lcec.0.[some_more_symbols].controlword) but lcec mode pins never changed their value.
On the nameplate of VFD among all the numbers etc there is a letter which according to manual means that the drive was preconfigured when ordering for some (unknown to me) addon module. And drive shows error A7AB which means that the drive does not find the module it has been configured for. And since that is a second-hand drive I have no way of finding out more.
Long story short - I gave up on my attempts to get this drive to work with EtherCAT and already told that to my customer.
Rod thank you for your time and effort helping me on this one!

grandixximo wrote:

The idea is a reference radius for each rotary axis, set in the INI. For example, `[AXIS_A] FEED_RADIUS = 25` 

This is a very bad idea, looks like it was captured from Mach3...
This is what LinuxCNC is good at, it doesn't have a thousand buttons that change the way it interprets g-codes.
Sharing settings between the ini file and the ngc file like this is bound to end in an accident at some point.
However, there are no contraindications to adding a new G or M code that will do what you write about. Then everything will be in one file and there will be no risk of running one program with the settings of another...

No problem, just trying to give a little back!

Maybe it was a limit error, but the message did not help figuring that out at all, was the sub itself that was out of limit? and it caused the error in the picture?

I'm deciding whether to work on a LinuxCNC feature and would like to know first whether anyone would actually use it.

Today, when a rotary axis moves together with X, Y or Z, F applies to the linear axes only, and a rotary move on its own runs at F in degrees per minute. On a 4th-axis wrap, where the surface of a cylinder is cut with X and A, the surface speed therefore doesn't match F. The usual workaround is inverse time (G93) from the CAM.

The idea is a reference radius for each rotary axis, set in the INI. For example, `[AXIS_A] FEED_RADIUS = 25` puts A in the feed calculation as if it were a length at 25 mm from its centre. A move of A alone at F100 would then run at 100 mm/min on the surface at that radius, and X with A would run at F along the combined path. Siemens (FGREF) and Fanuc (a parameter) do the same.

Questions:
1. Would you use this, or does G93 from your CAM already cover it for you?
2. What machine: 4th-axis wrap, rotary table, something else?
3. The useful radius is usually the stock radius, which changes per job. Is a fixed INI value good enough, or would you need to set it from G-code?

A short "yes, I'd use it", "no" or "G93 is fine" helps. If nobody needs it, I'll leave it.

 

@plasmanfm

1.0.7 will release today and the help file fix is in.

I received the braking resistor yesterday and mounted it on the left side of the cabinet. The cables that came with it were just long enough to reach all the way to the spindle drive.

 

 

With the braking resistor installed and the parameters set in the spindle drive the faults when stopping the spindle from high RPM disappeared.

As the machine seemed to be ready for the first test cuts I cleaned the vices in the parts cleaner and installed them.

 

Getting all three of them trammed in took it's time as usual...

 

For the first nervous test cuts with the new spindle I used a piece of 7075 aluminum.

I started with an 80 mm face mill and immediately noticed a clear improvement in surface finish which I hadn't expected.

 

Next I milled the sides with a 16mm DLC coated solid end mill. The resulting finish was something I've never seen on this machine before.



This was just a quick cut with a width of 0,5 mm so this feels very promising. I'll report back when I've milled a few real parts.

All shielding should be wired to a terminal block to machine ground.
Search for HyperTherm grounding best practices, they had a very good pdf about it.
And since we are here, grounding and shielding is never simple, so requires a bit of time, but it is very well worth it for the time it saves when working with such machines.

Got myself one. I will add it to my collection of backup ISO's