Program number transfer

    post content of the CELL.SRC. evaluation of the signals is done by P00.SRC and CELL() has loop and several calls to P00(). sometimes people mess with the structure and remove or swap the call lines without paying attention to parameters.

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

    Quote from panic mode

    post content of the CELL.SRC. evaluation of the signals is done by P00.SRC and CELL() has loop and several calls to P00(). sometimes people mess with the structure and remove or swap the call lines without paying attention to parameters.

    SCR module is not available in the KUKA system, so delete it.

    As shown in the figure, there is no CELL.SCR file under the R1 file.

    Quote from hermann

    - thread should be in Kuka section. :winking_face:

    - What is the question?

    Have you seen the diagram and explanations for auto extern signals in robot documentation?

    You can use the version from newer robots, as there are no changes since first generation.

    The HMI writes the program number. The program number has been written to the KUKA system, but the PGNO remains at 0.

    Only CELL.SRC uses PGNO. Why would someone write a different program that also uses PGNO? Is this an old Volkswagen or GM robot? If this robot is not using CELL.SRC, then the value of PGNO may be irrelevant. What program is this robot using in place of CELL? Post the actual code.

    Anyway, PGNO only gets set if CELL.SRC is running and calls P00. P00 can only set PGNO correctly if PGNO_FBIT, PGNO_TYPE, PGNO_LENGTH, PGNO_PARITY, have all been configured correctly, and the PLC receives PGNO_REQ correctly and responds with PGNO_VALID in the correct method.

    Quote from SkyeFire

    Only CELL.SRC uses PGNO. Why would someone write a different program that also uses PGNO? Is this an old Volkswagen or GM robot? If this robot is not using CELL.SRC, then the value of PGNO may be irrelevant. What program is this robot using in place of CELL? Post the actual code.

    Anyway, PGNO only gets set if CELL.SRC is running and calls P00. P00 can only set PGNO correctly if PGNO_FBIT, PGNO_TYPE, PGNO_LENGTH, PGNO_PARITY, have all been configured correctly, and the PLC receives PGNO_REQ correctly and responds with PGNO_VALID in the correct method.

    It's not VW welding, it's the old Mercedes welding robot, but it feels the same as the VW welding robot.

    Quote from SkyeFire

    Only CELL.SRC uses PGNO. Why would someone write a different program that also uses PGNO? Is this an old Volkswagen or GM robot? If this robot is not using CELL.SRC, then the value of PGNO may be irrelevant. What program is this robot using in place of CELL? Post the actual code.

    Anyway, PGNO only gets set if CELL.SRC is running and calls P00. P00 can only set PGNO correctly if PGNO_FBIT, PGNO_TYPE, PGNO_LENGTH, PGNO_PARITY, have all been configured correctly, and the PLC receives PGNO_REQ correctly and responds with PGNO_VALID in the correct method.

    I now suspect that PGNO_FBIT_REFL and REFLECT_PROG_NR are not high enough to understand, I set REFLECT_PROG_NR to 1 RKC2 system to submit directly to stop .

    The procedure inside the SPS is to activate the interrupt procedure INTERRUPT DECL 91 WHEN $PRO_STATE1==#P_FREE DO RESET_OUT ().

    $Out[SpsSubRun]=False This program is supposed to stop Submit.


    I tried to start Submit but there is a $OUT[1001] variable write protected in module SPS line 205.


    1001 is related to $ROB_CAL.

    Use code boxes.

    On a cursory examination, P00.SRC does not appear to be called. So we can probably ignore that module entirely, since none of its subroutines are DECL'd Globally.

    Mercedes appears to have substituted their own modified copy of P00 but called by the SPS, P00_SUBM. Which the SPS has multiple calls to.

    You provided no data on the setup of the various PGNO variables. But the message you listed in the first post only occurs at lines 176 and 205 of P00_SUBM. Line 176 only executes if PGNO_VALID is a negative number, and 205 if PGNO_VALID is a positive number.

    Going by your photo in post 4, PGNO_VALID is 3206, and the photo from Post 3 shows that Input 3206 is not coming on. So either your PLC is not sending that signal, or your IOSYS mapping is incorrect.

    Quote from jack123

    $Out[SpsSubRun]=False This program is supposed to stop Submit.

    That has nothing to do with Waiting for PGNO_VALID

    Quote from jack123

    I now suspect that PGNO_FBIT_REFL and REFLECT_PROG_NR are not high enough to understand, I set REFLECT_PROG_NR to 1 RKC2 system to submit directly to stop .

    What? That sentence made no sense. Regardless, the REFL signals are not related to the issue from the first post.

    Quote from jack123

    I tried to start Submit but there is a $OUT[1001] variable write protected in module SPS line 205.


    1001 is related to $ROB_CAL.

    This means that you have the REFL outputs conflicting with a system output. Your various PGNO variables need to be set correctly.

    Quote from SkyeFire

    Use code boxes.

    On a cursory examination, P00.SRC does not appear to be called. So we can probably ignore that module entirely, since none of its subroutines are DECL'd Globally.

    Mercedes appears to have substituted their own modified copy of P00 but called by the SPS, P00_SUBM. Which the SPS has multiple calls to.

    You provided no data on the setup of the various PGNO variables. But the message you listed in the first post only occurs at lines 176 and 205 of P00_SUBM. Line 176 only executes if PGNO_VALID is a negative number, and 205 if PGNO_VALID is a positive number.

    Going by your photo in post 4, PGNO_VALID is 3206, and the photo from Post 3 shows that Input 3206 is not coming on. So either your PLC is not sending that signal, or your IOSYS mapping is incorrect.

    Settings

Advertising from our partners