End of file encountered on FormatIntoSting

[instrumento]

Running the attached VI gives me a popup with

  LabVIEW: End of file encountered.

  The top-level VI "crash.vi" was stopped at

  FormatIntoString on the block diagram of

  "crash.vi"

This is most likely a corrupted VI, but it's such a simple VI.

I did cut all the elements from a much larger VI, recreating the simple example from scratch doesn't seem to do it.

This is bit puzzling and wastes time to track down, as from a built executable the message was not clear at all.

[instrumento]

Which VI, the FormatIntoString?

On that particulat example VI, replacing doesn't do it, deleting than adding, works.

Visually the whole thing looks the same, so much for visual programming.

Hopefully it will work on the real larger VI.

[RavensFan]

It gave that error for me as well.

I started digging into it and saw that the constants in the cluster had units associated with them.  While units sound like a great idea in theory, the implementation of them in LabVIEW has been buggy.  I think that is what is happening hear.  When I created the cluster without units and stripped the unit part out of the format string, it did not cause an error.

Copying the constant with units and feeding that directly into the format into string did not cause an error, but using it within the cluster did.  Somehow the cluster must be mangling the units in a way that the format into string can't handle.

I recommend getting away from using units.

EDIT:

This works.  It converts and strips the units before going into the Format Into String

[RavensFan]

Where did the comment about "Format Into String" come from?  It wasn't mentioned at all in this thread.

Are you talking about the other thread you started?  http://forums.ni.com/t5/LabVIEW/End-of-file-encountered-on-FormatIntoSting/m-p/3558529

Are these problems related?

[instrumento]

Oops. Replied to the wrong thread.

[instrumento]

I keep telling that to the guys around here, but they like units.  Two of us have been removing them from lots of places, but there are too many to tackle.

Anyway, on the example VI, if I delete the FormatIntoString and add it back, that particular VI works.

On the original VI, I did the same and it worked, to fail later on on another call to FormatIntoString. 

I'm running a repair on LV2015 SP1 and SP1 f5 to see whether it fixes, as I have a built executable that runs fine on several other machines, so something is corrupted on LV itself, I think.

[RavensFan]

---

@instrumento wrote:

Oops. Replied to the wrong thread.

---

No problem.  Your comment makes sense now.  I'll move that message over to the other thread.

(For historical record, the message was originally posted here.  http://forums.ni.com/t5/LabVIEW/An-input-parameter-is-invalid-when-opening-a-VI/m-p/3558546)

[instrumento]

By copying and pasting from the original vi, I created the attached vi, crash2.vi.

That double constant, with units, is somehow messed up, in a way that is not visible to the user.

Running it the code stops with the same error message.

If one clicks into the white space to the left of the value and when the cursor shows up to the left of the 4 one hits backspace, the constant looks a bit better and the code runs fine.

The problem is, that constant doesn't really exist in our code, it is in a cluster, like in crash.vi, which is generated by another VI.

I probably need to recreate the cluster typedef, but this is pretty messed up

[yea_likethecity]

Hi Instrumento,

It seems to me that the unit is improperly formatted. Using {m} instead of {um} works in the original crash.vi, as do many variations on {m}, but {um} and a few other variations do not work. Have you been able to use {um} as a unit in other parts of the code? 

[instrumento]

If you create a constant, add unit, e.g. m, and wire to the format with {um} things work fine.

The problem is with the value in the wire, which was generated by LabVIEW somewhere else, by adding units (um) to some value.

I think I know where the problem is coming from, and how to fix it, but it creates another mystery, as it requires making some changes to a typedef, which, after I make them, don't seem to change the CTL file as no asterisk shows in the title bar. 

If I run under development with the changes, the code runs.  When I close all the VIs, LabVIEW doesn't ask me to save the file.  And if I open and run them again, puff, the error returns.