Ah ah, you are killing me, so much easier. And completely improves my understanding. I am reworking my scripts 😉
I wrote a similar code yesterday but it was failing:
nidaqmx.errors.DaqError: Trigger line requested could not be reserved because it is already in use.
Property: DAQmx_Exported_10MHzRefClk_OutputTerm
Makes sense, I was still exporting manually the 10Mhz clock on RTSI0 thus there was a theoretical resource conflict even if it would achieve the same => task_master.export_signals.export_signal(nidaqmx.constants.Signal.TEN_MHZ_REF_CLOCK, "/Dev1/RTSI0")
Sharing also some experiments for the community:
- if I remove this export or set it to RTSI2, it works fine
- I also export manually the start trigger to RTSI1, if I move this to RTSI0, same kind of conflict:
nidaqmx.errors.DaqError: Specified route cannot be satisfied, because it requires resources that are currently in use by another route.
Property: DAQmx_Exported_StartTrig_OutputTerm => right, the framework reserved RTSI0... and I try to also reserve it
I can then conclude that a lot can happen under the hood, reserving RTSI routes 1 after the other in an incremental order. And it is better to leave it under the hood because it works (no PLL lock issue) 😉
For NI I would suggest to add this in the examples. I was not at all thinking about that (for Linux) because:
- some examples use cfg_dig_edge_start_trig on same card like playrec.py and ai_ao_sync.py so I was OK with the use of ai/StartTrigger (vs RTSIx) and it did not ring any bell to me
- there is a lot of use of Dev1/PFIx so I thought the exact naming of terminals was the way to go (but PFI is not like RTSI, RTSI is handled automatically by the framework)
- the only "right" example is PXIe one, it was not helping me for sharing the master OnboardClock to the slave BUT I could have paid attention to the PXI1Slot7 slave triggering on /PXI1Slot3/ai/StartTrigger from master. Still that was PXIe so I thought it was specific, my bad
