LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

cDAQ-9188 problems

I have a complex task with cDAQ-9188 and four NI 9402. Now for component testing I trying build simple vi.
And have some problems.
First of all, I start VI and al tasks return "no error". After stop and start VI one of DO task return -50103 error (resource busy). It may be first or second task but not both of them.
And I should on-off cDAQ to get working again. I'm not shure this is DAQ or windows problem (win xp and strange ethernet cards).

Then I'm trying build such system:

pulses.png

 

 

Bottom of img is reason why I can't use counter output as gate counter input. Pause increase continuously.

so, I have signal from external device. This signal is pulses which I should count. But device is expensive and for safety I working with simulated signal. With rising gate signal I need counter reset. And with falling gate signal I need counter result move to buffer.

I built task for gate signal (first line of VI). There are buffered DO with regeneration disabled and continuously updating signal.

I built task for device signal modeling (2nd line of VI). There are buffered DO with regeneration. Signal updated with user command.

And I built task for counting pulses.

ctr.png

 

Gate lines for example dev1/port0/line1

Test pulse line for example dev2/port0/line1
counter = dev3/ctr2

CI.CountEdges.Term = dev3/PFI 1

pause/reset term = dev3/PFI 3

 

And finally I connected dev1/port0/line1 with dev3/PFI 3
and  dev2/port0/line1 with dev3/PFI 1 by wire.

DO tasks work (tester show me signal on terminals).
And buffering ctr seems work to (I get updating of Waveform Chart). But all values is 0. So counter count nothing.

Have somebody ideas where is mistake or reason of problem?

 

main VI in archive gate_test.vi

0 Kudos
Message 1 of 5
(4,659 Views)

That vi is not shutting down correctly! Problems:

  • Top loop is using a latching boolean that the second loop has a Value Change event registered for.  This is bad juju Latching booleans with a registered VC event need to be in the case that handles that event which means you need some new method to shut down the top loop.
  • The event loop Stop VC event should just simply output a T constant- I'm not sure what will happen if the latcher is reset before the new value is read- you might find a bit of a bug there since two VC events are thrown one when the button is pressed and one when the termial is read.
  • The bottom loop should shut down fine
  • The third loop can't shut down at all! the ctrl ref is read once, given a value of F and nothing sets the value T

Given that the only way you are stopping that vi is by hitting the Abort button! (you probably do hit the Stop button first) Doing that means the unexecuted code never executs and DAQmx does not release the resources of the tasks in the uncompleted loops

 

Suggested fix:

  1. Use a Notifier with a -1 timeout and a boolean data type to stop loops 1,3
  2. Put the stop button where it belongs and write a True value to that notifier in the Stop VC event case

Additionally you have other troubles you are seriously abusing ctrl refnums:

  1. Knob Value (signalling) can only be written once.  Change that Event case to fire on freq, Hz VC AND duty cycle (%) VC and unload that control ref entirely
  2. Bool refenum and all assocated property nodes should be hunted down and shot.

"Should be" isn't "Is" -Jay
0 Kudos
Message 2 of 5
(4,636 Views)

Sorry Jeff, but you say nothing true.
It seems you don't see attached VI.

--->>
Top loop is using a latching boolean that the second loop has a Value Change event registered for.  This is bad juju. Latching booleans with a registered VC event need to be in the case that handles that event which means you need some new method to shut down the top loop.
<<---
stop button is switch mode.
And placing latch button into event case necessary only for reading and button's "bounce".
In next picture

2loops.png

When user press button, system generate event "value change" with new (TRUE) value. And 2nd loop will finished after event process. First loop get value (TRUE) because button latched before first reading. So both loops stop correctly.

 

--->>
The event loop Stop VC event should just simply output a T constant- I'm not sure what will happen if the latcher is reset before the new value is read- you might find a bit of a bug there since two VC events are thrown one when the button is pressed and one when the termial is read.
<<---
But I'm shure you need study more about Event structure.

 

 

--->>
The bottom loop should shut down fine
<<---
All loops stops fine. You can run my VI and press stop button. SURPRISE, vi finished.

 

 

--->>
The third loop can't shut down at all! the ctrl ref is read once, given a value of F and nothing sets the value T
<<---
Really? But how I finish VI by stop button every time?
Ctrl ref is read once but property node read every iteration. More than, the button in switch mode, and I set F value at the VI's beginning (see left side).

 

 

--->>
Given that the only way you are stopping that vi is by hitting the Abort button! (you probably do hit the Stop button first) Doing that means the unexecuted code never executs and DAQmx does not release the resources of the tasks in the uncompleted loops
<<---
Hm, are you clairvoyant? How you know what am I do?
I repeate: VI stoped by stop button every time. No once abort or somethig like that.

 

 

--->>
Suggested fix:

    Use a Notifier with a -1 timeout and a boolean data type to stop loops 1,3
    Put the stop button where it belongs and write a True value to that notifier in the Stop VC event case
<<---
I'm surprised again. Are you serious? Notifier with a -1 timeout newer get timeout. So, loops 1,3 makes one iterations and will waiting stop. And how you think to get working of that loops?

 

 

--->>
Additionally you have other troubles you are seriously abusing ctrl refnums:

    Knob Value (signalling) can only be written once.  Change that Event case to fire on freq, Hz VC AND duty cycle (%) VC and unload that control ref entirely
    Bool refenum and all assocated property nodes should be hunted down and shot.
<<---
Look at original diagram (I'm sure you don't open it).

l2.png

I set 0-filled buffer to DO and want to get real signal with default values. Easiest way set one of parameters to "change".

0 Kudos
Message 3 of 5
(4,606 Views)

Hi Artem.SPb,

 

You have two hardware timed DO tasks. The 9188 chassis only has one DO timing engine, which means it only supports 1 DO task. However, a task can have multiple channels. I think channel expansion is another way to get around it. Here are a few KBs on the related topics.

 

Number of tasks per chassis: http://digital.ni.com/public.nsf/allkb/5E0B829E50ADE1BC86257AC50062B2D2

Multiple Channels per task: http://digital.ni.com/public.nsf/allkb/A3A05920BF915F1486256D210069BE49

Channel Expansion: http://digital.ni.com/public.nsf/allkb/B7E7C6A92467E5438625792E0067ED80

 

Ren H.
Applications Engineering
National Instruments
Message 4 of 5
(4,572 Views)

Thanks Ren, it is important information.

0 Kudos
Message 5 of 5
(4,556 Views)