Netlinx System Log Error Messages

TurnipTruck

Greetings,

Can anyone point me to a list of what the log messages mean from the System file tab?

I've been getting:

20: 08-28-2005 SUN 01:13:33 Interpreter Ref Error ^CTICKER_MESSAGE Tk=0x0000

CTICKER MESSAGE is a char array set as a buffer for receiving data from a pager-type data receiver.

Thanks.

Reese Jacobs

Netlinx System Log Error Messages

I have never seen any documentation that would shed light on the meaning of the interpreter error messages or many of the log file informational messages that appear from time to time. In your case, this error is most always caused by an out-of-bounds array reference - generally using an index of 0 or an index value larger than the size of the array to reference an element of the array.

I really wish the interpreter would identify the module and line number where the error occurs to help pinpoint problems like this one. Perhaps this is hard to do given how module code sections are handled when the token file is created.

cwpartridge

Reese Jacobs wrote:

I really wish the interpreter would identify the module and line number where the error occurs to help pinpoint problems like this one. Perhaps this is hard to do given how module code sections are handled when the token file is created.

If you compile with debug info (NetLinx Studio -> Settings -> Preferences -> NetLinx Compiler -> Options -> Compile with Debug Info), the interpreter will try and locate the reference error line location and place that information in the error message.

As for this particular error, a token value of 0 is invalid, and that triggered the error. Afraid I can't offer an explanation on the cause without seeing the code, which of course you need the line info to know where the problem is located.

As for documentation for the error messages, there are literally several thousands of messages in the code. It is a logistic issue in getting them documented and putting an easily understood explanation that is relevant for someone that does not have knowledge of the inner working of the master. It's just something we have never gotten around to doing.

HTH,

Chuck

Spire_Jeff

I think what Reese is refering to is the following:

Line    605 :: CIpLibrary::Atoi - Error - 15:17:27
Line    606 :: Library Call error on Line 134 - 15:17:27

I do have debug enabled, but which line of code is really line 134?

I vaguely recall having this problem before and as I recall had a tough time tracking down the violating code. It would be nice if we could somehow have a way to cross reference the compiled code line # to the code as it is within include files and modules. I'm not sure how difficult this request is or if it is already possible.

Along the same lines, is there a way to break on error when in debug mode?

Thanks,
Jeff

Reese Jacobs

Netlinx System Log Error Messages

Jeff,

Exactly -- I have found that even with debug compiled into the token file that the line number information leaves a lot to be desired. You then have to check all of your modules to see which statement might be the offending one. I do not use a lot of system calls or include files for code but I can imagine they cause the same (if not worse) problem as you pointed out in your example. I can generally narrow down the problem to a handful of modules since you are looking for modules that have code sections (events, calls, subroutines, startup, or program) in common. Most of the time it is fairly obvious but not always.

The problem is exacerbated by modules for which we do not have access to the source code (AMX and vendor supplied modules). This generally requires calling Tech Support once you have eliminated all of the other possibilities to see if they can locate a copy of the module source and check it out.

Now, I realize that if I wrote perfect code then ....

Reese

DHawthorne

It's a complete nightmare if you use a lot of modules and/or include files - both practices I rely on heavily to organize projects. You simply can't depend on the line numbers in runtime messages in a complex code structure.

I have taken to making sure all my variables in a module have unique names, often with the module name as a part of them, so I can see when an assignment error is from a particular module. I've also started making sure that variables passed as a parameter to a module have a different name internally than the one declared in the passing code. Since modules internally distinguish there own variables from others by prepending the instance token, why doesn't the runtime error message also include this?

Include files are the other bugbear. It irriates the heck out of me to have to go check the length of all my includes, add them up and subtract from the error message line number to get the real error location. Of course, you have to allow for where in the calling file the include was inserted...it's a huge pain.

Then, of course, there is the issue where in even simple files, some lines seem to be attributed to adjacent code blocks, depending on the type of error or type of code block. This goes for highlights on compiler errors as well as runtime.