Normally I do machine control tasks with Visual C++. The problem here is that other people without compiler can't modifiy, on some moments it would be easy that someone else can do some small modification.

I was wondering if there are some scripting engines available that can be easily used for doing machine control tasks. (freeware/open source?)

Best regards,

Willem

 

THIS topic has been a muse for me, as I been developing software since 1981 in various languages and platforms, now I've been working for a Automation Company for 5 years now and we Cannot advertise that we do any Custom Software development because of insurance Reasons, it's a Liability Factor They say how do u guys get away with writing software with a 3rd Party Compiler, and for Our automation guys to even look at c++ would be twisting Their brain cells wayyy more than they want. Isn't writing ladder logic for that controller a liability factor as well?? This statement makes no sense at all, i'd just like to hear some Comments on it, please....

Thanks

 

I think it's a question of _who_ is liable. While you can certainly create some very brain dead ladder logic, the potential for software mayhem is far greater with a general programming language unless the programmer is skilled and experienced. Skill and experience being dirty words to business these days, (read $$$) that attitude is not that surprising. Consider the flak I take for even suggesting doing PLC work with a language like C even where it is far more suitable and efficient. As for the original question, doing machine control with anything under Windows is not something I would recommend. Especially if it's dangerous machinery. I should tell the conveyor story again.

Regards

cww

 

Hi Willem,

You can build in engines/interpreters in Tcl/Tk, Python, Forth, Basic, and many other languages. None of them uniquely appropriate for machine control. Not that C++ is
the best choice for the less experienced, either.

Also, what type of "small modifications" are you putting in the hands of "other people"? I always worry about "other people" hurting themselves because too much
customization reprogrammability was left in the hands of people who think machine control is a simple thing.

For low-level work, I'd lean toward an embedded Forth. For user interface modifications, Tcl/Tk is pretty slick.

Please followup with what manner of "modifications" you intend to put in those hands, and when you're done, what you decided on.

Rufus

I assume you've already looked at the Puffin projects (now MAT) and a related project classicladder.

http://mat.sourceforge.net/ and
http://membres.lycos.fr/mavati/classicladder/

 

Well, while I won't hang my life on the reliability of a windows applications just yet, it can be used quite well in a control applications.

First, I think that your question may not be precise enough to get a exact explicit answer...
What is the hardware behind the control app ?
What are you controlling ?
They are dozens of applications like Pharlap, NI Labview, CVI, VB, wonderware and other hmi that work well under windows for control.

But then they may be overkill for you.
The easiest way to make it easier for someone
to change parameters in your program is to use a *.ini file. This is simply a text file that will store strings names along with associated values for each name. Then whenever your applications is launched, it will look for this file in it's root directory, open, read and make use of whatever is in there...

Hope this helps

Walt Njuh
Akumeka

 

While I snicker when I see Windows and control in the same sentence, I will still endeavor to help :^) Why not use GCC, then they can have a compiler. Otherwise, I have used a disk file to initialize arrays somewhat as mentioned. I prefer shared memory so that a cooperating process can update values synchronously. A crude method might be to signal the program to reread a file. The idea being that the control process can remain running, at least until it leaks enough memory to crash.

Regards
cww

 

Re: Curt Wuollet's reply on this subject. The original poster (Willem) was asking for a recommendation on selecting scripting languages for this application. His criteria were a scripting language, easy to make small modifications to an existing system, suitable for control tasks, and free (e.g. GPL).

His reasoning seems quite sound to me, and agrees with my own conclusions on this subject and also with those of other people I have spoken with. I replied on this topic last November with my recommendation (Python). Is there any reason why you appear to think otherwise?

 

Hi Michael

I could be wrong, but it appeared to me he requires modification of information used at runtime in a running process. Grafting stuff on except through well known common interfaces and dealing with stuff like synchronization would be every interesting with closed libraries, etc. But, if he were to redo the application in something like Python to make it easy for users to mod, that is a different matter and a far better bet. I must confess I haven't seen Python on Windows, but it finds quite a bit of use for exactly that type of thing on Linux. It has its own set of issues for control purposes and users wouldn't like to have to learn it but, those aside, it would be one of the better Open choices. So it depends on whether he wants to sell closed apps with some
open tinkerables somehow integrated or open his application. The first is much less desirable than the second. And of course, if you want to be Open and do control, Windows is a non-starter for me. But then, I've got a headache from dealing with closed software all week.

