stop without exit

[kmous]

nd why would you want to revert (step back) to the older code??

LOL just because I need something fast  , nothing else ....well u said my architecture wont let me do this so I agree with you 🙂 u are the expert.

ou didn't mention that in your problem statement...  So it is not a problem, it is a lack of definition 

I though you did understand me when we sopke on the fone last weekend 🙂

 I didn't try the other rates, but they are likely so slow that it "feels" like it is frozen (although the weather is not helping )

No i am sure , nothing happened i waited 1 min 🙂 

[Ray.R]

LOL!  😄

Reverting to the previous code style will not get you solutions faster.  Things have to be tried out..

I tend not to remember everything over the phone...  I speak to many people all wanting different things, so I rely on specifications / details / plans, etc.. emails or posts.. 😉  If it's not visible, then I don't see it 😉  

I will check the rate issue.  It's probably something simple.  Have a look into one of the subvi's.. The one that converts the string to numeric for the DAQ rate.. Maybe the larger values do not work with the DAQ...  I did not investigate... So if it is, then always send 500ms to the DAQ, but take a sample at the rate that you want..  The code portion doing the measurement is triggered by the producer loop anyway..  Try hardwiring 500 to the refresh rate in the initialization state of the consumer loop (bottom one).

R

[kmous]

ahahha , the previous version was working with 1s 2s and even 5 sec 🙂 so that works with the DAQ .

Any ways let's focus on this one now!!! 🙂 ....when u told me on the fone , Oh ok great , awesome lol i thought you got it.

In my previous version I had to devide the rate by 1000 since the items are declared in (ms) , that might be the problem in triggertime.vi

Message Edited by kmous on 01-15-2009 12:10 PM

[Ray.R]

Yes... I noticed that you were dividing by 1000... But 1sec div 1000 = 0.001 ms...  You should get 1000 ms = 1 sec. 

Thus multiply 1 by 1000 = 1000ms..  Not 0.001ms = 1 sec..

Unless my math is horribly wrong, then how could the original code work?  Am I missing something?  😮

🙂

I'll have a look at the code.. 

Message Edited by JoeLabView on 01-15-2009 07:39 PM

[Ray.R]

Here's an updated version..

I am not saying that it is bug free, but I will describe the caveats that I observed...

I did fix an error in the delay calculations.  You were right, it would have waited for a very long time...  😮  😉 

There was also a problem about the number of samples being taken and selecting pause or Stop... Since the DAQ is still reading, it can fill up the buffer quite fast.

I changed the sampling rate to 10 samples per second, which is still probably too fast for a temperature measurement, you would not likely see such a sudden change in temperature..  But I don't know what you are measuring.  I tried to maintain the original configuration..

Have a look at the physical channel state in the bottom loop (consumer).  Check the way I harcoded the refresh rate to 10.  I left the Cluster output intact and you can play with wiring to it..  But I don't think you want to use the refresh rate (1000 ms or more) to be the sampling rate.. Even 500 (ms) is too high for temperature measurements..  For most applications, that is..  You may want to read up on the recommended refresh rates for temperature measurements. 

Should the pause stop the DAQ?  Should the Stop button stop the DAQ?  Stop the DAQ meaning that the program will need to re-initialize the physical channel.  Can you provide more details about the pause & stop features?  other than Stop resets the graph and the channel settings.

I do not know what you want to do with the invert of the refresh rate to configure the graph display.

Enjoy...

[kmous]

it is getting better 🙂

1-Yes the stop button must stop the Daq and re-initialize the physical channel and also the Daq refresh time. so User can choose another settings (like another refresh rate, another Daq and maybe another file name).

I noticed something , if we stop the vi and do another test using same file , the daq keep writing on the same file ? can we manage that i a way that with new test and same file name , the daq will overwrite the data ?

2-Yea you are right 🙂 The pause button  must pause reading from the DAQ.

3- i noticed sometimes , when i do start at the beginning , the line on the graph goes fast , this is normal i guess at the begining right ? 

4-Check the way I harcoded the refresh rate to 10.  I left the Cluster output intact and you can play with wiring to it..  But I don't think you want to use the refresh rate (1000 ms or more) to be the sampling rate.. Even 500 (ms) is too high for temperature measurements..  For most applications, that is..  You may want to read up on the recommended refresh rates for temperature measurements. 

yea , but the 1 s and 2 sec works fine !!!i did a test with 1 sec and 3 sec , they work fine!!!

I will read about the recommended refresh rates for temperature measurements.  teh asked me before to put 2 s and 5 sec......so i will read about it.

Here what i meant in my previous msg : see attached.

the values are 1000 , 2000 etc so we divide by 1000 to get the 1 s , 2 s

[Dennis_Knutson]

I may be out of line here but personally, I don't want to see this thread get as large as the other thread that the two of you created and since it seems like both of them are more of a client/contractor nature, it might be better to conduct your business through personal emails instead of this public forum.

[kmous]

He is Helping , and please stay out of it.

Thank you

[Dennis_Knutson]

I really don't care if he is helping you or not. From my point of view, you have relied on Ray to do every piece of LabVIEW coding and it is a personal project between the two of you. It does not belong on the forum.

[kmous]

good to know!!