[etherlab-users] Controlling motor drivers
Gavin Lambert
gavinl at compacsort.com
Thu Feb 11 23:20:21 CET 2016
With the current Etherlab master code, yes, you will need to read them individually, although you don’t need to create separate request objects for each one, you can re-use the same one as long as it’s for the same slave and has the same data size.
A few months ago I posted some patches that enable support for SDO Complete Upload requests – with those applied (and provided the slave supports it, but most do) you can read an entire object (one index with all subindexes) in a single request.
Regarding registering it as a PDO, typically you cannot just invent your own – you can only use values as PDOs if the slave documentation has made a PDO Mapping object (something in 0x16xx or 0x1Axx) available that links to the data of interest. Note that you must look at the documentation – the Etherlab scan will only show the default-selected PDOs, not all possible PDOs. I’m not familiar with that particular slave myself so I can’t tell you whether that object is available in a PDO or not; but if it’s not, then you’ll have to read it via SDOs only.
From: etherlab-users [mailto:etherlab-users-bounces at etherlab.org] On Behalf Of Paul Mulligan
Sent: Friday, 12 February 2016 01:30
To: Graeme Foot <Graeme.Foot at touchcut.com>; etherlab-users at etherlab.org
Subject: Re: [etherlab-users] Controlling motor drivers
Hi Graeme,
There are not many examples, but if I want to check the motor diagnostic bits A010 during runtime, with 5 motors for example, an ec_sdo_request_t object would need to be created for each error bit on each motor, so 50 objects in total.
Then at runtime, when necessary, I would need to go through the state machine with the ecrt_sdo_request_* commands for each of these 50 bits? Is there a way to read all the error bits at once in one word?
Would it not be possible to register these diagnostic bits in an ec_pdo_entry_reg_t structure and exchange them at runtime like the pdos?
Thanks again,
Paul
On Sunday, 24 January 2016, 22:19:58, Graeme Foot <Graeme.Foot at touchcut.com <mailto:Graeme.Foot at touchcut.com> > wrote:
Hi,
The Target Position is an absolute position (not incremental). If you ask it to go to position 2 it will move there and then stay there. If you want to move from zero to 200 over 100 cycles you need to explicitly change the Target Position every cycle:
Cycle 0: Target Position = 0
Cycle 1: Target Position = 2
Cycle 2: Target Position = 4
Cycle 3: Target Position = 6
Cycle 4: Target Position = 8
Cycle 5: Target Position = 10
...
Cycle 99: Target Position = 198
Cycle 100: Target Position = 200
If your increment per cycle is too big for the motor to handle you will get errors.
ecrt_slave_config_sdo() is used for one time setup of SDO configuration values (before the master is activated). The EtherCAT master will apply the SDO configuration values when it is activated, or if the module is repowered, ensuring it is correctly configured every time it starts up and is enabled.
If you want to manually interact with SDO values (read/write values at arbitrary times) at runtime you use ecrt_slave_config_create_sdo_request() to create a request object you can interact with. You then use a state machine with the following functions:
ecrt_sdo_request_data()
ecrt_sdo_request_data_size()
ecrt_sdo_request_state()
ecrt_sdo_request_write()
ecrt_sdo_request_read()
You should be able to find some older forum message re how to use them (there’s also various patches out there that make them a bit more powerful, not sure if any of them are currently added to the etherlab master).
I can’t really comment as to why the Ready to Enable bit is not on, except that there is probably an warning or error. Check the warning and error bits from the PDO and also check the A010 bits. You can also access this data (and any SDO data) while the app is running from the EtherCAT master command line:
ethercat upload -p<pos> 0xA010 0x01
ethercat upload -p<pos> 0xA010 0x02
...
Regards,
Graeme.
From: Paul Mulligan [mailto:mulligan252 at yahoo.ie]
Sent: Saturday, 23 January 2016 5:33 a.m.
To: Graeme Foot
Subject: Re: [etherlab-users] Controlling motor drivers
Hi Graeme,
Many thanks for your help.
I thought that by replying here , it would also get written on the forum also but I can update it.
Sorry, I know, many questions. I won't keep hassling you but there is just one or two things more that I don't understand. I feel that there is a lack of code examples out there on how to communicate using the master, especially for motor control.
When setting the target position in each cycle, say for example with value 2, I assume that this moves the motor by 2 steps every cycle. If 200 is the number of steps per revolution (I even explicitly set it with the 8010:06 SDO parameter), I would expect that after 100 cycles, the motor would do a full revolution but it's not the case. I tried different time periods of calling the cyclical function, even as high as one second, but the motor just instantaneously moves into some position and stays there.
The state machine for initialising the motor fails for me. On reading the ready to enable bit (6010:01), it never gets set. I enable the motor anyways but then the 6010:02 bit also never gets set.
When writing SDOs, is it just a matter of calling ecrt_slave_config_sdo() without having to register them first like the PDOs? In order to read the error bits of A010 , i'm not sure how.
Thanks again ,
Paul
On Thursday, 21 January 2016, 22:40:52, Graeme Foot <Graeme.Foot at touchcut.com <mailto:Graeme.Foot at touchcut.com> > wrote:
Hi,
I don’t use ecrt_domain_reg_pdo_entry_list() so can’t comment on that one.
To configure my devices I use (without error checking):
/* configure the slave */
dev->slaveConfig = ecrt_master_slave_config(ecMod->master, dev->alias, dev->position, dev->vendorID, dev->productCode);
/* configure the PDOs */
ecRes = ecrt_slave_config_pdos(dev->slaveConfig, EC_END, EL7031_syncs);
I then use the following to get addresses for the PDO items:
offset = ecrt_slave_config_reg_pdo_entry(dev->slaveConfig, EL7031_pdoEntries[pdoIdx].index,
EL7031_pdoEntries[_pdoIdx].subindex,
ecMod->domains[domIdx].domain, &bitPos);
Re Target Position updating:
EtherCAT works with PDO’s and SDO’s. The PDO’s (Process Data Objects) are sent every cycle to exchange data with the slaves. The SDO’s (Service Data Objects) are used to exchange non-cyclic / non-urgent data (eg configuration). You want the PDO data to be as minimal as possible to reduce the amount of data being send across the fieldbus. This allows you to either have more slaves or smaller cycle times.
EtherCAT motors in position mode get the Target Position updated via PDO’s. This means each and every cycle your app needs to tell the motor where you want it to be at the end of that cycle. If your motor is to be stationary you do not need to update the Target Position value from your app if you don’t want to, but your app still has to send out the PDO, which will be sending out the old value until your app starts changing it again.
When you want to move your motor you need to update the Target Position with the new value for that cycle. The Motor slave’s (ie the EL7031) job is to take that Target Position and over the period of the next cycle to interpolate the motor between the last cycles Target Position and the new Target Position.
So if you have an EtherCAT cycle time of 1000Hz (1 ms) then:
- to turn the motor forward at a velocity of 5000 counts/second then you need to increment the Target Position value by 5 counts each cycle
- to turn the motor reverse at a velocity of 5000 counts/second then you need to increment the Target Position value by -5 counts each cycle
- to turn the motor forward at a velocity of 10000 counts/second then you need to increment the Target Position value by 10 counts each cycle
- to turn the motor reverse at a velocity of 10000 counts/second then you need to increment the Target Position value by -10 counts each cycle
It is up to your app to decide the speed and therefore the per cycle increment. You can’t just set a final Target Position and wait for the motor to get there as it will try to get there in one cycle.
This motor module is a very low level of control. The app needs to provide the high level control ie:
- what does motor count mean (ie you need a scale factor between you realworld units (eg mm) and the motors counts units.
- when you want to move the motor to a new position you need to calculate the speed profile and therefore the motor position at each cycle increment
- also motors don’t like instantaneous speed changes so you also need to take care of acceleration and deceleration.
If you want a motor where you can set and forget a final target position then you will probably need an EtherCAT servo amp with an Interpolated Position Mode.
Regards,
Graeme.
PS: remember to also reply to the etherlab forums so others can learn and comment too.
From: Paul Mulligan [mailto:mulligan252 at yahoo.ie]
Sent: Friday, 22 January 2016 4:37 a.m.
To: Graeme Foot
Subject: Re: [etherlab-users] Controlling motor drivers
Thanks for that Graeme.
I am having issues however. I copied your set-up for the motor driver to my application as shown below but at run-time on calling ecrt_domain_reg_pdo_entry_list I am receiving the error "Failed to register PDO entry: No such file or directory".
If I remove the motor entries from the domain1_regs[] however, there are no problems. Am I missing something else?
With regards to stepping the motor, you mentioned that I must update the target position on every cycle. I'm not sure I understand that. Won't the target position always be the same when it's set? Do I increment the motor by one step on each cycle until it reaches the target position?
/* Master 0, Slave 6, "EL7031"
* Vendor ID: 0x00000002
* Product code: 0x1b773052
* Revision number: 0x00170000
*/
ec_pdo_entry_info_t slave_6_pdo_entries[] =
{
// 0x1602, stepper control (0)
{0x7010, 0x01, 1}, // Enable
{0x7010, 0x02, 1}, // Reset
{0x7010, 0x03, 1}, // Reduce torque
{0x0000, 0x00, 5}, // spacer
{0x0000, 0x00, 8}, // spacer
// 0x1603, stepper pos (5)
{0x7010, 0x11, 32}, // Target position
// 0x1a03, stepper status (6)
{0x6010, 0x01, 1}, // Ready to enable
{0x6010, 0x02, 1}, // Ready
{0x6010, 0x03, 1}, // Warning
{0x6010, 0x04, 1}, // Error
{0x6010, 0x05, 1}, // Moving positive
{0x6010, 0x06, 1}, // Moving negative
{0x6010, 0x07, 1}, // Torque reduced
{0x0000, 0x00, 1}, // spacer
{0x0000, 0x00, 3}, // spacer
{0x6010, 0x0c, 1}, // Digital input 1
{0x6010, 0x0d, 1}, // Digital input 2
{0x1c32, 0x20, 1}, // Sync error
{0x0000, 0x00, 1}, // spacer
{0x1803, 0x09, 1}, // *** unknown ***
};
ec_pdo_info_t slave_6_pdos[] =
{
{0x1602, 5, slave_6_pdo_entries + 0},
{0x1603, 1, slave_6_pdo_entries + 5},
{0x1a03, 14, slave_6_pdo_entries + 6},
};
ec_sync_info_t slave_6_syncs[] =
{
{0, EC_DIR_OUTPUT, 0, NULL, EC_WD_DISABLE},
{1, EC_DIR_INPUT, 0, NULL, EC_WD_DISABLE},
{2, EC_DIR_OUTPUT, 2, slave_6_pdos + 0, EC_WD_DISABLE},
{3, EC_DIR_INPUT, 1, slave_6_pdos + 2, EC_WD_DISABLE},
{0xff}
};
/*------------------------------------------------------------*/
//motor
//commands
static unsigned int off_motor_speed;
static unsigned int off_motor_enable;
static unsigned int off_motor_reset;
static unsigned int off_motor_target_pos;
//status
static unsigned int off_motor_err_status;
static unsigned int off_motor_ready_to_enable;
static unsigned int off_motor_ready_status;
static unsigned int bitPosit = 1;
const static ec_pdo_entry_reg_t domain1_regs[] =
{
{DigOutSlave1Pos, Beckhoff_EL2008, 0x7000, 1, &off_digout1},
{DigOutSlave2Pos, Beckhoff_EL2008, 0x7000, 1, &off_digout2},
{DigInSlave1Pos, Beckhoff_EL1008, 0x6000, 1, &off_digin1},
{DigInSlave2Pos, Beckhoff_EL1008, 0x6000, 1, &off_digin2},
{AnaInSlavePos, Beckhoff_EL3001, 0x6000, 0x11, &off_anain},
{MotorSlavePos, Beckhoff_EL7031, 0x7010, 0x21, &off_motor_speed},
{MotorSlavePos, Beckhoff_EL7031, 0x7010, 0x01, &off_motor_enable},
{MotorSlavePos, Beckhoff_EL7031, 0x6010, 0x04, &off_motor_err_status, &bitPosit},
{MotorSlavePos, Beckhoff_EL7031, 0x7010, 0x02, &off_motor_reset, &bitPosit},
{MotorSlavePos, Beckhoff_EL7031, 0x6010, 0x01, &off_motor_ready_to_enable, &bitPosit},
{MotorSlavePos, Beckhoff_EL7031, 0x6010, 0x02, &off_motor_ready_status, &bitPosit},
{MotorSlavePos, Beckhoff_EL7031, 0x7010, 0x11, &off_motor_target_pos, &bitPosit},
{}
};
/*-----------------------------------------------------------------------------------------------------------------------*/
/* Inside main function*/
if (ecrt_domain_reg_pdo_entry_list(domain1, domain1_regs))
{
fprintf(stderr, "PDO entry registration failed!\n");
return -1;
}
On Wednesday, 20 January 2016, 22:54:33, Graeme Foot <Graeme.Foot at touchcut.com <mailto:Graeme.Foot at touchcut.com> > wrote:
Hi,
To get information about what PDO’s can be mapped for a device you will need to look into the in device documentation.
Some devices do not allow reconfiguration so you must match what is already there (cstruct command fine for this). Some devices allow you to map different PDO’s, but only from preconfigured group options (the EL7031 falls into this category). And lastly some devices allow you to configure any PDO item in any order as long as you have enough space to do so, however with these devices not all items can be used as PDO’s.
If you have a Beckhoff module you can easily download its documentation from their site using the url: http://www.beckhoff.com/ <http://www.beckhoff.com/%3cmodel_number%3e/> <model_number>/
Eg: http://www.beckhoff.com/EL7031/
Then click on the “Documentation (CHM)” link and it will download the documentation. Note: being a chm file you will need to open it in Windows from a local drive. The content will also be blocked until you select “Unblock” from right-click, properties:
Have a look at the “Object description and parameterization” section (in this case it is under: EL70x1 - Stepper Motor Interfaces, Configuration with the TwinCAT System Manager, EL7031, ...)
Have a look at the 0x160x groups. These are the preconfigured read/write item groups. The value of each item tells you which PDO item addresses will be used.
Then have a look at the 0x1a0x groups. These are the preconfigured readonly item groups.
Note: there may be restrictions as to which groups you can use together. This is generally found in the XML device description files. These files are what tells TwinCAT what configuration options are valid. Also note that different module firmware revisions will probably support different options and PDO mappings. If over time you need to support different firmware revisions you will need to read the modules revision from your app and match the correct configuration.
It’s also a good idea to get the Beckhoff XML device descriptions from: http://download.beckhoff.com/download/Config/EtherCAT/XML_Device_Description/Beckhoff_EtherCAT_XML.zip
You can view them in Internet Explorer, but they are large and really slow. I generally load them into Notepad++ and delete the irrelevant modules and revisions (without saving) to speed things up and make searching easier.
In the XML file find the “AlternativeSmMapping” nodes. This tells you what various “modes” the module is designed to be used in and what PDO mapping groups are used.
For my application I wanted “Position control”, so I used the following:
<AlternativeSmMapping>
<Name>Position control</Name>
<Sm No="2">
<Pdo>#x1601</Pdo>
<Pdo>#x1602</Pdo>
<Pdo>#x1603</Pdo>
</Sm>
<Sm No="3">
<Pdo>#x1a01</Pdo>
<Pdo>#x1a03</Pdo>
</Sm>
</AlternativeSmMapping>
But I also didn’t want to use latching, so in my case I left off 0x1601 and 0x1a01.
As to changing moving direction, you just need to change the Position Target in the negative direction.
Eg, if you want to move from position 0 to 20 and then back to 0 you would output the positions (one each scan):
0
0 // accelerate moving forward
1
3
6
10 // decelerate moving forward
14
17
19
20 // pause
20
20
20 // accelerate moving reverse
19
17
14
10 // decelerate moving reverse
6
3
1
0
0
...
Note: If the above scan time is 1000Hz then the above would be accelerating/decelerating at 1000 counts/second.
It is up to you to come up with the trajectory of the motor (ie where you want to go) and the kinematics (ie how fast do you want to go and accelerate / decelerate). Then for each scan period output the target position.
You can use kinematic equations to figure out a simple kinematic profile (eg from: http://www.physicsclassroom.com/class/1DKin/Lesson-6/Kinematic-Equations). However you may need to get into some more advanced mathematics if you want to introduce smoothing factors (jerk etc.)
However, if you want to move forward and the motor goes in reverse for your mechanical configuration (and vice-versa) then the motor has a Reverse configuration option (0x8012:09, Invert motor polarity).
Regards,
Graeme Foot
Kinetic Engineering Design Ltd.
From: Paul Mulligan [mailto:mulligan252 at yahoo.ie]
Sent: Thursday, 21 January 2016 3:32 a.m.
To: Graeme Foot
Subject: Re: [etherlab-users] Controlling motor drivers
Hi Graeme,
Thanks alot for that.
I'm completely new to Ethercat. Where can I find the SDO entries with indexes that you mentioned, for any device?
Up until now I have only been using the Ethercat command line tool to retrieve the c-structures relating to the PDOs for the slave device and then copying and pasting this information into my code.
Also, in order to change moving direction of the motor, do I need to change an SDO value ?
Regards,
Paul
On Tuesday, 19 January 2016, 22:55:37, Graeme Foot <Graeme.Foot at touchcut.com <mailto:Graeme.Foot at touchcut.com> > wrote:
Hi,
We also use the EL7041 in production, but have also used an EL7031 for testing.
The default the PDO mapping is for velocity control. You need to change it to use the position control PDO's.
For the EL7031 the PDO setup I use is:
ec_pdo_entry_info_t EL7031_pdoEntries[] = {
// 0x1602, stepper control (0)
{0x7010, 0x01, 1}, // Enable
{0x7010, 0x02, 1}, // Reset
{0x7010, 0x03, 1}, // Reduce torque
{0x0000, 0x00, 5}, // spacer
{0x0000, 0x00, 8}, // spacer
// 0x1603, stepper pos (5)
{0x7010, 0x11, 32}, // Target position
// 0x1a03, stepper status (6)
{0x6010, 0x01, 1}, // Ready to enable
{0x6010, 0x02, 1}, // Ready
{0x6010, 0x03, 1}, // Warning
{0x6010, 0x04, 1}, // Error
{0x6010, 0x05, 1}, // Moving positive
{0x6010, 0x06, 1}, // Moving negative
{0x6010, 0x07, 1}, // Torque reduced
{0x0000, 0x00, 1}, // spacer
{0x0000, 0x00, 3}, // spacer
{0x6010, 0x0c, 1}, // Digital input 1
{0x6010, 0x0d, 1}, // Digital input 2
{0x1c32, 0x20, 1}, // Sync error
{0x0000, 0x00, 1}, // spacer
{0x1803, 0x09, 1}, // *** unknown ***
};
ec_pdo_info_t EL7031_pdos[] = {
{0x1602, 5, EL7031_pdoEntries + 0},
{0x1603, 1, EL7031_pdoEntries + 5},
{0x1a03, 14, EL7031_pdoEntries + 6},
};
ec_sync_info_t EL7031_syncs[] = {
{0, EC_DIR_OUTPUT, 0, NULL, EC_WD_DISABLE},
{1, EC_DIR_INPUT, 0, NULL, EC_WD_DISABLE},
{2, EC_DIR_OUTPUT, 2, EL7031_pdos + 0, EC_WD_DISABLE},
{3, EC_DIR_INPUT, 1, EL7031_pdos + 2, EC_WD_DISABLE},
{0xff}
};
PDO Item #5 {0x7010, 0x11, 32} is the Target position.
You will want to pre-configure some of the SDO values:
maxCurrent 0x8010, 0x01
reducedCurrent 0x8010, 0x02
nominalVoltage 0x8010, 0x03
motorCoilResistance 0x8010, 0x04
motorFullSteps 0x8010, 0x06
maxSpeedRange 0x8012, 0x05
reversed 0x8012, 0x09
On initialisation you need to set the motor to use the Position Controller mode of operation (3):
ecrt_slave_config_sdo8(dev->slaveConfig, 0x8012, 0x01, 3);
You may also want to set up the distributed clock (eg:)
ecrt_slave_config_dc(dev->slaveConfig, 0x0300, g_app.scanTimeNS, 500000, 0, 0);
You will probably want to set up a motor enable state machine but the guts of it is that you will want to:
- before enabling, if the error status bit (PDO Item #9 {0x6010, 0x04, 1}) is set
set the faultReset control bit (PDO Item #1 {0x7010, 0x02, 1}) for around 100ms
- ensure the readyToEnable status bit (PDO Item #6 {0x6010, 0x01, 1}) is on
if there is no error set the enable control bit (PDO Item #0 {0x7010, 0x01, 1})
wait until the ready status bit (PDO Item #7 {0x6010, 0x02, 1}) is on
Once enabled you need to update the target position (PDO Item #5 {0x7010, 0x11, 32}) every scan cycle with the position you want to go to. It is up to you to create a motion profile for the motor and then figure out what the target position is at each time increment.
Lastly, if you get the warning or error status bits set you can look up what the error or warning is via the 0xA010 SDO diagnostic bits (0xA010:0x01 - 0xA010:0x11). Note: these are only available via SDO access, so what I do is have a state machine that looks them up if the warning or error status bits are set.
Hope this helps.
Regards,
Graeme Foot
Kinetic Engineering Design Ltd.
-----Original Message-----
From: etherlab-users [mailto:etherlab-users-bounces at etherlab.org <mailto:etherlab-users-bounces at etherlab.org> ] On Behalf Of Thomas Bitsky Jr
Sent: Wednesday, 20 January 2016 3:57 a.m.
To: Paul Mulligan; etherlab-users at etherlab.org <mailto:etherlab-users at etherlab.org>
Subject: Re: [etherlab-users] Controlling motor drivers
I use the EL7041 often. He’s a quick copy/paste of how I make it move to position. The code snippet below writes to EtherLAB through a library I wrote, but the tasks required should be pretty obvious.
Thanks!
============
static int
stateIdle(void* lp)
{
EL7041StepperInterface* p;
EL7041_ENTER(p, lp);
if (p->doMove)
{
p->doMove = false;
if ( !lcxReadPdoBit(p->pdoOffset + IX_READY) )
{
PRINT( "EL7041.%s not ready for motion. Cancelling.\n",
__FUNCTION__ );
return StateMachineRunning;
}
lcxWritePdoUInt16(p->pdoOffset + QW_SETACCEL, p->targetAccel );
lcxWritePdoUInt16(p->pdoOffset + QW_SETDECEL, p->targetDecel );
lcxWritePdoUInt16(p->pdoOffset + QW_SETVELOCITY, p->targetVelocity );
p->fsm = &stateWaitWriteMotionParameters;
return StateMachineTransition;
}
}
static int
stateWaitWriteMotionParameters(void* lp) {
EL7041StepperInterface* p;
EL7041_ENTER(p, lp);
p->fsm = &stateWriteStartType;
return StateMachineTransition;
}
static int
stateWriteStartType(void* lp)
{
EL7041StepperInterface* p;
EL7041_ENTER(p, lp);
lcxWritePdoUInt32(p->pdoOffset + QW_SETTARGETPOSITION, p->setTargetPosition );
lcxWritePdoUInt32(p->pdoOffset + QW_SETSTARTTYPE, p->setStartType );
p->ton = TON_ENDTIME(100);
p->fsm = &stateWaitWriteStartType;
return StateMachineTransition;
}
static int
stateWaitWriteStartType(void* lp)
{
EL7041StepperInterface* p;
EL7041_ENTER(p, lp);
if (TON_ISDONE(p->ton))
{
/*
* ALERT!
* This command should start motion on the axis.
*/
lcxWritePdoBit(p->pdoOffset + QX_CONTROLEXECUTE, true);
p->ton = TON_ENDTIME(500);
p->fsm = &stateWaitExecute;
return StateMachineTransition;
}
return StateMachineRunning;
}
Thomas C. Bitsky Jr. | Lead Developer
ADC | automateddesign.com <http://automateddesign.com/>
Follow ADC news and media:
Facebook <https://facebook.com/automateddesigncorp> | Twitter <https://twitter.com/ADCSportsLogic> | YouTube <https://www.youtube.com/user/ADCSportsLogic>
From: etherlab-users <etherlab-users-bounces at etherlab.org <mailto:etherlab-users-bounces at etherlab.org> > on behalf of Paul Mulligan <mulligan252 at yahoo.ie <mailto:mulligan252 at yahoo.ie> >
Reply-To: Paul Mulligan <mulligan252 at yahoo.ie <mailto:mulligan252 at yahoo.ie> >
Date: Tuesday, January 19, 2016 at 7:49 AM
To: "etherlab-users at etherlab.org <mailto:etherlab-users at etherlab.org> " <etherlab-users at etherlab.org <mailto:etherlab-users at etherlab.org> >
Subject: [etherlab-users] Controlling motor drivers
Hi, (Formatting was wrong on previous post)
We bought various Beckoff modules for Digital in , Digital out, Analogue in and Stepper Motor control.
I am able to communicate with with the digital I/O and analogue input slave modules from Ethercat master IGH 1.5.2 without problems, but the stepper motor controller (EL7031) is more complicated.
Below is a list of the PDO entries for the motor controller retrieved from the Ethercat bus using the command line tool with the cstruct option.
I am only able to set the velocity and then set the enable bit to start the motor running. I have no idea how to command the motor to just turn a certain amount of steps and change direction etc. I have tried to set a counter value but it doesn't make a difference. Also, if I set the bits to move positive or move negative, it doesn't change direction as I would expect. I can't seem to find any documentation or examples on how to control motors with this module EL7031. If anyone has any information or knowledge , I would really appreciate your help. Thanks
ec_pdo_entry_info_t slave_6_pdo_entries[] = {
{0x0000, 0x00, 1}, /* Gap */
{0x7000, 0x02, 1}, /* Enable latch extern on positive edge */
{0x7000, 0x03, 1}, /* Set counter */
{0x7000, 0x04, 1}, /* Enable latch extern on negative edge */
{0x0000, 0x00, 4}, /* Gap */
{0x0000, 0x00, 8}, /* Gap */
{0x7000, 0x11, 16}, /* Set counter value */
{0x7010, 0x01, 1}, /* Enable */
{0x7010, 0x02, 1}, /* Reset */
{0x7010, 0x03, 1}, /* Reduce torque */
{0x0000, 0x00, 5}, /* Gap */
{0x0000, 0x00, 8}, /* Gap */
{0x7010, 0x21, 16}, /* Velocity */
{0x0000, 0x00, 1}, /* Gap */
{0x6000, 0x02, 1}, /* Latch extern valid */
{0x6000, 0x03, 1}, /* Set counter done */
{0x6000, 0x04, 1}, /* Counter underflow */
{0x6000, 0x05, 1}, /* Counter overflow */
{0x0000, 0x00, 3}, /* Gap */
{0x0000, 0x00, 4}, /* Gap */
{0x6000, 0x0d, 1}, /* Status of extern latch */
{0x6000, 0x0e, 1}, /* Sync error */
{0x0000, 0x00, 1}, /* Gap */
{0x6000, 0x10, 1}, /* TxPDO Toggle */
{0x6000, 0x11, 16}, /* Counter value */
{0x6000, 0x12, 16}, /* Latch value */
{0x6010, 0x01, 1}, /* Ready to enable */
{0x6010, 0x02, 1}, /* Ready */
{0x6010, 0x03, 1}, /* Warning */
{0x6010, 0x04, 1}, /* Error */
{0x6010, 0x05, 1}, /* Moving positive */
{0x6010, 0x06, 1}, /* Moving negative */
{0x6010, 0x07, 1}, /* Torque reduced */
{0x0000, 0x00, 1}, /* Gap */
{0x0000, 0x00, 3}, /* Gap */
{0x6010, 0x0c, 1}, /* Digital input 1 */
{0x6010, 0x0d, 1}, /* Digital input 2 */
{0x6010, 0x0e, 1}, /* Sync error */
{0x0000, 0x00, 1}, /* Gap */
{0x6010, 0x10, 1}, /* TxPDO Toggle */ }; _______________________________________________
etherlab-users mailing list
etherlab-users at etherlab.org <mailto:etherlab-users at etherlab.org>
http://lists.etherlab.org/mailman/listinfo/etherlab-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20160212/1a724e03/attachment-0004.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 139639 bytes
Desc: not available
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20160212/1a724e03/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 11689 bytes
Desc: not available
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20160212/1a724e03/attachment-0011.png>
More information about the Etherlab-users
mailing list