I came across a discussion of real time programing on this site which seemed to have some good insights. I would like to get your thoughts on my next project.
I plan to write a C# HMI for a machine which runs a short, about 30 second production cycle. There would be some setup functions that would need to look real time to the operator but the important part is the production cycle. In the production cycle, as much as possible, the controller would directly read all the inputs and control the servo motors and outputs according to parameters down loaded before the cycle. If the real time response lapses between cycles no problem.
My plan is to have a thread which reads the status from the controller and may send commands to the controller if needed, but avoids anything, like updating the screen, that might block it’s execution. A timer which gets status information from the thread then updates the on screen information and puts up error message boxes as needed. The original thread would respond to the on screen controls. I expect some sort of synchronization object will be needed to control passing data from the thread to the timer. As I understand C# the timer would share time with the original thread and could block its execution. I’m not sure if that could happen or if it would be good or bad?
What problems can you see in this plan, what should I look out for, any place I can look at other peoples work, and is there a better way?
BTW: I don’t buy many lottery tickets and I don’t drink much hard liquor so moving to the mountains and setting up a still is not yet a viable better way for me.
Thanks for your time
I agree that C# will never give true real time. I am just asking how people make the best of what C# can do.