Am 08.10.2008 um 06:59 schrieb Hendrik van Rooyen:
[...]
OK, this is gives an impression of SPEED.
In your application the REAL-TIME requirements
are isolated and implemented in the custom controller.
And the HMI which has to be fast enough (SPEED, not HARD-REAL-TIME)
you implemented in python probably on a standard hardware/OS.
That is exactly what I suggested the OP to consider.
Unless we do not know more details of the requirements
for the OPs application I think it is a bit early
to give this advice, althoug Python is a great
programming language in many aspects.
The only requirements we know of the OPs program project are:
- able to address interrupts (python can)
- execute an operation within 70[Hz] or less (python can)
But we do not know what operation has to be done at this
rate.
My concern is to point out, that the terms
SPEED and REAL-TIME and HARD-REAL-TIME
should not be misused or misunderstood.
Read:
Grüessli
--
Kurt Müller, mu@problemlos.c h
"Blubaugh, David A." <dblub....elcan .comwrote:
>I have done some additional research into the possibility of
>utilizing
>Python for hard real time development. I have seen on various
>websites
>where this has been discussed before on the internet. However, I was
>wondering as to how successful anyone has truly been in developing a
>program project either in windows or in Linux that was or extremely
>close to real time constraints? For example is it possible to
>develop a
>python program that can address an interrupt or execute an operation
>within 70 Hz or less?? Are there any additional considerations that I
>should investigate first regarding this matter??
>utilizing
>Python for hard real time development. I have seen on various
>websites
>where this has been discussed before on the internet. However, I was
>wondering as to how successful anyone has truly been in developing a
>program project either in windows or in Linux that was or extremely
>close to real time constraints? For example is it possible to
>develop a
>python program that can address an interrupt or execute an operation
>within 70 Hz or less?? Are there any additional considerations that I
>should investigate first regarding this matter??
If I run it between 2 PC's, faking the I/O by writing to a disk,
I sometimes get up to 250 such "pings" per second. Going full
duplex would pass a lot more info, but you lose the stimulus-
response nature, which is kind of nice to have in a control
environment.
Its not real time, but its not exactly yesterday's stuff either.
I sometimes get up to 250 such "pings" per second. Going full
duplex would pass a lot more info, but you lose the stimulus-
response nature, which is kind of nice to have in a control
environment.
Its not real time, but its not exactly yesterday's stuff either.
We have also used python to do the HMI for an Injection
Moulding machine, talking to a custom controller with
an 8031 and an ARM on it via an RS-422 link running at
115200 - and the python keeps the link fully occupied
Moulding machine, talking to a custom controller with
an 8031 and an ARM on it via an RS-422 link running at
115200 - and the python keeps the link fully occupied
are isolated and implemented in the custom controller.
And the HMI which has to be fast enough (SPEED, not HARD-REAL-TIME)
you implemented in python probably on a standard hardware/OS.
That is exactly what I suggested the OP to consider.
So don't be afraid - go for it!
for the OPs application I think it is a bit early
to give this advice, althoug Python is a great
programming language in many aspects.
The only requirements we know of the OPs program project are:
- able to address interrupts (python can)
- execute an operation within 70[Hz] or less (python can)
But we do not know what operation has to be done at this
rate.
My concern is to point out, that the terms
SPEED and REAL-TIME and HARD-REAL-TIME
should not be misused or misunderstood.
Read:
Grüessli
--
Kurt Müller, mu@problemlos.c h