This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM3359 ICE EtherCAT OUT port will not scan with TwinCAT

Other Parts Discussed in Thread: AM3359

I am trying to connect a second EtherCAT device to the OUT port of the AM3359 ICE EtherCAT unmodified demo application, and TwinCAT cannot find any EtherCAT device I connect to it.  Is this a limitation of the present 1.0.0.3 release of the SDK, or is there some workaround to get other nodes to scan?

  • upon further investigation it seems to be a hot connect issue, the board needs a reset when a connection on the OUT port is changed.  This seems to be different behavior than the Beckhoff ET1100 devices.

  • Peter,

    yes, this is a known issue of current EtherCAT firmware. You can also enable the port using TwinCAT manually.

    Regards.

  • Frank,

    Thanks for the info!

    Was this limitation implied in the list of limitations in the release notes?  i.e. 'enhanced link detection' not supported?

    Also, as a non-expert in EtherCAT I find it hard to understand the implications of the release notes 'what is not supported' list, is there a more complete explanation somewhere about what the user may see as an actual consequence of the items mentioned?

     

    i.e. 'DC not supported' is clear to me,  but 'PDI side register permissions' or 'AL Event mask support', for example is mystifying as to whether I need to worry about that or not.

    Any elaboration on application level implications for this list of unsupported features would be greatly appreciated! 

    Also, can we reasonably expect that some of these WILL be supported 'soon'?  i.e. Process data LRW, is there a plan to implement that in a future release?

    thanks!

    from the release notes:

    What Is Not Supported

    • In general, peripherals or features not mentioned as part of "What is Supported" section are not supported

    • For EtherCAT Slave Controller, the following features are not supported in this release

    • Distributed Clocks (DC)

    • Enhanced Link detection

    • Redundancy

    • LRW for process data

    • PDI side register permissions

    • PDI side support for 16/32 bit access

    • AP/FP/BRW/LRW for SM mapped area

    • ECAT side register protection for LRD

    • AL Event mask support

  • Peter,

    no, I don't think that the link issue on OUT port was listed so far. We plan to release more elaborate info based on internal issue list with the next release.

    Overall our documentation assumes some knowledge of EtherCAT and the Beckhoff terminology. As our work is based on Beckhoff material we often re-use their terms too. You may also want to use the ETG support team for example through their online forum on www.ethercat.org.

    Of course we have a plan to work through the missing features. You may contact your TI field sales team or local distribution for details.

    Regards.

  • ok, thanks, it just wasnt clear to me whether the release notes are describing temporary limitations all of which will eventually be corrected, or hardware limitations that will remain in this platform, or some mix of both? 

    anyway, I would agree that the number of EtherCAT experts who understand the phrase: "AP/FP/BRW/LRW for SM mapped area not supported", let alone the implications, is a very small club indeed! 

     

  • Peter,

    I suggested to move the feature discussion to the ETG forum for the hope you would get more help of the experts there. Of course we do not assume every customer to be a full expert on EtherCAT. Same as with most TI people...

    Now I tried to answer to your post on the ETG forum as you didn't get any useful answer there yet. But for some odd reason I can't enter anything in the post reply section also I am fully logged in. So I will answer here...

    PDI is the process data interface from the host controller in our device (or in other words the stack). We currently use 8 bit mode to avoid alignment issues. 16/32 bit will improve performance in future. Obviously the stack can access PDO memory.

    Register protection is something implemented in the Beckhoff ASICs that will follow. E.g. that some regs are only readable from PDI side.

    Enhanced Link Detection is an optional feature too on the Beckhoff Asics. We plan to implement a similar scheme in future. Right now link detection is based on MDIO status and RX-Link signals only.

    The only hardware limitation currently is the redundacy support which is documented also in the silicon errata. That is why a new rev of the chip is planned. All the rest is planned to be fixed/added by software updates.

    Regards.

  • great, thanks very much for the info!

    Related question: should we expect that the 1.0.0.3 SDK EtherCAT stack on the ICE will pass the ETG conformance test?

  • Frank,

    Any idea as to when the next release of the chip with redundancy support is going to be released?

    Regards,

    Ignacio Velasco

  • When will the chips be available with a certified slave stack implementation?

    -Jaden


  • Jaden,

    the AM335x devices are production released. This is independent of any software we provide.

    If you refer to EtherCAT slave stack then we still plan to do conformance test at ETG labs in 3Q of this year. We could go their now and I am pretty sure we do pass conformance tests (we run the ETG conformance test tool on all releases). But we would like to wait until we are feature complete. If you need to go through certification at ETG earlier with your own product we can support that.

    Regards.

  • Frank,

    I just tested the TI Ethercat example of the 1.0.0.5 version of the SDK. The issue with the OUT port seems still to exist: A second Ethercat device (another ICE or also a Beckhoff EK 1100) connected to the OUT port of the ICE is not found again if the ethernet cable connenction is opened/reconnected or the device is switched off/on. It needs a reboot of the first ICE to get the second device recognized again.

    Is this the "Enhanced link detection" solved in 1.0.0.5?

    Regards

    Frank Moldenhauer

  • Dear Frank,

    no, this has nothing to do with enhanced link detection.

    Yes, we still see the issue that a port that got lost is shut off from register side. It needs a register write from the master to enable Port B again. I am not 100% sure if that only occurs with TwinCAT and if it is an issue on our side or not... For a recent demo we wrote code on TwinCAT that re-enables the second port from master if the number of slaves is not correct. This way we can restart a chain in any sequence.

    Maybe our EtherCAT developer will also send a comment on this.

    Regards.

  • Hallo Frank,

    thank you for your fast response to my question last Monday. Unfortunately, it didn't solve my problem, and I didn't get any other answer. Different to the ICE, e.g. Beckhoff EK 1100 modules always recognise reconnected modules on the OUT port without any (user) programming in TwinCAT. Will there be a fix in the PRUSS firmware? How to program the workaround in TwinCAT?

    In your mail from July the 3rd you mentioned a planned ETG conformance test in Q3 this year. Are there any news about that?

    We will show a prototype of out EtherCAT device with the AM 3359 at the SPS/IPC/Drives in Nuremberg next week. We intend to have a certified device in production in Q2 2013. Is this realistic from your point of view?

    Regards

    Frank M.

  • Frank,

    ok, I need to get back to our firmware team on this.

    The ETG certification tests were done and passed all technical items. We are not in conformance with ICE regarding some of the marking and marketing requirements but that was not the point of this test. We are still waiting for the official paper work from ETG as we were a bit late signing some contracts.

    Any future product should be based on AM335x PG 2.0 devices (they have the fix for the redundancy mode errata). Samples should be available now. Otherwise I see no issue with your date at the moment. But this is no official statement. Only officially released schedules and releases on the web should be used for your planning. Contact your TI sales or distri for more details. Or send me a private mail and we can setup the links.

    Regards.

  • Hi,

    I can confirm that this a firmware issue and will be fixed in next SDK update (1.0.0.6) planned for Mid December time frame. 

    For redundancy support : PG2.0 device is required along with 1.0.0.6 SDK . PG1.0 device can't receive frames on OUT port due to silicon bug and hence redundancy can not be supported.  

  • PratheeshGangadhar said:

    Hi,

    I can confirm that this a firmware issue and will be fixed in next SDK update (1.0.0.6) planned for Mid December time frame. 

    For redundancy support : PG2.0 device is required along with 1.0.0.6 SDK . PG1.0 device can't receive frames on OUT port due to silicon bug and hence redundancy can not be supported.  

    Hi PratheeshGangadhar, hi Frank,

    thank you for the information that the issue will be fixed in the firmware, so we don't need a workaround in the master and we can wait for the 1.0.0.6 release.

    Frank M.

  • Hi Frank:

     I use SDK 1.1.0.4 on ICE board (Slave) to test the EtherCAT functionality, Master selection TwinCAT (version V2.11.0), both connected can to control 8 LED

     I then connected in series one ICE board, while TwinCAT Scan Device will find two ICE Board, relative ID & Address is different, but I can only control a single ICE Board from TwinCAT
     
     Questions:
     1.Master send a packet to the EtherCAT Slave, first slave have to get, and will go down to the second packet transmission!?, Why test results are only one packet for a station ID??

     2.EtherCAT with ethernet packet is the same, there is an Ethernet frame header, EtherCAT head, EtherCAT data (about 1498 bytes), why SDK 1.1.0.4 receive 2Bytes information only once??

  • Hank,

    I suggest you open a new thread with a clear description of your system and the issues seen. From above I don't understand if you have one or two baords connected and what software they are running. You may also need to provide network captures. However I assume you have an issue with implementing your application and the accordingly required EtherCAT device description. That is an area where we can't help a lot. Our EtherCAT ESC is in use now for quite some time in many projects and we know it is working.

    Regards,