Scan from String Issue with variable Format String

[Arkaru]

Hi everyone,

i was trying to use the "Scan from String" VI for one of my project, in which i stumbled upon the following issue:

I tried to connect a String Control in to the "Format String" input of the VI, however even if i give a correct "Format String" input throught the control, the "Scan from String" VI does not interpret it correctly and i get an error saying "Too many format specifiers". For reference check the attached example VI.

Am i misunderstanding something here or is it simply not possible to connect a control in to the "Format String" input?

[Andrey_Dmitriev · Accepted solution]

Yes, because the only one output was requested. Try this way:

[GerdW]

Hi Arkaru,

---

@Arkaru wrote:

Am i misunderstanding something here or is it simply not possible to connect a control in to the "Format String" input?

---

You can connect a control to ScanFromString formatstring input.

But you cannot change the ScanFromString behaviour (by sending different format code stirngs) "at the fly"! ScanFromString adapts to the format string at EDIT/COMPILE TIME, so any change later on will give error messages like yours…

On your attached VI: you use the most recent LabVIEW version - many of us don't use that so far. Please downconvert your VI (File->Save for previous) to an older LabVIEW version (LV2021 or older) before attaching.  I prefer LV2019…

[Bob_Schor]

I echo @GerdW -- I also couldn't read your code.  I also created a simple example showing how to use the Format command (though you need to be careful if you include a "string" in what you want to parse -- read the Help carefully when it talks about parsing strings).

The Example has a String Control as an input with the string "ABC = 5.4" as its value.  We want to get two outputs -- the "String Part" (by which I mean the name "ABC", which needs to have no spaces, and a "Value Part" (by which I mean a Dbl with the value 5.4).

Here is a VI Snippet for LabVIEW 2021:

I want to extract two values from the String Control, a String and a Dbl, so I "drag down" the bottom of the function to expose a second input.  The first Input is a Strring constant, the second a Dbl constant.  The Format of the input string is a String ("%s"), an equals sign that I do not want to be scanned (in the Input, it is " = "), and a Dbl ("5.4").  So I want to scan a String (%s), an exact part ( =), and a Dbl (%f).

The tricky part is the "exact part", because it follows a string.  Scan from String likes to use spaces to mark the end of a string, so when it finishes with the "C" and sees the space, it says "OK, I've got the String", and it is "sitting" waiting to parse the rest of the string input, which is " = 5.4".  So if you ask it to exactly parse " =", it will be sitting just after the equal sign, ready to parse a number (5.4).  It turns out you could have specified an exact part for " =       ", with lots of extra spaces, but the trailing spaces are ignored.  [Don't ask me, I didn't make the rules, but it works pretty well].

Bob Schor

[altenbach]

---

@Arkaru wrote:

i was trying to use the "Scan from String" VI for one of my project, in which i stumbled upon the following issue:

I tried to connect a String Control in to the "Format String" input of the VI, however even if i give a correct "Format String" input throught the control, the "Scan from String" VI does not interpret it correctly and i get an error saying "Too many format specifiers". For reference check the attached example VI.

---

Unfortunately, you did not say what output you expect from your input!

(Please don't use sequence structures and local variables for any of this. It is completely misguided!)

Assuming your string is a sequence of words delimited with digits surrounded by a space, here's one possibility that will work with any number of fields.

[Arkaru]

Hi Andrey_Dmitriev,

thanks! That actually solved my issue!

[Arkaru]

I see, i was not aware of that. Thank you for letting me know and for the help!

Since the issue/question has been solved, i don't see any reason to downgrade the VI anymore. But i thank you anyways!

[Arkaru]

Thank you so much! This example was very helpful. Most of it, i already knew from the specification from NI. However, the mistake that i made was to not specify the output as "Strings", which is why i encountered the aforementioned errors.

I appreciate taking the time to explain this though!

[Arkaru]

True, that was my bad.
My question and confusion was mainly related to the issue regarding connecting a control to the "Format String" input, which is why i did not say what output i expect. The attached VI was also just a quick example that i made to clarify my point.

But i did not know that using sequence structures and local variables is misguided! I am pretty much self-taught in using LabVIEW so i do not know any "best-practices". Thank you very much for pointing that out. 
Is there any good online resource, that you could recommend, where i can learn about this kind of stuff?
And i know it is out of topic but when would you recommend using sequence structures and local variables instead?

Have a nice day and thanks again!

[Bob_Schor]

Hello, @arkaru.

     As a suggestion, when you reply to a post, let us know which post you mean.  You can do that by (as I did, above) mentioning the name of the person you are thanking or otherwise responding to.

     LabVIEW differs from most other programming languages in being a "Data Flow" language.  Here  is how Data Flow works in LabVIEW.  The idea is that a function (or a structure) doesn't run until all the Inputs have "data" on their input "wires", and that data on output "wires" doesn't flow until the function (or structure) finishes.

A practical expression of Data Flow is that a Sequence structure is almost never needed.  Most LabVIEW functions (and almost all user-written sub-VIs) have Error In/Error Out terminals, which form a "natural" method of specifying the order of function/structure operation -- just follow the Error Line.  Instead, Sequence structures tend to "bloat" LabVIEW code, making it much more difficult to see how the data flows through the program.

There are occasions when Local Variables make sense, but if you can "flow" the data in a Wire, it makes it much clearer (to the person trying to understand and debug the code) to understand how the data are being processed and manipulated.

A good Rule of Thumb for LabVIEW beginners:

• Never (well, hardly ever) use a Sequence Structure.  [When you get skilled enough in LabVIEW to program a LabVIEW Real-Time FPGA, you'll use Sequence Structures].
• Rarely use Local Variables.  If you are tempted to use them, find a LabVIEW guru, show her your code, and ask how to avoid Local Variables.

Bob Schor