User's Manual

NodeBuilder Errors Guide 5-5
NCC# Description
19 Extra entries in preprocessor directive [NCC#19]
This error indicates that, although the preprocessor directive was of
the correct syntax, there are additional entries on the line that were
not part of the directive.
20 Empty input source file
Check for the existence of the file that is being compiled. Is the file
name and path name correct?
21 Unexpected END-OF-FILE in source file [NCC#21]
An incomplete source construct unexpectedly ended in an end-of-file
condition. This may indicate mismatched brace characters { and } or
may indicate the use of a function macro with an insufficient number
of right (ending) parentheses.
22 Repeated keyword was ignored [NCC#22]
The keyword const or volatile is used more than once in
modification of a pointer type.
23
24
Not enough address table entries [NCC#23] (See NCC#24)
Not enough address table entries for optimum efficiency
[NCC#24]
A Neuron Chip has up to 15 outgoing message ports. (Ports are also
known as “address table entries.”) Each bindable message tag
consumes one port, whether bound or not. Network variables can
share ports, but there must be at least one port available.
If there aren’t enough address table entries for all the message tags
plus at least one for network variables, you get the error [NCC#23].
However, if there aren’t enough entries available for each output
network variable to have its own port, you get the warning [NCC#24]
(unless you already have the maximum number of address table
entries in your program). This is because the binder would then
have to share the remaining address table entries among the
network variables.
EXAMPLE: If there are three network variables (each going to a
different destination) and there are only two address table entries,
then at least two of the network variables would have to use the
same address table entry (if they are all connected). Now let’s
assume that all the variables are connected, each point-to-point to a
different node. If each variable had its own address table entry, the
LonTalk messages would all use subnet/node (i.e. point-to-point)
addressing.
However, for the two variables sharing the same entry, a group will
be constructed. This means that, when either variable is updated,
the updates will go to all members in the group. This does not
necessarily cause a problem, as the nodes that don’t have the
variable will discard the update. The major inefficiency the compiler
is warning about, though, is that each destination in the group,
regardless of whether it uses the message, will respond with an
acknowledgment message. This situation thus leads to increased
unnecessary acknowledgements, or other extra network traffic.