Synchronizing SMU (PXI-4139) and DAQ (PXI-4462) OR Synchronizing DAQmx with NIDCPower

[sarlington]

Hello,

I am trying to synchronize the output of a SMU (PXI-4139) to the acquisition on four channels of a DAQ (PXI-4462), they are in a PXIe-1077 chassis with a PXIe-8133 embedded controller. The other slot in the chassis currently holds a PXI-4461. 

In the past, we have successfully synchronized the output from the DAC on the 4461 to acquisitions on the 4462, by synchronizing the clocks to the PXI_CLK10 and exporting a start trigger from the 4462 to the 4461.

However, now that we want to drive the experiment through the SMU (4139), I am encountering issues. Explicitly, I want to trigger the start of an NIDCPower sequence from the start of an DAQmx analog input event. In essence, the SMU is being used as an arbitrary function generator for either current or voltage, and we are measuring the voltage response at four points in the system. The measurements can be quite short and proper synchronization is key. 

I cannot find a means to synchronize the clocks. Is that possible? Even in trying to do a less-thorough synchronizing job, my attempts to export a start trigger from the 4461 to the 4139 have all failed. I tried to route the ai/starttrigger from the 4462 to the digital edge for the 4139, which did not seem to trigger the 4139 at all.  I also attempted to route that start trigger through the back-plane manually, but that did not seem to work either (perhaps I did it wrong?).  The best I seem to be able to do is have LabView start both the NIDCPower and the DAQmx events at the same point, which ends up with between 20-50ms of delay, far from what could be done with reference clock synchronization.

I have looked through the help files and boards pretty extensively, but if anyone has additional suggested reading or can point me towards other working solutions it would be greatly appreciated. If some VI screenshots would help, I can try to provide them - the overall code is quite complicated so I was not sure what to show. 

Thanks in advance!

[Cavarval]

What you propose should be possible.

Clarifying a few things:

1. Are you just trying to synchronize the start of the devices or are you also trying to sync clocks?

2. How are you exporting / importing the trigger?

3. What type of trigger are you setting on the PXIe-4139?

4. This all would be easier if you could share the code. Is this something you can do? If not, at least a snippet of the trigger settings would help.

5. What is the chassis model? PXIe-107x chassis are 1071, 1073, 1078 and 1075. If you are using a 1075, there may be additional considerations depending on what slots are the cards installed on.

6. The PXIe-4462 has a delay caused by the filtering it performs that depends on the sample rate. Please se these:

https://www.ni.com/docs/en-US/bundle/ni-4461-4462-specs/resource/373770k.pdf

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P8toSAC&l=en-US

It will not account for 50 ms, but may be contributing to it.

Regards,

[sarlington]

Camilo,

Thank you very much for your time and help. Sorry for the delay in my response. The forums were not working for me yesterday and kept kicking me to an error page whenever I clicked “reply.”

 I have attempted to answer your questions below.

