Re: [etherlab-users] Twincat communicate with yaskawa SGDV alarm A12 (Sync Error)
Hi,
1) If your cycle time is 4ms, I think it should instead be:
0x60C2, 0x01 = 4
0x60C2, 0x02 = -3
Eg:
ecrt_slave_config_sdo8(dev-slaveConfig, 0x60C2, 0x01, (uint8_t)4);
ecrt_slave_config_sdo8(dev-slaveConfig, 0x60C2, 0x02, (int8_t)(-3));
Where the first parameter is the significand and the second parameter is the
exponent. So:
(0x60C2, 0x01) * 10 ^ (0x60C2, 0x02) = 4 * 10 ^ -3 = 0.004 seconds = 4 ms
2) I’m currently patching against 1.5.2 (2526). Yes it is still quite old but
I haven’t needed to (or had the time) to move on. I don’t think any of my
patches have made it into the master. My current DC patch is:
etherlabmaster-1.5.2-2526-c_dc_helpers.patch (attached). There is still the
odd issue with some of the slaves taking a while to sync on startup. This has
been solved by other people but I haven’t had a chance to add it in myself yet.
I don’t think the EK1100, EL1008 and EL2008 modules are able to be set up as DC
slaves, but they can be used as the reference clock slave.
Before starting realtime polling I set the reference clock slave using (where
refSlaveConfig is the slaveConfig of the module I select via a config file):
ecrt_master_select_reference_clock(ecMod-master, refSlaveConfig);
This is after ecrt_master_application_time() and before ecrt_master_activate().
My realtime loop is:
// receive process data
ecrt_master_receive(ecMod-master);
// process domain data
for (i = 0; i EC_DOMAIN_COUNT; i++)
{
ecrt_domain_process(ecMod-domains[i].domain);
}
// check domain state, check master state
...
// prepare pdo data
...
// send process data
for (i = 0; i EC_DOMAIN_COUNT; i++)
{
ecrt_domain_queue(ecMod-domains[i].domain);
}
// always sync distributed clock (just before master_send)
ecMod_syncDistClock(ecMod);
// do the send
ecrt_master_send(ecMod-master);
// update the master clock (if this module provides the ref slave)
// Note: called after ecrt_master_send to reduce time jitter
ecMod_updateMasterClock(ecMod);
My syncDistClock function gets the current ref slave time and requests the
slaves to sync to the ref slave:
// cache prev master time and get now
masterTime = (uint32_t)ecMod-m_dcTime;
ecMod-m_dcTime = filterTime( rt_get_time_ns() );
// get lower 32 bit of clock time from reference slave (after first scan)
if (ecMod-m_getDCDiff)
{
int res;
uint32_t slaveTime;
res = ecrt_master_reference_clock_time(ecMod-master, slaveTime);
switch (res)
{
case 0 :
{
// calc time diff
ecMod-m_dcDiff = masterTime - slaveTime;
} break;
default :
{
// no ref clock found or datagram failure
ecMod-m_dcDiff = 0;
}
}
}
else
{
ecMod-m_dcDiff= 0;
ecMod-m_getDCDiff = true;
}
// call to sync slaves to ref slave
// (which is used for ecrt_master_reference_clock_time)
ecrt_master_sync_slave_clocks(ecMod-master);
// update the master time for the next cycle (in nano-seconds)
// (this is required for the master to figure out the modules initial
// dc time)
ecrt_master_application_time(ecMod-master, ecMod-m_dcTime +
g_app.scanTimeNS);
My updateMasterClock function is responsible for tracking and filtering the
master time drift. This drift is added to the rtai time. So whenever I need
to get an rtai time I need to wrap it in the filterTime() function. When I
need the realtime cycle to sleep for the next period (using
rt_sleep_until(wakeTime)) the wake time is adjusted by the filtered time.
(Note: error checking removed to hopefully make clearer)
I hope this helps,
Graeme.
From: 陈成细 [mailto:crazyintermi...@gmail.com]
Sent: Friday, 29 May 2015 2:19 p.m.
To: Graeme Foot
Subject: Re: Twincat communicate with yaskawa SGDV alarm A12 (Sync Error)
Dear Graeme Foot,
Thanks for your kindly guide in the mailing list and private email. In the
recently half year, I do on the track and make in progress to drive my yaskawa
servopack and servo motor via etherlab master.
First of all, I would like update my status to you.
1. I create three domain, readdomain, write domain for yaskawa, another domain
for others.
2. I can make motor rotate in free run mode without setup DC
3. Two times success to drive motor with DC, others 5000ms sync error
My setup:
ubuntu 14.04, xenomai real time kernel, etherlab1.52 stable
I do my homework already, and I think the answer already in the mailing list,
so I have several point need to make clear.
1. http://lists.etherlab.org/pipermail/etherlab-users/2012/001562.html post
you mention
Hi,
Yes I have thanks. My cycle time is 1ms. I have set:
0x60C2, 0x01 = 1
0x60C2, 0x02 = -3
Graeme.
My cycle time use 4ms, I set
0x60C2, 0x01 = 01
0x60C2, 0x02 = FD
refer to
[Inline image 1]
2. Regarding DC patch
http://thread.gmane.org/gmane.network.etherlab.user/1421, do you have latest
patch for etherlab1.52 stable, since it is years ago, or
Re: [etherlab-users] Twincat communicate with yaskawa SGDV alarm A12 (Sync Error)
FWIW, while I could be wrong about this, as far as I know it’s generally a bad
idea to explicitly set the reference clock slave. It defaults to being the
first DC-capable slave on the network, and you shouldn’t set it to any other
slave because of the way the DC sync datagrams work. Specifically, any
DC-capable slaves that are topologically earlier than the reference clock will
not receive the reference clock’s time, but instead whichever value happens to
have been initialised by the master (I haven’t checked exactly what this will
be but I expect it’s probably either zero or the master’s time). As a result
these slaves will be desynched with the rest of the network.
Of course, you can get away with this if you don’t care about the DC times of
any slaves prior to the selected reference clock, but it still seems like a bad
habit unless there’s a very good reason to select some specific device (eg.
known as a “better” clock) – but then you should try to get it as early in the
network as possible.
Also, you’re not supposed to call ecrt_master_application_time() before
ecrt_master_activate(); the master is expecting that the first application_time
it receives is in phase with the application loop – ideally as close to the
ecrt_master_send() call as possible. (The examples don’t really make this
clear, but the goal is to make the ecrt_master_send()call at as close to the
desired cycle time as possible. The sleep is at the other end of the loop
because there is a natural delay between send and receive anyway and because
the assumption is that the processing time is reasonably constant.)
From: etherlab-users [mailto:etherlab-users-boun...@etherlab.org] On Behalf Of
Graeme Foot
Sent: Tuesday, 2 June 2015 11:45
To: 陈成细; etherlab-users@etherlab.org
Subject: Re: [etherlab-users] Twincat communicate with yaskawa SGDV alarm A12
(Sync Error)
Hi,
1) If your cycle time is 4ms, I think it should instead be:
0x60C2, 0x01 = 4
0x60C2, 0x02 = -3
Eg:
ecrt_slave_config_sdo8(dev-slaveConfig, 0x60C2, 0x01, (uint8_t)4);
ecrt_slave_config_sdo8(dev-slaveConfig, 0x60C2, 0x02, (int8_t)(-3));
Where the first parameter is the significand and the second parameter is the
exponent. So:
(0x60C2, 0x01) * 10 ^ (0x60C2, 0x02) = 4 * 10 ^ -3 = 0.004 seconds = 4 ms
2) I’m currently patching against 1.5.2 (2526). Yes it is still quite old but
I haven’t needed to (or had the time) to move on. I don’t think any of my
patches have made it into the master. My current DC patch is:
etherlabmaster-1.5.2-2526-c_dc_helpers.patch (attached). There is still the
odd issue with some of the slaves taking a while to sync on startup. This has
been solved by other people but I haven’t had a chance to add it in myself yet.
I don’t think the EK1100, EL1008 and EL2008 modules are able to be set up as DC
slaves, but they can be used as the reference clock slave.
Before starting realtime polling I set the reference clock slave using (where
refSlaveConfig is the slaveConfig of the module I select via a config file):
ecrt_master_select_reference_clock(ecMod-master, refSlaveConfig);
This is after ecrt_master_application_time() and before ecrt_master_activate().
My realtime loop is:
// receive process data
ecrt_master_receive(ecMod-master);
// process domain data
for (i = 0; i EC_DOMAIN_COUNT; i++)
{
ecrt_domain_process(ecMod-domains[i].domain);
}
// check domain state, check master state
...
// prepare pdo data
...
// send process data
for (i = 0; i EC_DOMAIN_COUNT; i++)
{
ecrt_domain_queue(ecMod-domains[i].domain);
}
// always sync distributed clock (just before master_send)
ecMod_syncDistClock(ecMod);
// do the send
ecrt_master_send(ecMod-master);
// update the master clock (if this module provides the ref slave)
// Note: called after ecrt_master_send to reduce time jitter
ecMod_updateMasterClock(ecMod);
My syncDistClock function gets the current ref slave time and requests the
slaves to sync to the ref slave:
// cache prev master time and get now
masterTime = (uint32_t)ecMod-m_dcTime;
ecMod-m_dcTime = filterTime( rt_get_time_ns() );
// get lower 32 bit of clock time from reference slave (after first scan)
if (ecMod-m_getDCDiff)
{
int res;
uint32_t slaveTime;
res = ecrt_master_reference_clock_time(ecMod-master, slaveTime);
switch (res)
{
case 0 :
{
// calc time diff
ecMod-m_dcDiff = masterTime - slaveTime;
} break;
default :
{
// no ref clock found or datagram failure
ecMod-m_dcDiff = 0;
}
}
}
else
{
ecMod-m_dcDiff= 0;
ecMod-m_getDCDiff = true;
}
// call to sync slaves to ref slave
// (which is used for ecrt_master_reference_clock_time)
ecrt_master_sync_slave_clocks
Re: [etherlab-users] Twincat communicate with yaskawa SGDV alarm A12 (Sync Error)
The “No app_time received up to now but master already active” warning is due to a race between the internal master starting to configure the slaves once ecrt_master_activate() is called and the realtime loop calling ecrt_master_send() for the first time. As long as your master thread starts up faster than your slaves can be configured (which is usually the case, but not always if you have a small number of slaves or a particularly slow thread start-up time) then you shouldn’t get the warning (which also makes the DC times at the wrong phase from your PDO exchange; that may or may not matter to you – but it also happens if you don’t call ecrt_master_application_time() for the first time just prior to the send). My preferred solution to avoid this warning is to start the realtime thread before calling ecrt_master_activate(), but make it sleep without calling the ecrt functions until a flag is set by the main thread after activating. This way it’s already “hot” and the delay will be minimal, practically guaranteeing that it will win the race (since it requires multiple cycles to configure even a single slave). It also means that I can deactivate, reconfigure, and reactivate the master without having to stop the realtime thread (although that requires some care and another patch, if using the usermode library). From: Graeme Foot [mailto:graeme.f...@touchcut.com] Sent: Tuesday, 2 June 2015 13:41 To: Gavin Lambert Cc: etherlab-users@etherlab.org Subject: RE: [etherlab-users] Twincat communicate with yaskawa SGDV alarm A12 (Sync Error) Hi, Good comments to make. Yes, the DC reference slave should be the first capable slave and definitely before (or at least the first) DC enabled slave. However, I had some EK1100 modules (which at one stage were my first slaves) that just did not seem to provide a settled enough time for the yaskawa SGDV drives. But when I changed my reference slave to an EL1008 slave (the next slave in the system) everything was fine. I suspect the EK1100’s time was running too fast (or too slow, I can’t remember) compared to the SGDV’s time and it couldn’t adjust quick enough. If you don’t call ecrt_master_application_time() before ecrt_master_activate() then you can get: No app_time received up to now but master already active.. However, as you say, you should call ecrt_master_application_time() in phase with your realtime cycle time. I set my time just before going realtime and the first realtime period is scheduled to run 50 times my cycle period later. The 50 times is to allow the rt_make_hard_real_time() call to go realtime. As we are not yet realtime, this call can take a little time to happen. Yes, I agree, the ecrt_master_send() should be as consistent as possible. To allow this my cycles sequence is to perform the EtherCAT code below straight after waking up. All other calculations and processing, to prepare for the next cycle, are performed after this. Graeme. From: Gavin Lambert [mailto:gav...@compacsort.com] Sent: Tuesday, 2 June 2015 12:52 p.m. To: Graeme Foot Cc: etherlab-users@etherlab.org mailto:etherlab-users@etherlab.org Subject: RE: [etherlab-users] Twincat communicate with yaskawa SGDV alarm A12 (Sync Error) FWIW, while I could be wrong about this, as far as I know it’s generally a bad idea to explicitly set the reference clock slave. It defaults to being the first DC-capable slave on the network, and you shouldn’t set it to any other slave because of the way the DC sync datagrams work. Specifically, any DC-capable slaves that are topologically earlier than the reference clock will not receive the reference clock’s time, but instead whichever value happens to have been initialised by the master (I haven’t checked exactly what this will be but I expect it’s probably either zero or the master’s time). As a result these slaves will be desynched with the rest of the network. Of course, you can get away with this if you don’t care about the DC times of any slaves prior to the selected reference clock, but it still seems like a bad habit unless there’s a very good reason to select some specific device (eg. known as a “better” clock) – but then you should try to get it as early in the network as possible. Also, you’re not supposed to call ecrt_master_application_time() before ecrt_master_activate(); the master is expecting that the first application_time it receives is in phase with the application loop – ideally as close to the ecrt_master_send() call as possible. (The examples don’t really make this clear, but the goal is to make the ecrt_master_send()call at as close to the desired cycle time as possible. The sleep is at the other end of the loop because there is a natural delay between send and receive anyway and because the assumption is that the processing time is reasonably constant.) From: etherlab-users [mailto:etherlab-users-boun...@etherlab.org
Re: [etherlab-users] Twincat communicate with yaskawa SGDV alarm A12 (Sync Error)
Hi, Good comments to make. Yes, the DC reference slave should be the first capable slave and definitely before (or at least the first) DC enabled slave. However, I had some EK1100 modules (which at one stage were my first slaves) that just did not seem to provide a settled enough time for the yaskawa SGDV drives. But when I changed my reference slave to an EL1008 slave (the next slave in the system) everything was fine. I suspect the EK1100’s time was running too fast (or too slow, I can’t remember) compared to the SGDV’s time and it couldn’t adjust quick enough. If you don’t call ecrt_master_application_time() before ecrt_master_activate() then you can get: No app_time received up to now but master already active.. However, as you say, you should call ecrt_master_application_time() in phase with your realtime cycle time. I set my time just before going realtime and the first realtime period is scheduled to run 50 times my cycle period later. The 50 times is to allow the rt_make_hard_real_time() call to go realtime. As we are not yet realtime, this call can take a little time to happen. Yes, I agree, the ecrt_master_send() should be as consistent as possible. To allow this my cycles sequence is to perform the EtherCAT code below straight after waking up. All other calculations and processing, to prepare for the next cycle, are performed after this. Graeme. From: Gavin Lambert [mailto:gav...@compacsort.com] Sent: Tuesday, 2 June 2015 12:52 p.m. To: Graeme Foot Cc: etherlab-users@etherlab.org Subject: RE: [etherlab-users] Twincat communicate with yaskawa SGDV alarm A12 (Sync Error) FWIW, while I could be wrong about this, as far as I know it’s generally a bad idea to explicitly set the reference clock slave. It defaults to being the first DC-capable slave on the network, and you shouldn’t set it to any other slave because of the way the DC sync datagrams work. Specifically, any DC-capable slaves that are topologically earlier than the reference clock will not receive the reference clock’s time, but instead whichever value happens to have been initialised by the master (I haven’t checked exactly what this will be but I expect it’s probably either zero or the master’s time). As a result these slaves will be desynched with the rest of the network. Of course, you can get away with this if you don’t care about the DC times of any slaves prior to the selected reference clock, but it still seems like a bad habit unless there’s a very good reason to select some specific device (eg. known as a “better” clock) – but then you should try to get it as early in the network as possible. Also, you’re not supposed to call ecrt_master_application_time() before ecrt_master_activate(); the master is expecting that the first application_time it receives is in phase with the application loop – ideally as close to the ecrt_master_send() call as possible. (The examples don’t really make this clear, but the goal is to make the ecrt_master_send()call at as close to the desired cycle time as possible. The sleep is at the other end of the loop because there is a natural delay between send and receive anyway and because the assumption is that the processing time is reasonably constant.) From: etherlab-users [mailto:etherlab-users-boun...@etherlab.org] On Behalf Of Graeme Foot Sent: Tuesday, 2 June 2015 11:45 To: 陈成细; etherlab-users@etherlab.orgmailto:etherlab-users@etherlab.org Subject: Re: [etherlab-users] Twincat communicate with yaskawa SGDV alarm A12 (Sync Error) Hi, 1) If your cycle time is 4ms, I think it should instead be: 0x60C2, 0x01 = 4 0x60C2, 0x02 = -3 Eg: ecrt_slave_config_sdo8(dev-slaveConfig, 0x60C2, 0x01, (uint8_t)4); ecrt_slave_config_sdo8(dev-slaveConfig, 0x60C2, 0x02, (int8_t)(-3)); Where the first parameter is the significand and the second parameter is the exponent. So: (0x60C2, 0x01) * 10 ^ (0x60C2, 0x02) = 4 * 10 ^ -3 = 0.004 seconds = 4 ms 2) I’m currently patching against 1.5.2 (2526). Yes it is still quite old but I haven’t needed to (or had the time) to move on. I don’t think any of my patches have made it into the master. My current DC patch is: etherlabmaster-1.5.2-2526-c_dc_helpers.patch (attached). There is still the odd issue with some of the slaves taking a while to sync on startup. This has been solved by other people but I haven’t had a chance to add it in myself yet. I don’t think the EK1100, EL1008 and EL2008 modules are able to be set up as DC slaves, but they can be used as the reference clock slave. Before starting realtime polling I set the reference clock slave using (where refSlaveConfig is the slaveConfig of the module I select via a config file): ecrt_master_select_reference_clock(ecMod-master, refSlaveConfig); This is after ecrt_master_application_time() and before ecrt_master_activate(). My realtime loop is: // receive process data ecrt_master_receive(ecMod-master); // process domain
