From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

Digital I/O

cancel
Showing results for 
Search instead for 
Did you mean: 

Manchester Bits generation

Solved!
Go to solution

 

Hi!

 

I am trying to generate a Manchester code through a digital output of the PXIe-6612 module.

 

In the attached VI, I am able to generate a Manchester code over 1ms clock. This means that as each bit is encoded in a low-to-high or high-to-low transition, each bit actually takes 2ms to transmit.

 

The thing is that I have to generate the signal with a period of 500us --> I would need to execute the loop every 250us.

 

Which is the best way to do this? I am a newbie in LabView.

 

Any assistance would be appreciated.

0 Kudos
Message 1 of 11
(2,685 Views)
Solution
Accepted by topic author Erlie

You will need to create a digital waveform task and output that through the DIO board.  This takes the timing away from your software (which will be slow) and puts it on your board (which is actually made for this).  Open the example finder (Help->Find Examples) and go to Hardware Input and Output->DAQmx->Digital Output->Digital - Finite Output.vi.  That example should be what you are looking to do.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 2 of 11
(2,668 Views)

Thank you very much for answering!

 

Actually, I have taken the "Digital - Continuous Output.vi" example, as I would like to generate the same code continuously, so I think that this example would fit me better. Am I right?

 

First, I am trying to make the example run in my HW, and then, to modify it to adapt it to my needs.

 

But, I think that there is something that I don´t understand in the example, since I can´t configure it correctly so that I can see that the outputs change their values.

 

The configuration that I am using is the following for PXIe-6612, which in my case is in Slot 2:

  • Line(s): PXI1Slot2/port0/line8:14
  • Sample Clock Source: /PXI1Slot2/PFI0
  • Sample Rate: 1000
  • Number of Samples: 1000

Please, could you tell me what I am not configuring well?

0 Kudos
Message 3 of 11
(2,658 Views)

You configured your task to use a signal at PFI0 as your sample clock.  Have you routed such a signal to PFI0?   You'll need to, otherwise there won't be a clock-like signal (a digital pulsetrain) there.

 

 

-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 4 of 11
(2,654 Views)

How can I route a sample clock to PFI0?

 

Or, is there any better way of using an internal sample clock directly?

 

I´m sorry, but I´m new in LabView.

0 Kudos
Message 5 of 11
(2,643 Views)
Solution
Accepted by topic author Erlie

Lucky you, your device is a newer design that can derive its own sample clock for DO tasks.  So if you're working on a modified version of the shipping example, you can just select "OnboardClock" and DAQmx will figure out the rest for you.  (The same would be true if you simply left the corresponding input on DAQmx Timing.vi unwired.  That would tell DAQmx to do the default thing, which is to derive a sample clock from its internal timebase.)

 

 

-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 6 of 11
(2,640 Views)

Thank you very much for your reply Kevin!

 

I have configured it as "OnboardClock", but the output doesn't change. I should be doing something wrong, I don't know if it is in SW, HW...

 

Attached you will find the vi I am using. Any idea?

0 Kudos
Message 7 of 11
(2,630 Views)

I forgot to attach the vi, here it goes!

0 Kudos
Message 8 of 11
(2,628 Views)

No errors though, right?

 

As posted, the default value of the 'number' control is 0, leading to an unchanging stream of 0 values (False) being generated.  Did you run it with any non-0 bits in the 'number' control?

 

What are you doing to try to detect changing bits?  The default sample rate is 1000 Hz, so you wouldn't be able to see distinct changes if you're probing the output voltage with a multimeter for instance.

 

 

-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 9 of 11
(2,595 Views)

Yes, of course I have run the vi with different non-0 "number" values, but even the program runs without any error, the output doesn't change. I'm measuring the output with an oscilloscope and I'm expecting signal at 1ms period. The signal I see is a constant 0.

 

In case of executing the vi that I attached in the first comment of this thread (DigitalOutput_ManchesterBits.vi), I do see that the output signal changes.

 

Any idea of what I'm missing in "DO_ContinuousGeneration.vi"?

 

My aim is to generate a Manchester code type signal from an input value (number). But as a first step, I want to be able to generate a signal continuously. Once this is done, I will modify the "number" array to adapt it to Manchester code.

0 Kudos
Message 10 of 11
(2,566 Views)