Regards

cww

 

I don't like arguing about what someone else meant, but my interpretation was that he was asking for a scripting language to allow other people to more readily modify the *program*, not the parameter data.

<clip>
> I could be wrong, but it appeared to me he requires modification of
> information used at runtime in a running process.
<clip>

Parameter data should of course be accessable via data input screens and saved in files. Modifying the actual program logic is something else again.

> (CW) I must confess I haven't seen Python on Windows, but it finds
> quite a bit of use for exactly that type of thing on Linux. <

Like most non-proprietary language, it is relatively platform independent and is available for Linux, Windows, and Mac OS/X (of course you know this already).

> (CW) It has its own set of issues for control purposes <

What "issues" are those? If these "issues" relate to using scripting languages for real-time programming, that is a red herring for most control applications (see numerous previous discussions on this).

> (CW) and users wouldn't like to have to learn it <

Considering he is (was) using Visual C++, Python would look quite good to users by comparison. As a language, it is probably one of the more easy ones to learn. I would assume that whatever he is doing with computers, it isn't
something that can be solved with ladder logic.

> (CW) but, those aside, it would be one of the better Open choices. <

I have cited the following source before when commenting on the "popularity" of various programming languages. The "TIOBE Programming Community Index" attempts to rate the "popularity" of different programming languages based on
a number of criteria. http://www.tiobe.com/tiobe_index/index.htm

The results for the top 10 languages for January 2005 are:

1) C - 21%, 2) Java - 18%, 3) C++ - 12%, 4) PHP - 10%, 5) (Visual) Basic - 8%, 6) Perl - 8%, 7) SQL - 3%, 8) Python - 3%, 9) Delphi/Kylix - 3%, 10) C# - 2%

It is possible to argue about the details of the "rating" system TIOBE uses, but the above list does appear quite reasonable in terms of the entries and the relative rankings. I have brought up these figures as I believe there are strong advantages to sticking with main stream programming languages in terms of library support, documentation, availability of books, quality of software
tools, etc.

Looking at the above list, we can see that C, Java, and C++ together total over 50% of the rating. However, they are all compiled languages, and so don't meet his criteria. Visual Basic, Delphi/Kylix, and C# are proprietary languages which are also compiled and so fail the original criteria on two points. PHP, Perl, and SQL are probably all too specialised (web apps for the first two, and database for SQL) to be considered for "control" applications. This leaves us with Python as the main stream non-proprietary general purpose scripting language.

> (CW) So it depends on whether he wants to sell closed apps with some
> open tinkerables somehow integrated or open his application.
> The first is much less desirable than the second. <

Most applications will involve a consultant who writes a custom application for a customer, either as a stand alone program, or delivered with a hardware system (e.g a test system). The customer will require delivery of all source
and libraries. The customer would also like to be able to maintain the software themselves after acceptance, including minor bug fixes and changes. A scripting language is much more convenient for the customer in this
scenario as it permits rapid change and debug of small changes during short equipment availability windows.

The "free/open" criteria (one of the criteria in the original message) is also valuable as it eliminates the problem of software license compliance. The consultant can hand over just about any piece of software (including
libraries) to his customer without worrying about whether it is legal or not. By comparison, a lot of custom industrial programs using proprietary development systems and libraries include pirated software.

> (CW) And of course, if you want to be Open and do control, Windows is a
> non-starter for me. But then, I've got a headache from dealing with closed
> software all week. <

That of course, is another issue which is independent of operating system provided you avoid proprietary languages and development systems.

 

Hi Michael

