There are actually several ways to configure
the Wedge to correctly parse both records in the above example. The most elegant method is
to use the "Pre-Input Character Translation Table" to modify the delimiters so
that they are all the same. For example, we could translate all asterisks to commas to end
up with the two records shown below:
Sample#1,,213,,32,,,,23,,<CrLf>
Sample#2,,215,,437,,141,,797,,89,,56<CrLf>
Now both records obviously have multiple, delimited, data
fields with a carriage return-linefeed signaling the end of each record. We now determine
the maximum number of fields in a record by adding up the number of delimiters in each
record and adding one. (i.e. the first record has 11 fields and the second record has 13
fields therefore the maximum number of data fields is 13).
Now, when you define the record structure in the Software
Wedge you would select "Any Character Received" as the Start Of Record Event and
"Carriage Return or CrLf Received" as the End Of Record Event and for the
Record Structure you would choose "Multiple Delimited Data Fields" and
specify that the maximum number of data fields per record is 13 with a comma delimiter
separating each field.
When parsing records with multiple delimited data fields,
if you choose a space character as your delimiter, then consecutive spaces would be
treated as a single delimiter. Therefore, in the above example, if instead of translating
asterisks to commas, you were to translate both commas and asterisks to spaces, and
then you chose the space character as your delimiter, you would effectively end up with
the two records shown below with each field now separated by a single (space) delimiter:
Sample#1 213 32 23 <CrLf>
Sample#2 215 437 141 797 89 56<CrLf>
Suppose you had a device that normally sent its output to a
serial printer in the following manner with more than one line of data:
Device# Height Width Length <CrLf>
---------------------------------------------------------
<CrLf>
1 23 12 24 <CrLf>
2 27 13 8 <CrLf>
3 27 13 9 <CrLf>
4 27 13 8 <CrLf>
---------------------------------------------------------
<CrLf>
<FF>
(<CrLf> represents a carriage return-linefeed and
<FF> represents the form feed character)
You can still think of the entire output shown above as a
single record even though it contains several lines of data or you can think of each
individual line as a complete record. (In fact, you could even think of each word or
number outputted from the device as a complete, single field, data record).
Again, there are hundreds of different ways to parse the
entire output from the device using the different features available in the Software
Wedge.
If you wanted to capture only the lines with numeric data and parse each
of these lines
into records with four fields, one way to accomplish this would be to specify
the "Start Of Record Event" as "Numeric Character Received" and then
specify the "End Of Record Event" as "Carriage Return or CrLf
Received". Finally you would define the record structure as "Multiple Delimited
Data Fields" with four fields per record and a space as the delimiter character.
Because you chose "Numeric Character Received" as the "Start Of Record
Event" and because there are no numeric characters in the first, second,
seventh and
eighth lines of data, these lines would be ignored.
If you wanted to capture the numeric data as above but with
all 16 numbers in one record, you could again specify the "Start Of Record
Event" as "Numeric Character Received" and then specify the "End Of
Record Event" as "Special Character Received" and select the Dash
("-") character as the special character . Next, using the Pre-Input
Character Translation Table, you would translate all carriage returns and linefeeds to
spaces and finally you would define the record structure as "Multiple Delimited Data
Fields" with 16 fields per record and the space character as the delimiter.
Once you understand all of the features provided in the
Wedge, you can get very creative with how you deal with the data from your
instruments.
The important points to remember are that the Wedge always
waits until the selected "Start Of Record Event" occurs before it starts reading
in any data after which it keeps reading in characters until the specified "End Of
Record Event" occurs. When the "End Of Record Event" occurs, the Wedge
takes the data record that it just received and parses it according to the definition of
the Record Structure that you selected (i.e. Single Field, Multiple Delimited Fields or
Multiple Fixed Length Fields). For each field that you have defined, the Wedge applies the
chosen field Filter, Math Function and Format Expression. Finally the Wedge passes each
field to the target application in sequence sending each field followed by the field's
"Postamble" that you defined.
In many cases you could define the structure of your input
data in many different ways. For example if your device transmitted the following data in
bursts with some time between bursts, you could define the "End Of Record Event"
as either "Carriage Return or CrLf Received" or as "Time Delay Between
Records".
1, 23,12,24<CrLf>
2,27 ,13,8<CrLf>
3,27,13,9<CrLf>
If you specified "Carriage Return or CrLf
Received" as the "End Of Record Event" then the Wedge would see the data as
three records with four fields per record.
If you specified "Time Delay Between Records" and
also used the "Pre-Input Translation Table" to translate carriage returns to
commas and linefeeds to "Nul" or "Ignore", then the data would appear
to the Wedge as follows:
1, 23,12,24,2,27,13,83,27,13,9
In other words you can think of the original data above as
either three records containing four fields each or as a single record with 12 fields.
Again, as long as you understand the data from your serial
device and have a clear understanding of the full capabilities of the Software Wedge, you
can transform almost any serial data collection problem into an extremely simple task.
|
