ATC Project - Debug phase

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Note, selecting 'libgdk-pixbuf2.0-bin' for regex 'libgdk-pixbuf2.0'
Note, selecting 'libgdk-pixbuf2.0-dev' for regex 'libgdk-pixbuf2.0'
Note, selecting 'libgdk-pixbuf2.0-doc' for regex 'libgdk-pixbuf2.0'
Note, selecting 'libgdk-pixbuf2.0-0' for regex 'libgdk-pixbuf2.0'
Note, selecting 'libgdk-pixbuf2.0-common' for regex 'libgdk-pixbuf2.0'
Package libreadline5 is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
However the following packages replace it:
  readline-common

Package libboost-python1.67.0 is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

Package libpython3.7 is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'libboost-python1.67.0' has no installation candidate
E: Package 'libpython3.7' has no installation candidate
E: Package 'libreadline5' has no installation candidate


Is this OK to proceed, or something else needs tweaking?

libboost-python1.74.0
libboost-python1.74.-dev

libpython had many available, up to 3.10

libbreadline has no response, but readline-common replaces it.

No joy.

I've run through about every permutation in the past couple days of a linux distro that works with the new PC.  I think the fundamental problem is that the video drivers are only 'native' (if that's an actual linux term) on bookworm and MX21.  It's got a Intel UHD600 video system, BTW.

I was able to get Debian 11.3 loaded and discovered 'backports'... and the video driver started working.  No more 800x600...  until I loaded the rt kernel.  Then it reverted back to stuck in 1990 display mode.

Tried again, only installing the backports thing after rt kernel & LCNC were installed. Seemed to work, but on the first reboot it reverted to 800x600.  Couldn't figure out how to get it sorted out.

I'm now back on the older (Odroid) PC and have MX21 loaded.  For some reason, everything just works out of the box with MX.

Time to start trying to load LCNC again...

Tommy -

xrandr: Failed to get size of gamma for output default
Screen 0: minimum 800x600, current 800x600, maximum 800x600
default connected 80x600=0=0 0mm x 0mm
800x600 75.00*

The display resolution problem is only happening on the new computer.  All distros but bookworm and MX21 wind up with an 800x600 VGA resolution with no way to change it.
Following the Debian official help page didnt work (install xserver-xorg-xconf, untilstall xserver-xorg-display-intel).

Based on random internet advice, I installed Debian-backports and that fixed it until I installed the rt kernel, then it reverted to 800x600.  This occurred on all versions of Debian (free, non-free, 11.0, 11.1, 11.2, 11.3)

I'm now back on the Odroid.  The only problems that one has are intermittent booting-from-USB fails, and having to manually install the nic card drivers after linux installation.  Right now MX21 seems to be the most 'friendly' with the hardware (and me).

I had 2.9, qtpyvcp, and probe basic working for a few weeks on MX21 - until I needed to install a difference version of carousel and found halcompile didn't exist or work.  That's what started this whole thread.

So I have multiple 'pathways' to get lcnc, qtpyvcp, and probe basic back on the computer and it's a matter of figuring out which one works best.  There's the 'Joco-NZ' script, the instructions on QtPyVCP page, and a number of threads on this forum which appear promising.

Andy (and anyone else following),

After much pain & suffering, I can report that your updated version of carousel is working.

I was able to get MX21, LCNC 2.9, QtPyVCP (master), & Probe Basic (python3) finally playing together following the instructions in the qtpyvcp sub-forum.

I think this pulled the latest version of everything, and the carousel is now working like expected.  Initial carousel.0.enable starts the rotation, and it stops at the index pin & sets the tool pocket to 1.  No more constant rotations or other nonsense.  No need to command pocket 1 before the first enable - the homing works fine.

After that, it works as expected - M68 E0 Qn will set the desired pocket, and re-enabling carousel.0.enable moves the platter to the right pocket.

Works like a charm!  Thanks for your assistance and patience.

Now, on to a toolchange macro...

Now that I've got a working PC, linux, & LCNC...I've just discovered a bit of a snag when trying to use carousel.comp with a stepper & gearbox instead of a geneva mechanism.

When in index mode, carousel homes to a signal/pin (sense-0), then counts the pockets up and down when the sense-1 input is triggered.  So far so good.

Problem is that I'm using inductive proximity sensors (with flag at each pocket) and have found that the stopped position is entirely dependent on the rotational speed and decel settings of the stepgen.  There is no way to have the sensors trigger at exactly the same location unless the flag is approached at very low speeds and in the same direction every time - like an axis homing.

Run it slow - appears fine.  Up the speed, and the carousel overshoots the flag.  Next time it reverses direction for a different pocket it's off by one; the overshot flag 'appears' to carousel.comp as the next lowest pocket.

This is fine for a geneva drive, or for a single-direction lathe turret which reverses back on to a stop.  These mechanisms are mechanically locked to a specific position, and the actual motor position need not be precise. 

The only way I can think of making this work with carousel.comp is to use a shot pin with a hole/detent for each pocket.

1. Pocket number is commanded, shot pin retracts, carousel rotates
2. sense-1 triggered, carousel stops (past the flag)
3. shot pin extends, carousel reverses, pin drops in hole
4. carousel stops the motor

Problem with this is that it might not work very well with closed-loop steppers or a servo - the drive would be fighting the shot pin and probably alarm out.

Unless someone has a clever idea I'm stuck abandoning the gearbox for a geneva drive... or controlling the ATC like an axis.

Anyone know of an example of an ATC-as-axis HAL/INI/remap?