Advanced Search

Hi,
I have new servo drive: Leadshine EtherCAT EL6-EC400
I can read feedback of EL6-EC400, but could not control it.
 

I tested well with Leadshine EtherCAT drive EL7-EC400F.
I know that this model is in LCNC EtherCAT database: linuxcnc-ethercat.github.io/esi-data/devices/EL7-EC400F
Maybe EL6 series is new, not yet updated in LCNC database.
I confirm that ESI of EL6-xxx is same as EL7-xxx

Can you advise how to solve issue ?. Thank you.

Hello zmrdko,

Thanks a lot for your reply.
I don't get the usage of 120 Ohm on both ends? I just would determinate the last one - as shown in the delta manual.
Do I missunderstand it?
 

Are you working with an extra translator from CANopen to EtherCAT - like   in front of the EL6751?

Thanks a lot for your help in advance,
best regards

Jürgen




 

Thanks,but I'm using full customized qtvcp (using .ui file and handler.py),so ,not very fitable .

Thanks,but what I need is using vismach in my full customized qtvcp control pannel (which is controlled by an UI file and a handler.py)

Da hatten wir wohl die gleiche Idee 
Ich habe mir das gestern Abend nochmal angesehen und bemerkt das motmod ja in EMCMOT enthalten ist,
dann habe ich einfach unlock_joints_mask=0x8 da dran gehängt und in die passenden Signale verknüpft:

# --- Werkzeug-Revolver loesen-spannen ---
net   revolver-unlock  joint.3.unlock  =>  hm2_7i92.0.7i76.0.0.output-00
net   revolver-is-unlocked  joint.3.is-unlocked  <=  hm2_7i92.0.7i76.0.0.input-09

In der INI hatte ich unter:

[JOINT_3]
LOCKING_INDEXER_JOINT = 3
LOCKING_INDEXER = 1

Das funktioniert dann allerdings nur beim referenzieren das die Klemmung gelöst wird, bei zB. T3 M6 wird einfach die Achse gedreht ohne die Klemmung zu lösen, das Gleiche gilt, wenn man G0 C180 etc. laufen lässt.

Richtig ist es dann so

[AXIS_C]
LOCKING_INDEXER_JOINT = 3

[JOINT_3]
LOCKING_INDEXER = 1

Jetzt funktioniert es einwandfrei und ich kann mir die ganzen Unterprogramme für den Wkz-Wechsel sparen.
So sieht jetzt das Toolchange Unterprogramm aus:

o<toolchange> sub
#4001=45            (bei 8 Positionen 360 Grad durch 8)
M61 Q#4999            (Werkzeug aus Speicher setzen)
o500 if[#<_current_tool> EQ #<_selected_tool>]
    (DEBUG,Tool bereits in Spindel)
o500 else
    G0 C[#<_selected_tool> * #4001-#4001]
    M6 G43
    #4999=#5400
o500 endif
o<toolchange> endsub
m2

Danke das du dir die Mühe gemacht hast, hätte mir dann spätestens jetzt geholfen wenn ich nicht noch selbst drauf gekommen wäre.

Danke auch an alle anderen für eure Hilfe 


Gruß
Olli

I added some debug lines to the code and did the same procedure.
First tool call works and the machine stalls on the second tool call after the tool change is confirmed.
On the screenshoot u can see that the machine called the toolchange macro.
 

Hallo Olli
Habe mal Deine Maschinenconfig mit Klemmung erweeitert.
Ich hoffe es funktioniert.

Gruß Josef

FWIW, I added a Mesa output to my HAL, connected to the same signal used for motion.probe-input in order to monitor it with the oscilloscope along with the touch probe's trigger signal.

The total delay is 2-3ms (see attachment;CH1 is the probe trigger signal, CH2 is the Mesa output).

The reason it's not ~1ms (servo period) is that I had an OR gate connected to motion.probe-input for both a touch probe and a tool setter and the OR's function was executed after hm2_7i92.0.write. Removing the OR gate and connecting the Mesa input used for the touch probe directly to motion.probe-input (and the new output) dropped the delay to 1-2ms (I don't have a screenshot for that).

Either way, even 3ms delay does not explain the pretravel variation I'm observing, so the problem must be somewhere else. At 50mm/min probing speed, the total error introduced by that delay should be around 2.5um (given that I didn't make a mistake in my calculations). So not an actual problem at the moment.

Looking at my HAL file (initially generated by PNCconf) I wondered whether I need the PIDs (EDIT: I'm using open-loop steppers). After searching the forums I found that it helps with position estimation (if I understood correctly). A couple of questions:

1. How do the PIDs affect the position recorded during probing?
2. Is the following snippet correct or it's a bug in PNCconf?

net x-output     <= pid.x.output
net x-output     <= hm2_7i92.0.stepgen.00.velocity-cmd

Doesn't this mean that x-output has 2 writers?

yes i read thru this thread. Do u have any idea ?

Have you seen the docs?
linuxcnc.org/docs/stable/html/gui/qtvcp-vismach.html

Also the sample configurations qtdragon_metric or qtdragon_inch show vismach models in the utilities tab.

Have a look here:
forum.linuxcnc.org/38-general-linuxcnc-q...vcp-tabs-axis#268582

That was very helpful.

I still am having trouble coming up with lat and lon values that show the X/U and Y/V planes as vertical. It seems to me that changing the viewpoint through the lat and lon values never gets to such an orientation. Lat = -45 and lon = 0 almost looks like vertical X/U and Y/V planes, but I think it is an optical illusion.

Hi,everyone.
     I'm developing a cnc control panel using Qtvcp,and I need to display the vismach 3d model and movement in the qtvcp UI interface,but I dont know how to make it ,does anyone help me how to make vismach 3d model and movement in qtvcp's UI interface (not popup window),thank you 

yes I understand, I saw your answers there, I thank you for responding, but the link you gave me in the other post I tried to make it work but I couldn't, I even asked more questions there but I didn't get an answer, so I created another one, my apologies

First off tommy & myself replied.
Second, no double posting.