VeriStand

cancel
Showing results for 
Search instead for 
Did you mean: 

reflective memory setup in Veristand

Solved!
Go to solution

The Late counts go up sporadically. See attached log file.

0 Kudos
Message 21 of 54
(4,780 Views)

OK I did some thinking about this more and I think I know the reason. The systems are still not syncrhonized so they are still drifting from one another. This is happening because prior to NI VerIStand 2012... only M and X series DAQ devices actually reference the 10 MHz chassis clock. So your PXIe-4300 is getting the start trigger but it is not referencing the chassis clock and therefore the shared chassis clock you connected via BNC cables is not helping at all.

 

The fix for this is in NI VeriStand 2012.

 

To avoid a software upgrade, you can work around this issue by using an M or X series device as the chassis timing master instead of the 4300.

 

To avoid a software upgrade or a hardware change, you can work around this issue by sharing the sample clock between the chassis directly INSTEAD of sharing a start trigger and reference clocks. So change controller 1 chassis to this (and use whatever PFI lines you wired together):

controller 1.PNG

 

And this is controller 2:

 

controller 2.PNG

 

Sorry, I didn't think about that.

Stephen B
0 Kudos
Message 22 of 54
(4,773 Views)

I configured the clocking as you suggested and that works.

 

The late counts stay at zero, which is what I originally set out to do.  You have been a huge amount of help. Thank you very much.

 

One issue I’m seeing  is an ADC conversion error (see below) pops up which causes me to have to redeploy. When I look at the 10 MHz clock with a scope it is a very noisy signal, which could be the source of this error. It was wired up quickly for proof of concept with unshielded wire. So, it can be cleaned up to some degree with better wiring and connectors.

Do you know of any other reason this error might occur?

 

Thanks again

 

ADC Conversion Error

0 Kudos
Message 23 of 54
(4,770 Views)
Solution
Accepted by topic author pmac

You do not need to share the 10 MHz clock anymore since you are sharing the sample clock directly with the PFI pins. So that is not it.

 

The error is saying the sample clock the 4300 is using ticed twice before the module was ready to sample again. This probably means it is glitching... try getting a cleaner signal.

Stephen B
0 Kudos
Message 24 of 54
(4,764 Views)

Stephen,

 

I was able to get a hold of an M-series DAQ (PXI-6259) and configured hardware syncing as we origiinally were attempting. So I'm sharing the 10 MHz clock between chassis' and I have chassis1 exporting a start trigger that is wired to a PFI channel on the M-series DAQ in chassis2. This works great.

 

I have 4 PXIe-4300 AI cards installed in chssis1. In the configuration for each of those cards the checkboxes labeled "Turn off hardware-timed single-point support analog input/output" are both checked. If I uncheck "Turn off hardware-timed single-point support analog input", the deployment times out reporting it never received the start trigger. Don't I need to uncheck that box to for those cards to take advantage of hardware timing?

 

Thanks

PatM

0 Kudos
Message 25 of 54
(4,732 Views)

At this point I should probably start another thread.

0 Kudos
Message 26 of 54
(4,718 Views)
Ok cool. Yes you should uncheck those boxes to ensure simultaneous sampling and higher performance. It is surprising you receive an error. Verify your chassis routing settings route away from the bus segment the master card resides in
Stephen B
0 Kudos
Message 27 of 54
(4,712 Views)

I checked in MAX and the trigger bus routing is correct for both chassis'. Attached is the error text from the deployment dialog along with Console Viewer screen shots from both controllers.

 

Thanks,

PatM

0 Kudos
Message 28 of 54
(4,697 Views)

I think controller 1 is taking so long to get started that it times out. There is a hidden property (public in 2013) that can extend this timeout. If you open up your system definition file with a text editor, look under the controller 1 section that looks like this: <Target Name="Controller 1" TypeGUID="775504BB-1485-13A6-56755DBF2C326980">

for a property named this:                     <Property Name="TL timeout">
                        <Double>120</Double>

 

Extend that up to like 200 and see if that fixes it.

 

Also, I noticed controller 2 is throwing an error from the 433x device. The error is indicitive you're using a very old version of that custom device. Can you update to the latest version and see if that resolves the 433x error? 

Stephen B
0 Kudos
Message 29 of 54
(4,684 Views)

I increased "TL Timeout" to 200 and then 300 with the same deployment results. I also downloaded and installed the latest 433x Custom Device but still get the 433x error. Is there anything else I can try?

 

Thanks,

PatM

0 Kudos
Message 30 of 54
(4,674 Views)