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

Hi,

sorry, but this can't work :
addf motion-command-handler servo-thread
addf motion-command-handler servo-thread
addf motion-controller servo-thread
addf lcec.read-all servo-thread
addf lcec.write-all servo-thread
addf cia402.0.read-all servo-thread
addf cia402.1.read-all servo-thread
addf cia402.0.write-all servo-thread
addf cia402.1.write-all servo-thread
addf pid.s.do-pid-calcs servo-thread
addf classicladder.0.refresh servo-thread
#addf spi_interlock servo-thread
addf carousel.0 servo-thread
addf near.0 servo-thread
addf scale.0 servo-thread

The function execution order is an fundamental part of every machine control, plc, software programm etc. 
I explained this a few times in the ethercat thread, also in the doc for the 402 component and it is good explained in the
"Hal introduction" and "Hal Basics" Chapter of the linuxcnc docs .....

In an Microcontroller or Realtime Program you have an task. (example servo-thread) this task is executed in an specified rate (examble every 1ms) . Into this task you have to add programms (functions) that do certain things. if you got more then one function and they have to interact together it is important  which is the first that is executed.  Injecting fuel after the ignition of the spark plug  will not work...

In an hal-thread the functions are executed as they are added in the hal file (addf).

looking at this:
 
addf motion-command-handler servo-thread

addf motion-controller servo-thread

addf lcec.read-all servo-thread

addf lcec.write-all servo-threadyour task starts and do the calculating of the motion part, but you have not readed the position and other values from the hardware yet. the result is that motions uses the old value from the last cycle. If you have a PID Systems this would let to horible behaviour.... The correct order would be :

-First read from hardware 
-motion calculations 
-(pid calculations)   (important: pids after motion!) 
-last write to hardware (with the new calculated values from this cycle)

this also is important for the 402 component and for scale/near components. You need the actual values from this cycle. 

The correct order for your hal would be:

addf lcec.read-all servo-thread
addf cia402.0.read-all servo-thread
addf cia402.1.read-all servo-thread
addf scale.0 servo-thread scale in front of near, because it calcs the input for near and motion
addf near.0 servo-thread
addf motion-command-handler servo-thread
addf motion-controller servo-thread
addf pid.s.do-pid-calcs servo-thread
addf classicladder.0.refresh servo-thread
#addf spi_interlock servo-thread
addf carousel.0 servo-thread
addf cia402.0.write-all servo-threadaddf cia402.1.write-all servo-threadaddf lcec.write-all servo-thread

i hope this helps, i think the behaviour should now changed. At your old order the pos_cmd (with the new home pos) arrived one cycle later as the mode switch bit. so the drive would have seen zero or another value instead of the new readed fb_pos and it says fb-err at this moment.
 hmm, hab gerade erst in der hal gesehen das ich mir gar keinen in Denglisch hätte abbrechen müssen..... 

 

Hi Dominik,

now we're cooking! Thank you so much!
This is so embarrassing, sorry for ignoring the really basics :/
Also thinking doing english things in this intern. part of the forum seems to be very okay

Greetz
Conny

Hi, I've been trying hard to get my cia402 drives using this component and have had no luck with homing.
The drives can home to a home switch. At this stage I am just using a proximity sensor connected to the motor on the bench.
If I commence homing, the motor takes off and when I activate the home switch it stops. but if I leave it there too long I get a following error
If I deactivate the sensor, I the drive continues moving again.
I have my config in Git
github.com/rodw-au/linuxcnc-cia402

Hal FIle: github.com/rodw-au/linuxcnc-cia402/blob/main/cia402.hal
Ini File: github.com/rodw-au/linuxcnc-cia402/blob/main/cia402.ini
XML FIle: github.com/rodw-au/linuxcnc-cia402/blob/main/ethercat-conf.xml
I did try the suggested change to the source but it only prevented all movement but the DRO's were changing.
I would appreciate some guidance.

 

Hi,

please try what happens if you set home_search_velocity to zero.

Using the drives internal home functions with this component is like a work around, to prevent changing a lot in lcncs internal home procedure.

There are no official pins to get the home command from motion. Related to this
i only use the index_homing part from the lcnc internal homing part. For the index homing the pin index_enable exists.
the behaviour should be like this:

-start home (search_velocity = 0)
-lcnc internal homing jumps to the state home_on_index
-lcnc sets joint.x.index_enable to 1
-with index_enable at 1, the CIA402 starts the internal home routine of the drive
-if the drive finished homing, CIA sets joint.x.index_enable to 0.
-lcnc detects the end of the index search run and reads the enc_pos and finished homing.

If you got following errors, try to set the home_latch_velo to the same velocity you have configured in your drive for homing.

Thanks, if I zero the search velocity, I get no movement. Am I missing a connection?  (only look at  drive 0, the rest home immediate on a later sequence)
The latch velocity is in sync with the drive homing velocity (by my best maths anyway as the drive is in pulses). There are two velocities in the drive though so I use the fast one.

So joint.0.index-enable is not enabling but joint.0.homing goes true
So what have I missed to activate the index-enable?
I checked in halscope just in case there was ajust a pulse her but there was nothing.
Homestate goes to 7. There are no docs for what that means.

OK I set
HOME_SEARCH_VEL            = 0
The index-enable then goes true and the DRO counts.
But the drive does not move
In the drive:
opmode changes to 6 and opmode homing goes true
Target position counts up but actual position does not change

So its like there is additional configuration required in the drive. But what?

Actually, I think I had a version of the component with your suggested changes earlier in this thread when it was counting. I re-cloned your component and now on homing it does not move at all and returns a following error

I spent a few hours working on this and made some changes to the component. Now my drives will with some caveats.
The changes I made was to ensure that system commands were made in a logical order and the homing command was only issued once. See below:



The issues I have seen have been discussed earlier on this thread.
the drives will home and rehome using the home all button but.
Movement is restricted to about 3/4 of a turn before a following error is raised. Hitting a homing switch attached to the drive in that distance will let it home  correctly otherwise a following error is raised.
I don't understand why this happens as we are keeping pos-fb in sync with pos-cmd

These drives have provision to connect  sensors for home, min limit and max limit which seems to be part of the cia402 standard.

Having read the earlier comments, I think we need to modify homing.c and create a new ini file homing flag for drives like this that bypasses checks for home and limit switches and other linuxcnc stuff. Eg homing should jump from
case HOME_INDEX_ONLY_START: (start homing)
to
case HOME_INDEX_SEARCH_WAIT: (until end homing ends)

After all, if you are going to use the dives homing, surely you will also use the drives lint switches too.

So any ideas about this would be appreciated.
 

Hi Rod, I have been working on homing for ethercat amps for literally several years. I started in the original ethercat HAL forum but stopped paying attention once the thread got high jacked. About six months ago I managed to get my machine running by several edits to the source code. It requires a couple of custom M-codes to switch the amplifiers mode from CSP  to Homing mode and back. As well as a bit of ladder logic to toggle the enable pin in order to switch modes. However, it allows any of the thirty or so homing routines to be used. Also I managed to hack a delta C2000 VFD with ethercat card to work as well. Admittedly the homing solution is slightly incomplete at the moment because I don't understand anything about bit masks and once I got the lathe running I need to start making some parts.  I am currently trying to install Debian 11 with ethercat ... without much luck in order to complete this.Also, I have been following in the developers forum and see that you have been pushing for adoption ethercat. I have no idea how to push my changes and have ethercat homing supported when this happens. I have attached my src file from linuxcnc-dev 2.9  Use visual studio code or similar to search for HOME_AUTO to see where I made the changes. 

Kind regards,
Dan