Advanced Search

What is the mod as marked in the attached photo?

Hi mark,

Finally got around to compressing some photos of the spindle re-grease.

4797 shows the tool retaining system with the Belleville spring stack and the hydraulic ram.

4800 shows the quill clamps. The 2 arced pieces fit in a groove in the head bore. The Kipps handle moves the collar on the bolt. There are thumbnail milled cuts in the ends of the arced pieces (4 places). The collar and the bolt head are sitting in them. So tightening the Kipps slides the collar and brings the ends of the arced pieces closer together, clamping them onto the quill.

4803 Shows the whole assembly laid out.

4805 Is one of the taper roller cages. Looks like cast aluminium with some machining.

4806 Is one of the taper roller inner races. Looks good for 4000 running hours.

4814 Is a view along the bore for the quill in the head. Odd perspective, but what you are seeing closest is the recess that the 2 clamp arcs sit in. The 2 pins fit into the thumbnail cuts to hold the other end of them so they stay immobile when the other ends are clamped. Nice piece of engineering.

4817 The bore where the handwheel assembly fits. My finger is on the tapered dowel that scotch keys the handwheel assembly in place.

4819 Is the clamping assembly for the tool holder retention. I'm guessing it's like yours. Note the slots in the male thread on the draw bar. When the grub is torqued the ball expands that thread and locks it to the female thread on the claw assembly. You can't actually adjust the assembly until it's all assembled back into the machine since you need to have the hydraulics running to put it in the  "release" position.

Cheers,
David

To clarify my comments on pocket sensors:

This didn't work (pins):
 

This works great (optical w/flags)
 

Lcvette wrote:

for my specific use case I think I would like to use the home switch to be able to home to the center of a pin that is inline with the pocket center (kind of like probing ridge center) and then use a preset amount of step counts per pocket based on the number of pockets in the carousel to divide it into that many moves for a full revolution of the platter. I am using a 2 pin geneva wheel so 1/2 rotation is one pocket. I would like to confine all of the hal into one file if possible to make implementation as easy as possible and have some options to be able to use the index method as well. kind of a one setup page allows all types and each type has a unique hal file that can be called from the ini. make it as modular and easy to use/setup as possible. ATC seems to be one of those things that scares most folks because of its complexity. I think having it made easier would be a good thing.
 

A word of caution on using a pin for homing...

When I first built my ATC, I used stainless pins with proximity sensors for both home and pocket flags.  After struggling with pocket alignment, I finally realized that round pins weren't really suitable as flags.  At least not with the geometry I used, where the pin was vertical (up from the platter) and the proxy was pointed at the pin circumference.

When the round pin went past the proxy, the slight variation in sensing distance (due to pin radius) was magnified further out at the pockets.  Result was inconsistent pocket alignment.  And slight changes in rotational speed made a huge difference in pocket alignment consistency.

I wound up ditching the pins and proxys and installed some optical fork sensors with 3D printed flags.  Despite the circular motion, since the flags have straight edges they trigger the sensors MUCH more consistently - and at any speed.


Regarding your plans for incorporating a GUI-based ATC config, I quite like that idea.  But I think you might consider just sticking with INDEX mode for carousel, and not trying to offer both INDEX and COUNTS modes.

In your case, you don't need to specify a preset number of step counts if you're using INDEX mode. In that mode, carousel.comp uses a velocity-mode stepgen and the motor is 'dumb'.  Carousel just looks for the pocket sensor and stops rotating the motor (and does a second fine-alignment if you've opted for that feature).

For a geneva wheel, a slight motor overshoot is a non-issue, and because carousel.comp is using per-pocket sensors, there's no cumulative error stacking up over multiple pockets.

On a direct-drive (with or without reducer) ATC like mine, overshoot is a problem... but the fine-alignment feature takes care of that. Again, no cumulative error.

For a slightly more complicated mechanical & electrical installation (need pocket sensors), it's much easier than COUNTS mode to configure.  And potentially more reliable, especially if someone chooses to use an open-loop stepper.

An open loop stepper in INDEX mode is fine - if the motor stalls, carousel.comp won't set the 'ready' pin high and a macro waiting for that pin will time out and throw an error.  In COUNTS mode, neither carousel.comp or LCNC have any idea that the open-loop stepper stalled and will probably crash the ATC.

I think you'll find that regardless of what kind of ATC a potential Probe Basic user has - or is building - if you simply set some ground rules it'd be easier for you and the end users in the long run:

• MOTORS
  • On/off controled AC or DC motor, or
  • Step/dir stepper or servo
• ATC Mechanism
  • Direct drive (reducer, belt, or direct-to-motor)
  • Geneva wheel
  • Worm drive (?)
• ATC Sensors
  • One home sensor
  • One per-pocket sensor
• ATC Movement
  • One retract sensor
  • One forward sensor
  • One retract output (valve or motor or something)
  • One forward output
• Drawbar
  • One drawbar engaged sensor
  • One drawbar output

Maybe something like that as a baseline config?

With daisy chaining of HLFB. There's a decent chance that I have erred in some way setting this up. Please take a look!

Teknic_Servo wrote:

Hi fully_defined,

I'm an engineer with Teknic and came across your post. While we're not familiar with the exact board and pinout, the ClearPath wiring makes sense. (Good suggestions PCW)

If you encounter any problems or have other questions, please reach out directly at 585-784-7454 or teknic.com/contact/.

Best regards,
- Aaron B. Teknic Servo Systems Engineer
 

Would you mind taking a second look? I have updated this post, and the image at the top reflects my current understanding of how to wire this. I think the only question relevant to you now is: now that I am powering the field inputs with 24v, can I get away with daisy chaining hlfb to save on inputs? I thought I recalled hearing that this is the preferred Teknic method, but I can't find anymore where I read that.

In this post, the OP said he figured it out and then the thread went cold. People had more questions that were unfortunately never addressed again: www.forum.linuxcnc.org/10-advanced-confi...fb-mesa-7i76e#114031

The purpose of this thread (the one you're reading now) is to create a definitive resource for myself and others to refer to later.

I worked on it a bit more. It's missing 2x 24v NPN-NC probes, and I think with 24v common supplying the sensors and hlfb circuit, I may be able to daisy-chain the hlfb after all. Still confirmation there.

I have LCN version 2.9.3 on Debian 12, but in /usr/share/linuxcnc/, but there is no aux_gladevcp folder, nor a folder named gladevcp.

Thanks for the information.
How do you set the lcec.0.D1.stepspermm1 command to control the stepper motor driver, for example, if it is set to 1600?
What relationship should it have with respect to the screw pitch if it has a pitch of 5 mm per turn?

 

This was a mod for someone else would something like this suit ?
Basically where do you want the button?

Ok, but there aren't that many things that could be different between the two systems i now have...
I am just stuck thinking of what it could be...

Thanks for testing. I pushed it to the master branch.

What happened with enable and error hardware implementation in riocore?