Reading a digital data in labview

[Abbishek94]

Hi,

I am making a program to trigger various components like servo, encoder etc. and the I am planning to generate the trigger from a motion control system. In the motion control system, the signals are being generated to drive a stepper motor. In the motion system, there is a digital output signal which I am using to trigger other components. However, before I moved to trigger it, I wanted to see if LabVIEW is able to acquire the digital signal. I connected the digital output from the motion controller to the digital input port of NI USB-6218. However, when the digital data was received, I didn't see the digital data. So, I took the signal to the oscilloscope. From there I observed that when the digital data is received at the probe, the voltage increased, which means the digital data is being correctly sent from the output channel.

So, I don't understand why is the program not showing the digital input when it is received. The program is attached with the mail. Any help with the program to get the digital data might be helpful.

Thank you

Abbishek

[Kevin_Price]

I've been in a few threads with you and I'm surprised at this code.  I thought you were "getting there", but this code doesn't look like it.  It's time to slow down, pause, think, understand, and learn.

Think carefully about your code and see if you can explain to me (us) why you might not see the trigger signal data.

Hint 1: How long does the trigger pulse last?

Hint 2: How often are you looking for it?

Then, take a look at some of the shipping examples that show how to make tasks that *react* to a trigger rather than using software timing to query the trigger signal value.

-Kevin P

[Abbishek94]

Hi Kevin,

From our previous discussions, I was able to get everything else working with a software trigger. I am just having problems with the hardware trigger since I am new to digital I/O, and do not know much about properly reading digital signals.

The trigger signal from the motion system is kind of step signal. So, once the motor starts running, the digital output becomes a high state. So, that state will last until the motor stops rotating.

But sorry, I am not able to understand why we are not able to see the trigger signal.

Abbishek

[Abbishek94]

Can you please point out what mistake I am making in understanding the digital signal input?

Abbishek

[Kevin_Price · Accepted solution]

The code you posted created an on-demand software-timed query of your digital inputs.  However, you tried to read it as a digital waveform (not really sensible without configuring a clock with DAQmx Timing), then converted it to an analog waveform, wired it to a function that expected "Dynamic Data" rather than an analog waveform, and tried to use that function to convert <whatever the heck you ended up with after all that mess> into a single floating point scalar, which you compared against a floating point 0 to figure out True/False state.  

You could have read directly as a single boolean instead. 

Did you use any debug probes to inspect what was on those various inputs and outputs?  All those unnecessary manipulations could be part of the problem.  Did you try using MAX or a shipping example to inspect the digital state instead of your own (possibly faulty) code?   

You only mentioned that the voltage "increased" on the scope.  Is the voltage compatible with the 5V logic of your device?  Do you know how long the trigger signal stays in the higher voltage state?  Did you try any of the shipping examples that *react* to triggers rather than trying to observe one?   Did you try to generate your own triggering signal using MAX or another shipping example (plus physical wiring to connect your DO and DI lines)?

These are among many things you could do to further diagnose and troubleshoot.  There's a limit to what we can guess -- you're in the best position to experiment and gather more information.

Try MAX.  Try examples.  Try controlling the triggering signal yourself.   Don't think of a trigger signal as something to *read*, think of it as something you want to configure your task to *react to*.

-Kevin P