Developments on my Home built 5C CNC Lathe - new spindle and progress on the ATC

Thanks for responding-

problems with :
sudo apt-get update under LinuxCMC Master (2.9) -
error =
Malformed entry 36 in list file /etc/apt/sources.list (URI Parse)
The list of sources could not be read

EDIT:
I suspect that after so many convoluted attempts at this 2.9 install, I have corrupted my machine - I am re-installing my 2.8 ISO and will start again from the beggining

..Really....

Still no progress..
I have re-created the V2.8 machine, all working as it was.
Then I tried -
Terminal:
sudo apt-get update
sudo apt-get dist-upgrade
sudo apt-get install dirmngr
sudo apt-get install software-properties-common - this fails -Unable to locate package. 
Googled this - found lots of gumf and messed around a lot - did not manage anything.

LinuxCNC Master (2.9):
sudo add-apt-repository "deb  buildbot.linuxcnc.org/ buster master-rtpreempt"
This fails obviously since add-apt cannot work without software-properties-common.

I presume this just adds master to the repository - same as if I use synaptics package manager to add it.
cannot do the below items obviously..

sudo apt-get update
sudo apt-get install linuxcnc-uspace
sudo apt-get install linuxcnc-uspace-dev

I did add 
deb http:// buildbot.linuxcnc.org/ buster master-rtpreempt
deb-src buildbot.linuxcnc.org/ buster master-rtpreempt
to the repository with synaptic, but the Reload fails with :

W: Skipping acquire of configured file 'master-preempt/source/Sources' as repository 'buildbot.linuxcnc.org buster InRelease' does not seem to provide it (sources.list entry misspelt?)
W: Skipping acquire of configured file 'master-preempt/binary-amd64/Packages' as repository 'buildbot.linuxcnc.org buster InRelease' does not seem to provide it (sources.list entry misspelt?)

Mhhh, that is strange. I just created a virtual machine from scratch with the latest 2.8.2 ISO and those steps worked.

Odd...

Slowly, slowly we progress...
Symantic pckg mngr now knows that the latest installed version is 2.8.2, and it shows the latest available version 2.9.
But it fails when I try to mark the file for upgrade - fails with dependancy errors:

linuxcnc-uspace:
 Depends: python3-tk  but it is not installable
 Depends: python3-numpy  but it is not installable
 Depends: python3-pil but it is not going to be installed
 Depends: python3-pil.imagetk but it is not going to be installed
 Depends: libgtksourceview-3.0-dev  but it is not installable
 Depends: python3-xlib  but it is not installable
 Depends: python3-cairo  but it is not installable
 Depends: python3-gi-cairo  but it is not installable
 Depends: python3-opengl  but it is not installable
 Depends: python3-configobj  but it is not installable
 Recommends: python3-pyqt5.qsci  but it is not installable
 Recommends: python3-pyqt5.qtopengl  but it is not installable
 Recommends: python3-pyqt5.qtsvg  but it is not installable
 Recommends: python3-pyqt5.qtwebkit  but it is not installable
 Recommends: python3-opencv  but it is not installable
 Recommends: librsvg2-dev  but it is not installable
 Recommends: python3-dbus.mainloop.pyqt5  but it is not installable
 Recommends: python3-espeak  but it is not installable

linuxcnc-uspace-dev:
 Depends: python3-serial  but it is not installable
  Depends: linuxcnc-uspace (=1:2.9.0~pre0.4753.g976e8ba02) but 1:2.8.2 is to be installed
 Depends: python3-yapps  but it is not installable

How do I fix this?

 

No 'software sources' item that I could find.
Also, no optional sources in repositories to enable either..

EDIT:
I believe I have resolved this - 
Really did not expect this amount of grief!
Anyway - Repositories have only these stanzas - 
for deb & deb-src
deb.debian.org/debian buster-updates main contrib non-free
security.debian.org/debian-security buster/update main contrib non-free

And so nothing else in sources.list either..

You should have these in as well - as soon as I added in repository, update worked and no more dependencies. 

After juggling a bit, setting up MESA IP addresses again, re-installing components, we appear to be up and runnin with master 2.9x. Our 'Switckins' is now removed and am busy adapting the setup to use 2.9's switchkins..
I believe we have a reasonable grasp of the setup now, and how to integrate 'Polarkins' with 2.9.switchkins, etc.

I have some concept issues, not with Lcnc, but with how a Caxis/Live tool lathe is supposed to work...
The convention is that the Caxis must be @ 0 deg on entering G12.1 ( Polar mode), and @ 0 deg again when exiting, ie, via G13.1, back into 'normal mode'  At the moment the Caxis does an 'unwind' which I believe is correct but am not sure how that is handled in the Caxis Lathe world. I have not been able to find useful info on this.

The unwind occurs since:
In normal mode, zero C, move Z and X to the position of workpiece, ready to cut a square on the end of the shaft.
C DRO shows zero.
then do G12.1 ( which we remap to our polar mode, etc) which enters polar mode
Now moves of the C axis are akin to distance moves of the Y axis on a cartesian plain.

