Program lost part of functions after 1.5 month?

[JÞB]

Harry- Thanks for the additional info

 (BTW: sorry you felt beaten up posting to the forums- that should not happen! but some of us do tend to look down on text programmers)

OK so what you have is a DAQmx version older than 9.1.  You've got the Autostart bug!.

So here is what you need to do.   Before the loop use Control Task.vi and explicitly commit the task.  surround your read task vi with start task and end task. 

[Harry.W]

Jeff,

Yes after adding a "DAQmx Control Task.vi" just outside my main while loop and setting action as "commit", the error did go away and I can see the AvailSampPerChan p-node displaying 90, 80,,...0 and then 90, 80 ... again and again. But didn't this tell me that the buffer actually will not overflow because it keeping dropping and starting over and over?  

Can you explain a bit more what you mean "You've got the Autostart bug!"? Do you mean this bug can cause my program having that 46 days issue? What i need to do beside adding the control task vi?

Also what do you mean by "surround your read task vi with start task and end task". The start task and end task are all OUTSIDE while loop and I cannot put them inside because it will cause memory leak, won't it?

I looked my DAQmx help, it says my version is 9.1.

Sorry that I still knew very little here.

Harry

[nathand]

---

@johnsold wrote:

Try creating the file and writing more than the maximum amount of dummy data to it before entering the loop. That should cause the OS to create a file and to allocate more than enough space to it.  Before entering the loop reset the file postion to the beginning.  Inside the loop you may need to track the file position in a shift register.  Inside the loop you overwrite the dummy data with the real data as it is acquired.

---

Not directly on-topic, but there's an easier way to do this: use the "Set File Size" function found in the File I/O -> Advanced palette.  No need to write any dummy data nor reset the file position.

[JÞB]

---

@Harry.W wrote:

Jeff,

Yes after adding a "DAQmx Control Task.vi" just outside my main while loop and setting action as "commit", the error did go away and I can see the AvailSampPerChan p-node displaying 90, 80,,...0 and then 90, 80 ... again and again. But didn't this tell me that the buffer actually will not overflow because it keeping dropping and starting over and over?  

OK- I think we can identify a DAQmx bug (or perhaps more closely called undocumented behavior) is close to the root of what you are seeing.  <Hand Waving for a DAQmx GURU/\/\/\/\/\/>  these pesky N-sample tasks are becoming very troublesome. if you really want to dig under the hood there is a good discussion about DAQmx state transitions here But lets assume your task is in Xanadu. "90, 80,,...0 and then 90, 80 .." to solve this we will need to get around the current behavior of 90, 80,,...0 and then 90, 80 ...  samples in the buffer.  we will do this by explicitly transitioning states and never leaving anything in the device buffer.

In CurrIn.vi make these changes:

 

Tis will cause the task to acquire 10 samples each time it is run and to be in the commit state before the loop starts (From Commit to Run causes the least amount of overhead and when a running state completes DAQmx tries to return to the state it was started from) AND we will not use the "Auto-Start feature (Auto-Start with NSamples does NOT transition to any documented state in the DAQmx State diagram but goes to "Xanadu" (TTWIW: That's the way it works) so I've been told.

Can you explain a bit more what you mean "You've got the Autostart bug!"? Do you mean this bug can cause my program having that 46 days issue? What i need to do beside adding the control task vi?

I think that's as much as I care to explain at this time Believe me.  I don't understand WHAT really happens in the guts of DAQmx But I can work around it!

Also what do you mean by "surround your read task vi with start task and end task". The start task and end task are all OUTSIDE while loop and I cannot put them inside because it will cause memory leak, won't it?

 In Main.vi insert this code: where the read is

This will start the acquisition, wait until it is done, read the whole buffer and explicitly transition back to the commit state. (If errors occur the task is destroyed and re-created just as it was when it ran the first time) Replace the error handeler with an error logger or whatever you want- the dialog is there as a placeholder and would halt the program untill the user clicked on the "OK" button.

I looked my DAQmx help, it says my version is 9.1.

 Hmmm. gee, I saw 9.1's release notes they include a fix for CAR

185781

NI-DAQmx auto start doesn't automatically stop task

As seen here but perhaps this fix only applies for reference triggering?????? 