> I don't like arguing about what someone else meant, but my interpretation was
> that he was asking for a scripting language to allow other people to more
> readily modify the *program*, not the parameter data.
>
> On January 11, 2005, Curt Wuollet wrote:
> <clip>
>
>>I could be wrong, but it appeared to me he requires modification of
>>information used at runtime in a running process.
>
> <clip>
>
> Parameter data should of course be accessable via data input screens and saved
> in files. Modifying the actual program logic is something else again.
>
>>(CW) I must confess I haven't seen Python on Windows, but it finds
>>quite a bit of use for exactly that type of thing on Linux. <
>
> Like most non-proprietary language, it is relatively platform independent and
> is available for Linux, Windows, and Mac OS/X (of course you know this
> already).
>
>>(CW) It has its own set of issues for control purposes <
>
> What "issues" are those? If these "issues" relate to using scripting languages
> for real-time programming, that is a red herring for most control
> applications (see numerous previous discussions on this).

Yes, it does rather depend on your definition of control and real time. I wouldn't use it for the interpolation and path planning for a high
speed robot, but manual control where nothing happens, waiting on the user, would be suitable. Or even as a UI loosely (asynchronously) coupled to a real time control loop. Unless controlling something glacial, I don't like the idea of user actions interacting with the process timing. And I've seen quite a few Python error messages.
But that could be who is coding it. It's much the same reason I don't like Windows for control in general. It often goes off and does God knows what while you wait. Recent Linux builds are far superior with kernel preemption and consistant latencies for control purposes. And you can get a far better idea what it's doing.
>
>>(CW) and users wouldn't like to have to learn it <
>
> Considering he is (was) using Visual C++, Python would look quite good to
> users by comparison. As a language, it is probably one of the more easy ones
> to learn. I would assume that whatever he is doing with computers, it isn't
> something that can be solved with ladder logic.
>
Heresy! Is there anything that you can't do with RLL? :^) Users don't like the challange of reading the manual. And even all the viral misery
and infelicity of attempting to work with Windows won't drive them to try anything else. I'm not optomistic about getting them to learn a new language to use a product. You can't write with a mouse.
>
>>(CW) but, those aside, it would be one of the better Open choices. <
>
> I have cited the following source before when commenting on the "popularity"
> of various programming languages. The "TIOBE Programming Community Index"
> attempts to rate the "popularity" of different programming languages based on
> a number of criteria. http://www.tiobe.com/tiobe_index/index.htm
>
> The results for the top 10 languages for January 2005 are:
>
> 1) C - 21%, 2) Java - 18%, 3) C++ - 12%, 4) PHP - 10%, 5) (Visual) Basic - 8%,
> 6) Perl - 8%, 7) SQL - 3%, 8) Python - 3%, 9) Delphi/Kylix - 3%, 10) C# - 2%
>
> It is possible to argue about the details of the "rating" system TIOBE uses,
> but the above list does appear quite reasonable in terms of the entries and
> the relative rankings. I have brought up these figures as I believe there are
> strong advantages to sticking with main stream programming languages in terms
> of library support, documentation, availability of books, quality of software
> tools, etc.
>
> Looking at the above list, we can see that C, Java, and C++ together total
> over 50% of the rating. However, they are all compiled languages, and so
> don't meet his criteria. Visual Basic, Delphi/Kylix, and C# are proprietary
> languages which are also compiled and so fail the original criteria on two
> points. PHP, Perl, and SQL are probably all too specialised (web apps for the
> first two, and database for SQL) to be considered for "control" applications.
> This leaves us with Python as the main stream non-proprietary general purpose
> scripting language.

Those figures are thought provoking in many ways. Compiling aside, the "obvious" choice, VB, ranking with perl says a lot about how anxious
people are to use a scripting language. Of course, _I_ would choose python out of that list although a pretty good argument could be made
for perl if visuals aren't involved.
>
>>(CW) So it depends on whether he wants to sell closed apps with some
>>open tinkerables somehow integrated or open his application.
>>The first is much less desirable than the second. <
>
> Most applications will involve a consultant who writes a custom application
> for a customer, either as a stand alone program, or delivered with a hardware
> system (e.g a test system). The customer will require delivery of all source
> and libraries. The customer would also like to be able to maintain the
> software themselves after acceptance, including minor bug fixes and changes.
> A scripting language is much more convenient for the customer in this
> scenario as it permits rapid change and debug of small changes during short
> equipment availability windows.

