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.

Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

Generate a variable pulse train frequency or clock

I've been trying to raise this on the PXI board (https://forums.ni.com/t5/PXI/Generating-a-variable-clock-pulse-train/td-p/3959809) but realise this may have been the wrong place.

 

I have a PXI 6683H card, and am trying to generate a variable clock - that is, I want to generate some kind of clock, but then vary the clock frequency without completely killing the clock and starting again.  I've tried some hacked up version of Generate Digital Pulses.vi from the example, but that tops out around 40Hz, and I was hoping to vary between 0 and 1MHz or so.

 

I might be able to specify the different clock rates in advance, if that helps.

0 Kudos
Message 1 of 7
(2,555 Views)

I read the linked thread, but am initially answering here.  I have extremely limited experience with niSync devices and API.  I don't have the driver loaded, so I can't really see the subvi's you call.  But it *appears* that you're essentially trying to schedule out timestamps and intervals for when the PXI-6683 should create individual transitions.

 

It's normally easy, nearly trivial, to generate a pulse train whose frequency can be changed on-the-fly using a device with onboard counter/timers.  One starting point example can be found here. 

 

Is there a specific (and valid) reason for needing to do this with an niSync device instead?  If so, I'm afraid I probably can't help.   But if you can do this with a counter instead, I probably *can*.

 

 

-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 2 of 7
(2,529 Views)

Thanks for replying!

 

No reason for niSync particularly, except that the system I'm working on has a couple of 6683H cards in it, and I will struggle to make the case for more hardware.  I do have other cards in the system and some C series chassis, but I doubt any card in the current setup would be able to produce a suitably sized pulse except the 5442 I have, but the output channel on this is unfortunately in use 

 

What would you suggest? 

0 Kudos
Message 3 of 7
(2,521 Views)

Do you have any "standard" DAQ devices that use the DAQmx driver?  What are they?  What's going on that you have 2 separate niSync devices in your PXI chassis?  I thought only 1 would be useful as a timing master, and only when located in slot 2.  (But again, my experience with niSync devices is very limited, so if there's a good reason for 2 such devices I'm willing to learn.)

 

What's the purpose of this variable freq pulse train, and how will it be used?  How often must the frequency be changed?  When changing from one freq to another, how important is it to change at a specific instant in time?  Is it ok to miss by 10's or 100's of millisec, or must it be precise to the microsec?

 

Note:  the vast majority of my NI hardware knowledge and experience is related to "standard" DAQmx DAQ devices.  If you don't (and can't) use any, I'm not sure how much I can help.

 

 

-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 7
(2,516 Views)

I do have a PXIe 6363 card in a different chassis, which I believe has a counter.  The wiring in the system might get a bit messy so it isn't preferable but could be managed

0 Kudos
Message 5 of 7
(2,515 Views)

I appreciate the replies. I have two devices across two chassis to synchronise all the cards so the generate samples simultaneously. But the synchronisation rate is low - everything advances generally on a single figure Hertz rate.  That's true of the frequency of this clock as well, so I'm trying to synchronise the clock change to a PXI trigger line.

 

 

0 Kudos
Message 6 of 7
(2,513 Views)

Oddly enough, my limited experience with niSync *also* included sync'ing across 2 chassis.

 

A. There might be a better method for generating a variable freq pulse train directly with one of your niSync devices.  That will probably be simplest, but I simply don't know enough to say how or whether it can be done.

 

B. My recollection is that I generated certain clock and trigger signals with regular DAQmx device(s) on one "master" chassis which I then routed over to the other chassis.  I accepted the sub-microsecond skew due to signal propagation delays for that particular app.  

 

C. My further recollection is that the signal sharing required configuring several distinct signal path segments.

- export the clock signal from the DAQmx counter device onto a PXI_Trig line of the 1st chassis

- route that particular PXI_Trig line to the external connector on the niSync device in the 1st  chassis.  (are these named similar to PFI0?)

- SMB cable physically connects the two niSync devices in different chassis

- second niSync device configured to route its external connector to a particular PXI_Trig line on the 2nd chassis.  Note: the directionality of this routing matters on niSync devices.  The role of source and destination are different when doing this routing on the 2 chassis

- devices on the 2nd chassis that need the pulse train import it from the PXI_Trig line

 

D. I also remember something similar to the following:

The niSync driver is "greedy" about reserving routings to the PXI_Trig lines.  If I configured the niSync device 1st, I would get errors when configuring the DAQmx devices.  I had to make sure to do all my task config and signal routings for DAQmx devices first.  Once reserved, niSync would respect that and not error out trying to be overly greedy.

 

It's very possible this restriction is no longer true, it's been quite a few years now.

 

 

-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).
Message 7 of 7
(2,509 Views)