09-15-2022 01:48 PM - edited 09-15-2022 01:55 PM
Hi Alex.
@EssperAlex wrote:
I had run multiple time on my full VI today with just minor amendment on the reducing "Local Variable" & sizing.
Well, when there is code like this in your VIs:
then you still have a long way to go!
Please simplify your code, this can also help with your other code problems!
Is there a reason you stick with IVI functions? Is there no VISA based device driver?
09-15-2022 04:40 PM
@Kyle97330 wrote:
@EssperAlex wrote:
But the main reason on why I didn't use subVI on those loop is due to I would need to see live results on every single loop on the table. If I were to subVI the loop, I found out that I am unable to see the live result until the whole subVI finished the execution than I will be able to see the whole result.I would like to say that you absolutely CAN see live results from subVIs if you have created your program in the correct way. If you're just using indicators and controls and local variables then yes, you need it all on one VI.
But if you switch to a messaging protocol for updating your controls (queues, notifiers, events, etc.) you can make a loop on your main VI that updates from subVIs.
Or you can update controls via reference (reference their controls and use property nodes, or use DVR references).
Or you could even put the subVIs in a sub-panel and they will look like they are part of your main VI.
Or you could have the subVIs run as pop-up VIs, show the results there, and when they finish also show the results on your main VI.
None of these changes will directly solve your running out of resources problem, but it will make the actual issue MUCH easier to find, and make it far easier to add other changes to your code later.
One reason it will make it easier to find where it is, is that the call chain will no longer just be "anywhere in main.vi". It will contain the path all the way down to the VI where the error actually occurred. Instead of having to search through the whole main VI, you just have to look at the small, simple code inside the subVI. (This is why I dread troubleshooting uber-VIs.)
09-15-2022 08:17 PM
Hi Gerd,
This is something new to me! Thanks for sharing! Didn't know I could have done it this way for the AC Listmode.VI
I will try to re-route some of the portion and tidy them today and see if things get better.
@GerdW wrote:
@GerdW wrote:
.Is there a reason you stick with IVI functions? Is there no VISA based device driver?
Yes, there is no VISA driver for this device. There is only IVI driver available for it which is why I use IVI functions. I personally preferred VISA driver too as I find it easier to use/communicate it.
09-16-2022 12:32 AM
Hi Alex,
@EssperAlex wrote:
Didn't know I could have done it this way for the AC Listmode.VI
I will try to re-route some of the portion and tidy them today and see if things get better.
What's the point at all to rebuild that table row by row with a delay of 1s between each iteration?
At the end you still present the very same data…
09-16-2022 12:46 AM - edited 09-16-2022 12:59 AM
@GerdW wrote:
What's the point at all to rebuild that table row by row with a delay of 1s between each iteration?
At the end you still present the very same data…
Hi Gerd,
Yes, it will present the same data. I placed the 1s delay there initially was to check if it was showing the correct result that I wanted. This table is an alternative method (key in data into table instead of using the top portion array) to insert data to the device. I had since removed the whole table already as for this test program, I will not need the table portion, I had remove the listmode.VI and replaced with the new listmode.vi without the table as shown in the picture.
But today I tried running on the full VI after replacing the new AC listmode.VI, I was still having error on the "Chr61507 Initialize With Option.VI" showing "Insufficient System Resource" after running for >308steps. (about >70mins)
09-16-2022 06:04 AM
Posting from phone. I'm going to jump on some observations and make a few assumptions. I'll look at the code later.
You are not properly handling errors. Or, LabVIEW would not throw the automatic error handler pop-up.
I would bet large sums of cash money that the error is not at a random time but at exactly the 256th open session.
09-17-2022 12:47 AM
Hi Jay,
@JÞB wrote:
Posting from phone. I'm going to jump on some observations and make a few assumptions. I'll look at the code later.
You are not properly handling errors. Or, LabVIEW would not throw the automatic error handler pop-up.
I would bet large sums of cash money that the error is not at a random time but at exactly the 256th open session.
Many thanks for the help! Currently, I am not sure which portion I am not handling the error properly but I think that might be the case to it that I am having errors on the program when I tried to run it for long hours.
Like what you mentioned on the 256th open session, I will now try to check the issues on the session where I open and close. Did I miss out any of them.
09-17-2022 06:13 AM - edited 09-17-2022 06:15 AM
@EssperAlex wrote:
Hi Jay,
@JÞB wrote:
Posting from phone. I'm going to jump on some observations and make a few assumptions. I'll look at the code later.
You are not properly handling errors. Or, LabVIEW would not throw the automatic error handler pop-up.
I would bet large sums of cash money that the error is not at a random time but at exactly the 256th open session.
Many thanks for the help! Currently, I am not sure which portion I am not handling the error properly but I think that might be the case to it that I am having errors on the program when I tried to run it for long hours.
Like what you mentioned on the 256th open session, I will now try to check the issues on the session where I open and close. Did I miss out any of them.
There should not be more than one each! They should be outside any loop and if you use an autoindexing loop make sure the session wire is on a shift register.
09-18-2022 08:13 PM
@JÞB wrote:
There should not be more than one each! They should be outside any loop and if you use an autoindexing loop make sure the session wire is on a shift register.
I had check on the listmode.VI that I am using within the For-loop. They are being close at 1:1 ratio.
For-loop,
I will re-check the whole full program VI to check if I miss out or added any additional VISA open/close or driver open/close.
Currently latest update, I am still having the same error "Insufficient System Resources". When I tried to run for long time.
09-19-2022 01:58 AM
I'll say +1 on Jays comment. You actually Open/Close too much. Open once and reuse that reference until done, then close.