1. If possible, I would like to have the clocks synchronized as my understanding is that the best possible synchronization is achieved that way.
2. I have attached a screen capture of how I am trying to import the ai/starttrigger to the NI-DCPower event. It does not work, so I can only assume this is an invalid way to manage the import/export. Looking more closely at some examples (such as in Fig. 8 here: https://www.ni.com/en/support/documentation/supplemental/10/synchronization-explained.html) I do not seem to have all the configuration options. Under my DAQmx Trigger property node, I do not have a “SyncType” or a “Start.Term” that I can set.
3. I am setting the PXIe-4139 to a Rising Edge trigger type.
4. I cannot share the whole code (and it would be cumbersome anyways), but I have attached some screen captures.
5. The chassis is a PXIe-1071 – my sincerest apologies for the typo in my original post!
6. That is good to be aware of. When we were synchronizing the 4462 to a 4461, we checked which device had the longest delay and set that as a delay for the slave device(s) after synchronizing their reference clocks, similar to Fig 13 from the linked page above.

Thanks again for your time and input!

Best Regards,

Shane

[Cavarval]

What you are trying to do, wiring the 4462/aistarttrigger directly to a VI expecting a trigger source is called Dynamic Routing. I know it works with DAQmx, but I have never tried it with different drivers (I prefer creating explicit routes). Can you try the following? 

1. Add a DAQmx Export Signal.vi to the 4462 task and set it to export the Start Trigger to a Backplane trigger line (i.e. to /4462/PXI_Trigger0).

2. Set the DCPower Configure Trigger.vi to receive the trigger for the 4139 in the same Backplane trigger line (i.e. from /4139/PXI_Trigger0).

Let me know if that works.

[sarlington]

Camilo,

Thanks for the followup! I tried what you suggested - I think I attempted something similar to this in the past. I still is not triggering the SMU task. I have attached two screenshots from the configurations I tested, one using the DAQmx Export Signal.vi and the other using a DAQmx Export Signal property node.

I also tested a few backplane lines (Trigger0, Trigger 1, and Trigger 4). No luck with any of them. 

-Shane

[Cavarval]

Hello,

About the clocks, I believe SMUs PLL automatically to the backplane clock. I could not find explicit information about this, but the 4139 specs say 

the Sample rate accuracy is "Equal to PXIe_CLK100 accuracy", which can only be true if it PLLs to the PXIe_CLK100.

About the triggers, I setup a PXI-4461 to export the start trigger through a timing card and into a scope and the pulse width of the trigger is about 40 ns. This is not good for the PXIe-4139 because its minimum trigger pulse width specification is 100 ns. Now, I don't have a PXI-4462, I am just assuming the pulse is going to be similar to the PXI-4461.

So, I think the alternative is to do this the other way around, exporting the niDCPower Export Signal.vi to export the start trigger or source trigger (depending on what exactly you are looking for) to the backplane and using it as the start trigger on the PXI-4461. Is this an option to you?

Regards,

[sarlington]

Camilo,

There may be some issue from exporting the signal from the SMU for more sophisticated implementations later on, but for now I think it would be sufficient provided we can achieve decent synchronization. I made the change you suggested, and it seems to have made some progress. I have attached a screenshot of the new triggering setup. 

By exporting the trigger from the 4139 to the 4462, I now at least get both devices to run. However, as when I was trying to initiate them both by software, there is a significant lag between the two. I seem to miss between 300-400 milliseconds of the SMU's pulse on the 4462 collection. 

Is there a way to have a delayed start on the 4139 and instead send a synchronization pulse to the 4162 such that they both start after an arbitrary (adjustable) delay time?

Thanks,

Shane

[sarlington]

As it turns out, if I disabled the imported trigger from the SMU and allowed the software to start reading once it moved into the next loop (an acquisition/live update loop), it reduced the delay to around 50ms. Then, if I moved SMU start command from where it was (a 'Value Change' event structure) to be inside the acquisition loop, it went to only around 3 ms. Finally, I re-enabled the trigger export from the SMU to the DAQ, with the SMU start command in the new location (the acquistion loop, which starts from the 'Value Change' event structure) and now I get a sub 1 ms delay - somewhere around 300 us. 

For now, I think that is all I need! I will admit, however, that I am not entirely certain why this solved the problem. There may be other issues that crop up if I need to synchronize other devices too, but that is likely a problem for another day.

Thanks for your help! 

[Cavarval]

It is hard to tell. Because of how the 4462 internal clocks work, you may have inconsistent behavior. I would test the system thoroughly to make sure results are repeatable.

Synchronizing Delta-Sigma devices like the PXI-4462 with with modular instruments like the PXIe-4139 SMU can be a challenge.

Let us know if you get into any trouble and we'll try to help.

Regards,

[gsosnowski]

I am trying to do the same thing (SMU card ch sweep start to trigger DAQ chs for sample measurements). I understand that the SMU triggers can include Time-based, as outlined below, but wasn't sure if this applied to DAQ as well or if they were just limited to Digital/Analog?

Thanks!

NI-DCPower Synchronization Methods

Synchronization allows you to coordinate the action of multiple NI instruments. There are multiple approaches to synchronizing NI instruments; the accuracy (trigger delay and jitter) of the synchronization depends on the approach you take and the system and instruments in use.

NI-DCPower supports the following synchronization methods.

• Software-Based Synchronization—Sends a software command from a host computer to an instrument. Not deterministic on general-purpose operating systems such as Windows.

  Accuracy: tens of milliseconds

• Time-Based Synchronization—Uses a time-based protocol such as GPS, 1588, or IRIG-B to coordinate events. Can be used over large distances (>10 m). Remote chassis that include a PXI synchronization module can be programmed to generate triggers on the backplane at a specific time.

  Accuracy: <100 ns + NI-DCPower instrument trigger delay and jitter

• Signal-Based Synchronization—Uses trigger signals to coordinate operations. Comprises the following:
  • PXI Trigger Routing—Sends a trigger signal, which corresponds to an event, from one instrument to another through the routes available in a PXI chassis (for PXIe/PXI instruments). The closer the signal paths between instruments are in length, the better the synchronization accuracy.

    Accuracy: tens of nanoseconds + NI-DCPower instrument trigger delay and jitter

  • External Triggering—Sends a signal external to a PXI chassis or, for other instrument form factors, to an instrument through I/O lines. The closer the signal paths between instruments are in length, the better the synchronization accuracy. Time locking improves determinism.