Indeed, I wonder why so few do business that way. Most would very much prefer that the customer has to call them and write the request on a check. Many customers are conditioned to this and have to be educated before they realize how vast the advantages of OSS are.
>
> The "free/open" criteria (one of the criteria in the original message) is also
> valuable as it eliminates the problem of software license compliance. The
> consultant can hand over just about any piece of software (including
> libraries) to his customer without worrying about whether it is legal or not.
> By comparison, a lot of custom industrial programs using proprietary
> development systems and libraries include pirated software.
>
>>(CW) And of course, if you want to be Open and do control, Windows is a
>>non-starter for me. But then, I've got a headache from dealing with closed
>>software all week. <
>
> That of course, is another issue which is independent of operating system
> provided you avoid proprietary languages and development systems.

Oh, that I _could_ avoid these! But I don't see any degree of independance when one OS is so much easier to develop under and the other is secret.

Regards
cww

 

Re: Curt Wuollet's reply on scripting languages in control applications.

In summary, your "issues" for Python in control applications (see your comments quoted at the end of this message) relate to real time. Essentially, you say OK for UI, but not for tight timing, and that the same could be said for any scripting language.

My reply to that is:

I agree that it is not suited for difficult real time applications. However most of industrial applications do not require real time with micro-second latencies. There is a great mass of problems out there that are not real
time.

However, you raised a number of points which I felt could best be answered by presenting some actual data. As an experiment, I whipped up a simple Python program to measure timing. The program had three threads. One (thread 'A') drew a sine wave on the screen, the second (thread 'B') emitted a series of beeps (by printing ASCII "bell" to the console), and the third (thread 'C') stored the current time into a list (array). Threads 'A' and 'C' were run at 10 msec intervals while thread 'B' was run at 500 msec intervals. The test was run for long enough to allow thread 'C' to collect 800 timing samples.

The above test was run under two conditions. The first was under where the computer was under light load (97% to 98% idle according to top). The second was where the computer was put under heavy CPU load by another application (a large spreadsheet operation), with the result being 0% idle. I did not test under heavy I/O (disk) load, as this condition is not typical for applications that interest me.

The actual Python test program put little load on the computer. Total user tasks under the lightly loaded conditions were less than 2% (this included all tasks, not just the test program). A real world application would impose greater load, but not drastically so.

The end results for 800 data points each were as follows (all times in milliseconds):

Lightly loaded - Average = 10.02 msec. Standard deviation = 1.52. Max = 37. Min = 3. Of all samples, only one was greater than 13 (one sample of 37 msec.). There were 16 samples of 13 msec, 5 of 12 msec., 1 of 3 msec., 16 of
7 msec., and 6 of 8 msec. All the rest were between 9 and 11 msec.

Heavily loaded - Average was 10.08. Standard deviation was 1.72. Max = 42. Min = 8. Of the total samples, only 3 were greater than 12 (one each of 19, 31, and 42 msec.). There were 7 samples of 12 msec., and 10 of 8 msec. All the rest were between 9 and 11 msec.

Note that the above data represents only one sample 'run' for each condition. I conducted the test several times without collecting data, and saw slightly different results each time. However, since I am not trying to conduct an exhaustive study, I only bothered to collect one set of data. The slight differences between the two sample sets is probably not significant.

In a separate non-threaded test, the total time to draw the sine waves (800 line segments) was 180 msec if the screen update was conducted after drawing was complete, or 620 msec if the screen was updated after each line segment
was drawn. Note - in the thread switching example above, the screen was updated after each thread switch (and therefore line segment) as the GUI thread got its turn in the schedule. The same loop which did no drawing but consisted of simply incrementing an integer took just over 0.2 msec (or 200 microseconds) according to the system clock (measured by clock time, not CPU time).

Additional info: The Python version was 2.3. The OS version was a stock Linux 2.4 kernal (no tweaks for high task switching resolution, standard scheduling algorithm). The PC was a 1.7 GHz Celeron, with 512 megabytes of RAM.
Threading was done using the standard Python "threading" module together with "time.sleep" statements in each thread.

From the above, I think we can draw the several conclusions. One is that it was quite possible to conduct thread switching rapidly. Also, high CPU loads (from other processes) did not seem to have a significant effect on on the ability of the test threads to run at the desired frequency.

