Advanced Search

Tried but no luck. Can't do very much now.

 

 

I would first check:

joint.1.motor-pos-cmd
joint.2.motor-pos-cmd

and see if they both change when Y is homing

Only 1 of the 2 Y-Axis moves.

They do not move in tandem. Only one Y-Axis moves. The other does not move.

Even if the drives move in different directions I would be able to make that change but, only one drive moves.

Are you saying that one step/dir output on the
7I76E is  unreliable or one drive is unreliable?

If Y does not home at all, what does it do?
Are the Y joint directions correct?

Hi Folks,
I can't seem to get the tandem Y-Axis to work as expected. One Y-Axis works all of the time but the other does not. I have tried switching the two Y- Axis sources in pncconf and the opposite Y-Axis works. Doesn't sound like a wiring issue.
All joints work otherwise.

Additionally, homing with single-switches are proving to be a real challenge. The tandem Y-Axis will not home at all. I'm thinking that homing could be easier.

Attaching my configuration files.

Thanks in advance for your feedback. 

Thanks for your reply

Yes, I thought about it over night and: you are right. I have implemented the lincurve now and from 1000/min to 24000/min it works really well. I think below 1000 it is hard for a U/f based converter to hold a precise speed (my converter also offers vector based control, but only up to 320Hz) - but I will check the voltage of spinout the next days.

Regarding the torque: I can use 5Nm so for small threads (up to M6) it should work. I'm machining only aluminium/plastics. But the direct thread machining is future. Currently I will stay with thread milling ... which of course is much more flexible: one cutter for many thread sizes and deeper threads.

I think for simplicity, I would ignore PID control and just use lincurve to linearize
the spindle speed control. PID is not needed for threading as the Z axis  is
"electronically geared" to the spindle rotation during threading so spindle speed
accuracy and speed variations are not very important.

I would also check that you do have sufficient torque for threading with a 24K RPM spindle

That said, its probably possible to use the hardware encoder Index to count revolutions since
it can function as a latch triggered by the index, if  hal logic is set up to create
a software encoder counter and the counter counts the index enable signal, and further
there is hal logic to set the index enable whenever its detected in a false state,
The index hardware can effectively be used to stretch out the index pulse (which
would be too short to be detected at the 1 KHz servo thread rate by an all software
hal setup.)
 

Hi folks!

I'm using LinuxCNC for a longer time and I'm now switching from a 5i25 to a 7i76e.
All is running smooth but I have a - small - problem with connecting and programming the main spindle.

The spindle is a professional HSD ES950, 5kW asynchronous motor, with ISO30 tool changer and up to 24000/min. In the past with 5i25 I used a frequency control of the spindle but now I want to use the 0-10V provided by the 7i76e. It works but the U/f curve is not very linear, even at low speeds below 1000/min.
But ok - I always wanted to do a PID control of the spindle speed (e.g. for thread machining) - there shouldn't be any problems with that.

My problem is, that the spindle encoder in my spindle is a 800 teeth gear, so the encoder gives me 3200 A/B pulses/revolution but the driver is limited to 200kHz, which gives a limit of 15000/min (this value can also be found in the manual). But of course I also want to use the spindle with higher speeds up to 24000/min.

So my idea is to use the normal encoder with A/B from 0-15000 and then use the Z index mark (one pulse per revolution - so that would lead to 400 pulses/s for maximum speed at 24000/min) for the PID.

I would implement a switch depending on the choosen S value and if it's higher than 15000 then switch the PID values and the feedback input from A/B to only Z.

But I have no real idea how to do this 

So my question is: how can I implement this in HAL - especially taking the Z pulses for feedback?

Thank you for your ideas,
Chris

P.S.:Another "ugly" way would be using PID up to 15000/min and then lincurve for extrapolating from 15000 to 24000/min. but this is not a PID - of course.

Da Pins nur eine Verknüpfung erlauben, aber Signale mehrfach verwendet werden können, geht die Lösung wohl in diese Richtung, würde ich zumindest mal testen.