Sorry that I still knew very little here.

 Don't be.....

More hand waving /\//\/

Perhaps we could all stand a refresher about what happens when an n-sample task finishes n-samples.  What state is the task in?

Or Quoting from a SR e-mail I recieved when investigating what happens to these darn n-sample tasks

In RE:

My statement

[Ref DAQmx Help]

Reading into the sub heading "Transitioning the state backwards" under
"implicit Task State Transitions"  we read "
When a task is implicitly transitioned backwards, it returns to the state
of the task prior to the last operation that resulted in a forward state
transition"

Hi Jeff,

Thank you very much for spending the time to find that information in the
help document. I have been working with R&D today on this issue and they
informed me this is normal behavior.  After toughly testing the VI that you
have giving me I cannot say that this is a bug since I am unable to find
any documentation that says it has this functional for a finite multiple
sample case. The document you referenced about the task stopping is for
single sample write operations, which are expected.

.....


Regards
(Redacted Name)

Applications Engineer
National Instruments

---

[Harry.W]

Jeff,

Wow, thanks Jeff for your explaination!!!  I think I need a little time to digest all these. But one quick question is, regarding the part of code you suggested below, should they go inside my While loop entirely? Or where I put my while loop so I can do these input and output over and over again? I recall someone told me to have the start task and clear task outside any loop to avoid memory leak. Is it still correct or not?

Harry

 

[JÞB]

---

@Harry.W wrote:

Jeff,

Wow, thanks Jeff for your explaination!!!  I think I need a little time to digest all these. But one quick question is, regarding the part of code you suggested below, should they go inside my While loop entirely

Harry

---

Yes-  inside the while loop-

Digest at your leisure- I still have my mouth full- but I am chewing!

{ thinking to myself}  I think I have felt this on my foot before...  What did I just step in?

[Harry.W]

Jeff,

Thanks!

I guess I probably sounds annoying, but can you tell me, if I put the Start and Clear DAQmx tasks in a while loop, will this cause memory usage keep growing up? I did had a big memory leak at the very beginning, which caused my program freeze. People from this forum told me to move Start/clear out of the loop. I did that and it worked (corrected the memory leak).

Rgds,

Harry

[Harry.W]

Jeff, I forgot to ask one more thing. Do I need to do similar changes for the Analog output? Putting it in the loop as well? You know I am writing to the current output device every cycle. Thanks!

Rgds

Harry

[JÞB]

 
 but can you tell me, if I put the Start and Clear DAQmx tasks in a while loop, will this cause memory usage keep growing up? I did had a big memory leak at the very beginning, which caused my program freeze. People from this forum told me to move Start/clear out of the loop. I did that and it worked (corrected the memory leak).

---

You will "Leak" a bit of memory creating the task repeatedly.  In this case, the task only gets destroyed and recreated if some error occurs (At which point you have something else wrong- likely that a connection was changed inadvertantly) this allows reestablishing the DAQmx task.  Just starting and stopping a task does not cause a memory leak.  so in the loop Start, wait for it to complete read and explicitly stop.  This allows us to stay in areas that are well documented in DAQmx for n sample tasks.  It sounds like i've been here before doesn't it?

---

---

Harry.W wrote:
Jeff, I forgot to ask one more thing. Do I need to do similar changes for the Analog output? Putting it in the loop as well? You know I am writing to the current output device every cycle. Thanks!

Rgds

Harry

---

No,  you are safe with the single sample flavor of DAQmx tasks, the behavior is defined to atuo-start, write 1 sample and return to the previous state in the state model-  What? they behave differently?  Yup- they do.  That's the way it works.  Seams funky to me too.

[Harry.W]

Jeff,

Thanks! I did the changes based on your suggestion: adding DAQmx control in CurrIn.vi and also made changes in the Main vi. I put here a screen shot of the changed main. I would truly appreciated if you can take a quick glance to see if I misunderstand anything.

I tried to change error tunnel to SR on both current input and output, and it seems it does not do much difference. Right now I have the current input error on tunnel and output on SR. Do you think I need to put both as SR?

I also log the error code (in the error case structure) to a txt file so later i can see what happened.

Any other suggestion you have for me? I really appreciate all your help!

Rgds

Harry