So, to 'mill' a square of 40mmx40mm we do: (omitting plain selection, diameter mode selection, speeds, feeds, live tooling on, etc)

G01 X20 C0   - moves tool to center right side of the square. C DRO shows 0deg
G01 X20 C20 - moves tool to top right corner of square. C DRO shows 20deg
G01 X-20 C20 - moves to top left corner. C DRO shows 20deg
G01 X-20 C-20 - moves to bottom left corner. C DRO shows -20deg
G01 X20 C-20 - moves to bottom right corner.C DRO shows -20deg
G01 X20 C0 - final move back to right side center of square. C DRO shows 0deg
Now the square is done. The C axis has however actually rotated 360deg in the 'normal mode' world after this.

Now when we do G13.1 to go back to normal mode, the C axis does a 360deg unwind, even though the DRO showed 0Deg, and the DRO is now incorrect. 
We can now correct this under Lcnc2.9, either before or after the event ( did not have access to some parameters under V2.8), but I am not sure what should actually happen.
Should the DRO show the ACTUAL degrees turned while in Polar mode, and not the commanded 'angle' - which is not an angle in polar mode, but a Y distance ( C20 in the example above)?
If so, then when we exit via G13.1, the C axis will show 360, which is not where we were when we entered G12.1, and so will have to unwind.
However, a 'un-commanded' unwind is bad practice, so I am not sure how this should be handled. Or is it supposed to be taken care of inside the Polar mode by sending the C axis to 0 deg, ie, 'unwinding' any residual from within the polar mode?

One can imagine many degrees of unwinding taking place when, for example, the above square is cut 40mm deep into the shaft length, with an incremental Z DOC of 0.5mm...sort of 80 x 360degrees to be unwound.
How is this best managed? The C axis needs to be where we left it before entering G12.1.

Some help and brainstorming needed please!
 

I'm still following this with interest; sorry I can't help with programming, but maybe a description of my lathe functions/state during polar interpolation may help you.

(Fanuc 21TB control)
There is a separate C-axis drive motor which connects to the spindle via a ring gear, and is engaged with an air cylinder.  The belt-driven spindle encoder is always engaged.

Here's the basic sequence, regardless of whether G12.1, G7.1 (cylindrical interpolation), or no interpolation is used.

C-axis mode engaged with M52:

• Disable main motor VFD
• Activates C-axis air cylinder
• Activates live tool drive motor
• C-axis is homed automatically to the encoder index pulse (1:1 encoder to spindle)
• C-axis actual value is displayed on DRO regardless of G12.1 interpolated position command

C-axis mode disengaged M53:

• Reverse everything above, and C-axis DRO disappears from display.  There is no 'unwind.'

For your LCNC switchkins, I think you can do away with the unwind function and just force the C-axis to home every time you enter/re-enter C-axis mode.

Even if you have a direct-drive servo spindle, you'd still preface a G12.1 with an Mxx command to 'engage' the C-axis and home it.  So you couldn't directly enter G12.1 mode having lost track of the interpolated C-axis position.  Or remap/alter G12.1 to force C-axis homing ever time.

Just make sure that the G21.1 milled/drilled features have some known reference point or relation to C0-actual so subsequent C-axis non-interpolated operations (radial milling/drilling) can be oriented correctly.

One solution to not knowing the actual vs. programmed/interpolated position would be to have a separate C-axis-interpolated DRO which displays the interpolated position.  This might help proving out programs, but I don't think would be super-useful most of the time.

Alternately, force the DRO to display C[actual] or C[interpolated] based on G12.1 being active or not.  Both of these DRO options seem complicated to me, but I don't really get the behind-the-scenes stuff in LCNC.

Hope this helps spark some ideas.

-R
 

Thank You very much for this info - Really good data.

My implementation is a little different from your Fanuc control, basically because the spindle motor is a motor and position controlled servo motor all in one.
M52/M53 means other things in Linuxcnc and since the drive is a combined one the implementation of C axis is such that when in spindle mode - M3/M4 , the C axis is disabled in effect. The DRO is still present, but does not change. When any spindle stop occurs , M5, etc, the spindle comes to a halt, and C axis mode is engaged - The spindle homes directly and stops. The servo remains engaged.
The position of the now homed C axis is irrelevant WRT any following spindle mode machining, and any C axis modes have the spindle at home to start.

So , from your info, I will simply do the same when executing G12.1 - Home the spindle and proceed with Polar, and then at the end G13.1 home the spindle again. Of course having moved tools to a safe place prior to G13.1. That will leave the C axis in a known place, home, each time.

I will find how to make the C axis DRO indicate angles all the time, even in polar modes. It's not important what is displayed on C DRO during Polar, but for consistency I would prefer actual angle.

Thank You again for your information - Most Helpfull!