LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Labview Digital output error code -200479

Hello everyone,

 

I have an issue with my LabVIEW code. I am using this program to control an external system(With a DAQ module).

 

In the execution of my code, I have a sequential logic that is executed until a certain condition is reached. In parallel to this, I have two digital outputs to activate continuously at the beginning of the program and to deactivate at the end of the program, with a 100 ms interval each time between the activation or deactivation of the two digital outputs. So:

 

  1. Activation Output 1 -> 100 ms wait -> Activation Output 2
  2. Sequential logic until the desired condition is reached
  3. Deactivation Output 2 -> 100 ms wait -> Deactivation Output 1.

 

When I tried to test the code on the real system, this error appeared from the part of the code that manages the 2 digital outputs:

 

MinHolly_1-1720368098541.png

(Screenshot from NI website)

 

Could someone enlighten me on this? I don’t understand where the error is coming from.

Also, is there a BETTER way to code these  digital outputs activation with the necessary 100ms interval?

 

Here is the relevant part of the code:

MinHolly_0-1720367888701.png

 

 

I have also attached the VI. For confidentiality reasons, I have not posted the entire code.

 

Thank you for your time.

0 Kudos
Message 1 of 4
(422 Views)

Basically,  you are trying to "Start" a Task using the DAQmx Start Task.vi while the Task is already running.  That error is the equivalent of the noise you hear when you engage the starter of your car with the engine running. (I wish my car would just throw an idiot light and not activate the Starter Solenoid)

 

Fun Fact about that call to DAQmx Write.vi:  The default value for the optional input "Autostart" is TRUE.   So, when you call that vi on a continuous output Task. The value is Written and the Task Runs using that output value until you call DAQmx Stop Task.vi (or Abort) or you Write a new value.

 

BETTER: Do all of your Task configuration exactly once before any loops. Then just Start (or Autostart) the Tasks inside your loop and Stop / clear the Tasks only when you are ready to exit the program. 

 

BEST: Save the Task Configurations in A) your LabVIEW Project or B) MAX and use a Task Constant to "Load" that pre-configured Task to LabVIEW for use in your code with no need to reconfigure the Task at runtime. 


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

Thank you for your response.

In my case, since I want it to run continuously, I should remove the DAQmx Start Task.vi, right? And let it run continuously(with the autostart) until I stop it with the Stop Task.vi.

Thank you for your recommendation. Also, is there any other way I can trigger my two outputs with a 100ms interval other than using a wait function in the sequence? I feel like there must be something better than that.

 

Thank you for your help.

 

0 Kudos
Message 3 of 4
(368 Views)

@MinHolly wrote:

Thank you for your response.

In my case, since I want it to run continuously, I should remove the DAQmx Start Task.vi, right? And let it run continuously(with the autostart) until I stop it with the Stop Task.vi.

Thank you for your recommendation. Also, is there any other way I can trigger my two outputs with a 100ms interval other than using a wait function in the sequence? I feel like there must be something better than that.

 

Thank you for your help.

 


Yes, just let Autostart do the work.

 

Timing, yes, for Software timing a Wait function is acceptable.   Better yet would be to:

  • Configure both Tasks first
  • Merge the Error wires out of each Task Configuration Code ( Use Merge Errors primitive)
  • insert a "Stall Dataflow.vim" on the Error wire between the two DAQmx Write.vis

There is a finite amount of time needed to configure each Task and you want it all done first.

 

Depending on what HARDWARE you are using you, could use a hardware trigger to delay the two outputs with better timing.  You would really need to have very tight timing requirements to make it worthwhile. 


"Should be" isn't "Is" -Jay
0 Kudos
Message 4 of 4
(354 Views)