12-06-2012 08:14 AM
I already post this question in another post, but i didn't have any answer, so that's a new post.
I created a Timing and synchronisation custom device.In this custom devcie, i created a Timing source and i generate this signal on RTSI0.
- I Parameter the chassis to use this custom device as master hardware synchronisation.
- I Parameter the Timing source of the controller (set the primary control loop timing source to use my custom device).
So if i'm correct, that means the PCL will use the Timing source created in the custom device. When you create parallel timing loop using the device clock, will these parrallel loop also use the same Timing source ? Or Veristand engine create another timing source from the original one (you wrote we will have a delay between the PCL and the asynchronous loop) ?
The other question is what the aim of the RTSI0? In Veristand i found that you have to overwritte the RTSI0 when you create a timing and synchronisation custom device, but why is it used for ? Does the engine create a timing source from RTSI0 signal ?
And the last one : when my custom device run alone, it seems to work, but when i add a board having analog input (e.g. PXIe-6358) in VeriStand configuration, it doesn't works, the application doesn't start. Is it because, when you declare an analogue input you can't use an external timing source, you must use DAQ as a master hardware synchronization device ?
Any answer welcome ...
12-06-2012 11:51 AM
Great questions. This is not documented so I understand the confusion.
any custom device can time the PCL. It just needs to include a tag in the XML to specify the timing source VI. The tag is <TimingSource> and you can see an example with the 433x custom device. Then, if this custom device is picked as the timing master for the controller on the controller page, the timing source VI specified by the XML will run and it is responsible for providing the timing source string to the PCL. The PCL will wake up whenever this timing source says so, and then the PCL will wake up all the other loops (via other software timing sources it created) when they need to iterate. For example... PCL wakes up -> writes to async custom devices -> PCL tic's the custom device's timing source -> async custom devices wake up
only timing and sync custom devices can time hardware. the timing and sync custom device must set the "RTSI0 capable" flag to true with the API provided on the palette. Once it does that, it can be selected as the chassis master on the chassis page. You can see an example with the 433x custom device. Other devices in the chassis are then set to slave mode and they expect to see a sample clock going at the PCL rate (ie 5kHz) on RTSI0 / PXI_Trig0, therefore your device must create that sample clock since it is the master. It is very important that your timing & sync custom device is not hardcoded to always write to RTSI0 / PXI_Trig0, but rather... it must only write to that line if it is selected as the chassis master. Otherwise you could create a configuration that would damage hardware if DAQ/FPGA is master and your timing & sync custom device is present. Again, see the 433x custom device for an example of how to check this (it uses an ActionVIOnCompile).
Your system will likely fail to work with the Timing & Sync device as chassis master and an addition DAQ device because of known issue 351622. This issue is fixed in NIVS 2012 and the beta should be out very soon.