Advanced Search

kzali wrote:

What is the mod as marked in the attached photo?
 

it lowers the voltage of the level shifters on the FPGA side to cope with the 1.8V on certain ports, is fixed in the current git for the board

Zayoo wrote:

What happened with enable and error hardware implementation in riocore?
 

what exactly do you mean?

You could try to create a new path /usr/share/linuxcnc/gladevcp/NativeCAM and follow the alternative instructions given up there by freemoore since he runs LinuxCNC on Debian.

Regards
Giovanni

PCW wrote:

Here's a 4 --> 2 diode encoder with polarity adjusted
for 7I73 inputs that have built-in pullup resistors
(so read high if unconnected)

 

Note that mux_generic has built in debouncing so the capacitors should not
be needed if you use mux_generic to select jog increments etc.
 

This was helpful. I got the diodes and switches and took some pictures and built a little graphic:

I guess the thing that confused me was what exactly it's doing; checking for continuity? Like, "okay, I see a path through bit 0 to ground, but not through bit 1, so I recognize switch position 1, and now I will do what I am assigned to do when I see that scenario." Right? That wasn't a mystery so much as just needing to visualize it. It didn't help that there are exactly zero photographs of such a thing labelled as such in the wild, at least that I could find.

Again, thanks for the print. It was genuinely helpful.

Now I've got to figure out if Mux8 is worth taking up 4 inputs, instead of doing the resistor thing, for the mode selector switch. I just did a Google search for "LinuxCNC mode selector switch," and the pickings are slim. Here is a Fanuc-style mode selector switch taken directly from the console of the Mitsubishi M64s control I used to run on a 3-axis mill:

Obviously I don't need DNC, but I want to be able to access the rest of these modes with a hardware switch. That's my goal.

dm17ry wrote:

if you can write a little bit in c - just make a one-liner custom component... something like

pin in float vin;
pin out float factor;
function _;
;;
if (vin < THRESH1) factor = 0.1;
else if (vin < THRESH10) factor = 1.0;
else if (vin < THRESH100) factor = 10.0;
else factor = 100.0;

select THRESH values somewhere in between values you get in corresponding switch positions.
the resistor thing should work fine. i did that for 24-pos switch, though with stm32 adc (12bit?)..
 

 

Allow me to revisit this. Again, I appreciate your post, but I literally know nothing about LinuxCNC AT ALL, so this code means nothing to me. I need to see it in context, where it goes, what it does, etc. I need to see the entire process of implementing it. This stuff is impossible to cross reference in the limited online documentation. Where there is information, none of it is in a practical format to learn from, because I have to know what I'm looking at to understand what it says.

It's why this forum gets the same questions over and over and over. When people finally do squeeze answers out of the same 5 people, they are almost always half answers and the OP usually gives up before they got what they were looking for. Or, they are 10-year-old 80-page epics with the answer buried on page 50.

Seriously, these guys would save so much time for themselves (and others!) if they published a 3-axis mill use case and a 2-axis lathe use case, with an example each of AC servos, Clearpath, & stepper drivers. Leave the hard questions for Ethercat and weirdo setups with only one person on Earth using it.

rodw wrote:

fully_defined wrote:

I found your page earlier, but your photos aren't very clear and the thread is 76 pages long. Is there a page there that is especially relevant to my goal?
 
I linked you to the exact post on about page 3 ot 4
 

Rod, I know your heart is in the right place, but there was one picture that could even be considered relevant, and it wasn't very informative. I just want to see a good, clear picture of a mux4 rotary switch, built to the specification described. That way I can compare a photograph of a known standard and a print (provided by PCW) and actually learn something from it.

Google has been a complete wash, with zero results using the search terms I have tried. Just for fun, I asked ChatGPT and they really came through for me. Why did I ever doubt AI?

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?