LabVIEW
Format into String - Too many format specifiers
Solved!
Hello,
I am developing a Labview application, which writes some measurements into an EDF-File. EDF means European Data Format. An EDF-File has two parts. An Header Part and a Data Part.
I found on this website "https://teuniz.net/edf_labview/index.html" a free and small collection of VI´s for EDF. I attached the small collection of VI´s to this post. These are a great starting point for developing my application.
I am using the "EDF-header.vi" from the "EDFrecorder Labview 2011" folder. My problem is that when I am running the unmodified EDF-header.vi I receive the following error message:
This error message occurs in the sequence 1 of the stacked sequence structure in this VI.
Can you please help me, why this error message occurs?
Thank you very much in advance.
Best regards,
Michael
Your problem is in some hidden code in Frame 1. If you expand that frame to the right you will find that there's some code there that ultimately does nothing. Delete that code and it should work fine.
I removed the hidden code and the error stopped happening. LV2020 SP1 32b.
Edit: weirdly enough, the given code ran with default values does produce an error in that version but not in 2017. Not saying I didn't believe you when you said it before, but yeah.
So what values are you giving it in 2017 that are producing an error? How can we replicate in 2017?
@pincpanter wrote:
@johntrich1971 ha scritto:
Your problem is in some hidden code in Frame 1. If you expand that frame to the right you will find that there's some code there that ultimately does nothing. Delete that code and it should work fine.
Good catch! It's a really ugly and Rube-Goldberg-ish code!
However, this hidden code does not produce any error with LV2017. Probably the compiler optimizer sweeps it away.
Furthermore, it seems the error should be another, since there is no format string connected here.
Yes, it was surprising that this was the error - I found it by running in highlight execution mode in LV2019. I didn't understand why it gave that error and didn't really investigate further once I found that removing it removed the error.
I fully agree with the Rube-Goldberg aspect of the code. Given some time (that I don't have right now) I think that I could get that code down to a few postage stamps in size without the stacked sequence (I can see immediately that at least 8 of them could be easily combined - they have FOR loops indexed off of the same input).
@FireFist-Redhawk wrote:
I removed the hidden code and the error stopped happening. LV2020 SP1 32b.
Edit: weirdly enough, the given code ran with default values does produce an error in that version but not in 2017. Not saying I didn't believe you when you said it before, but yeah.
So what values are you giving it in 2017 that are producing an error? How can we replicate in 2017?
Based on the first response I think that pincpanter was unable to replicate the error. It appears that something changed between 2017 and 2019 versions that caused this to throw this error.
