Profibus connection between festo CPX-FB13 and KUKA

    With my team were currently busy with trying to establish a profibus connection between our KUKA robot with KR2C controller and a CPX-FB13 pneumatic terminal. We have made the connection between the two without any error messages, however the terminal isn't changing the pneumatic 5/3 switches when we give output signals.


    We have declared the slave outputs as such in the iosys.ini file:


    Code
    [PBMASL]
;slave outputs
;OUTB0=3,0,x2 $OUT[1-16]
;OUTB2=4,0,x2 $OUT[17-32]
;OUTB4=4,0,x2 $OUT[33-64]
OUTB0=5,1,x1 ;$OUT[9-16]
OUTB1=5,2,x1 ;$OUT[17-24]


    Are these deleractions correct and is there something that we might be overlooking?


    Thank you in advance for your time and effort


    greetings


    MA

    Post your PFBMS.INI


    How many bytes of Input and Output does the CPX have? Does the CPX have power? Remember that many of these devices have separate power supplied for communications and for energizing the outputs.

    first of all thankyou for your reply. This is our PFBMS.INI, the power should be connected correctly but were going to double check them.


    Update: We have checked the power supply and it is correclty installed

    Edited once, last by martenH ().

    Hmm... nothing obviously wrong there. What do the contents of log/Profibus2015.log show? Also, what shows up in IOSYS.LOG?


    You're using PB address 5 for the CPX device, correct? Why do you have DEACTIVATED_SLAVES=3? What is device 3?


    Try setting WATCHDOG_TIME to 3 instead of 0.

    This is what Profibus2015 says:

    This is what iosys.log says:

    We used: DEACTIVATED_SLAVES=3 to test something to see for making a profibus connection however this is now changed into 0.


    We have changed: WATCHDOG_TIME however this sadly didnt change anything for the program.

    Again, no obvious smoking guns.


    This still leaves my earlier question: how many bytes of I/O does the CPX device have? You'll need to check the factory documentation. Some devices have the first few bytes taken by configuration signals, you might be firing your valve outputs into that memory area.


    In fact...

    Quote from martenH

    OUTB0=5,1,x1 ;$OUT[9-16]
    OUTB1=5,2,x1 ;$OUT[17-24]

    This might be the issue. Have you tried 5,0?

    the CPX uses 16 bytes and it uses them with status bits... We have tried 5,0 and that also didnt do anything. We also just called with FESTO the producer of the CPX and they said that everything is declared correctly in TIA portal. So it should be a software thing but what it is, is unclear.

    Hm... well, the brute force method would be this:

    1. Change IOSYS.INI to OUTB0=5,0,x16

    2. Write a program as follows:

    Code
     DECL INT _nIndex

 FOR _nIndex = 1 TO 128
   PULSE ($OUT[_nIndex], TRUE, 0.25) ; pulse for 1/4 second
   WAIT FOR NOT $OUT[_nIndex] ; wait for pulse complete
 ENDFOR

    Run that, and see what happens. This will basically pulse every bit that the CPX can receive. If none of them fires a valve output, then there's something really strange going on.

    We have found the problem, a previous programmer had allready used the outputs so they were double declared once the old code was removed it worked as programmed. Still thanks for all your help with this problem!

    That explains it. Even if the signal were DECL'd with two different names, it would only be constantly set/reset by SPS code, or if it were set up as a SYS signal (like $PRO_ACT or $PRO_MOVE or another auto-external signal), and double-DECLing a SYS signal would have generated an explicit error message.

Advertising from our partners