HAL CiA402 Drive Interface for Can Bus,Ethercat etc...

Hallo Andre,

das scheint aber device spezifisch zu sein. Siemens Posmodrive an EL6731 muss ich keine byte order tauschen. Das sollte auch wenn im Profibus master erfolgen, da die PDOs ja eigentlich fertige values für die Prozessebene sind.

Getauscht werden muss die byte order nur wenn ich manuelle SDO read/writes code, benutzt man aber z.b. die initcmd funktionen vom Etherlab master passiert das automatisch. Das ist aber bei CAN/EC/Profibus identisch, das die sdos big endian sind.

Hi Dominik,

My tests have not been with your component. Unfortunately, your component was not available when I started this project and it would require a lot of changes to my hal files.  Do you think it would be possible to simplfy the component to only handle the position parts? As you know, I have been trying for quite a while to modify the homing.c file to loop the position  feedback similar to your component. The only difference is that I handle the mode switch via m-codes and ladder logic tied to my estop. From looking at your example file I see that the search vel  = 0 and the latch vel != 0 , I use the same setup but define the latch vel = 9.9 so the homing routine knows that you want to use the internal routine of the servo's. This made me realize that the following error that I am getting is probably from the servo switching from search to latch velocity without a signal telling homing.c that it should expect the slower velocity. However, this is just conjecture at this point... 

Also, my machine does not home in the way that linuxcnc expects. i.e. when the home switch is tripped it does not reverse directions, instead it continues and when the home switch goes from high to low, that is considered the home position. This is homing profile 19. What homing profile are you using and will the component work for all available Cia402 profiles? 

Lastly, why are more people not working on this? It seems to me that if the ethercat is to be fully adopted before analog servo's go the way of the dodo's this is a critical issue. Roschi saw the homing issue from day one...he had absolute encoders which is now supported, however incremental encoders continue to be an issue since 2.7. 

Kind regards,
Dan
 

 

db1981 wrote:

Hi,

sorry but unfortunaly i have no hardware at the moment for testing.

but maybe you can test by your own.

insert this at line 238 in the component:

Code:

if (stat_homing) {    pos_fb = pos_cmd; } and do an reinstall. This ignores the pos feedback from the drive while homing, but be aware there is no following error monitoring from linuxcnc during homing anymore.

Hi Folks,

I got time to fiddle around further. First of all thanks Dominik for your code. I updated my comp with that snippet and have to admit that it seems not to help a lot
The thing is: the f-error happens in my drives. If I start homing in the near of my homing switches the homing succeeds.
If not the difference in pos values will be big enough to overcome the ferror limit set in the drives (atm at 2,5mm). If I set this limit to a value great enough the homing will work fine. 
I am using homing mode 3. so i think the problem is when the drives going slower in reverse direction for seeking the index signal - lcnc is going further in the initial seek direction so those pos values will differ too much when homing is finished and the switch back to opmode 8 happens. 
So then i have the amp error message in lcnc cause of the ferror message in my drive

Any ideas?

Thanks
Conny

Hello Conny,

i am trying to understand...

At witch point in time the error in the drives occour?
while homing the drive normaly should not give an f-error, does this only happen at the end of homing? what pos value does your drive have at the end of the home sequence? zero or annother value?

i guess, this could be a timing problem. in theory lcnc should overtook the drives position at the moment the drives tells "homing ready" and the the pos-cmd send to the drive should be eqal to the fb-position (no f-error), but this reads like an cycle delay....

did you noticed that the right running order of the threads in the hal file is important?

If the feed error is in the drives, that means the drives are not set up properly, not tuned at all for work with the motors attached, mechanical strain beyound what the drive/motors can handle, feedback issues etc.
So no ammount of messing with Hal/LinuxCNC will help.
Not exactly sure what else was posted here, lost track of a lot lately.

Hi Dominik,

right, the error occurs on the end of the homing cycle. Also right, that in opmode 6 the drive is ignoring the lcnc pos values - so no ferror there.
My homing switches are set for example on x-axis to ~380mm, so I moved the ref. point in the drive to that offset. This means after successful homing the drives pos is at that 380mm. Also in my ini there is home set to this same point. Therefore in theory you have reached the same point, so that no further moves after homing are engaged.
So as I sad, if I am doing the homing near the homing switch the error is smaller than the ferror setting, so that the homing cycle works. If I am doing this further away - trouble will come up

I didn´t mess with that order of the threads. Otherwise I have to admit that I am not really sure about that. First lcec.write-all then .read-all??

@tommy: the drive setup is fine..This is because of the different values in commanded positions within the drive and out of the drive/lcnc.

Thanks
Conny