Kuka Found mismatched set of tokens.

    • New

    KRC2? What KSS version?

    KRC4? What KSS version?

    The IMPORT commands are, as far as I know, no longer used under KSS 8.x. They weren't used under KSS 5.x either, but were tolerated as a holdover from old KRC1 programs from KSS 2.x, to the best of my knowledge.

    The purpose IMPORT once served is now handled by using GLOBAL Declarations.

    • New
    Quote from Ryno

    Can you tell me how to create a program correctly without using the import function?

    You will need to make a list of every item the old program is IMPORTing. In the screenshots you provided, it appears to only be variables, but IMPORTing subroutines and functions was also done.

    For variables, the simplest way to make them Global is to DECL them in the module $CONFIG.DAT. Any variable DECL'd in CONFIG.DAT is inherently Global, dating back to the earliest versions of KSS.

    However, tampering with $CONFIG.DAT, while legal, is not the best way to do things. An alternate method would be to create a new .DAT file, DEF'd with the PUBLIC keyword, then DECL GLOBAL each variable. This is part of the KUKA ConveyorGlobals .DAT file as an example:

    Every variable in a PUBLIC .DAT file that is DECL GLOBAL becomes Global across the entire KRC, available to any routine in any module.

    HOWEVER: this creates the potential to have "local" variables and Global variables that have the same name. This usually creates a Warning in WorkVisual, but does not generate a compilation error. So it is your responsibility to ensure no name collisions occur.

    • New
    Quote from SkyeFire

    You will need to make a list of every item the old program is IMPORTing. In the screenshots you provided, it appears to only be variables, but IMPORTing subroutines and functions was also done.

    For variables, the simplest way to make them Global is to DECL them in the module $CONFIG.DAT. Any variable DECL'd in CONFIG.DAT is inherently Global, dating back to the earliest versions of KSS.

    However, tampering with $CONFIG.DAT, while legal, is not the best way to do things. An alternate method would be to create a new .DAT file, DEF'd with the PUBLIC keyword, then DECL GLOBAL each variable. This is part of the KUKA ConveyorGlobals .DAT file as an example:

    Every variable in a PUBLIC .DAT file that is DECL GLOBAL becomes Global across the entire KRC, available to any routine in any module.

    HOWEVER: this creates the potential to have "local" variables and Global variables that have the same name. This usually creates a Warning in WorkVisual, but does not generate a compilation error. So it is your responsibility to ensure no name collisions occur.

    Thank you so much for your reply! Tomorrow I'll try to do as you said.

    • New
    Quote from SkyeFire

    You will need to make a list of every item the old program is IMPORTing. In the screenshots you provided, it appears to only be variables, but IMPORTing subroutines and functions was also done.

    For variables, the simplest way to make them Global is to DECL them in the module $CONFIG.DAT. Any variable DECL'd in CONFIG.DAT is inherently Global, dating back to the earliest versions of KSS.

    However, tampering with $CONFIG.DAT, while legal, is not the best way to do things. An alternate method would be to create a new .DAT file, DEF'd with the PUBLIC keyword, then DECL GLOBAL each variable. This is part of the KUKA ConveyorGlobals .DAT file as an example:

    Every variable in a PUBLIC .DAT file that is DECL GLOBAL becomes Global across the entire KRC, available to any routine in any module.

    HOWEVER: this creates the potential to have "local" variables and Global variables that have the same name. This usually creates a Warning in WorkVisual, but does not generate a compilation error. So it is your responsibility to ensure no name collisions occur.

    The main program uses a subroutine in which these problem points are used. It is quite clear to me how to register them in the main program.

Advertising from our partners