Interesting bug with shared modules in RW6.08

I have been trying to figure out why my shared module programs often get the error:

40330 Task: TASKSHARED. Module (line/column): SysGlobalFunc 67 5 . There is an error with symbol: ESCAPEMENT.

I have many other programs which which use shared modules (go check them out they are super useful) and this problem stumped me for a while.

Essentially, my system has 3 Tasks and is a multi-task system:
T_ROB1 (TASK1)
Escapement (TASK2)
Background (TASK3)

And I have two shared modules SysGlobalFunc And SysMessages.  Basically, they exist to serve messages and other common data to other tasks.

I would get the error 40330 when trying to install "SysGlobalFunc".  I could get rid of the error by commenting out like 67.  But that leaves me without the variable which I commented out.
MODULE SysGlobalFunc(SYSMODULE)
...
!CONST string ESCAPEMENT:="ESCAPEMENT";
Seems relatively benign, I couldn't figure it out.  So I uncommented out other variables, but no issue.  So I changed the offending variable to:

MODULE SysGlobalFunc(SYSMODULE)
...
CONST string NOT_ESCAPEMENT:="ESCAPEMENT";

THAT FIXED IT!!

Apparently, this bug is that you cannot have a string with the same name as a TASK.  I couldn't find any documentation in the Kernel on reserved words or having a variable with the same name as a other portion of the program.

Comments

  • Maxim Riabichev
    Maxim Riabichev Sweden admin
    edited February 2
    Hello,

    Edit: As lemster68 pointed out in a post below, this is not a bug.
    Post edited by Maxim Riabichev on

    Maxim Riabichev
    PC Software Support Engineer
  • lemster68
    lemster68 United States ✭✭✭
    This is neither a bug nor does it have to do with built in shared modules.  It is simply the "rules" of the rapid language.  You may not have a module name the same as a data declaration name, or a routine named the same as a module name.  The symbols are then ambiguous, does not compute.  The same will apply for the name of a task. 
    Lee Justice
  • Thanks for clearing that up @lemster68! It makes sense.

    Do you know if these "rules" are written down somewhere, or is this something one has to realize because "it makes sense"? :)

    Maxim Riabichev
    PC Software Support Engineer
  • lemster68
    lemster68 United States ✭✭✭
    You are welcome Maxim.  The rapid kernel manual gives some guidance, but I think that in this specific case it is not quite so clear.  Years of experience help, part of which is making mistakes like that or near enough.
    Lee Justice
  • lemster68
    lemster68 United States ✭✭✭
    I should also add that the Rapid Overview is useful, as well.
    Lee Justice
  • I still believe it is a bug, because even though I agree that this should be in the rules.  The Rapid Kernel manual is silent on the issue.

    And as a point, I can have the variable anywhere in the program with the same name of the task.  No errors occur.  But as soon as I have it in a shared module, I get the error.
  • lemster68
    lemster68 United States ✭✭✭
    I tested briefly in RS, it did not like it at all when I made a string variable named the same as the module name.  The same when I made a routine with same name as the module.  Did not go so far as to create another task, though, so I will not argue that.  Like I said, just a brief test.
    Lee Justice
  • I tried it on my real controller and having a CONT string Your_task_name produced no errors.  I haven't tried making a string the same name as a module however.
  • I still believe it is a bug, because even though I agree that this should be in the rules.  The Rapid Kernel manual is silent on the issue.

    And as a point, I can have the variable anywhere in the program with the same name of the task.  No errors occur.  But as soon as I have it in a shared module, I get the error.
    From the Technical Reference Manual - Rapid Kernel