Time critical loop with GUI updates/inputs architecture

[mjay]

Sorry, I submitted my previous post of "Best architecture for motion controller" multiple times by mistake. I had not complete the question.

I am developing a motion controller card for motor control.

Hardware: PCI general purpose IO card (on a PCI slot) with a Xilinx Spartan 2-200 FPGA

Software:

I developed the GUI using LabWindows/CVI.   The GUI is supposed to display the current positiions and is also used to input new commands to the controller.

I have a ThreadFunction that has a TIME CRITICAL While loop (PID loop)

The FPGA provides a real time stamp along with all the motion parameters (eg position of encoders, status of limit switches etc).

On receiving this info the PC calculates the new value of the PID signal and downloads it to the FPGA.

Problem that I am facing:

I am communicating with the GUI by simply updating the value of the GUI controls, using a simple counter to space the GUI updates. I also read the relevant input values from the GUI at the same time.

This method is not working because any GUI activity disrupts the time critical loop, and the system becomes unstable.

cncgui.c

{

   GUI control callback functions

   Schedule thread fuction to start

   ThreadFuntion ()

    {

      while  (1)

      {

          Pid control

          every 1000 increments of counter

             update GUI values

              read new GUI values

        }//end time-critical while loop

    }//end thread function

}

Would appreciate any input for some alternative architectures that would allow me to maintain my time critical PID loop, while being able to update the GUI at the same time.

Is there a way to offload the GUI activities to a graphics card?

[jr_2005]

Have you tried boosting the process priority of the time-critical thread?
I have used the SDK function SetThreadPriority (... THREAD_PRIORITY_TIME_CRITICAL) quite successfully in simiar applications.

JR

[cdk52]

mjay,

You could try this approach, which moves time-consuming operations out of the critical thread:

• Declare Control and Status variables to store data to be exchanged with the FPGA. Protect these variables using a thread lock or mutex.
• Run your PID control and FPGA interface in a loop in your existing dedicated thread.
• In your control callbacks, store the new values from the GUI in the Control variables, and set a "modified" flag.
• Every 1000 iterations of the control loop:
• check the flag; if it is set, copy the Control data, clear the flag, and download the data to the FPGA.
• update the Status variables with the current data from the FPGA, then call PostDeferredCall() to notify the main thread of the update. In the deferred callback, refresh the GUI and take whatever other action is required.
• As JR says, you can boost the priority of the time-critical thread. I would suggest that you use the lowest priority which gives stable operation, for maximum responsiveness.

Regards,
Colin.

[mjay]

Thanks to all of you for your inputs

As per your suggestions I tried  setting the thread priority 

I use CmtScheduleThreadPoolFunctionAdv (poolHandle, OpenPopup,
                                          NULL,
                                          THREAD_PRIORITY_REAL_TIME,
                                          NULL,
                                          EVENT_TP_THREAD_FUNCTION_BEGIN,
                                          0, CmtGetCurrentThreadID(), &fnID)

to schedule and set the priority of the PID loop thread to REAL_TIME.

However I find that even without any GUI updates the GUI is very unresponsive. It seems to queue up all the GUI requests, and the result is a very sluggish GUI response. My pid loop has very stringent time requirements. Requires a 100microseconds cycle time. Max jitter can go upto 500 micro seconds.

Any other priority setting other than real time - result in my PID loop not being able to keep the cycle time it requires for being stable.

I am not sure if there is anything elese I can do within a single processor environment given my stringent time requirements. Would you be able to suggest some alternativees like perhaps considering multiple processors, or is there any more tuning that could be done within the current architecture?

Thanks

[cdk52]

(just noticed the discussion in the other thread)

Message Edited by cdk52 on 03-01-2006 08:55 AM