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

Hallo Dominik,

für Profibus wird das so nicht funktionieren.
Hier muss in den Telegrammen das Low-Byte mit dem High-Byte getauscht werden.
Ich hatte mir hierfür eine Comp geschrieben, ist zwar mit Sicherheit nicht sauber abter tat was es soll.

Gruß

Andre

Hi,

@sqmathlete
E-stop should not be a problem. If nobody changes motion source in the last months,
linuxcnc resets its position to the feedback position in the case you switch power on again. otherwise every following error would not be resetable... Have your experiments been with my component?

Brake
normaly brake handling is done in the drive, also the neccesary delays that needed for power on/off. If you set/reset enable, the drive returns his powered on signal after external brake is ready and the control loop is running.

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:

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?

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

thread order:

first lcec.read-all, , at last lcec.write-all.

please attach the hal file for checking this.

Hi Dominik,

yes, my hal had that in the right order - only I had it the wrong war round im my head.
see attached hal