Advanced Search

I noticed that if I disable the machine the joint.0.motor-pos-cmd tracks the joint.0.motor-fb. So I set up a new hal file with only one cia402 and no cia402pv. Because you can't change the mode of the cia402 while LinuxCNC is running, I change between CSP and CSV by writing directly into the mode of the frequency drive via EtherCAT.

In CSP mode cia402.0.pos-fb -> joint.0.motor-pos-fb. 
In CSV mode joint.0.motor-pos-cmd -> joint.0.motor-pos-fb.

So I have no following error in CSV mode, but I need to change the position before changing from CSV back to CSP or I can turn the machine off and back on again. I built a network with mux2, oneshot and flipflop to toggle the machine for a very short amount and to reset all my mode switching logic. This works surprising well and isn't noticable.

I know that this soultion is not good and only works for my usecase because I only have one servo and nothing gets interrupted by the power cycle.

The bigger problem is that my gcode file gets stopped aswell and I can't resume. Maybe there is a way by tracking the executed lines and then starting from there... But I'm not happy with the power cycle solution in the first place.

Is there any other situation where joint.0.motor-pos-cmd tracks joint.0.motor-fb?

Looks like you got the pin name wrong. Try removing the 'gladevcp.' at the beginning.

I figured it out. The manual doesn't explicitly mention SDOs but it does say whether an index can be assigned to a PDO and I ignored that information the first time around.
260B, 260C, and 260D cannot be assigned to a PDO.

Is there another way of getting this information into HAL, or do I need to write a custom component?

Been quite a while since I've edited my linuxcnc v2.9.x Not sure what I am doing wrong here.

Help is appreciated

 

Output from "ethercat pdos" in attached file.

0x2605 works just fine: that's the DC link voltage and I can read that from all 3 drives.
0x260B does not.

The drive manual doesn't discuss SDOs, or whether some data index is a PDO or SDO. I would hope a temperature sensor would be continuously readable, which would require it to be a PDO.

With pll-reset-count steady at to 2 it should be fine.

Try to locate temperature sensors in the pdo listing from "ethercat pdos".
I suspect you are addressing a sdo with 2605 and that won't work.
You'll find out from the ethercat pdos listing.

I recently did this and my exact command was:
"./configure --sysconfdir=/etc/ --disable-8139too --enable-userlib --enable-generic --disable-eoe"

$lcecObject.pll-error-count is holding at 2. I haven't seen it increase yet.

I want to read some more data from the drives, and it won't work. See attached iX7NH.xml, line 23. I want to see the temperature values from the drive, but I can't read them. As shown, where pdoEntry idx="260B", the drive stays in PREOP (see dmesg output in dmesg260B.txt). If I change the index to "2606", the drive will go to OP (see dmesg output in dmesg2606.txt) and I can see the number through HAL (that I don't want). Registers 2606 and 260B are both 16 bit signed integers.
Any of 260B, 260C, or 260D (all temperature sensors in the servo system) have the same effect.


I can read the values manually with "ethercat upload -p0 -t int16 0x260B 0" and I get some number.
The drive manual says I can read up to 10 registers with one TxPDO: I have 6.
It also says that I am limited to 28 bytes in one TxPDO: I have 13.
How do I do this?

The sync component only calculates the c-pos-sync.0.pos_cmd_out, but has no effect to the joint.0.motor-pos-cmd.

It takes joint.0.motor-pos-cmd as c-pos-sync.0.pos-cmd-in and joint.0.motor-pos-fb as c-pos-sync.0.pos-fb_in. The calculated delta is called offset. So in spindle mode cmd_out = fb_in, but cmd_in is fixed. That results in the following joint error.

FUNCTION(_) {
    if (!c_mode_active) {
        offset = pos_fb_in - pos_cmd_in;
        pos_cmd_out = pos_fb_in;
    } else {
        pos_cmd_out = pos_cmd_in + offset;
    }
}

I thought ADm1N solved this with the c_pos_sync component?

I'm not familiar with ethercat but the somewhat 'established' strategy when switching between spindle and rotary is to use a hal component to freeze the encoder position feedback when switching to spindle mode and reposition the spindle using M19 before switching back to rotary mode and reconnecting the encoder signal.

The problem in spindle mode is, that the cia402 pos-fb is mapped to joint motor-pos-fb, but joint motor-pos-cmd is fixed. So joint f-error increases over time. Now I'm not sure how to solve this problem, cause I can't manipulate joint motor-pos-cmd. One way would be to freeze joint motor pos-fb, this way there is no f-error and track the movement to set an offset. But I can't figure out how to solve this, without writing to joint motor-pos-cmd.

The following error should also be a problem for aDm1N. But I assume it is less important, cause he only has 8000inc/rev, where I have 131072inc/rev, so the error adds up much slower. This would also explain FERROR = 1000000 in his ini.

Whats actual hardware do you have?

It sounds like a 7C81 and one 7I78.

It that case is might be simpler to use something like a pncconf 5i25/G540 configuration
as a starting point as that would al least let you setup the PWM spindle in pncconf.

In general, if you have the correct firmware for the daughtercard, the pins don't matter
in the hal files, what is significant is the module number like stepgen 0,1,2,3, etc.
The exception is GPIO pins.

The 7I78 encoder pins will have names like hm2_7c81.0.encoder.00.position.
7I73 MPG encoders will have names like hm2_7c81.0.7i73.0.0.enc0.position

Note that you can list all pin and parameter names when LinuxCNC is running with:

halcmd show all hm2





 

there is a duplicate addif at the beginning of the file, so it appears as the first error, I commented on that, but it also appears another type of scalemax.1 in not found

Thanks. That worked.
Before, it was unsuccessful with linuxcnc status.
Now i tested, by press the pushbutton, i can read the file by lines