String match failing to match string

[romanotio]

Hello, I am trying to match a string from the serial output from a capacitive sensor, that would come in the form of the following:

1.505949 pF 23.47 deg.C
1.503296 pF 23.54 deg.C
1.500016 pF 23.48 deg.C
1.498763 pF 23.46 deg.C
1.497160 pF 23.50 deg.C

and so on, essentially a ones digit and six digits after the decimal point. I have the regular expression ([0-9]\.[0-9]{6}) I am trying to match with this, using code I have adapted from a temperature graph readout, however it continues to return -1 and not detect this regex in my output stream. Why is it that this is happening? Thank you.

[romanotio]

VI attached, it was dropped from my original post

[Mancho00]

Match Pattern has limited regex ability.  Try using Match Regular Expression

[RTSLVU]

I notice you are using "Bytes at Port" and that's usually not a good idea.

Watch this video: VIWeek 2020/Proper way to communicate over serial

Also try this for parsing your string

EDIT: Fixed output1 display format so it was not rounding 

[Kyle97330]

The exact problem you have is that the {6} part looking for 6 matching characters in a row isn't supported by "Match pattern".  You could use "[0-9]\.[0-9]+" instead which searches for any number of digits after the decimal instead of always 6.

However just in general this seems too specific.  Are you 100% certain that you will never get back a reply with either a negative number or one that has 2 or more digits before the decimal?  It's much better to just scan for "a number" if you are going to convert it to a number later.  Basically doing what RTSLVU suggests.

If for some reason you do require the exact string and a numeric equivalent won't do, you either need to switch to a working pattern such as the example I gave, or the Match Regular Expression node as mentioned by a previous reply.

[JÞB]

And you might want "%6iF..." to get six significant digits in scIentific notation just in case you see some microfarads instead of picofarads.

[altenbach]

---

@JÞB wrote:

And you might want "%6iF..." to get six significant digits in scIentific notation just in case you see some microfarads instead of picofarads.

---

That is not a valid conversion code.

If you want to include the "pico" part to read the value in whole F units, there cannot be any space between the number and the p. After eliminating the space in some other way,  you could use %pf as scan format to get ~1.5e-12 for the first number.

[JÞB]

That's what I get for not having my lapheater booted up!

Obviously I would call Output 1 Farads and display in SI units e.g. 1.23456p or 21.0987u