LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

DAQ Digital Output custom Baud and waveform

Due to the special circumstances of the project, it is necessary to use the DO and DI of DAQ to output and receive digital signals and communicate with standard UART devices at a specified baud rate. The DAQ card I am currently using is PCI-6221. I am first short-circuiting P0 and P4 to confirm whether it can realize self-emission and self-reception of custom waveforms, but I have encountered some problems:

  1. I modified the Digital Finite Output example in Labview to custom waveform output, but there was an error after running the vi.RIchardLee0_2-1690184499350.pngRIchardLee0_3-1690184589896.png

     

  2. I used Digital Finite Input to receive, but there was an error that the signal could not be received.RIchardLee0_7-1690184652685.png

     

    RIchardLee0_5-1690184624602.png

     

So I have some questions:

  1. How can DAQ achieve custom waveform output and control the baud rate?
  2. Can directly short-circuiting P0 and P4 achieve self-emission and self-reception of waveforms?

The waveform is like:

RIchardLee0_1-1690184347213.png

bit time is 4.34us (baudrate: 230400)

 

If anyone can answer, I would be very grateful.

0 Kudos
Message 1 of 8
(776 Views)

You did not set the default values for the front panel controls. What is your sample clock source and sample rate?

 

NI 6221 only supports digital waveform at Port 0 with sample clock frequencies from 0 to 1 MHz only. The closest bit time you can get is 4 uSec.

The datasheet also states that The digital subsystem does not have its own dedicated internal timing engine. Therefore, a sample clock must be provided from another subsystem on the device or an external source. 

 

Message 2 of 8
(724 Views)

Thank you for your reply.
I just tried selecting Ctr0Source as the sample clock on the front panel and it ran without errors. I will continue to make progress.
Previously, when I chose other sample clocks (PFI0, RTSI0, aiSampleClock, aoSampleClock), I still received the same error after running the VI. Are these clocks not usable for DODI?

0 Kudos
Message 3 of 8
(709 Views)

@RIchardLee0 wrote:

Previously, when I chose other sample clocks (PFI0, RTSI0, aiSampleClock, aoSampleClock), I still received the same error after running the VI. Are these clocks not usable for DODI?


PFI0 and RTSI0 are just digital lines. You can connect external clocks to them.

For aiSampleClock and aoSampleClock, you need to create a dummy task to generate the clock.

If you specify those channels without supplying any clock signal, no samples will be acquired and you will be getting error -200284

0 Kudos
Message 4 of 8
(703 Views)

It seems that Ctr0Source does not support high sample rates:

RIchardLee0_0-1690252926819.png

So, to use PFI0 and RTSI0, I can only connect an external clock. Currently, I only have one 6221 card, so my choice is to use the ai and ao clocks. I need to create a virtual task in the VI to use them.Is that right?

 

0 Kudos
Message 5 of 8
(693 Views)

The sample rate is too high for the CPU to write enough data to the onboard FIFO.

Try to use the DMA transfer method instead. Configuring the Data Transfer Mechanism (Interrupts or DMA) in DAQmx and Traditional DAQ

0 Kudos
Message 6 of 8
(652 Views)

You should create a clock using a counter task.  I don't know why you didn't get errors when designating "/Dev1/Ctr0Source" as your DO sample clock source because that alone shouldn't have particularly helped.

 

To start, just open up a shipping example for continuous pulse generation.  Generate continuous pulses with Ctr0 at a requested frequency of 230400 Hz, and choose a PFI pin as the output terminal for those pulses.  Start the task then come back to this DO app.

 

Specify that same PFI pin as the sample clock source and try running your DO app under *those* conditions.

 

Notes: as mentioned by ZYOng, the pulse frequency you can actually achieve won't be exactly the baud rate you want.  By requesting what you want, DAQmx will give you a neighboring frequency that's actually possible.

    Also, I'm not up on the details of UART timing but I kinda wonder whether you might need to do some further tricks to make sure your data bits are valid at the instant the clock transitions.  On the DAQ device, the clock edge causes the data bits to transition to their next state, so the data bits may not be stable and valid for some very brief period of time.  You may need a scheme that accounts for that, but again, I don't know enough about UART details to say for sure.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 7 of 8
(645 Views)

Yes, you are correct.
Currently, I use a counter clock as the DI's clock and an AI's clock as the DO's clock because the device requires different baud rates for input and output. This setup allows for transmission and reception.
I use 1Mhz for the input clock, and the input baud rate is 166666, which is 6us/bit, collecting 166666 samples.
I use 230400Hz for the output clock, and the output baud rate is 230400, which is 4us/bit.
At present, I want to convert the signals collected from the input into byte data, with 1 start bit, 7 data bits, and 1 stop bit, each bit should be 6us.
However, when I use the received waveform directly to transform it to Binary U8, the program treats 1us as 1 bit unit, a 6us 0 would be transformed into six 0, sometimes seven 0.

RIchardLee0_0-1690448184123.png

 


I wonder if there is any other function in LabVIEW that allows me to convert a digital waveform into binary numbers using a specified bit time (dt)?
I am attaching my program below, the data received begins at 0.0363 seconds.

RIchardLee0_1-1690448236621.png

 

0 Kudos
Message 8 of 8
(629 Views)