• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 101 subscribers
  • Views 550 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

[ProfiNET on ICEv2] Board failure?

Philipp L.
Intellectual 795 points

Hello dear e2e community,

I set up a Siemens S7 PLC and Touchpanel, to communicate with a ICEv2 Sitara Board. After some problems at first, it then really worked smoothly, and I could send some bytes between my PLC and the sitara, boot from SD-card etc. Very nice so far...

Then, I tried to add SPI communication to the ICEv2, and also had some success. But somewhere in the procedure, I misplaced my connector and killed the ICEv2-Board and the other processor I was doing SPI with - because directly next to the SPI-Pins on the SPI-expansion connector there is also 24V. The ICEv2-Board just blinked wildly and I pulled the plug. After this, it would not boot again, so first question: Do you have any idea if I could fix this?

But, I had a spare board (also ICEv2, exactly the same as the first one), and I thought I could just put my SD-card into it and it would work again. Sadly, not really. It does boot from the SD-card, and prints my messages on the UART console, and also prints my message on the OLED-Display. But, ProfiNET does not work. My PLC cannot find the ICEv2-Board. 

And this is really strange: When connecting components via ProfiNET, every device has two ProfiNET-ports. So, I can connect them like this:

1.: computer -- PLC -- ICEv2 -- Touchpanel

or like this:

2.: computer -- PLC -- Touchpanel -- ICEv2

When using 1., not even the PLC and Touchpanel can communicate - that means, there is absolutely no ProfiNET-Operation going on on the ICEv2, because not even the "routing-through-functionality" works.

So, now here come my questions: How is it possible, that I have one SD-card with a program on it, which worked on the one board, but not on the other one? (all jumpers on the board checked)

Do I perhaps need to copy some binary into the PRU-processors before they work? (But I cant remember that I have done something like this on my first board..)

Or is the most likely possibility that my second board is somehow broken on the ethernet-functionality? But, everything else like normal SYS/BIOS operation, UART-console, bootloader, SPI, ... works fine on it.

I used the most recent SYS/BIOS-Industrial-SDK with CCS 5.5. I used the profinet-slave-example and only changed some little things like UART-Messages. But I really think this can't be the problem because I had the very same configuration on my first board, which worked really good - until I killed it...

Please help me with this! Thank you very much,

Philipp

  • 0
    TI__Expert 7360 points

    Hello Philipp,

    The same SD card binary should work with both the boards(unless like you mentioned the ethernet functionality is broken on the second board). I believe there is some re-configuration to be done on the PLC(MAC address change?), is this done?

    Regards,
    Vinesh

  • 0 in reply to Vinesh Balan
    TI__Prodigy 710 points

    Hi Philipp,

    Also check that the name you have assigned to the node (ICEv2) matches with the name configured in the PLC program for ICEv2. One more thing to check is IP address. If still you face issues then please provide us a network capture so that we can analyze it further.

    To check that Ethernet ports are working correctly you can just connect it directly to a computer. Then see if you are able to ping the board. Try it on both the Ethernet ports of the board. 

    Regards,

    Robin

     

     

  • 0 in reply to Robin Singh88140
    Intellectual 795 points

    Hey guys,

    I got this one solved. I was able to get my hands on a third board, which worked (kind of) out of the box with my application from SDcard.

    As I found out then, my first guess was right - the ethernet functionality on the second board is somehow broken. Using a crossover-cable I could not even ping the second board, which was possible with the third one.

    Of course I still had to assign the new MAC adress to the PLC, but even without doing this, it has to be possible to let the PLC discover all participants of the bus. 

    So, thanks for your quick help, with your ping idea I was able to be sure that the one board really is broken.

    Do you know if this happens to the ICEv2-boards frequently?

    Philipp

  • 0 in reply to Philipp L.
    TI__Expert 7360 points

    Philipp,

    Just to make sure, are the jumper setting done properly to select the ICSS mode?

    Regards,
    Vinesh

  • 0 in reply to Philipp L.
    TI__Mastermind 44306 points

    Philipp,

    Philipp L. said:
    Do you know if this happens to the ICEv2-boards frequently?

    No, actually the boards are quite stable... Our team mainly uses ICE boards and we sometimes have 5-10 running in long term tests over days. We have occasional faults but that is due to bad handling in most cases. As we made the boards industry compatible they carry 24V on some of the extension headers and shorts are usually deadly here. Also EMV is always an issue in an office environment... we recommend to only use them in labs with accordingly suited benches and anti-static protection.

    Still I would not recommend to use the boards designed for evaluation and software development in a production environment. But that should be clear anyway.

    regards,