help:question about how to wirte same file in two sub vi

[mmm2006]

Open a file in a subvi with wirte and read attribute, keep it open and wirte data to it.

when i open this file in another subvi with write and read attribute and write data to it too, operation

succeeds too. Is that right? I had thought one of subvi will report error when try to access a opend file.

But both of subvi can output to file. I attached my subvi, it will be copied and put into a main vi to run.

please correct it if any error and explain my test result.

If i want to check the value of file handler,which data tyep should be used?

thanks

br,

[smercurio_fc]

Your subVI is not reentrant. This means that even if you have two instances of the VI floating all by themselves on a parent VI, LabVIEW will wait until the first instance has finished before calling the next instance. Since you open and close the file in the subVI, there's no issue.

---

mmm2006 wrote:
 

If i want to check the value of file handler,which data tyep should be used?

---

I don't understand what you are asking here. The file handler is a reference, which is just a 32-bit number. You can use the Not a Number/Path/Refnum function to test is the refnum is valid.

[mmm2006]

hi, smercurio,

But from output file, lines writed by thread 1 and thread 2 are mixed together. It seem that

two subvi can open file and write in it.so I don't understand yet.

If i want to implementation like this: when one file is opened by one subvi, another subvi

will not allowed to write or read from this file. How should i do? Does Labview file I/o funciton support

this? Can i use a global variant to control it?

About file handler,I just want to check its value to find out whether the file is closed during my

subvi is running. Do you mean that i can use "Not a Number/Path/Refnum function" to test, right? 

Thanks.

[smercurio_fc]

---

mmm2006 wrote:

hi, smercurio,

But from output file, lines writed by thread 1 and thread 2 are mixed together.

---

That's not what I get, and it's not what you should be getting. You should be getting the (timestamped) values 1 through 1000, then followed again by the numbers 1 through 1000. If you really have a mixed up file I would like to see it. I would also like to see the main VI that is calling this subVI twice to see if you're really just placing two instances of the VI on the block diagram, or whether you're doing something else. 

Note that you do not need to set the file position in the loop. As the Help for the Write to Text File function says, when you wire a refnum to the function, the write occurs at the current file position, and this is moved as you write to the file. Thus, all you need inside the loop is the Write to Text File function. The setting of the file position can be placed outside the loop right after you're opening the file.

[Jörn · Accepted solution]

If you want to avoid that other VIs open a file with another RefNum you have to insert Deny Access.vi from the Advanced File Functions Palette. You can choose whether read, write or both actions are denied for other refnums, VIs or applications.

[mmm2006]

Hi

@semercurio,

Maybe i don't describe it clearly. In my test,I copy thread.vi to thread2.vi,

thread.vi outputs "thread1....", thread2.vi outputs "thread2...". Then put them

in a main vi directly and run. So it will get a mixed lines file.

I think i should try to set deny mode when open a file.

About file position, thank your instruction very much. It is very helpful for me.

@Proven Regular,
just put Deny Access.vi after open file, right?

[Jörn]

Yes.

[smercurio_fc]

---

mmm2006 wrote:

Hi

@semercurio,

Maybe i don't describe it clearly. In my test,I copy thread.vi to thread2.vi,

---

That's different. And also unnecessary. Why make a copy of a VI just to change the message? If you have to make a change then you have to remember to change it two places. Create a control to let the subVI know the instance (1, 2, 3... ) and in the subVI set the output string based on this. Not only that, but by using the same VI you will prevent any kind of simultaneous access.