Hi Rainer,
Thanks for your detailed response. inijoint.cc/taskintf.cc wasn't on my
radar. I'm still trying to wrap my head around how they work.
Based on your instructions, ,I made the following changes
1) in inijoint.cc
Line 75 static int loadJoint (int joint, EmcIniFile
*jointIniFile)
{
Line 100 bool home_ethercat;
Line 203 home_ethercat = 0;
jointIniFile->Find(&home_ethercat,
"HOME_ETHERCAT", jointString);
Added my new parameter HOME_ETHERCAT to the end of
Line 206 // issue NML message to set all params
Line 207 if (0 != emcJointSetHomingParams(
,
,
,home_ethercat);
2) in taskintf.cc
added int home_ethercat to list
Line 281 emcJointSetHomingParams(
Line 311 if (home_ethercat){
emcmotCommand.flags |= HOME_ETHERCAT
}
added home_ethercat to and %d to the rcs_print list for the added item
Line 349 if (emc_debug & EMC_DEBUG_CONFIG){
3) in motion.h
added int home_ethercat to list
Line 215 typedef struct emcmot_command_t
/* flags for homing */
#define HOME_ETHERCAT 256
I've added the extra code based on errors that came up in the terminal and
examined variables like use_index and volatile home that look similar to
what I am try to do.
to figure out the code However, Im getting an error that says
emc/task/emctaskmain.cc: In function 'int emcTaskIssueCommand(NMLmsg*):
emc/task/emctaskmain.cc: 1746:44: error 'class EMC_JOINT_SET_HOMING_PARAMS'
has no member named 'home_ethercat'; did you mean 'home_sequence'?
set_homing_params_msg->home_ethercat);
I added the above line since the previous error was that there were not
enough arguments in the list.
Since we are looking for something similar to home_sequence, I looked
through homing.c to try to determine how home_sequence is handled and then
tried to duplicate but, now I get even more errors.
Any ideas? Not sure if this matter's but I am using 2.9 since it now has
some nice lathe features.
>Would be nice to known if there is brand, that has been tested with
LinuxCNC's EtherCAT extension.
I am using Delta's ASDA-A2E and I believe that they one of the brands used
in the original development . Other than homing not working
correctly...yet, they are awesome.
Basically this is one of the last programming issues that I need to sort
out before putting my lathe through commissioning.
I'm hunkering down today to try and sort this out. Will let you know if I
get past step 1. Lol
Kind regards,
Dan
On Fri, Sep 17, 2021 at 7:52 PM Rainer <r.stel...@sgs-robotics.de> wrote:
> 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
>
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
