Advanced Search

That is a not known problem.

Running code means MDI Macros or commands, or AUTO programs?

How do your code end? 
I recommend M2 as stop

It appears based on the orient man page that index should not be needed
since orient effectively does a mod(turns) operation on the rising edge of orient enable.
That does not seem to be working, so probably the first thing to investigate.

That's what I thought.  But not sure why it isn't doing the math.

Setting index-enable isn't automatic via hal or an m-code, I've just been manually doing it while troubleshooting to see if it makes a difference.  And I haven't done it after commanding M19 but before it stops.

The only thing setting index-enable does is reduce the number of turns orient makes before (mostly) stopping.

That could work. But why do you choose a 47 ohm 1W resistor? That sounds so small. As a pull up I normally choose more in the 1k range

yeah, did you fix the other 2? the first one is you didnt install the nvmpg component, and the second one is the halfile for that usb pendant isnt present

but yes thats how you connect the x thing probably

Hi I want to add estop function to my CNC. So I want to link the estop to input 4 of my mesa 7i96s. The idea of the estop is because I want to link it to the alarm of my stepper drivers. So the circuit would look like this

 


So when the estop is pressed or the alarm of one of the controllers switches. I want Linuxcnc to stop.
I tried this with a default PNCCONF and it works. But when I try it on my original hal file without using pncconf. It doesn't work.  what I did was to copy the line 

# --- ESTOP-EXT ---
net estop-ext     <=  hm2_7i96s.0.inm.00.input-04-not

in my original hal file. But it doesn't have any effect. But in the Halmeter I can see the changes. Do I have to add anything more to add an additional  input?

It appears based on the orient man page that index should not be needed
since orient effectively does a mod(turns) operation on the rising edge of orient enable.
That does not seem to be working, so probably the first thing to investigate.

also

Oddly, orient position error is always 0 (orient.0.poserr).

Shows some logical error somewhere

Need to look and the encoder position and orient.command before and after the
orient enable rising edge.

Note that using index at the wrong time here could cause the problem you see:
That is, clearing the position with index after orient has latched its offset would
cause similar issues to the ones you are having so I would disable index operations to do the
"check encoder position and orient.command before and after the orient enable rising edge"
test
 

It's not overshooting; PID tuning isn't the issue, at least right now.

On my mill, I have to set index-enable once before the first orient.  From then on orient never rotates the spindle more than 1/2 turn one direction or the other for the remainder of the LCNC session without having to reset the index.

The problems on the lathe are

• I have to set index-enable every time I orient, otherwise it unwinds all the way until spindle revs = 0, and
• It only goes one direction: whichever direction takes spindle revs back to 0

My understanding of orient, based on my mill's behavior and reading the MAN file (and forum posts), is that something should be doing some math so that orient knows which way to turn, and that it only needs to move until spindle revs equals a whole number (ie. at the encoder z-position) plus however many degrees are programmed in the R-value.

Side note - I also found that ORIENT_OFFSET in the INI file doesn't take in to account multiple spindles.  There's no way to have separate offsets for my main and sub... not important right now but may become annoying down the road.

I first found a lot of advise to use mplayer. Could not make it do anything. (LinuxCNC 2.9.4 Debian 12 Bookworm PREEMPT-RT ISO) download from 9th Feb 2025

The qtvcp lines in the *.ini made a picture with several cameras I tried.

I guess it's  expected that unless you use index during orient the unwind would happen.
As far as tuning goes are you saying it does not get close enough for the desired position?

If this was the case I would add some I term

Note that you should be able to use the PID's maxerror and maxerrori to limit
the correction velocity in the position loop. This should allow higher P  and I terms
without overshoot.

Not in velocity mode, no.

What happens is when M19 R0 is commanded, the spindle unwinds (speed/accel dependent on PID) until spindle.0.revs = 0.

If I've run the spindle for any length of time it takes that many times to unwind during orient.

If I set spindle-index signal high (using tristate bit or setsig) after running the spindle it'll reset spindle.0.revs.  Orient then moves in the opposite direction until spindle.0.revs goes back to (or near) 0.

Same behavior if I run the spindle in reverse - orient unwinds the spindle until revs = 0.

And orient never completes, even when the orient position is well within orient tolerance setting.  It'll just sit there making microscopic nudges since the PID error is so low.

Oddly, orient position error is always 0 (orient.0.poserr).

OK so that suggests it's not a direction issue.

Yes, spindle works fine in both directions.

Encoder is fine: RPS, RPM, and counts are accurate.  Encoder position connected to spindle.0.revs

Scale is set so spindle.0.revs increment up 1/turn.

EDIT - note that the tristate-bit in HAL file was an addition today that hasn't been tested yet.  Used that on my mill config to get the index-enable signal triggered before the first orient.

I guess I would first verify that you can run the spindle in both directions
and that they are the correct directions (and that the encoder count reflects
these directions)

I used the firmware you cooked up for me last year (attached), so I think it's the actual pwm hardware pin.

Yes, that's how it's currently configured - no ABS component between mux2 output and pwmgen.

So maybe the orient one-direction-only problem isn't because I don't have an ABS in the logic?