ATC Project - Debug phase

In a terminal:
xrandr
What does it return?

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?

Setting it up an ATC as an axis should be too difficult. It's just gcode for moving the axis. You would likely use the axis in position mode and just send ich to the correct angle. Individual offsets may be required. If I recall correctly, the tool change motion in probe basic is entirely based on macros:
github.com/kcjengr/probe_basic/tree/mast...be_basic/subroutines
This will take some digging though.

On the issue of speed. Given that carousel runs within the servo-thread (so usually at around 1kHz) and the tools should remain in their pockets during rotation (), I had not expected such a high speed anyways. To me the challenge is therefore rather more the indexing from both sides.

To the issue at hand and in correlation to my own thread:
What spumco outlines is about what I expected. I have no experience with C (and it'sdreadful shorthand operators), but from how I understand the state switch in the actual comp, the following steps would be required:
-Add additional pins for a slow speed (e.g. lowfwddc or a multiplier for the forward speed)
-in state 11: modify so that when sense(0) and sense(1) are triggered (i.e. homed) it is considered pre-home, then add a state 12 for a precision approach of an index (i.e. reverse until !(sense(0) &&sense(1)) and repeat forward motion with motor_vel=lowfwddc
-for regular pocket approach after homing: This is a bit less clear to me at the moment. I would expect the some idea to apply: Use regular motion towards index (aka full speed ahead), if current_position=mod_pocket: set flag: preposition
Change to state 12 for precision approach while considering the previous direction of travel (this may require another variable): if motor_fwd=1 --> reverse, slowly approach index; if motor_rev=1 --> deliberately overshoot index, then approach slowly

Doesn't sound too bad - did I miss something?

GuiHue - Thanks for the confirmation and comments.

I was able to convert my ATC motor to an A-axis this morning and everything seems to work OK (homing & positioning via MDI).  Nice and smooth - no ka-CHUNK, ka-CHUNK of a geneva mechanism.

And yes, the tool change motions in PB are done via .ngc files and remaps.

I could really use some help with the toolchange gcode, however.  I've been unable to find any examples of anything similar; some forum discussions, but no sample files or file snippets in a thread.

The angle is easy - I've got 18 pockets, so each pocket is +/- 20 degrees.  And there are plenty of examples on how to control the other motions (carousel in/out, Z up/down, clamp/unclamp), but I'm not remotely clear on how to:

• Assign a tool number to a pocket
• Check the current position (or tool, then infer the pocket #)
• Calculate the distance to the desired pocket in either direction
• Compare which direction is shortest
• Select shortest path
• Command move via shortest path
• Update current position & tool number
• Make sure the GUI responds to everything appropriately

Maybe someone has done something like this, or remembers a forum discussion I've been unable to find thus far?

Thx,
Ralph