LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to syncronize sample clock to digital read and write simultaneously with USB-6341

Solved!
Go to solution

Hey there,

 

I´m trying to build a VI to implement a software-based SPI with a USB-6341.

With that programm wi want to write to a serial-in shiftregister and a serial-out shiftregister at the same time.

Therefore i want to digital-write at 3 lines and digital-read at 1 line on port 0.So at the end it can provide a clocksignal, chipselect, MOSI and MISO.

All these actions should be timed with the same clock to run read and write simultaneously.

I attatched the current VI so you can have a better idea of what i want to do.

In this example i tried to use the timing.vi twice, but I´m not sure wether the write and read actions are performed one after another or started in parallel just with the Sample Clock out of sync.

 

I'm rather new to LabVIEW and also to this forum, so please feel free to give me some tipps and tricks to place my questions more precisely.

I´m using the 64-Bit Version of LabVIEW 2020.

 

Vinc

0 Kudos
Message 1 of 8
(980 Views)

unfortunately, you missed attaching the VI.

 

You can make a DO and DI task sync by sharing the sampling clock and using start triggers.

Santhosh
Soliton Technologies

New to the forum? Please read community guidelines and how to ask smart questions

Only two ways to appreciate someone who spent their free time to reply/answer your question - give them Kudos or mark their reply as the answer/solution.

Finding it hard to source NI hardware? Try NI Trading Post
0 Kudos
Message 2 of 8
(960 Views)

Thanks for your fast reply.

Something seems to went wrong with uploading the file.

Hopefully it's working now.

 

I'll try that out and give you some feedback when I´m back in lab.

 

Have a nice day

Vinc

0 Kudos
Message 3 of 8
(956 Views)
Solution
Accepted by VincKoch

This is the exact technique you need to implement- https://www.ni.com/en-us/support/documentation/supplemental/10/synchronization-explained.html#:~:tex...

santo_13_0-1642691197414.png

 

Santhosh
Soliton Technologies

New to the forum? Please read community guidelines and how to ask smart questions

Only two ways to appreciate someone who spent their free time to reply/answer your question - give them Kudos or mark their reply as the answer/solution.

Finding it hard to source NI hardware? Try NI Trading Post
Message 4 of 8
(948 Views)

That whole linked article is an excellent resource!   I don't think I've read that all through before...

 

I've dealt pretty exclusively with systems and apps where I don't need the extraordinary fine detail available through careful config of the Sync Pulse and Reference Clock.  I've been able to "get away with" merely sharing a sample clock signal and accepting the 10's of nanoseconds skew that might result.

 

I'll probably still often advocate sync via sample clock alone, but I'll be more likely to think twice before I do.

 

Note to OP: in santo_13's snippet, you would need to start Task 2 first so it's ready to receive and react to the 1st sample clock from the master task.

 

 

-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 5 of 8
(941 Views)

Sharing the sample clock like you showed in your post is now working.

Now i got a problem with the aquisition of the output, when i shorted the write and read pins (line 2 as CLK_line and line 1 as MISO_line).

I expected the read-array to be the same as the write-array. The problem is, as you can see in the screenshot, that there is always the bit in the same position and also the bit in the following position recognized as "high". I tried to vary the sample rate and also the number of bits to write, but there was no difference.

It seems that the on-times in the output are a bit longer than it should be. That would explain, why there are always two bits "high", but i can´t measure when the aquisition exactly happens.

Does anybody know what's the reason for this issue and how to fix it?

 

Vinc

Download All
0 Kudos
Message 6 of 8
(913 Views)

Only had a moment for a quick look and I fixed one thing -- making sure that the AO task is started *last* because it's the source of the shared sample clock.

 

 

-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
(904 Views)

Many thanks for your help. Everything is working now.

 

Have a good day

Vinc

0 Kudos
Message 8 of 8
(856 Views)