In maschine hal, um das Signal zu belegen:

net laser_pwm_enable halui.program.is-running

nachher kann das Signal laser_pwm_enable (was ja jetzt halui.program.is-running entspricht) beliebig oft für diverse Zwecke weiterverwendet werden.

net laser_pwm_enable => hm2_7i76e.0.pwmgen.00.enable

**************************************************************

und in hal fürs Handbediengerät:

net laser_pwm_enable whb.halui.program.is-running

Hallo zusammen,

ich brauche mal wieder eure Hilfe. Ich hatte ganz am Anfang mein XHC Handrad über das Tutorial von Talla83 eingerichtet und das hat auch funktioniert.
Nun hatte ich mir aber noch zusätzlich eine PWM Laserdiode an die Fräse gebaut und ebenfalls mit eingebunden, das Problem ist, dass ich das sich mit dem Handrad kein Jogging ermöglich. Ich kann mit dem Handrad aber Programm starten und bekomme teilweise die Koordinaten angezeigt im Display vom Handrad.

Ich vermute, dass in der LinuxCNCV2.hal hier der Fehler liegt, net laser_pwm_enable halui.program.is-running => hm2_7i76e.0.pwmgen.00.enable, da halui.program.is-running ebenfalls bei der Konfigurationsdatei Handrad vorkommt und ich diese austexten musste.
xhc-whb04b-6.hal  #net pdnt.program-is-running whb.halui.program.is-running halui.program.is-running #*hier geändert*

Die Frage ist wie kann man die halui.prgramm.is-running so ändern dass das Handrad und der Laser damit klar kommen? das leutet mir nicht ein.

Danke Vorab

Christoph
 

Chaining them together is a great idea, why didn't I think of that. Big thanks Andy!

I did a quick test with some temporary wiring and the SRDY signal goes high as soon as the e-stop is lifted if there are no fault codes which should be exactly what's needed for the motion.enable input.



As the drives use DO+/DO- style outputs chaining the outputs should be very straight forward.

Ohh and sorry for hijacking your thread decor82, I'll start my own build thread shortly

You could AND them all together and link to motion.enable.

The "logic" and "LUT5" components can be used as a more-than-two input AND. Or, depending on the output type of the drives you may be able to wire them together to create a single input.

Thanks for your reply Andy.

The Delta B3 servo drives have both a servo ready signal and an alarm signal. I'm trying to figure out how to best use the two them.

I figured the joint.N.amp-fault-in would be best used with alarm signal.

But for the ready signal I haven't been able to find a matching hal input. Maybe it would be best to write a short hal code snippet that AND checks the ready signal from all drives and prevents the enabling of the machine if not all drives are ready.

I'm rookie when it comes this stuff so any feedback is very welcome.

Unlogic wrote:

What in LinuxCNC/HAL did you map the SRDY (servo is powered on, no alarm) signal to?

linuxcnc.org/docs/stable/html/man/man9/motion.9.html
joint.N.amp-fault-in IN BIT -Should be driven TRUE if an external fault is detected with the amplifier for this joint

This looks like a good choice, though it might need to be inverted in HAL.

I'm in the process of installing a set of Delta B3 servos and came across your detailed post.

What in LinuxCNC/HAL did you map the SRDY (servo is powered on, no alarm) signal to?

H2B wrote:

Drive outputs, which are digital inputs to the Mesa board:
SRDY (servo is powered on, no alarm)
ALRM (servo has tripped an alarm, machine must stop)
BRKR (brake control output from the drive, used to drive a relay controlling the servo break on my Z axis)

Drive inputs, which are digital outputs from the Mesa board:
SON (switch servo on - basically an enable signal to the axis, and not the enable signal from the stepgen commands)
ARST (alarm reset, when estop is lifted, to clear any alarm flags on the drive)
EMGS (send the servo an estop command, which should be common to all axes simultaneously)
NL (reverse inhibit limit - for axes hard limit at min position)
PL (forward inhibit limit - for axes hard limit at max position)