LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Problem with generation pulse (Width) by Counter

I met strange problem that pulse was restricted by ~75 ms.
 
My full system consists of 2 PCI card.
PCI-6711 has 3 tasks. First task is 4 channels AO. These work from external trigger and external clock. Second task is Counter0 that generate one Pulse from external trigger (Initial delay and Low are 10E-6 sec; High can be from 1 ms to 0.6 sec) . Third task is Counter1 that measure Width of external Pulse (from 100 us to 1 ms). (Actulally, here I met another problem. Task one (AO) and task 3 (measure width) can't use together DMA data transfer. When I initialize in order task 3 -> task 1 then LabVIEW give error immediately. When I initialize in order task 1 -> task 3 then LabVIEW gives error after some minutes when I read data of task 3. I set that task 3 use Interrupt and it helped. But according manual PCI-6711 has 3 DMA channels and  one DMA channel can be used per task. So here is definetely a bug also.)
PCI-6111 has 2 tasks. First task is AI that grab 50 kSamples on 1MHz rate from external trigger. Second task is the same as second task of PCI-6711.
 
According manual of PCI-6711 I can changed width on-fly by changing Set Width High parameter. But it didn't work. So I added Stop and Start and it worked fine when I tested only Counter with single task 2.
When I started to use this approach in full program the pulse became restricted ~75 ms. For example, program set s High Width 0.4 s but scope showed ~75 ms. Also it worked fine (changed) below 75 ms. Moreover, when I read parameter it gave me correct value 0.4 s. Finally, after some changes I began to set all 3 parameters Initial delay, Low, and High. I also deleted Stop and Run. That helped me to get long pulse. But it, definetely, is bug ..., actually, 2 bugs because readback was incorrect also.
0 Kudos
Message 1 of 19
(3,802 Views)
Hey Vasilich2004,

I am not clear on what exactly you are doing that is causing the problem and how you are receiving the errors? When you are initializing your tasks, what error does LabVIEW give you? Can you post a screenshot?

Also, I am not seeing any reference to a Set Width parameter in the 6711 user manual or seeing anything about changing it on the fly. I have attached a link to the manual below. Can you post a screenshot of your VI? Maybe this will better help explain why your pulse is being restricted to 75ms.

PCI-6711 User Manual
http://digital.ni.com/manuals.nsf/websearch/9EB2F4E475DF58928625730900584FF3
Regards,

Chris Delvizis
National Instruments
0 Kudos
Message 2 of 19
(3,774 Views)
Hi Chris_D
 
I attached vi. Dev1 is PCI-6111. Dev2 is PCI-6711.
 
According DMA confilct problem.
At first moment, the program didn't set CI.DataXferMech of Dev2/Ctr1 (CI Pulse Width).
If program would initializes Dev2/Ctr1 and Dev2/AO Voltage later it gets error immediately.
If program would initializes Dev2/AO Voltage and Dev2/Ctr1 later it doesn't get error immediately. It gets DMA error later in loop when Dev2/Ctr1 reads.
Now the program sets CI.DataXferMech to Interrupt and avoid this problem.
 
According ~75 ms restriction. Dev2/Ctr0 or Dev1/Ctr0.
Now the program changes CO.Pulse.HighTime, CO.Pulse.LowTime, and CO.Time.InitialDelay. At the beginning, the program changed only CO.Pulse.HighTime and was rounded Stop function from left side and Start function from right side (in another case it didn't work). It worked but real pulse CO.Pulse.HighTime wasn't more than  ~75 ms. At the same time I have test program that have only this task. It works Ok.
 
0 Kudos
Message 3 of 19
(3,761 Views)

Hey Vasilich2004,

Your code is very hard for me to follow because there is so much of it. I would highly suggest making your code more modular especially with some of the measurement calculation functions by using sub VI's. This will make your code much more readable and easier to debug.

You should have no problems running 2 counters tasks and an analog input task at the same time even when they are all configured to use DMA. I think you are having problems doing this due to the implementation of your code. I was not able to run your code and therefore could not reproduce the error message you are seeing. Can you provide a screenshot or simplified example that shows this error?

I also think the 75 ms restriction may be due to your while loop. This is why the test program you mention works, but your main VI does not. Remember that everything in the loop must be executed before it moves on to the next iteration. Also, because of LabVIEW dataflow, VI’s in the loop will not execute until others are finished executing. If the entire loop takes 75 ms to execute, then the loop will only execute once every 75 ms.  This means your counter read may not execute until your AI read is done. Writing to file will also slow us down even more. I would suggest separating your DAQ tasks out into parallel loops and using the produce/consumer loop architecture to process the measurements.

Application Design Patterns: Producer/Consumer
http://zone.ni.com/devzone/cda/tut/p/id/3023

Let me know if you have further questions.

Regards,

 

Regards,

Chris Delvizis
National Instruments
0 Kudos
Message 4 of 19
(3,739 Views)
Hi Chris_D,
 
I agree that that my code is not perfect. But that is research project, the program is very primitive, and it is small part of whole system. Again, I know about multithreading Smiley Happy But in this case state machine is measurement -> calculation - > apply to NEXT measurement. I doubt that anyone will make 2 states machines and use produce/consumer technique between states machines in this case. If you like we can continue discussion when we need to use multithreading/state-machine/multi-layers/objects and so on.
 
Now let me come back to NI card problems ...
I restored a program (changes initialization flow) and now Counters are initialize at first, then AO. I attach 2 print-screens with DMA error and without error during initialization. I marked a change by red circle in "without error" print-screen. I also show NI devices on back front.
 
75 ms restriction can't connect to while loop. At first, this subsystem depends of FTICR mass-spectrometer that has > 1 sec cycle. At second, I also check that program in while loop takes ~10 ms for 32 KSamples FFT.
 
Thanks, Andrei
 
0 Kudos
Message 5 of 19
(3,663 Views)
Forgot to attach ...
Download All
0 Kudos
Message 6 of 19
(3,661 Views)

Hello,

I realize that the linked KnowledgeBase (KB) is in reference to E series devices.  However, a common timing system is used in the PCI 6711 that relates to the known issue.  Please refer to the following KB for reference.  You seem to already be on the right track by starting the AI prior to the counter task in the posted code.

KnowledgeBase 2ZKDKLB9: NI-DAQmx Error -200079 Returned While Performing Counter and Analog Output T...

Samantha
National Instruments
Applications Engineer
0 Kudos
Message 7 of 19
(3,627 Views)
Samantha hi,
 
Thank you for your answer. I do searched in NI cite and couldn't find that issue.
 
Unfortunately, that is half answer about incorrect AO behavior. If program will use correct order during initialization and will not use "Interrupt" data transfer then the DMA error comes after some minutes in the loop.
Also do you have any idea about 75 ms restriction?
 
0 Kudos
Message 8 of 19
(3,616 Views)
Hello,
 
So after using the recommended order from the KnowledgeBase and using DMA for the CI on the 6711, you are still getting a DMA error, right?  What is this error number?  Is it the same as before (error -200079) or did the recommended order for starting the tasks resolve the 200079 error? 
 
If you don't mind I would also like to better understand the 75 ms pulse width restriction.  You are trying to change the pulse width of a CO on the fly and if you just set the High Time input on the fly you cannot get a pulse width larger than 75 ms.  This issue does not occur if the task is running in a program by it self or if all three inputs (High Time, Low Time, Initial Delay) are adjusted on the fly in the main program.  Thus, the main level program is working with all three inputs, but you want to know why the restriction / bug was there previous.  Please let me know if I have misinterpreted summarizing the previous posts or any details.
 
I am curious to know if the ~10 ms loop time you referenced is for the posted code's loop, where you are acquiring 32 KSamples via AI and preforming an FFT and the other CO and CI tasks.
 
I am sorry for all the questions, but I want to make sure I am on the same page as you and with what is going on with the two issues.
Samantha
National Instruments
Applications Engineer
0 Kudos
Message 9 of 19
(3,599 Views)
I am also interested to know version of the DAQmx driver is on your system.
Samantha
National Instruments
Applications Engineer
0 Kudos
Message 10 of 19
(3,595 Views)