Interesting bug with shared modules in RW6.08

RAPID Programming
, , ,
1

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.

2

Hello,

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

3

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.

4

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”? :slight_smile:

5

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.

6

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

7

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.

8

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.

9

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.

10

From the Technical Reference Manual - Rapid Kernel

image.png
image.png729×401 50.6 KB