ASD-A2 EtherCAT on LinuxCNC

Hello "db1981"
Thank you very much for the tip.

When I write it like this:

so will it be ok?

Will the servos behave completely differently, or will the behavior change slightly?

Thank you very much.
Jirkam

that is the correct order.

you are not using pids in linuxcnc. So the behavior will change slightly.

Hello.
So I tried it and the servo motors behave exactly the same.
I'm tracking the servos in the Hal Scope.
Thanks Jirka

db1981 wrote:

Hello Jirka,

i have noticed an "~big" error in your hal file.

you adding lcec.real-all and write-all at the beginning of the hal file.

caused that liunxcnc builds its execution order of task functions in the order they are placed in the hal file, your servo-thread calls ec-read and then immediatly writes out lcec-write. So nothing is done with the Data in the meantime. Lcec.write-all uses "old"data from the last cycle . Which causes timing issues and leads to an bad servo tuning.

the right order would be:

addf lcec.read-all (gets data from hardware)
addf motion, value-converts, pids, classicladder etc.. (works with the data)

last addf lcec.write-all (send new data to hardware).


In your case lcec.write-all is called in front of motion and pids. So it sends "old" data from the last cylce to the drives without the new calculations. You got an 1
cycle offset between input and output data.

(you can search for "execution order" in the forum, i have descripted this in detail somewhere)
 

Hi I think you are wrong,hal file is not a program, but only a "description". It doesn't matter what order the lines are in, because it only runs at the end when linuxcnc starts. Just like when I enter HAL lines into halcmd, I have to enter start at the end, nothing happens until then.
Martin

 

Hi,

i am shure im absolutly right.....

Yes, hal is an description / script file. The order from net descriptions doesn't matter, but by parsing the hal also the running-order of the "realtime threads" are created.

lcnc places the running order per cycle from the functions you declare in the same order the addf commands in the hal file are placed.

This is very important for every realtime or plc system.
In every cycle every function is called 1 time, so its important to have the right order to get the expected behaviour of the realtime system.

The top description of an plc system should look like this :

-read Inputs (from Hardware)
-work with Data
-write Outpus (to Hardware)

in case of linuxcnc:
-read from hardware
-Motion Task (controll values)
-PIDs (compare actual hardware date with actual controll data)
-PLC functions
-write to hardware

docu:

linuxcnc.org/docs/stable/html/hal/intro.html

fupeama wrote:

Hi I think you are wrong,hal file is not a program, but only a "description". It doesn't matter what order the lines are in, because it only runs at the end when linuxcnc starts. Just like when I enter HAL lines into halcmd, I have to enter start at the end, nothing happens until then.
Martin

Sorry in this case the order of lcec read and write calls is absolutley critical. What you want to do is read from the ethercat bus, let Linuxcnc modify things, then write changes back to the bus.

We ar not talking about pins here, we are calling functions so the order is critical.

this is also very important for converter or mux functions (conv_to_float etc.)
They have to be in the right order too.

example:
If you convert an incoming encoder value, this function has to be placed between encoder readout (lcec / mesa read) and the motion / pid part. If you need to convert the motion/pid output again for the drive_cmd , this function has to be placed after motion/pid in front of the hardware output (lcec/mesa) write .

For plc/ladder this is the same.

I have read tons of bad hal / inis , when the config is growing many people start to add things at the end of their hal file or more worse in the postgui halfile. You can get very unexpected behaviour . And the issue finding could take years....

Yes guys you are both right and i was wrong.
I made easy experiment.
load function or2 (three times) and connect
siggen.clock -> or2.0.in0
or2.0.out -> or2.1.in0
or2.1.out -> or2.2.in0

wrong order
addf or2.2
addf or2.1
addf or2.0
addf siggen.0.update
three cycles are needed to change the signal at the end of the chain

right order
addf siggen.0.update
addf or2.0
addf or2.1
addf or2.2
only one cycle is needed to change the signal at the end of the chain YOU CAN SEE THE TIME SEQUENCE FROM THE PICTURE
You can see the time sequence from pictures.

I apologize once again for the mystification
Martin

 

Yes, that is an very important Case.

I think this behaviour should be better descripted and point out in the Documentation.

If you are not an prof. PLC Programmer or Microcontroller Developer you will never notice this.
And in the most cases this is also not clear to Prof. IT Guys / PC Programmers, cause they all code "event" based and not familar with the processing of realtime / hardware / atomic coding ...

I would say that > 70% of all the tuning problems in this forum are related to wrong execution order. Control Loops can not work, if the basics are wrong.