Arrays, sub VIs

[Mbdeck]

Hi MikeS81 and others,

I moved to a new place and it took me some time to settle down but I'm back to learning Labview basics again. Anyways, I'm still having problems with the Array over Threshold VI.  I tried to replicate MikeS81's example but the coding did not work. I also tried the "Find examples" option on the labview programme menu but it didn't have any example there that was helpful. I've attached a copy of what I did.  I'll appreciate any help and suggestions. Thanks.

[StevenD]

Here is your Sub-VI with some notes and a fixed version of the code.




Message Edited by StevenD on 06-25-2008 10:55 PM

[Mbdeck]

Hi StevenD,

I couldn't open the code you attached because you have a newer version of labview. I have the 8.2.  I got this error message when I tried to open the file :

An error occurred loading VI  "Array%20Over%20Threshold%202[1].vi"  Labview load error code 9: VI version(8.5) is newer than version 8.2.

Is there any thing I can do to view the file you attached?. Is there any kind of upgrade that can be downloaded?.

Thanks

[RavensFan]

Here is his VI saved for LV 8.2

[Mbdeck]

Hello everyone,

I'm trying to create a VI that writes a temperature data to a file and I'm having a bit of a hard time completing it. I'm wondering if the "write text to file VI" is the right one. Can someone help me out?. Please see the attached code.

Thanks

[RavensFan]

That should work for you.  Go ahead and try it.

Oneproblem though with your handling of the file paths.  You will have errors, and probably a broken run arrow already. 

1.  Delete the Empty path constant before the loop.

2.  Replace it with an Open/Create/Replace File function.

3.  Wire it through the shift register to the Write text file.

4.  Wire the file refnum from the Write text file to the right hand shift register.  This will keep the program from asking you for the same file on every iteration.

5.  Use a format code so that you can have carriage return/line feeds after each number.

Message Edited by Ravens Fan on 09-04-2008 01:10 PM

[Mbdeck]

Hi Raven's Fan'

Thanks for your help,.. the programme works now but I have a question. I don't quite understand the function of the characters you had in the "codes display".  I meant these.... %d\r\n. I've seen %f, ....that is "percent F comma". Can you explain these to me a bit more?. 

Thanks

[RavensFan]

%d is format decimal character.  %f is format fractional character.  If you right click on the Format Into String function and select Edit Format String, it gives you a dialog box to help you format it.  Also look in LabVIEW help for a few screens that describe the various format codes.  I'm not sure whether you would want %d or %f, you will have to experiment with the codes and read up on them to figure out exactly what you want.  A %F, comma gives a decimal number with digits to the right of the decimal point if a fractional part of the number is present, and puts a comma after that.

\r is the slash code for carriage return (ASCII 13) and \n is the code for line feed (ASCII 10).  These are put in there to break up the values onto separate lines. 

[Mbdeck]

Also, why must the error output of the "replace file function" be wired to the "write text to file" function?.  Is that wiring critical?.

[RavensFan]

Critical?  No.  But best practices are to always wire up the error wires.  I could (should?) have gone 1 step further and put an Error dialog box after the loop and fed a wire from the Write to Text file function through to that.  Error wires allow other functions to handle errors appropriately and depending on how the functions and subVI's were written.  Write to text file won't run if the Opening of the text file did not work.

Also, if a function does not have an error wire coming out, it will show a LabVIEW error box right then and there asking whether you want to stop or continue.  In the case of something happening over and over in a loop, that box could pop up repeatedly.  This can be especially troublesome for some activities like when you are trying to constantly communicate with a serial device.  Also, if your code is something you do not want to have freeze up because it is for unattended operation (like for machine control), you don't ever want to have something that could halt the code while waiting for a user response.