K
Hello everyone.
I think I have an idea here based on Jiris previous email, so I'll tell you what I have been working on lately and where I see could be a
potential way to extend the LinuxPLC and add RT functionality to it.
I have been working a lot with RTLinux at a project funded by my employer. Certainly what you say Jiri about user space processes not being able to inherit hard RT is definitely true. I have written some RT code that does all of the aspects of our mcahine control and logic. machine programmers' code interface with my common machine code through predefined callback kind of functions that are written byt he user with C and a machine control oriented API. I have also written some code to scan a simple Compact PCI Industry Pack IO carrier card, etc.
On the HMI front, I have started building a simple HMI using GTK+. Right now I am passing my system parameters to the HMI user space task through a RT fifo. Its pretty simple, I have a structure and I stream it out to the FIFO as a whole entity and copy it to a structure on the other end, and update the data in that structure to the screen. Simple and effective. The problem is that you have to modify these structures every time you want to be able to add another data variable to pass to the user space HMI. Plus, it is only uni-directional and you must take care to clean up things, etc. Bottom line, it is a bit messy and hard to use as a widespread methodology
of data passing.
I am still using the FIFO methodology indefinitely for what static functionality I have now, but I want the machine programmers to have
access to all the global machine variables fom within the HMI code as well as the RT code. In addition, we are starting to do more data aquisition related projects at my company that involve a co-mingled partitioning of real time stuff versus user space related tasks. For instance, in one application we are sampling a ADC card with a sub millisecond kind of way and the internal buffer just aren't cutting it for this application. So what we really need is simply a RT task that would handle the data sampling and copy the data to a RAM buffer. In this case, most of your application would be in user space, dealing with plots and user input,
etc, and you have a very simple RT task that just buffers data.
What I am proposing for my end of things, and possibly as a add on or enhancement of the linuxplc is to bridge the RT side of things with the user space side of things. How do you do this, you ask? I am grasping at this idea, so let me describe it and see if it makes sense:
Lets assume your system needs both hard real time and user space application programming (RT for control, user for HMI, etc). Lets also assume that both memory space threads need read and write access to common data (where data is RAM variables, IO tables, etc etc). At first glance you start thinking about protocols and things of that nature to try and abstract things and make it flexible, but in essence all you really need is a shared RAM space that contain all of this data. This methodology provides you with a means of treating your entire system as one big multithreaded process running several threads (some of them real time and some non real time.) that communicate with some global IO and variables. Lets face it, all a multithreaded process is just a big shared ram section that
schedules different threads based upon a schedule algorithm(s). To the casual machine programmer, the fact that the different threads are executed by different kernels isn't really known, or cared about. Of course, this concept of resembling a single multithreaded process is not entirely true since you cannot make GTK or disk write calls form within the RT processes, etc etc, but I think you get the point.
As far as IO drivers are concerned, they are very simple. The RT threads have direct access to hardware, so you write a thread that scans the IO periodically and transfers the IO data to and from the IO table/images/structures (pick a word) in the shared memory area to be used by either memory space threads. It would be fast, simple, and very effective.
The reason I like this idea is that now you have a basic automation environment (machine control, data aquisition, scada, a combination of all three, whatever ..) . You have access to RT threads if you need them. You have virtual access to IO. You have access to linux threads. You can
program it natively in C if you want to, or you can add another layer of abstraction and use the linuxPlc environment on top of it. I think there
are a lot of people out there that are usign these proprietary packages such as steeplechase and labview primarily because it makes the interface to the IO seamless and because they allow you to do some real time and HMI as well. I know there are people like me who prefer to not relyon vendors and to program in high level languages. I think the architecture I describe here could be the open source glue between IO, HMI, netowrking, RTLinux, and the actual automation code. Of course we could tap into, merge, and/or cross pollinate between environments like COMEDI and others.
to use it you would include the appropriate header files into your code and compile the project. Then you would load the RTlinux modules which will handle any RT threads and IO scanning threads that you might have defined for yor project. Then you run your user space process which opens up the shared memory area and maps its IO variables into it, etc.
Let me know what you guys think about this idea.
~Ken
Jiri wrote:
********
A few observations as far as relevance to MAT is concerned:
- User-space tasks can't inherit hard-RT priority, so they cannot
interface to the same MAT core as the RT tasks.
This would mean that most likely the computer would end up running two
separate MATs - one in RT doing the control, and another in userspace
handling lower priority tasks, with some sort of protocol between them.
(For instance, it'd probably be unrealistic to have the GUI real-time.)
- The situation with porting SysV IPC calls to RTLinux was not cleared =
up.
However, it's not likely to be a major problem.
- Licensing was not cleared up (at least to me), needs further
investigation.
Jiri
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
I think I have an idea here based on Jiris previous email, so I'll tell you what I have been working on lately and where I see could be a
potential way to extend the LinuxPLC and add RT functionality to it.
I have been working a lot with RTLinux at a project funded by my employer. Certainly what you say Jiri about user space processes not being able to inherit hard RT is definitely true. I have written some RT code that does all of the aspects of our mcahine control and logic. machine programmers' code interface with my common machine code through predefined callback kind of functions that are written byt he user with C and a machine control oriented API. I have also written some code to scan a simple Compact PCI Industry Pack IO carrier card, etc.
On the HMI front, I have started building a simple HMI using GTK+. Right now I am passing my system parameters to the HMI user space task through a RT fifo. Its pretty simple, I have a structure and I stream it out to the FIFO as a whole entity and copy it to a structure on the other end, and update the data in that structure to the screen. Simple and effective. The problem is that you have to modify these structures every time you want to be able to add another data variable to pass to the user space HMI. Plus, it is only uni-directional and you must take care to clean up things, etc. Bottom line, it is a bit messy and hard to use as a widespread methodology
of data passing.
I am still using the FIFO methodology indefinitely for what static functionality I have now, but I want the machine programmers to have
access to all the global machine variables fom within the HMI code as well as the RT code. In addition, we are starting to do more data aquisition related projects at my company that involve a co-mingled partitioning of real time stuff versus user space related tasks. For instance, in one application we are sampling a ADC card with a sub millisecond kind of way and the internal buffer just aren't cutting it for this application. So what we really need is simply a RT task that would handle the data sampling and copy the data to a RAM buffer. In this case, most of your application would be in user space, dealing with plots and user input,
etc, and you have a very simple RT task that just buffers data.
What I am proposing for my end of things, and possibly as a add on or enhancement of the linuxplc is to bridge the RT side of things with the user space side of things. How do you do this, you ask? I am grasping at this idea, so let me describe it and see if it makes sense:
Lets assume your system needs both hard real time and user space application programming (RT for control, user for HMI, etc). Lets also assume that both memory space threads need read and write access to common data (where data is RAM variables, IO tables, etc etc). At first glance you start thinking about protocols and things of that nature to try and abstract things and make it flexible, but in essence all you really need is a shared RAM space that contain all of this data. This methodology provides you with a means of treating your entire system as one big multithreaded process running several threads (some of them real time and some non real time.) that communicate with some global IO and variables. Lets face it, all a multithreaded process is just a big shared ram section that
schedules different threads based upon a schedule algorithm(s). To the casual machine programmer, the fact that the different threads are executed by different kernels isn't really known, or cared about. Of course, this concept of resembling a single multithreaded process is not entirely true since you cannot make GTK or disk write calls form within the RT processes, etc etc, but I think you get the point.
As far as IO drivers are concerned, they are very simple. The RT threads have direct access to hardware, so you write a thread that scans the IO periodically and transfers the IO data to and from the IO table/images/structures (pick a word) in the shared memory area to be used by either memory space threads. It would be fast, simple, and very effective.
The reason I like this idea is that now you have a basic automation environment (machine control, data aquisition, scada, a combination of all three, whatever ..) . You have access to RT threads if you need them. You have virtual access to IO. You have access to linux threads. You can
program it natively in C if you want to, or you can add another layer of abstraction and use the linuxPlc environment on top of it. I think there
are a lot of people out there that are usign these proprietary packages such as steeplechase and labview primarily because it makes the interface to the IO seamless and because they allow you to do some real time and HMI as well. I know there are people like me who prefer to not relyon vendors and to program in high level languages. I think the architecture I describe here could be the open source glue between IO, HMI, netowrking, RTLinux, and the actual automation code. Of course we could tap into, merge, and/or cross pollinate between environments like COMEDI and others.
to use it you would include the appropriate header files into your code and compile the project. Then you would load the RTlinux modules which will handle any RT threads and IO scanning threads that you might have defined for yor project. Then you run your user space process which opens up the shared memory area and maps its IO variables into it, etc.
Let me know what you guys think about this idea.
~Ken
Jiri wrote:
********
A few observations as far as relevance to MAT is concerned:
- User-space tasks can't inherit hard-RT priority, so they cannot
interface to the same MAT core as the RT tasks.
This would mean that most likely the computer would end up running two
separate MATs - one in RT doing the control, and another in userspace
handling lower priority tasks, with some sort of protocol between them.
(For instance, it'd probably be unrealistic to have the GUI real-time.)
- The situation with porting SysV IPC calls to RTLinux was not cleared =
up.
However, it's not likely to be a major problem.
- Licensing was not cleared up (at least to me), needs further
investigation.
Jiri
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc