VeriStand

cancel
Showing results for 
Search instead for 
Did you mean: 

PCL does not always run at the specified rate

Yesterday I tried to integrate a LabVIEW model (that uses it's own DAQ card) into VeriStand and discovered major timing issues with the model. It took a while, but I determined it was NOT my model or DAQ card, it was VeriStand itself.

 

After restoring a version of the VeriStand code that was supposedly working daily for the past 6 months and removing the DAQ card used by model (and deleting the cfg from the RT MAX cfg), I discovered that after 3-6 undeploy/deploy cycles, the PCL does NOT run as specified...it toggles back and forth from 100 Hz/50 Hz, or is stuck at 50 Hz. When it does run at 100 Hz correctly, none of the 8 CPUs are over-burdened, HP/LP/Model Counts are 0.

 

I did not setup this system nor am the user, but, I am told VeriStand has worked perfectly, even the PID loops that control the temperature of various fluids, so I'm not sure if it's always been like this (it's possible the processes being controlled by the control loops are easy enough that it's not sensitive to PID timing).

 

This system has 2 PXIe chassis and uses a PXI-6683H for the sync source.

 

Has anyone else had issues with the PCL acting like this? If so, any suggestions?

 

Thanks,

 

Todd

 

labviewman_0-1671041821186.png

labviewman_1-1671041840325.png

labviewman_0-1671043134753.png

 

 

 

0 Kudos
Message 1 of 5
(1,691 Views)

I think I found the cause...one of the models communicates via TCP to a device and that device is shut off. Not sure why the PCL rate is often different with each deployment, but with the model starting in the pause state, the PCL runs at the expected 100 Hz

0 Kudos
Message 2 of 5
(1,637 Views)

Have you looked at your HP Count and HP loop Duration?  Your model may be taking too long to run and slowing down your PCL.

0 Kudos
Message 3 of 5
(1,630 Views)

Yes, they were indicating there was an issue.  

 

Very strange that the PCL rate was so erratic. Tomorrow if I get a chance I'll re-enable the model, deploy until it's erratic, then pause the model...that should give 100% confidence the instrument that is shut down is the issue.

0 Kudos
Message 4 of 5
(1,626 Views)

Confirmed...it was the model that communicated with a device over TCP but the device is shut off. Pausing the model when the PCL timing was erratic stopped the erratic PCL timing. Still...strange how the PCL timing was not the same from deployment to deployment....

0 Kudos
Message 5 of 5
(1,602 Views)