<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.18.3">
</HEAD>
<BODY>
This drive initially drove me crazy too.<BR>
<BR>
1.) You should obtain Firmware Version 3.01 from Yaskawa where they appear to have improved the SII EEPROM interface. If you have anything earlier you may be wasting your time. I got nowhere until I received a drive with this firmware from my Yaskawa USA office.<BR>
<BR>
When I told Yaskawa there was a problem the initial response from their developers was the device passed the EtherCAT conformance test and it works with TwinCAT. However, what they don't seem to recognize is that the EtherCAT conformance test does not test everything for specification compliance and that there still may be something wrong with their device. Fortunately the newer firmware seemed to fix the EEPROM size error I was receiving. <BR>
<BR>
2.) In addition to getting newer firmware you must declare a domain for the Output and a second one for the Input <BR>
since Yaskawa sets notLRW = yes. <BR>
<BR>
3.) Moreover, the Output Domain must be registered with <I>ecrt_domain_reg_pdo_entry_list</I> before the Input Domain otherwise you <BR>
will not have any data exchanged even though the drive goes into OP mode. <BR>
<A HREF="http://lists.etherlab.org/pipermail/etherlab-users/2010/001000.html">http://lists.etherlab.org/pipermail/etherlab-users/2010/001000.html</A> I am not sure if this is Yaskawa's bug or something <BR>
in the Hilscher module they are using. The same issue occurred in a Control Techniques module I tested. <BR>
<BR>
I received from Yaskawa via Hilscher that SyncManager2 -> Output -> FMMU0 and SycnManager3 -> Input -> FMMU1<BR>
and this is made with the ETG concerted and an integral part of the ESI. <BR>
According to Florian Pose it is arbitrary that Outputs are always mapped to FMMU0 and inputs are mapped to FMMU1.<BR>
<BR>
<PRE>
Maybe if IGH informs ETG of typical problems like the EEPROM size error and the arbitrary FMMU usage ETG will add them to the
conformance tool and we will have less interoperability errors as new slaves arrive in the future.
On Thu, 2010-11-25 at 12:31 +0100, Dr.-Ing. Wilhelm Hagemeister wrote:
</PRE>
<BLOCKQUOTE TYPE=CITE>
<PRE>
Hallo takeshi ikeya,
the SSI-contents (EEPROM) is broken. We had that up until now with two
vendors.
> I saw other user's mail about YASKAWA SIGMA5, in which he said he couldn't
> even get vendor ID and product code.
Because of this we updated the Master Code. Now it is possible to read
the first mandatory 64 words from the EEPROM which also contain vendor
ID and product code. But the EtherLab-Master also needs at least the
sync-manager information from the EEPROM.
Please contact the vendor and point out, that there is a conformance
test tool from the EtherCat technology group available to check if the
slave meets the spezification. Every vendor shipping EtherCat slaves has
to check his slaves against this tool. Ask for the test report of this
tool for the particular slave you are using. This usually generates
"enough pressure" on the vendor to improve the slave...
Regards Wilhelm.
_______________________________________________
etherlab-users mailing list
<A HREF="mailto:etherlab-users@etherlab.org">etherlab-users@etherlab.org</A>
<A HREF="http://lists.etherlab.org/mailman/listinfo/etherlab-users">http://lists.etherlab.org/mailman/listinfo/etherlab-users</A>
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>