The data did show that hard real time performance was *not* possible under these conditions. The Python interpreter uses its own thread switching mechanism, which is not a real time scheduler even if the OS itself had been.

However, I would conclude that for a lot of industrial applications the above would be quite satisfactory. The 10 msec thread switching might be a bit ambitious if a lot of real work was being done, but I believe that even a significantly lower rate would likely be "fast enough" and responsive enough for most applications, including typical computerised test or monitoring systems.

It is worth noting that the test program included a simple GUI, graphics drawing, and multi-threading in about 100 lines (including blank lines and comments).

 

Hi Michael I don't doubt your conclusions or your methods. I would be interested in a comparison of this with a Windows platform. And a user mousing around and interacting. And of course, this is properly coded for the purpose. But have the average, non-cs user code this functionality and the results would likely be different. And writing, say a multipage menu type GUI with some disk and network IO would introduce some variability. But, I agree it really depends on what you are controlling. I have shell scripts controlling a lot of things without a care about execution time. But those have little or no cost if they drag on or even if they don't occur. When it does matter, I like to seperate the control functions from the GUI in such a manner that the control process remains as time invariant and predictable as possible. Then, no matter what your GUI and/or user does, short of bringing the machine to it's knees, control is maintained. And the control portion contains as few paths and as little, simple code as possible.

What I am saying, is that, as used by the people attracted to the ease of scripting languages over other methods, scripting languages can be way too simple :^) I'm sure you've seen (and waited for) examples. A good programmer who understands the platform and has time to profile and test, can probably produce acceptable results with almost any language on today's hardware. But what I've seen from the VB crowd, for example, doesn't inspire confidence. And I'm not sure how you could ever fully understand some platforms.

 

Further to my previous message on this subject where I discussed the results of some software timing tests, I have some information on additional tests. Since the Python language runs on multiple operating systems, I thought it would be interesting to see what, if any effects differences in the underlying operating system may have.

I repeated this test with the same program on a computer with a Windows XP Pro operating system. The computer has a 2 GHz Pentium 4 M processor with 512 meg of RAM. The Python version is also 2.3 as in the previous test.

The test program was identical to that run in the previous experiment. However, due to lack of time, I only ran it under the "lightly loaded" scenario (98% to 99% idle), and not under heavy CPU load. Again, the test consisted of measuring whether a thread could be reliably called at 10 milli-second intervals when sharing the system with two other threads performing some simulated work. I didn't have time to collect and analyse the same detailed statistics as I did in the previous test, so what I have is the results from the brief notes I took.

The result for most of the data points was similar to the timing results obtained when the test was conducted with a Linux 2.4 kernal. The timing thread usually met its schedule. However, the test conducted under Windows XP "stuttered" (the program would "freeze" momentarily). Whereas the worst case timing for the test under the Linux OS was 37 milliseconds (instead of the nominal 10 ms), whenever the Windows XP test missed the schedule (which it did by about a dozen times), it would do so by more than 200 ms.

The number of deviations from the nominal timing are probably less disturbing than the size of the deviations. An occasional 37 ms (worst case value for the Linux test) deviation could be ignored in many applications. A number of 200 ms deviations worst case for the Windows XP test) though becomes a factor which needs serious consideration as to its effects.

I don't have an explanation for this behaviour when using Windows nor do I intend to spend more time investigating. My conclusion though is that the underlying operating system has an effect that must be taken into consideration in any application which is designed to poll readings at regular intervals, even if for something intended to be "soft real time". I would also conclude that a program which is intended to poll for data at (semi) regular intervals should include a means which allows the developer to measure what the polling rate actually is over a significant number of samples.

To repeat the objectives, the tests were intended to show the performance of a popular scripting language when used in typical computerised test or monitor applications. So, to address Mr. Wuollet's earlier points:

On January 14, 2005, Curt Wuollet wrote:
<clip>
> Yes, it does rather depend on your definition of control and real time.
> I wouldn't use it for the interpolation and path planning for a high
> speed robot,

Not many people write low level robot software. Most just buy a robot. I didn't imply that a particular language was good for all applications.

> but manual control where nothing happens, waiting on the
> user, would be suitable. Or even as a UI loosely (asynchronously)
> coupled to a real time control loop.

