01-05-2023 10:26 AM - edited 01-05-2023 10:27 AM
Hi. I'm trying to synchronize 2 different DO channels from different DAQ devices.
I'm using the DO channels as a digital boolean 1 line 1 port.
The problem is, because the DO are from different DAQs, they have a time difference when they first start. So, I want to synchronize these two channels. I saw a lot of ways to synchronize DO channels using sample clocks, but as you can see in may case I am not using a sample clock so I just can get to know how to do it.
Please be aware that I am using a 1 line l port digital output.
I would be greatfully thankfull for some advice.
Yoo
Solved! Go to Solution.
01-05-2023 12:32 PM
Put both channels in the same task, DAQmx driver will take care of synchronizing them
01-05-2023 01:45 PM - edited 01-05-2023 01:45 PM
Hi hobbes,
@hobbes4000 wrote:
Hi. I'm trying to synchronize 2 different DO channels from different DAQ devices.
I'm using the DO channels as a digital boolean 1 line 1 port.
The problem is, because the DO are from different DAQs,
In your image both channels are from "dev1", so what exactly are "two different DAQs"?
In your image both channels are even set to the very same hardware line - how should that work?
Why is there a large sequence?
Why don't you use a loop to repeat the same task several times?
Why don't you use arrays?
Which hardware do you use?
Suggestion:
01-05-2023 06:59 PM
Sorry for my mistake. The labels are a typo. The channels are from differant DAQs as I stated. I'm not using a while loop or array, since I just need to operate the sequence 1 time.
Thanks for your reply, and I would be really thankfull for a solution.
Yoo
01-05-2023 08:11 PM
Thanks for your adivce. Do you mean by merging the errors from each channels?
Can I see an example of it?
I really appreciate your answer a lot!
Yoo
01-05-2023 09:27 PM
Software-timed tasks when using the default timing mode of On Demand can never be synchronized as the computer is simply polling the data from the hardware. You must use a hardware-timed timing mode for example Sample Clock for synchronization.
Besides, the tasks must share the same reference clock and the same start trigger. A sample clock is generated from the reference clock and start trigger thus sharing the sample clock provides a simpler configuration but the tasks must use the same sample rate. You can read Synchronization Explained to learn more about this.
Depending on the form factor of the DAQ hardware (PXI, PCI, USB or cDAQ), external wiring might be required to route the clock signals. If you provide the models of the hardware and the desired update rate for both tasks, I might be able to provide more details on the wiring and DAQmx configuration.
01-05-2023 10:10 PM
Thank you so much for your reply. I understand. But the reason I'm not using a sample clock to my digital output is that I want to generate a timed signal as I drawed. Can I still make that kind of timed signal with a sample clock? Also, in my understandings, sample clocks are used for continous signals, but I don't want continuos signals. The devices I am using are both PCI-6259, and Im not sure about the update rate. The update rate is probably not an important issue to me.
Thanks once more. It really helped
Yoo
01-06-2023 12:05 PM
If you are using multiple channels from a single PCi-6259, the example provided by GerdW at 3rd message is what you need. You can include multiple channels in a single task such that the hardware receives the command at the same time. See NI-DAQmx Syntax for Specifying Physical Channel Strings.
However, you should be aware that the the wait time between pulses is still software-timed without using sample clock. You can use sample clock timing for finite acquisition. Once you are done with the acquisition or output, call DAQmx Clear Task to release the resource so that the sample clock can be used for the next operation.
According to the spec of PCI-6259, the DO does not have a dedicated sample clock but supports correlated sample clock. The DO task can use the sample clock from AI, AO or counter. See DAQmx Multifunction Synchronization with Shared Sample Clock for an example of how digital task can use the correlated sample clock of analog task.
01-08-2023 07:25 AM
I'm trying to synchronize two DO channels from two differant DAQS. I see that my signals have a time delay. When using the channels from the same DAQ, I see no time delay. Also, I'm using a non continous DO signal for my signal. I know how to synchronize two differant continous signals, but as I said, I'm using non continous signals.
Here's my question
=>
I just want to get rid of the time delay of my signals. Since I see no time delays when using the channels from the same daq, I thought that synchronizing the start clocks can solve this problem. I'm thinking about using a "dummy" continous signal to synchronize my non continous signals. Will it work? Or is there another way for the synchrnoization? Here are the block diagram, front pannel, and an illustration of the signals I want.
Again, I repeat. The DO channels are from differant DAQs. The're not from the same DAQs.
Also, the're non continous DO signals.
Each DAQ is a PCI-6259. I'm using two PCI-6259 for my DAQ.
I'd be very greatfull for specific block digrams or detailed explinations.
Thank you.
01-08-2023 08:26 AM - edited 01-08-2023 08:27 AM
Assuming you have a good reason for needing to produce identical DO timing from 2 distinct PCI-6259 devices, here's what I'd suggest:
1. Inside the PC, connect the 2 devices with a 34-pin RTSI ribbon cable. The RTSI bus allows desktop PCI and PCIe devices to share timing signals.
2. In MAX, add this new RTSI cable "device" and declare which 6259 devices are attached to it. Now DAQmx will be aware that each device is able to share timing signals over RTSI. (There is no auto-detection of RTSI for desktop PCI or PCIe devices.)
3. You *need* to use hardware-clocked DO tasks to sync the timing of your DO signals. No way around it.
4. You need to supply a sample clock signal for your DO tasks -- they can't create their own on M-series devices like the 6259.
5. I recommend you generate a sample clock signal using a counter pulse train task.
6. In your code, both DO tasks should use the counter output as their sample clocks. AND you must make sure both DO tasks are started *before* starting the CO pulse train.
7. You must also figure out exactly what your DO signal buffer needs to look like to generate the DO signal timing you want, given the timing resolution you want and the pulse train frequency (which becomes the sample clock rate).
8. You also need to decide whether to approach this with finite DO tasks that you start and stop in software, continuous DO tasks that keep repeating the same signal timing output until you stop the tasks in software, or continuous DO tasks that do *not* repeat but require you to keep feeding them new data until you stop them. There may also be similar options to consider for the pulse train task that supplies the sample clock.
Best choices for #8 depend on what happens *outside of* the part of the timing diagram you've sketched. Does something trigger the t=0 point? What happens after the 100 msec pulse width? Will you repeat the 2 pulse pattern sometime in the future? When? Is is based on a defined delay, a hardware trigger, or a software decision?
-Kevin P