RT OS timer interrupts problem

[DPearce]

I already posted this in the PXI forum but someone suggested I might get more results here. Sorry in advance if I am not abusing the forum.

I have PXI system with a RT OS. It was working pretty well until I upgraded to LabWindows/CVI 2013. It seems to be a context switching problem; I will describe it the best I can and see if there have been others with a simular problem.

The section of my code which has the problem is where I am trying to measure the effect of a RC filter by injecting a DC signal to a external device which has its own signal acquisition system. The external device is communicated to via CAN. The DC signal is generated by a DAC in my PXI system. My PXI system also has a CAN device I control in my application.

Here is the steps of my software.

1.) a CAN message to my external signal acquisition system to start acquiring a waveform of 100 samples at a sample rate of 150us. The waveform is 15ms long.

2.) p for 5 ms

3.) the DAC to a voltage

4.) load signal from external device and record to a file.

So by Sleeping for a bit before setting the DAC I will see the effect of my RC filter in the external acqusition system's generated waveform.

When I had LabWinodws/CVI 2012 this worked just fine but now it seems that the DAC output changes before my external device receives the CAN message to start acquisition.

Here are some of the complexities of the system.

The CAN message is sent on a separted thread so use the function PostDeferredCallToThread() to post this.

Right after that I go to sleep so the RTmain() function can allow this lower priority thread (the CAN message) to execute.

Then I set the DAC output.

Here is the code which Posts the CAN and sets theAC.

PostDeferredCallToThread( ActOnStartAbsorptionMeasurement, &g_InputVoltage[g_InputVoltageptr], g_mainThreadID); // send CAN message
// 5 ms delay

timerTracker = GetTimeUS();
timerTracker += 5000;
SleepUntilUS((unsigned long)timerTracker);

// set the DAC
(void) SetDACoutput(VoltageLevel);

Here is what I do in the RTmain()

while (!RTIsShuttingDown () && !gDone)
{
/* Your code. */

/* Sleep for some amount of time to give the desired loop rate */
/* and to allow lower priority threads to run. */
timerTracker = GetTimeUS();
timerTracker += RT_MAIN_SLEEP_TIME; // RT_MAIN_SLEEP_TIME == 400us
SleepUntilUS((unsigned long)timerTracker);
ProcessSystemEvents ();

}

I appreciate any help. Thanks in advance

When I collect the signal acquisition waveforn from the DUT and look at it I would expect it to look like this:

The first 5 ms of the waveform would not see the change in the DAC output. After 5ms, in the waveform, I would see a transition to the DAC output value. However what I do see in the waveform is the DAC is already set before the DUT starts acquisition and sometimes the DAC is not set until the acqusition is done.

When I had the 2012 LabWindows installed I did not have this problem. One problem I did have on LabWindows is one function did not work as advertised; I notified NI about this and after a bit of back and forth they realized it was not working. The problem had to do with reseting the asynchronous timer counter. When you set the timer internal attribute with this function:

SetAsyncTimerAttribute( gRegCalMainLoopID,ASYNC_ATTR_INTERVAL, Some Number);

It is suppose to reset a counter so that the timer thread will start at the proper time. However, setting this attribute did not work as advertised; since the counter was not reset the timer therad started at various times and caused a bit of a problem. I figured out a work around to get this to work well enough for my application. I did not hear back from the NI support is this feature was fixed in 2013 and did not notice any mention in the release notes about it so I assume it was not repaired. I only mention this because they might have fixed it and added a new feature LOL.

I have been posting this in the PXI system because since I am using a realtime OS it would only have to do with a PXI system. I might be wrong in my thinking. Part of the problem I am running into is I do not think many folks are suing the realtime OS so I feel I am breaking ground a bit. I have been getting help from the NI support but let my license agreement lapse; I do not believe I recieved an email to remind me to update teh service so I sent NI an email to try and reactivate the agreement. I think if I get some of these folks involved I can get it resolved; meanwhile I am trying to sort it out the best I can.

When I moved to 2013 there was some software compatibility issues between the LabWindows/CVI and the PXI so I went into MAX and updated the software in the PXI controller. It is possible my problem is because of this. Perhaps the CAN software in the PXI is not compaitble with my CAN device in the PXI.

[ConnorM]

Good Morning DPearce

At first glance, this application is suffering from a race condition. The DAQ thread and the CAN thread are not synchronized or have any communication between them. All we have here is a start wait start. Race conditions do not go away just because we are in RT. The compiler changed from CVI 2012 to CVI 2013 that has caused some change in behavior. Depending on your DAQ hardware you may want to consider a reference trigger to get the data that you want in a synchronized way.

If you can, post a small program that replicates the change from CVI 2012 to CVI 2013. This will help to identify what calls or combination of calls are having the change in behavior. 

ConnorM

[DPearce · Accepted solution]

I think I did have a race condition problem with the CAN and I found that something on the DAC was taking too long. I managed to find a work around but still do not what happened between LabWindows/CVI 2012 and 2013.