Scripting behind a GUI would (not surprisingly) be a good application for a scripting language. Fast development is typically more important than fast execution.

> Unless controlling something glacial, I don't like the idea of user
> actions interacting with the process timing.

Even allowing for some degree of hyperbole, "glacial" would imply time scales of minutes, or at least seconds. I think that the tests I conducted would suggest that tens of milli-seconds might be a reasonable time scale for application.

> It's much the same reason I don't
> like Windows for control in general. It often goes off and does God
> knows what while you wait.

The tests I conducted did "God knows what while you wait" when conducted under Windows XP, but the worst case for a Linux 2.4 kernal was 37 milli-seconds under the light load scenario, and 42 milli-seconds under full load. Of course a few test cases doesn't *prove* anything, but I think it shows that scripting languages shouldn't be dismissed out of hand.

I suspect that a 'C' program would have shown similar threading performance if tested under identical conditions. Whether the increased execution speed of 'C' would offer any advantage is something that would depend upon the application.

> Recent Linux builds are far superior with
> kernel preemption and consistant latencies for control purposes. And
> you can get a far better idea what it's doing.

I may have access to a 2.6 kernal some time within the next few weeks. If so, I will repeat the tests again and publish them here. Based on the information I have read, I would not be surprised to see this also significantly reduces
the "jitter" in the test program.

 

> I don't doubt your conclusions or your methods. I would be interested in
> a comparison of this with a Windows platform. <

See a previous message on this subject - I conducted a test using Windows XP Pro. Summary - *most* times were about the same as the identical test with Linux 2.4 kernal. The magnitude of the deviations though was much greater (more than 200 msec). I suspect this is an OS issue and not a language issue.

> And a user mousing around and interacting. <

Moving the mouse by itself has no detectable effect that I have been able to measure. This should be no surprise as even very heavy CPU load seems to have only a very small effect. Moving a mouse cursor is of course not any sort of a significant CPU load.

"Interacting" is difficult to define. "User interaction" with the program would realistically consist of entering or changing values in one of the GUI screens. This may in turn trigger input validation routines. I would expect the effect this should have on the running program to be small, as the actual load created would itself be small.

Drawing a real time strip chart on the screen should have little effect. A simulated real time graph is one of the tasks in the test program I have been using and the results of this are included in the numbers I have been reporting.

> And of course, this is properly coded for the purpose.
> But have the average, non-cs user code this functionality and the
> results would likely be different. And writing, say a multipage menu
> type GUI with some disk and network IO would introduce some variability. <

I don't have a network set up for realistic network I/O effects, but I have conducted another set of tests to show the results of disk I/O. The program for this is simply a copy of the previous one with file output substituted instead of printing "beeps" to the console.

The experiment was intended to simulate logging test result data to a log file. Each test run consisted of writing a record every 500 milli-seconds. Each record consists of ASCII coded integers from 0 to 49. Each record is intended to simulate writing the test results for one test.

As in previous tests, there was some degree of variability in the results. The following is a fairly typical of the "worst case" results.

Starting with a large existing file (system default buffered) - Average = 10.07 msec. Standard deviation = 1.46. Max =29. Min = 6.

Of the samples, there were 1 of 13 msec, 2 of 20 msec, 1 of 21 msec, 1 24 msec, 1 of 29 msec, one of 6 msec, one of 7 msec. All the rest (out of 800 total) were between 8 and 12 msec.

I ran a number of tests under various conditions, but the results didn't deviate too much from the above. In some cases, all of the data points were between 8 and 12 msec.

<clip>
> What I am saying, is that, as used by
> the people attracted to the ease of scripting languages over other
> methods, scripting languages can be way too simple :^) I'm sure you've
> seen (and waited for) examples. A good programmer who understands the
> platform and has time to profile and test, can probably produce
> acceptable results with almost any language on today's hardware. But
> what I've seen from the VB crowd, for example, doesn't inspire
> confidence. And I'm not sure how you could ever fully understand some
> platforms.
<clip>

What you are saying is that a good programmer will write good programs, and a bad programmer will write bad programs. That is more or less a truism, and it isn't a language issue. Yes there are a lot of chimpanzees writing programs with VB, but that has more to do with the amount of advertising for VB which brought it to their attention first rather than anything else. The VB language itself is not actually easy to master as it is very irregular. The people who write good programs with it had to work at it.

