Hi Dan,
I respect your position regarding uploading a proprietary solution to GIT,
I have no problem publishing the stuff related to LinuxCNC.
I would be happy to provide it with EtherCAT.
It simply made no sense with CANOpen when it lacks a configurable
CANOpen Stack.
It does make sense with Ethercat, comming with fixed/manual edited CoE
configuration.
Theoretical it would make sense with CAN/CANOpen, with a fixed
configuration, too.
But EtherCat has an advantage here.
CAN Bus is limited to only 1Mbit/s while EtherCAT run's with 100Mbit/s.
Example: In my case I operate 4 Servo drives, 2 spindle drives and one
Wago/Beckhof Kbus I/O unit .
Spindle drives do not operate with spindle orientation (what would lead
to run the spindles in positioning (and speed) mode, too)
To send 16bit speed set command and receive 32bit actual position
to/from 4 servo drives brings the CAN bus very fast to it's max.
If you want to push the bus usage to it's limits to reach minimal PID
cycle time or have spindle orientation or additional servos for the atc,
you need to optimize the bus usage, and/or add further busses.
To optimize the bus usage to your special machine, you need bus
configuration functionality. (And detailed knowledge )
Fundamentally it is the same with CANOpen over EtherCAT, but with
transfer rates being 100 times faster, there is no strong need for a
changeable configuration.
No problem to reach 1ms PID cycle time for eight servo/spindel drives
and some I/O.
This fixed setup will probably serve 95% of all applications.
" I added a parameter AUTOHOMING_SERVOSYSTEM = 1 in ini File "
How? I have tried adding a variable but cannot use it to take control in
homing.c,
The parameter is parsed in inijoint.cc and added as Boolean to
emcJointSetHomingParams() parameter list
This is copied to the flags in emcmotCommand in taskintf.cc .
emcmotCommand.flags |= HOME_AUTOHOMING_SERVO;
The definition is added in motion.h
/* flags for homing */
#define HOME_IGNORE_LIMITS 1
#define HOME_USE_INDEX 2
#define HOME_IS_SHARED 4
#define HOME_UNLOCK_FIRST 8
#define HOME_ABSOLUTE_ENCODER 16
#define HOME_NO_REHOME 32
#define HOME_NO_FINAL_MOVE 64
#define HOME_INDEX_NO_ENCODER_RESET 128
-> #define HOME_AUTOHOMING_SERVO 256 <-
- created a new section similar to HOME_SEARCH_WAIT that resets the timer and
calls a void (routine) that syncs the servo position feed back to commanded
position ?
added the states HOME_AUTOHOME_READY_WAIT and HOME_AUTOHOME_READY_DONE
to the homing statemachine in homing.c / home_state_t enumerator
case HOME_AUTOHOME_READY_WAIT:
{
if ( GET_JOINT_AUTOHOME_FINISHED_FLAG(joint))
{
// joint->home_state = HOME_FINISHED;
H[joint_num].home_state = HOME_AUTOHOME_READY_DONE;
}
}
break;
.
.
.
case HOME_AUTOHOME_READY_DONE:
{
/* The converter delivers 0 in case he has executed a
homing sequence.
* if it already was homed, it delivers the recent
position, what is actualy the correct value */
H[joint_num].home_offset = 0;
/* this moves the internal position but does not affect the
motor position */
joint->pos_cmd = joint->pos_fb;
joint->pos_fb = joint->pos_fb;
joint->free_tp.curr_pos = joint->pos_fb;
joint->free_tp.pos_cmd = joint->pos_fb;
joint->motor_offset = 0;
/* next state */
H[joint_num].home_state = HOME_FINAL_MOVE_START;
immediate_state = 1;
}
break;
- this section also handles limit
In my case no need for that. The drives use the limit switch with an
index mark on the linear scales.
If something goes wrong when homing, it is handle like e-stop ...
and e-stop
e-stop cuts the AC power from the drives and the drive statemachine
changes to error.
This unrequested change of state is signaled by the error output of the
CAN hal driver.
I believe the above section can be handled by custom m-codes and ladder logic
but, if you could explain this part as well,
CANOpen (and thereby CANopen over EtherCat ) defines device profiles for
a bunch of device types.
DS402 is the drive profile.
Part of this definition is a statemachine that is mandatory to implement.
(something I like very much about CANOpen, because only very few
fieldbus protocols go to level 7 of iso/osi stack.
Thats why every frequency converter on Modbus must have a specific piece
of software.
Not the case for CANOpen/CoE. Works for all brands the same way.)
This is a link to picture showing the statemachine.
https://infosys.beckhoff.com/index.php?content=../content/1031/el72x1-9014/1859316107.html&id=
In my CAN/CANOpen driver the hal enable input controls the target state
of the drive.
If true, I try to reach the state "operation enabled"
If false, I try to reach the state "ready to switch on"
If the AMP can not reach the requested state (e.g. it lacks AC power),
error flag is set.
If in "operation enabled", you can send a request to home the drive.
All this is explained in the drive manuals in detail.
that would be helpful since it is the more elegant solution.
I like the old fashioned simple speed set, actual position, enable in
and error out very much.
But it simply does not reflect the features of modern servos.
Besides autohoming, things like actual load, diagnostics messages,
switching operation modes (torque/speed) could be added.
Not sure exactly what this means but providing only this part of the solution
is probably all that is necessary
Yep, no problem sharing the extension of the linuxcnc homing part and
the DS402 state machine handling.
Would like to test it with physical EtherCAT devices, before publishing.
" Hints regarding the EtherCAT Hardware are welcome"
I have Delta ASDA-A2-E 2 KW amps and a Delta C2000 VFD running on ethercat,
are you looking for something specific?
I have some spare Servostar 300 / 600 that could be extended with a
EtherCat card.
But this card is as expensive a Chinese EtherCat servo.
So I think I will go with Chinese servos.
Would be nice to known if there is brand, that has been tested with
LinuxCNC's EtherCAT extension.
cheers
Rainer
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
