Search string without split

[Jason Stallard]

Is there a way to search a string and find an offset without splitting the string? My problem is this: I'm doing serial communications on two different ports while also doing I/O, TCP, and file writes. The frame must run inside of 1 second, and I'm pushing 900msec with some message drop-offs. I'm afraind that the match pattern and search/split vi's are taking too much overhead doing all the string manipulation. I do not need to maintain a buffer, so I simply read the serial port, and search through for the information I need. The primary port averages around 2300bytes worth of string data, non terminated/non deliminated, so I must search for Start Of Frame patterns and count offsets from there. Like I said, I do not need to split or cop
y the string in any fashin, simply find the data contained within a 19byte message, and covert to deciman values.

Any suggestions on how to speed up the string searches?

[Mads]

Have you checked what's taking time?

A search using match pattern through a 2300 byte string is very fast, it only takes a few microseconds.

Could you post a picture of the code, or the code itself?

[Greg_McKaskle2]

> Any suggestions on how to speed up the string searches?

The Match Pattern returns the string subset that matched the expression
as well as the string before and after if you request it. It sounds
like you are then splitting up the string and looping again to search
the next portion for the next piece of data. It is typically much
faster to use the offset integer on the bottom of the Match to indicate
where to start searching, and the output integer can be fed back around
using a shift register as the next place to start searching -- until
your offset is to the end of the string or -1. This will avoid memory
management, if that is actually what the problem is. The other post
that indicated you should determine if this is what is slow was a good

one. Either time individual parts of the diagram, or use the profiler.

Greg McKaskle

[Joel_Mulig]

Here is another example of searching a string without using the match pattern or search/split string. Here, I search the string by converting strings to binary and returns the offset. Good luck!

The following data performed through VI profile:

String Size: 404KB
String Length: 401170
Return Offset: 401170
Total Exec Time: 15.6ms

[Jason Stallard]

Here's a piece of what I'm doing. The target is a cFP-2020RT controller. This subvi searches through a string, from a CAN converter which is read off a serial port, for J-1939 public broadcast messages.

Unfortunately I haven't had much luck getting the profiler to give me usefull information...not sure why.

The vi is in LV7 format

[Mads]

Greg was on the right track here; instead of keeping the buffer data constant, just extracting what you want and keeping the offset(s) in a shift register you rebuild the whole buffer in every case. My guess is that if you get rid of the concatinations you'll be fine. When you find the part you are looking for, just use the substring function to extract the part, and just wire the offset from the search to a shift register to be used as a start offset for the next search.

If you have a string sample we can use to test the code and optimize it that would be great, if not I'll make a simulated string later.

Mads

[Jason Stallard]

I revised the vi's so they do not concat strings, nor do they take the split strings from search/split. I take offset for the start of the message (010304), add to it to find the data byte(s). Use string subset to get the 2or4 bytes, then convert to a value. This seems to have had a negligible improvement.

I set the string control in publicdata.vi to a default value wich is the serial buffer for one frame itteration..~=2500 bytes worth of hex string. The public data is broadcast at varying intervals, so I can't rely on it being in the buffer in any particular order. The secon vi process a company protocol which is a request/reply scheme, so it should be in order of request(the default string provided has 42 reques
ts in it). The converter acks each request sent with 010204007, so this can be ignored. Each data message begins with 010304, is 19bytes long, the last byte being a checksum...so bytes 11-18 are the actual payload, everything else is converter/protocol overhead.

Any insight is greatly appreciated!

[Mads]

I ran the public data VI with the buffer contents you had included as default value. To allow it to write results to the publicIn VI I scaled it large enough to hold the maximum index accessed. I then timed the execution time; 0,16 ms. So the problem does not seem to be that VI..and I assume that's where you suspected it to be, or? There might be something in the above test procedure that differs from how you use it, but what? I'm on an old Pentium III 600 MHz here, running Win98.

In the other VI (which does not seem to be slow either) you have an array called ERPTCANInfo, how large is that array?

[Jason Stallard]

The target is an NI cFP2020-RT controller. I believe it only has a 486 processor. The ERPTCANInfo array is 42 elements with what I provided...it is filled via an ini file at startup. I'm attaching the main VI to give you a bigger picture.

Again thanx for the help