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

More
04 Aug 2021 07:00 #216890 by andrax
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

Please Log in or Create an account to join the conversation.

More
04 Aug 2021 07:53 #216893 by db1981
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.

Please Log in or Create an account to join the conversation.

More
04 Aug 2021 08:02 #216894 by db1981
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.

Please Log in or Create an account to join the conversation.

More
04 Aug 2021 22:58 #216944 by sqmathlete
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
 

Please Log in or Create an account to join the conversation.

More
08 Aug 2021 11:54 #217213 by JimPanski
 

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

Please Log in or Create an account to join the conversation.

More
08 Aug 2021 14:40 - 08 Aug 2021 14:41 #217238 by db1981
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?
Last edit: 08 Aug 2021 14:41 by db1981.

Please Log in or Create an account to join the conversation.

More
08 Aug 2021 19:23 #217256 by tommylight
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.

Please Log in or Create an account to join the conversation.

More
09 Aug 2021 08:52 #217303 by JimPanski
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

Please Log in or Create an account to join the conversation.

More
09 Aug 2021 10:27 #217309 by db1981
thread order:

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

please attach the hal file for checking this.

Please Log in or Create an account to join the conversation.

More
09 Aug 2021 15:04 #217320 by JimPanski
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
Attachments:

Please Log in or Create an account to join the conversation.

Time to create page: 0.238 seconds
Powered by Kunena Forum