RobotStudio event

Changing DeviceNet master Adress (IRC5)

Options

Hi,

I changed my master DeviceNet. I will have 4 IRB340 with IRC5 on the line and I will also need the DN_SLAVE. I changed the adress of the Master from 2 to 30 and reboot. The problem is that the MS ligth on the DSCQ 377 (Queue Tracker) is flashing after rebooting (also after a power On-Off). The MS ligth on the DSQC 328 is solid GREEN. 

I ran some projects (e.g. Picking from the conveyor with no vision and a I/O, picking from Index to Index) and everything is fine. When I use a camera to locate the pick, the robot don't move and this ERROR happens:

error 4016

Description: A scene (item positions and scene information from a

robot controller) has been discarded because it was too old. Either

because of missing scene information or missing item positions.

When I put back the MasterAdress at 2, everything is fine...

Does someone knows what is wrong???

Thanks for you help!

Nick

Nick B.


Comments

  • claudio
    Options
    Hi Nick.

    I never used Dual DeviceNet on IRC5, but in my experience "30" is not a very good address for a master. Usually masters have addresses like 0,1,2 or 3.
    Probably you can reorganize your adresses or simply specify "30" for your slave and leave "2" for your master.
    Regarding the error 4016, I think the controller cannot communicate with the DSQC377. Flashing green light usually means "Good cabling, but no connection with master."
    Attach your EIO to the message to have more help.

    Bye
    Claudio

  • Hi Claudio,

    this his my EIO file:

    EIO_UNIT:

          -Name "Qtrack1" -UnitType "d377A" -Bus "DeviceNet1" -TrustLevel 0
          -DN_Address 10

          -Name "PPABOARD1" -UnitType "d327A" -Bus "DeviceNet1" -TrustLevel 0
          -DN_Address 11

          -Name "PPASIM" -UnitType "Virtual" -Bus "Virtual1"

          -Name "PLCDEVICENET" -UnitType "DN_SLAVE" -Bus "DeviceNet1" -DN_Address 6

    AND:

    EIO_BUS:

          -Name "Virtual1"

          -Name "DeviceNet1" -BusType "DNET" -ConnectorLabel "First DeviceNet"
          -DN_MasterAddress 6

    Like said in the book, my DN_SLAVE have the same adress has my Master..if I let the adress of both at 2...there is no problem, no flashing ligth. If I changed both at 6...I have the flashing ligth on the QueueTrack.

    In resume, I cannot change my Master adress at all. If I change it, I have a QueueCard flashing...

    Thanks for your help!

     

    Nick B.


  • claudio
    Options
    Hi

    I don't think I can help more.
    Craigp started another thread with more or less the same topic.
    He's using the Second Devicenet bus. I wonder if you can use the First DeviceNet for local boards (as you're doing) and Second Devicenet for PLC connection.
    Maybe you can join that thread and ask there.

    Best Regards.
    Good Luck

    Claudio

  • I can add to this thread from painful experience I had with Conveyor Tracking, the 377A module and changing a DeviceNet scanner address. 

    Basically, don't do it.  Keep the scanner at the default address or you will have trouble with the 377A module even though you should be able to change to an unused address. After installing and configuring Conveyor Tracking and watching it work, I later changed from the system defaults for the two Scanner/Adapter channels because I wanted to use a "typical" node address for the scanner (like 1 or 0) and I first checked to be sure no other device was using that Node #.

    After changing the addresses I lost some of the functionality on the 377A (Qtrack1 in your EIO file).  I could still add items to the tracking queue, increment their X position on the conveyor, and remove them from the queue again after they passed out of the queue tracking window, but I could never get Conveyor Tracking to "attach" a work object. 

    I spent quite a lot of time trying to decide what was wrong with Conveyor Tracking, and then an ABB engineer came and spent two days, also without result, trying to troubleshoot this problem.  In all, at least 12 different ABB engineers in the USA and Germany looked at emailed versions of the RAPID and config files.  Noone could find anything wrong.

    Normally when a DeviceNet scanner cannot properly communicate with a slave device the scanner exhibits a clue as to what the problem is by way of it's (generally) two LED's that show connection/network health and attached device configured/functioning OK.   In this case the Scanner is dumb and happy showing two solid green LED's.  As mentioned above in another reply the clue is that inside the 377A module one of the two LED's is blinking green (yes means can't correctly connect to the Scanner).  BTW - It's not very easy to see the blinking LED or to see what LED it is.  When we noticed it and went back to original default address for the scanner it started working again.

    I've spoken to several people at ABB about this issue and so far everyone voices the opinion that this ABB implementation of DeviceNet is vanilla (follows the spec's) but I personally believe that somewhere in the application code or the firmware of the 377A module or the Conveyor Tracking software lurks an ugly assumption:  That you will leave the Scanner configured at it's default Node Address or you will suffer.  If so, it's not a DeviceNet implementation which works like DeviceNet should.  If you cannot change this address and correctly function, then please please please make it impossible to change this address at all! 

     

  • labu
    Options

    The issue is with the TimeKeeper, As reported in the PickMaster forum. The DN is OK but the tracking board is looking for the wrong clock...

    We got the same unexplained issue until we got it solved...

    -----------Extract from PickMaster Forum----------

    Thank you but I found the problem...We have to change some parameters on Queue Track Card Signal..


    Eio.cfg
    -Name "TimeKeeperInit" -UnitType "d377A" -DefValue "2" -OrderNr 1
    -DN_Path "6,20 68 24 01 30 01,C1,1" -DN_Service 16

    Thank you for your Help

    Nick