Jump to content

String with multiple delimiters

Recommended Posts

Hi guys! I know that it is an old topic , but I will try !  Smiley feliz

My DAQ board sends to PC data in the following format.


! is the starting character

and we have "," , ":"   and ";" as delimiters.

In the end of the packet (after ":") my board sends the values of two microcontroller timers (4 and 5).

The first data packet ends with a <CR> and my boards repeats that every 3 seconds.


I need to plot voltage1[n] and voltage2[n] in two separate graphs and my time base is the value of TIMER4 / n.


The real data is like showed below.




I have used and modified altenbach's VI (https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Contract-multiple-delimiters-for-quot-Spreadsheet-string-to/idc-p/1239830#M7564) but some delimiters are bothering me yet.


Modified Altenbach's VI


Case value 1 detail


The result is:




The VI was great to separate correctly the values of voltage1 and voltage 2 in two separate strings but I did not know how to avoid the last comma.

Also in Timer4 and Timer5 I could not avoid the characters ":" and "," right before the numeric values.

I would be grateful if anybody help to solve this issue or give me other tips to do what I need with that data.

Thank you everybody in advance !


Edited by Bira
Link to comment

Here's my attempt.  Not sure if it is the fastest but I didn't know if you wanted other information so I just wrote code that allows for N different delimiters, but all of which are a single character.

Multiple Delimiter Hooovahh.png

Multiple Delimiter Hooovahh.vi

Edit: Just noticed the <CR> is still there in my test, might want to perform a string subset, or trim whitespace on the last element.

Link to comment
On 10/26/2017 at 10:12 AM, Bira said:

we have "," , ":"   and ";" as delimiters.

When you break down your string into different sub-sections, the problem becomes much easier to solve. Don't try to handle 4 delimiters at the same time.

The format for the full packet is:



The format for <VOLTAGE_LIST> is:



The format for <VOLTAGE_PAIR[k]> is:


The format for <TIMER_LIST> is:



Notice that:

  • The full packet only has '!' at the start, ':' somewhere in the middle, and '\r' (<CR>) at the end
  • <VOLTAGE_LIST> only has 1 delimiter: ';'
  • <VOLTAGE_PAIR[k]> only has 1 delimiter: ','
  • <TIMER_LIST> only has 1 delimiter: ','


You can translate the above breakdown into very simple LabVIEW code:

Data Parser BD.png

Data Parser FP.png



  • The pink VI is <vi.lib>\AdvancedString\Split String.vi
  • Regular Expressions (Regex) are very useful for string manipulations. Play with it at https://regexr.com/ (note: You might need to replace '\r' with '\n') 
Edited by JKSH
  • Like 2
Link to comment

Hi guys ! All of you were great !

Thank you for your prompt help and sorry for duplicating the post.

I have tested all the VI and they worked very well. Now I am trying to make the data that comes form serial port to work with that VI.

Have a very nice day and thank you once more !!

Link to comment
  • 2 weeks later...

Hi guys. I am here again !

I've tried for some days to make my serial communications to work correctly, but I could not do it the way I need.

I used GraigC's String.vi to separate voltages and timers, and the VI does it perfectly. The problem is when I try to attach this VI to the serial communication. My AD conversion board sends the data package described in the beginning of this post, every 3 seconds. I need to use the package to calculate some energy power parameters and then wait for the new serial transmission. Once the new serial data arrives, I need to clean all plots and strings and calculate new parameters using the new package. New plots need to be showed every package read through serial reading.

I have attached a video in this post but if that were not possible to open I also uploaded to Youtube. (https://youtu.be/swWmabgipFE)

The video shows that the first package (correctly received and decoded by CraigC's VI) is showed in the indicators and remains this way forever. We can see that the "Response" indicator is incremented every serial transmission. (see side bar)   Even if I stop executing VI and start again, these data remain in the indicators. We also can see in the first line of "Response" indicator that some data received incorrectly is showed.

I am not sure if the value of "read count" is essential for correctly receiving and decoding the serial data.

So my questions is:

1) How do I arrange CraigC's VI with my own serial VI for reading and showing serial data correctly and update that every new serial transmission ?

I would like to thank all of you in advance for helping me again !

Have a very nice week !





craigc with serial.PNG

Simple Serial for adm00523 - continuos reading with CRAIGC VI.vi

Link to comment

Hi Bira,

Your data is being accumalated by the use of the Feedback and Concatonate string nodes.  You are essentially appending each "packet" with all the previously received packets which is why your REsponse indicator is growing every time round the outer loop.

You also need to think about how your "packet" is defined.  As you mentioned in your first post the "packet" is terminated by a Carriage return, hence you should terminate your read with a Carriage Return.

See attached VI

EDIT as you have stated 

"The first data packet ends with a <CR> and my boards repeats that every 3 seconds. "

Then you will need to increase the timeout value in my VI to something greater than 3000ms, say 5000ms or so.



Edited by CraigC
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...

Important Information

By using this site, you agree to our Terms of Use.