The original question in this discussion asked about scripting languages which don't need an additional development system of their own. VB doesn't really fall into that category as it needs a special proprietary development system. The language and development software are bound together. With Python, Perl, PHP, Ruby, etc. you have your choice of development systems, including a simple text editor if that is what you wish.

I would also like to point out if I have not done so already, that the test program I created had a simple GUI, "real time" graphics, and multi-threaded operation in about 100 lines of code. The language and library support seems to be there for doing these types of things in a straight forward manner.

I would conclude from the experiments that I have conducted that the original question concerning the use of a scripting language for custom "control" applications is reasonable for at least a very large class of such problems. I don't claim that it would be suited for all problems.

 

This is a follow-up to a previous discussion, where as part of the debate I presented some timing data from running a small program simulating a PC application using a scripting language on a non-real time OS. The data was intended to show how regular the software timing could be without actually using a compiled systems langauge (e.g. 'C') or an RTOS. At the time I said I would follow this up with more timing data comparing the results on a newer OS kernal.

To recap, the experiment consisted of three program threads. One was a GUI thread drawing "real time" graphics, the second was a data logging thread appending to a file, and the third was a "control" thread which wrote clock times to an array. These were scheduled at 10, 500, and 10 milli-seconds respectively. A total of 800 time samples were collected. The application language was Python 2.3. Threading was done using the standard Python
"threading" module together with "time.sleep" statements in each thread.

Additional info: The PC was a 1.7 GHz Celeron, with 512 megabytes of RAM.


Case 'A' - Using a 2.4 Linux kernal. This data was reported previously but is repeated here for comparison purposes:
Average = 10.07 msec. Standard deviation = 1.46. Max =29. Min = 6. Of the 800 samples, there were 1 of 13 msec, 2 of 20 msec, 1 of 21 msec, 1 24 msec, 1 of 29 msec, one of 6 msec, one of 7 msec. All the rest (out of 800 total) were between 8 and 12 msec.


Case 'B' - Using a 2.6 Linux kernal:
Average = 10 msec. Standard deviation = 0.34. Max = 11. Min = 9 Of the 800 samples, ALL fell within 9 and 11 msec. (47 of 9 msec., 45 of 11 msec., the rest of 10 msec.).

Observation - The experiment using the 2.6 Linux kernal resulted in significantly more consistant timing.


The Linux kernal 2.6 used also has a resolution of 1 msec in scheduling timing (the 2.4 kernal had a 10 msec resolution). Repeating the above experiment at 10 times the scheduling rate (1, 50, and 1 msec.) showed the following typical results:

Case 'C' - Linux 2.6, 10 times faster scheduling rate:
Average = 1.02 msec. Standard deviation = 0.31. Max = 2. Min = 0. Of the 800 samples, ALL fell within 0 and 2 msec. (32 samples of 0, 45 of 2, the rest of 1 msec). The time measurement only had a resolution of 1 msec., so the precision of the results is limited.

Observation - Even at 1 msec scheduling, the times were surprisingly consistant.


The above tests were not conducted over a long enough period of time, or under enough different conditions to state that the above timings can be guaranteed under all circumstances. Linux is not a real time OS. However, this does look promising for a lot of non-real time applications which still require a quickly responding system.

 

Excellent report, Michael, Thanks very much.

Bill

 

Thanks, Michael; those are interesting and valuable observations. Looks like the 2.6 kernel is the way to go if you choose to use Linux.
--
Steve Myres, PE
Automation Solutions
(480) 813-1145

 

Hi Michael

That's pretty much what I found. I wouldn't worry replacing a PLC with a Linux box executing control oriented software. And I'd probably worry less about motion and fast loops than I would with the builtins in todays PLCs. I'd be really interested what Wind River has done with their "carrier grade" Linux products. I wish I had a project that would let me spend the time.

Regards

cww

 

Controling a mill or lathe is very simple with Win 2000 or xp program using my program. Full X,Y,Z, and A "A" and "B' axis using. Servo's or steppers systems.I can be contacted at [email protected]
Arthur