RT OS timer interrupts problem

[DPearce]

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

[DECONN]

Hi DPearce,

I would consider posting your question to the LabWindows/CVI forums for a better response. Also, have you made any other changes recently other than upgrading from LabWindows/CVI 2012 to 2013?  Can you clarify on the exact behavior you are seeing? I am assuming that step 3 from above appears to occur prior to step 1, is that correct? Are the CAN messages being sent/received correctly on both ends of the network?

[DPearce]

The only change I made was move from 2012 to 2013. The CAN communication seems to be OK between the DUT and the PXI system.

I think I described the behavior fairly well in my initial post; I will try to rephrase it a bit. 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.

[DPearce]

Forgot to mention. 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.