A: Open the port in binary mode (mode 3) instead of PakBus-enabled mode
(mode 0).
Q: Tests with an oscilloscope showed the sensor was responding quickly, but the
data were getting held up in the internals of the CR1000 somewhere for 30 ms or
so. Characters at the start of a response from a sensor, which come out in 5 ms,
were apparently not accessible by the program for 30 ms or so; in fact, no data
were in the serial buffer for 30 ms or so.
A: As a result of internal buffering in the CR1000 and / or external interfaces, data
may not appear in the serial port buffer for a period ranging up to 50 ms
(depending on the serial port being used). This should be kept in mind when
setting timeouts for the SerialIn() and SerialOut() instructions, or user-defined
timeouts in constructs using the SerialInChk() instruction.
Q: What are the termination conditions that will stop incoming data from being
stored?
A: Termination conditions:
• TerminationChar argument is received
• MaxNumChars argument is met
• TimeOut argument is exceeded
SerialIn() does NOT stop storing when a Null character (&h00) is received
(unless a NULL character is specified as the termination character). As a string
variable, a NULL character received will terminate the string, but nevertheless
characters after a NULL character will continue to be received into the variable
space until one of the termination conditions is met. These characters can later be
accessed with MoveBytes() if necessary.
Q: How can a variable populated by SerialIn() be used in more than one
sequence and still avoid using the variable in other sequences when it contains old
data?
A: A simple caution is that the destination variable should not be used in more
than one sequence to avoid using the variable when it contains old data.
However, this is not always possible and the root problem can be handled more
elegantly.
When data arrives independent from execution of the CRBasic program, such as
occurs with streaming data, measures must be taken to ensure that the incoming
data are updated in time for subsequent processes using that data. When the task
of writing data is separate from the task of reading data, you should control the
flow of data with deliberate control features such as the use of flags or a time-
stamped weigh point as can be obtained from a data table.
There is nothing unique about SerialIn() with regard to understanding how to
correctly write to and read from global variables using multiple sequences.
SerialIn() is writing into an array of characters. Many other instructions write
into an array of values (characters, floats, or longs), such as Move(),
MoveBytes(), GetVariables(), SerialInRecord(), SerialInBlock(). In all cases,
when writing to an array of values, it is important to understand what you are
reading, if you are reading it asynchronously, in other words reading it from some
other task that is polling for the data at the same time as it is being written,
whether that other task is some other machine reading the data, like LoggerNet, or
266