Advanced Search

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?

Is that an immense porosity supplement?

My lathe always works in mm/rev and the feed override works fine.

Which HAL pin do you have the potentiometer connected to?

Is there an updated file?  I clicked on the links provided and it said the files were in owner's trash.
The problem I've been running into with installing Python3-probe-basic is that I can't seem to get the repository to be recognized.  I tried adding the repo to synaptic and also tried adding to /etc/apt/sources.list.d/linuxcnc.list.  But there are multiple repo urls and I'm not sure if I just didn't find a valid one.

The outputs are SSRs so act like relay contacts/switches
The do not supply power, they only switch it.

I get it now. Thanks!

This is the current state of my understanding of how to wire a Clearpath SDSK DC servo to a Mesa 7i962 board:

I have also modified the HLFB circuit, based on the graphic below, from page 51 of the Teknic Clearpath User Manual Rev. 3.23:

Please correct me if I have gotten anything wrong.

The above graphic assumes the +5-24VDC is not internal to the board, so... is it? Do I need to apply +5v somewhere to drive the HLFB circuit? Keep in mind, I have to add 6x NPN NC sensors, and the above would need to be compatible with that too.