Parsing inbound strings with delimiters


Recommended Posts

very, very simple task - take inbound data coming in on a com port, parse various things out of the string, display the parsed output...

Here's the code:

global string datain = ""
global string site = ""
global string date = ""
global string time = ""
global string chan = ""
global string val = ""


      datain = ""
      datain = device.COM5.ReadUntil(10)
      site = parse(datain,0,"@")
      date = parse(datain,1,"@")
      time = parse(datain,2,"@")
      chan = parse(datain,3,"@")
      val = parse(datain,4,"@")

      ?"Datain: " + datain
      ?"Site: " + site
      ?"Date: " + date
      ?"Time: " + time
      ?"Channel: " + chan
      ?"Reading: " + val

I'm using global variables just so I can access them from the command alert window for testing - they'll normally be private variables - just FYI.

example of an inbound string:

TEST UNIT@11/06/08@21:00:25@ A1@     16.94/013/010
(pay no attention to the wrong direction slashes on the line termination
characters - the board apparently doesn't like backslashes in posts...)

The issue is this - I see the deata coming in on Com 5 just fine in both the direct port monitor and the docking window. The "datain" string gets stored, but then the parse commands don't actually seem to be parsing and I can't figure out why.

I've also tried the codee this way:

      datain = parse((device.COM5.ReadUntil(10)),-1,"@")
      site = datain[0]
      date = datain[1]
      time = datain[2]
      chan = datain[3]
      val = datain[4]

and in this case, when I display datain, which should be an array, all I get back is the raw string as opposed to something more like {"TEST UNIT","11/06/08","21:00:25", etc...}), thus I have no array to go through in the subsequent calls.

I'm clearly missing something simple - and after you stare at code for hours, you go a little funny in the eyes, so I'm sure it's an obvious and simple error.


Link to comment
Share on other sites

This is because DAQFactory's multi-lingual features are getting in the way. The @ sign as the first character of a string means that you want the string to be translatable and the @ is stripped. As it explains in the manual under creating multilingual apps, to create a string that starts with @, you must put to @@ signs.

Also, you might look into the parse() function passing -1 as the index. It returns an array of strings which is faster than parsing 5 times.

(Am I really that picky on these forums that you defend all the little things like global vs private and the / vs \? :) )

Link to comment
Share on other sites

OK, educate me on the following method:

      datain = ""
      datain = device.COM5.ReadUntil(10)
      PString = parse(datain,-1,",")
      site = PString[0]
      date = PString[1]
      time = PString[2]
      chan = PString[3]
      val = PString[4]

The "PString" array is created ok, and the ?PString[x] statements output the values in the array.

Clearly, however, I'm not assigning the variables correctly from that array (site = PString[0], etc) because those variables do not get populated, and in fact the while loops hangs just after that last ?PString[x] statement...

The software guys across the way are going to love it when I tell them that they're going to need a different sting delimiter than "@" if we're going to make our new box work with DF. Oh well, they'll get over it.

- and no, pickiness is not the issue - I'm trying not to look COMPLETELY dumb... :)

Link to comment
Share on other sites

There doesn't appear to be anything wrong with the script. I wonder if "site" has some issue. Try assigning it a constant.

There is no reason you can't use @ as a delimiter. Just use "@@" instead of "@" in your parse statement. The first @ is removed leaving just a single @. @ as a language specifier only gets stripped if it is the very first character of a string.

That said, I must say that @ is a weird delimiter to use, especially in the internet age where @ is used in email addresses. Same goes for <, >, and &

Link to comment
Share on other sites

Ah, now I get it on the "@" character.

As for the sequence, it finally turned out that DF apparently didn't like "TIME" as a variable name for some reason. Once I replaced that variable with "TM" instead, everything works fine.


I also had a great deal of trouble getting changes to take effect while editing the sequence. I couldn't just do "apply and compile" then hit "restart sequence". I had to stop the sequence, apply and compile, save the file, then hit "start sequence" in debug - otherwise my new edits would not be run. Something to do with still having the serial port open perhaps??

Anyway, main issue solved for now. Thanks for the pointers.

Link to comment
Share on other sites

Time is a reserved word. Think about the graph: you use Time usually for the X axis. Of course it only really means anything in a graph, but it still ends up as a global reserved word.

As for the restart: try just using F5. This is the quick way to stop, apply and restart a sequence.

Link to comment
Share on other sites


This topic is now archived and is closed to further replies.