S
Stan Brown
On Fri Jan 21 04:34:41 2000 Curt Wuollet wrote...
>
>Yes, I did some more reading last night. As often happens it raised more
>questions than answers. I need to study it more but, a nagging concern
>was raised. We are wanting to schedule tasks that take appreciable time
>to complete. We will probably have several. IF we switch to RT mode, will
>we ever get switched back to run "normal" tasks. If all resources are
>devoted to RT, in our case, that won't neccesarily speed things up.
>Fieldbus IO, for example will take it's sweet time regardless of how
>many machine cycles we make available. IF these overlap due to external
>causes, we may not leave RT mode. Slow serial I/O is not well suited
>for this model. We may need an interesting mix of RT tasks for fast IO
>and interrupt driven processes for the rest. The interaction should
>prove interesting. Traditionally this is met with a top end that
>executes quickly and a bottom end that waits for the result. It
>would help to get an idea of the turn around time of the various type
>of I/O supported. Does anybody know enough about it yet to put these
>concerns to rest?
Right, that's why the I/O scanners do not need to run as real time processes.
--
Stan Brown [email protected] 843-745-3154
Westvaco
Charleston SC.
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
>
>Yes, I did some more reading last night. As often happens it raised more
>questions than answers. I need to study it more but, a nagging concern
>was raised. We are wanting to schedule tasks that take appreciable time
>to complete. We will probably have several. IF we switch to RT mode, will
>we ever get switched back to run "normal" tasks. If all resources are
>devoted to RT, in our case, that won't neccesarily speed things up.
>Fieldbus IO, for example will take it's sweet time regardless of how
>many machine cycles we make available. IF these overlap due to external
>causes, we may not leave RT mode. Slow serial I/O is not well suited
>for this model. We may need an interesting mix of RT tasks for fast IO
>and interrupt driven processes for the rest. The interaction should
>prove interesting. Traditionally this is met with a top end that
>executes quickly and a bottom end that waits for the result. It
>would help to get an idea of the turn around time of the various type
>of I/O supported. Does anybody know enough about it yet to put these
>concerns to rest?
Right, that's why the I/O scanners do not need to run as real time processes.
--
Stan Brown [email protected] 843-745-3154
Westvaco
Charleston SC.
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc