Advanced Search

First real job for this lathe-
Parting off from a 4" 304 bar, then facing back side of the part.

Had some extreme and abnormal chatter at first so I looked around for loose components. Tightened up the X gibs, tried again, nope. Put a bar in the chuck and an indiciator on the spindle, gave it a push and a shove and saw .004" TIR. Ended up having to tighten the spindle preload and good to go.

 

Check syslog with "sudo dmesg | tail -20", the master usually tells you in its own cryptic way what's wrong.

Edit, sorry I see you have already done that. Nevertheless, show us messages in the syslog.
And the ethercat-conf.xml file.

 

Assuming this is what you mean?

Can you not message the vendor for any documents ?
Unless someone else has one and is willing to share their experiences, you're venturing into unknown territory.

If it does run 7i92 firmware any threads relating to 7i92 setup should suffice.

Yes that one sir

Yes sir this one from aliexpress
www.aliexpress.com/item/1005010164851154.html

I’m trying to connect an ICLA ILA2E servo drive over EtherCAT using LinuxCNC 2.9.7 with the lcec driver and the IgH EtherCAT master 1.6.8 (on Debian 12 RT). The EtherCAT bus is: PC → Beckhoff EK1100 → ICLA ILA PLCOpen (the ILA2E servo). The EK1100 coupler always reaches OP state without problems, but the servo stays stuck in PREOP + ERROR when controlled through lcec.When I control the servo manually with thecommand-line tools, it behaves correctly. If I send controlwords 0x0006, 0x0007, and then 0x000F to object 0x6040, the drive enables, holds torque, and moves as expected. The feedback position from 0x6064 changes correctly, and the motor clearly enters operational state internally, even thoughstill lists it as PREOP + ERROR. So communication works and the drive can be controlled directly, but it never transitions to OP when LinuxCNC and lcec are running.The PDO mapping was taken directly from the drive:RxPDO 0x1600 contains 6040 (controlword, 16 bits), 6060 (opmode, 8 bits), 607A (target position, 32 bits), and 60FF (target velocity, 32 bits).
TxPDO 0x1A00 contains 6041 (statusword, 16 bits), 6061 (opmode display, 8 bits), 6064 (actual position, 32 bits), 606C (actual velocity, 32 bits), and 6077 (actual torque, 16 bits).The XML configuration for the slave defines these PDOs and basic HAL pins for cia-controlword, opmode, target-position, actual-position, and so on. I have not included any DC configuration yet because the drive does not reach OP even in basic mode.When I start LinuxCNC, lcec loads normally, but the servo never leaves PREOP. The HAL pins show that the slave is online but not operational. The logs show mailbox or CoE errors such as “Invalid input configuration (0x001E)” or timeouts while reading SDOs like 0x1C33:3. Despite that, if I exit LinuxCNC and usecommands directly, the servo behaves correctly every time.So the problem is that the drive can reach operational state when commanded manually through, but it stays in PREOP when controlled via lcec. I suspect the issue might be in the XML configuration or a missing initialization SDO sequence.Has anyone successfully used an ICLA ILA PLCOpen (Vendor ID 0x0800005A, Product ID 0x000022DB, model ILA2E) servo with LinuxCNC and lcec? Any hints about what might be missing in the configuration would be greatly appreciated.

Hmmm ... why are you running a hal file with halrun?
You need to run an ini file with LinuxCNC, so right click on the ini file, open with, use custom command and type linuxcnc, enter.

Thank you for reporting back.

actually I found out it was caused by a tool being called that doesn't exist, so it cancelled the file load

I am stuck at the same point again. I was leaning heavily on LLM's to get me this far, but I think some human common sense and experience might be required here.
Please, If anyone can shed some light as to what might be required here, it would be much appreciated.
 

I think I understand the width and scale now, I have illustrated my understanding in the pictures attached.  If you could confirm that those measurements are the correct ones for the width and scale parameters that would be amazing.

Our problem is the understanding of how the carousel component integrates with the hardware, for example how come some people leave pins or parameters out. And what is carousel-lock and unlock and how does it relate to the component. 

Also my illustration was fast it is not to scale unfortunately, so I included a photo of the actual carousel.  
Thank you

 

unknown wrote:

You didn't by chance use the new trixie image on the downloads page did you ?
 

Actually, yes I did... Shouldn't I?

It is definitely a python 3 version. If I remember correctly, it was shortly after the pip install method stopped working and the install documentation was in a little bit of flux at the time. The new version I am working on does not throw an error when I try to disable a button, It just does nothing.

I will preface this next part by saying that I have just enough skill in reading and understanding code to get into trouble. I haven't used AI stuff because I don't have the skill to double check it. I found when digging through the source that sub call buttons reference issue_mdi.bindOk which references some stuff in the status plugin.

With guess and check I have found that on SubCallButtons I can do this:

STATUS.homed.onValueChanged(lambda: self.probe_spindle_nose_subcallbutton.setEnabled(False))

With this added to the top section of the file:

STATUS = getPlugin('status')

I don't know if this is a good way to do it but it does disable the button.

Perfect, thank you, that helps me prove some of my suspicions. I have to dig more, seems like I didn't understand the Omron data sheet. Apparently you can select the PDO's you want mapped to SM 2&3, through some registers.

"The PDO mapping to be used is specified in Sync Manager 2 PDO Assignment (1C12 hex) and Sync Manager 3 PDO Assignment (1C13 hex)."

I would be surprised if you don't get "83" errors. I get alot of unmatched datagrams but it will go into "op" mode. It might have to do with the actual PDO assignment register.

Yours might work because you have different PDO's defined, however it also states:
"Since the mappings you changed are not saved in EEPROM, you must specify objects each time you turn ON the power of the G5-series Servo Drive in order to use the mapping other than the default setting."

I did not see any SDOconfig for those registers, so I will assume you have the "default" values, which I will confirm on my drive:

Drive Firmware version v2.14 ( ethercat upload -p3 --type string 0x100a 0)
My Default values are:
Sync Manager 2 PDO Assignment Register readings
ethercat upload -p3 0x1C12 0 = 0
ethercat upload -p3 0x1C12 1 = 0x1701
ethercat upload -p3 0x1C12 2 = 0x0000
Sync Manager 3 PDO Assigment Register readings
ethercat upload -p3 0x1C13 0 = 0x1
ethercat upload -p3 0x1C13 1 = 0x1b01
ethercat upload -p3 0x1C13 2 = 0x0000

So we can see the hal file you are using is incorrect.
Unless you set these up somewhere else, but I wasn't able to see it in the XML settings

yours have 0x1702 & 0x1b04 which are mixed matched, not sure if thats allowed. By default it should be 0x1701 & 0x1b01

Ah so the variable PDO mapping makes sense now. You can assign whatever PDO's you want, you set the Assignment registers to 0x1600 & 0x1A00 respectively. If I can get that to work I will post a xml file for that example as well.