07-24-2012 08:55 AM
Ah, now it starts to make sense. In In the sub-vi, possibly in several places, you read a file (why?) which'll cause 6*X file reads, and i guess you have a open/close connected to that also. If you want to read a file in a loop, try to make sure you only read it once, and use that data in all calculations. Keep file opening/closing outside the loop.
/Y
07-24-2012 08:58 AM
From what I can see, I think your problem is going to be in that subVI, or one of its subVI's. It is password protected, so it is impossible to see what it is doing. Read from spreadsheet is certainly not the problem.
One more thing you can do to clean up the code is to eliminate all of the extra Index Array functions. Instead of splitting that 2-D array multiple times going into individual Index Array functions, you can use one. Expand the bottom of the Index Array function downwards to get more outputs.
If you have the LabVIEW Desktop Execution Trace Toolkit, you ought to be able to see what which subVI's are taking the longest.
07-24-2012 09:02 AM
@Ravens Fan wrote:
From what I can see, I think your problem is going to be in that subVI, or one of its subVI's. It is password protected, so it is impossible to see what it is doing. Read from spreadsheet is certainly not the problem.
One more thing you can do to clean up the code is to eliminate all of the extra Index Array functions. Instead of splitting that 2-D array multiple times going into individual Index Array functions, you can use one. Expand the bottom of the Index Array function downwards to get more outputs.
If you have the LabVIEW Desktop Execution Trace Toolkit, you ought to be able to see what which subVI's are taking the longest.
Sorry I forgot to unlock vis. password is 4987. sorry for that.
07-24-2012 09:06 AM
Yameada nailed it.
Those subVI's have several Read from Spreadsheet files scattered throughout.
Are these your subVI's. (I'm assuming so since you knew the password.)
I would consider rearchitecting those. Read the spreadsheet file once at the beginning of the VI. If you need to refer to that data in multiple locations throughout the subVI's, then consider storing the data in an action engine or functional global VI. In the subVI's get the data out of the FGV instead of rereading the file.
07-24-2012 09:20 AM
Where is the file:
H:\Aktif Calisma Klasoru\WORKBENCH\LABVIEW WORKS\Read P-h Program\ORIGINAL PROJECT VIs\SubVIs\R600a Tables_txt\R600a_bar_P_0,1_sat_refprop_labview.txt
That seems to get read numerous times at several levels of subVI calls. Why can't you read it once and cache the data? Does it constantly change?
07-25-2012 01:25 AM
@altenbach wrote:
Where is the file:
H:\Aktif Calisma Klasoru\WORKBENCH\LABVIEW WORKS\Read P-h Program\ORIGINAL PROJECT VIs\SubVIs\R600a Tables_txt\R600a_bar_P_0,1_sat_refprop_labview.txt
That seems to get read numerous times at several levels of subVI calls. Why can't you read it once and cache the data? Does it constantly change?
No this text file does not change, it is constant.
07-25-2012 01:49 AM
Then Altenbachs idea is a very good one, read the file and store it in an AE (Action engine) ouside the loop, and refer to this AE in the sub-vi's instead of rereading the file.
/Y
07-25-2012 01:57 AM
@Ravens Fan wrote:
From what I can see, I think your problem is going to be in that subVI, or one of its subVI's. It is password protected, so it is impossible to see what it is doing. Read from spreadsheet is certainly not the problem.
One more thing you can do to clean up the code is to eliminate all of the extra Index Array functions. Instead of splitting that 2-D array multiple times going into individual Index Array functions, you can use one. Expand the bottom of the Index Array function downwards to get more outputs.
If you have the LabVIEW Desktop Execution Trace Toolkit, you ought to be able to see what which subVI's are taking the longest.
@Ravens Fan wrote:
Yameada nailed it.
Those subVI's have several Read from Spreadsheet files scattered throughout.
Are these your subVI's. (I'm assuming so since you knew the password.)
I would consider rearchitecting those. Read the spreadsheet file once at the beginning of the VI. If you need to refer to that data in multiple locations throughout the subVI's, then consider storing the data in an action engine or functional global VI. In the subVI's get the data out of the FGV instead of rereading the file.
I changed the VI that you mentioned in your previous thread here and attached a printscreen of it. Did I understand you correcty on this?
All subVIs were prepared by me and I gave the password before here (4987). The main reason to prepare these subVIs is to prevent the confusion on the block diagram. However, using these subVIs leads the VI to read a lot of time from text files. Now, all I understand from as your says that I need to prepare one VI that consists of whole program and read text files just for one time. I have just installed Desktop Execution Trace Toolkit module. I have never used this module before. I started to learn about it.
Storing data in an action engine or functional global VI sounds too strange for me. I have never used or heard about them. I will search on it. Thanks.
07-25-2012 02:57 AM
"I need to prepare one VI that consists of whole program"
No, not really, you need to create an AE which'll hold the file information instead of rereading it every time.
In the sub-vi you read from this AE instead.
This can either be handled in your existing sub-vi by First Call, or initialized in your main vi outside the loop.
/Y
07-25-2012 06:58 AM
Follow Yamaeda's link for how to implement an action engine. You will basically need 2 actions. Load and Get Data.
Your image of the Index Array is much better. Here is another tip that will help. Since it looks like you have all the indices from 0 to 7 used, if you rearrange all of your indicators in order, you can get by just wiring the 0 constant at the very top output like you have now which defines the 0th column. Eliminate all of the other constants. All of the outputs below that will be the 1st, 2nd, 3rd, .... 7th columns by default automatically. It's a way of saving time of having to duplicate all of those extra constants and changing them manually to sequenctional numbers.