Interesting bug with shared modules in RW6.08

barrettsmithbb

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.

Maxim Riabichev

Hello,

Edit: As lemster68 pointed out in a post below, this is not a bug.

lemster68

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. 

Maxim Riabichev

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"?

lemster68

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.

lemster68

I should also add that the Rapid Overview is useful, as well.

barrettsmithbb

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

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.

barrettsmithbb

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.

xerim

barrettsmithbb said:

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