# Data acquisition and Linux

L

#### Levent Cetin

I try to make a presentation for students titled "Measurement in Linux". In this presentation I try to adjust fan speed according to temperature. I have two problems, one is unstable input data and the other is linux compiling of C++ code.

The first problem is due to data aquisition.When using standard IO card (Keithley DAS1600), I have problems with sequential operation.First i read data from Analog input channel and after calculating proper value, I am sending data to Analog output.It is a simple C++ code for presentation.But problem is that analog input is changing in quite wide range(for ~23 °C range is 18 to 50) when analog output part of the programme is sequentially running after input part and its not changing so much (for 23 °C 22 to 24) when analog input programme is running itself.I really dont know what to do to stabilize data.

For linux problem is compiling header files and commands."conio.h and dos.h,inportb,delay" are only valid in DOS not in unix and there is no information about linux.But I have also read about "asm/io.h" file which supplies commands like "outb".

C

#### Curt Wuollet

Hi levent

Suggest you get the driver from the Linux Lab project. Has examples of reading and writing. I am using a clone of this card succesfully under
Linux for automated test equipment. The easiest way to stabilize your input is to acquire several readings into a buffer and average them. Once you have them in an array you can apply any statistical treatment you wish. Using the driver lets you use read and write in normal UNIX
fashion rather than doing the low level stuff with ins and outs. Feel free to ask questions and I will try to help.

Regards

cww

R

#### Ron Gage

> For linux problem is compiling header files and commands."conio.h and
> dos.h,inportb,delay" are only valid in DOS not in unix and there is no
> supplies commands like "outb".

Try the following command - man outb

This will call up the manual page for all of the low level IO Port commands.
As an example...

NAME
outb, outw, outl, outsb, outsw, outsl - port output
inb, inw, inl, insb, insw, insl - port input
outb_p, outw_p, outl_p, inb_p, inw_p, inl_p - paused I/O

DESCRIPTION
This family of functions is used to do low level port input and output. They are primarily designed for inter-nal kernel use, but can be used from user space, given the following information in addition to that given in outb(9)

Does this help?

--
Ron Gage - Saginaw, MI
([email protected])

Free Gas Price Tracker - http://gastracker.rongage.org

J

#### Jiri Baum

> For linux problem is compiling header files and commands."conio.h and
> dos.h,inportb,delay" are only valid in DOS not in unix and there is no
> supplies commands like "outb".

Ideally, you want a driver for the card, but if you can't find one on the net...

Take a look at the manpages for outb and ioperm/iopl:
man outb
man ioperm
man iopl

(To browse through manpages, use the apropos command. Sometimes, like for printf, you also need to specify the manual chapter: "man 1 print" for the shell command and "man 3 printf" for the C function. Look at the intro page for each chapter for more info.)

For conio.h, that depends on what you want. If you just want to clear the screen, you can simply hard-code the escape code \e[H\e[J into a printf(3). For anything fancier, it's probably better to use curses.

Jiri
--
Jiri Baum <[email protected]>
"[Microsoft] cleverly associate the word 'open' with XML. What they don't mention is that to see the XML file definitions for Microsoft Word, you
have to sign a file license that says you will never use the code."
-- http://www.itworld.com/Man/2685/IDG010503source2/

P

#### Prabhat Ranjan

Levent,
First the answer to your second part. For low level IO Port programming we use 'outb' and 'inb'. Compared to DOS I believe the arguement order needs to be interchanged. You can see a document "IO-Port-Programming" in
HOWTO set of documents under mini directory. It is placed in /usr/doc/HOWTO directory in RH6.2 and /usr/share/doc/HOWTO in RH7.0 installation. You may get it from internet if not installed on your machine. For the 'delay' you can use either sleep() with 1 second time resolution or usleep() with microsecond resolution. However usleep() under normal linux would be only accurate to possibly 10 ms or so. We normally use Real Time Linux for Control with more demanding time response.
I have not understood your first part of the question correctly. But if you mean that there is lot of noise in the input data, then you may either place a hardware filter to filter out noise or use a digital filter in the software to reduce the noise.
I hope this helps!

- Prabhat Ranjan

*******************************************************************************
Dr. Prabhat Ranjan
e-mail : [email protected]
** SST Operation and Control Group Fax : 91-79-3269017
** ADITYA Tokamak Phone : (079)-3269001/02/03/04/05
Institute for Plasma Research, Bhat Village, Gandhinagar
Gujarat(India) - 382428
*******************************************************************************

D

#### Dale Malony

Curt wrote:
>"The easiest way to stabilize your input is to acquire several readings
>into a buffer and average them.
>Once you have them in an array you can apply any statistical treatment
>you wish. Using the driver lets you use read and write in normal UNIX
>fashion rather than doing the low level stuff with ins and outs."

Hello Curt,
I have some questions for you and others on the LPLC or other open source projects after my comments below.

Last night I read much of "Halloween I"
http://www.opensource.org/halloween/halloween1.html and consider the analysis in the leaked Microsoft document regarding Open Source Software
(OSS) very insightful. As much as I hate to say anything good about MS, it seems they and the developers of tools that run on Windows understand and target the wants/needs of the average user better than the Enthusiast
Developer Community of Linux and other open source tools which please the expert Sys Admin or integrator like yourself. This is likely related to Eric Raymond's explanation that OSS is usually developed to "scratch an itch."

I'm sometimes not sure whether developers with the knowledge to accomplish what you described in the quote above realize that just the description you gave is enough of a foreign concept to cause many or most to either pass on the idea or spend, lots of money for a tool. I believe most people that have a need for such tools only want to use them, not develop them. That's why my group at Honda spent $10k-$15k for a Labview package. When I buy such software, I expect the developer to make it work, and I expect them to continue to develop it to meet my future needs as technologies
develop. Unfortunately that doesn't happen as my ideal would define.

#1 Is development underway or planned to create user friendly tools to accomplish what you described above for Puffin or other projects that you are aware of?

#2 Big Picture: Once an OSS tool meets the expectations of project developers, should I believe that such tools will to continue to be
refined to the point that the install-to-productivity process and learning curve would be comparable to a product such as Labview?

I would love to see OSS like Linux achieve world domination, especially for operating systems and connectivity, but businesses depend on software tools for their survival, growth and profitability. If my software fails me, my
ability to support my family is compromised.

#3 How would you realistically ensure a company which does not have the resources to continue development of a tool that they should put themselves in position of long-term reliance on an OSS tool?

C

#### Curt Wuollet

> Curt wrote:
> >"The easiest way to stabilize your input is to acquire several readings
> >into a buffer and average them.
> >Once you have them in an array you can apply any statistical treatment
> >you wish. Using the driver lets you use read and write in normal UNIX
> >fashion rather than doing the low level stuff with ins and outs."
>
> Hello Curt,
> I have some questions for you and others on the LPLC or other open source
> projects after my comments below.
>
> Last night I read much of "Halloween I"
> http://www.opensource.org/halloween/halloween1.html and consider the
> analysis in the leaked Microsoft document regarding Open Source Software
> (OSS) very insightful. As much as I hate to say anything good about MS, it
> seems they and the developers of tools that run on Windows understand and
> target the wants/needs of the average user better than the Enthusiast
> Developer Community of Linux and other open source tools which please the
> expert Sys Admin or integrator like yourself. This is likely related to
> Eric Raymond's explanation that OSS is usually developed to "scratch an itch."
>
> I'm sometimes not sure whether developers with the knowledge to accomplish
> what you described in the quote above realize that just the description you
> gave is enough of a foreign concept to cause many or most to either pass on
> the idea or spend, lots of money for a tool. I believe most people that
> have a need for such tools only want to use them, not develop them. That's
> why my group at Honda spent $10k-$15k for a Labview package. When I buy
> such software, I expect the developer to make it work, and I expect them to
> continue to develop it to meet my future needs as technologies
> develop. Unfortunately that doesn't happen as my ideal would define.
>
> #1 Is development underway or planned to create user friendly tools to
> accomplish what you described above for Puffin or other projects that you
> are aware of?

Yes, we intend to provide a full featured system with reasonable user interfaces. This will be some time in coming and will be implemented with Open Source tools of course so it won't be exactly like all the other offerings. Let's be clear on the concept, If the other guys were
to suddenly open up their source, would the product be any harder to use? There is no reason we can't build the same functionality with
OSS. How long depends on the support we get from the community,

> #2 Big Picture: Once an OSS tool meets the expectations of project
> developers, should I believe that such tools will to continue to be
> refined to the point that the install-to-productivity process and learning
> curve would be comparable to a product such as Labview?

Learning curve should be better as _all_ the information is available and you have the folks that wrote it available on the lists. If a significant number of users have some programming talent available we will improve and mature much more quickly than a commercial project. Labview is more about what I do than what the project does being oriented towards test and measurement
more than factory automation. Since you can buy Labview for Linux, albeit not Open Source, obviously we can match that. We will probably go more towards traditional PLC territory initially but since I am doing automated test equipment, some of that may well show up in LPLC. If users were to share the applicaions that they do where feasible, your productivity would, of course
skyrocket. It's the sharing and reuse that makes much OSS development very fast. We have had to start from scratch in this area. As we move out towards the user, things will accelerate as we are able to make use of existing code..

> I would love to see OSS like Linux achieve world domination, especially for
> operating systems and connectivity, but businesses depend on software tools
> for their survival, growth and profitability. If my software fails me, my
> ability to support my family is compromised.

Where I am working right now we use Linux exclusively. Trust me, if your software fails you it's that other stuff :^) Seriously, the hardest part about migrating to Linux is simply convincing people they can learn other tools.
If you absolutely can't live without Office, don't switch, it will never be available for Linux. If all you need is to be able to do everything that Office does and you're willing to spend time here and there learning a new package
it is relatively easy to run your whole business on Linux. We had some whining for a week or two then business as usual. 80%reduction in costs
means we won't be switching back anytime soon. Expect a lot of this as Microsoft changes it's licensing to recover losses in the tech downturn.
My consultancy specializes in conversions from MS to Linux and other places are seeing similar results. I haven't had anyone who didn't make
it or has wanted to go back. There are line of business products that are not available on Linux but all the most common stuff can be found.

> #3 How would you realistically ensure a company which does not have the
> resources to continue development of a tool that they should put themselves
> in position of long-term reliance on an OSS tool?

This is the very best reason to rely on OSS. Since no single organization owns or controls it, it will survive as long as there is interest. With the commercial products you are familiar with, perfectly good software can become useless
when they decide you need to buy an upgrade. And if they go out of business or just drop that product? With an OSS product, if all else fails it can still be repaired or enhanced and no one can ever force you to upgrade. I use Linux 1.02 on some machines, no problem, Try to use Windows 1.0! If it breaks, any good programmer can still fix it for you because you have the source.

Please think about that seriously, in reality it is much more security than you are getting spending megabucks on commercial systems where you own nothing and they can cut you off tomorrow.

Regards

cww

C

#### Curt Wuollet

Thank You Micheal, for the big picture viewpoint. I would only add that we are Machine Automation Tools now. http://mat.sourceforge.net

Regards

cww

J

#### Johan Bengtsson

For the first problem: it sounds like you have a noice problem and need a low pass filter before the input card. It could easily be done by a resitor and a capacitor (or an inductor and a capacitor) You can low pass filter in software too, but you should really put at least one analog filter in hardware before the card. Use values where R*C is in the approximate range of your sampling interval or more. (higher value = more filtering = slower input)

For the second problem: I don't know offhand, someone else is probably however....

/Johan Bengtsson

----------------------------------------
P&L, Innovation in training
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------

M

#### Michael Griffin

Dale Malony wrote:
<clip>
>#3 How would you realistically ensure a company which does not have the
>resources to continue development of a tool that they should put themselves
>in position of long-term reliance on an OSS tool?

I'm not involved in any way with the Linux PLC project, but there was a general discussion about this subject when the project was started. I suspect that any initial interest in this may come from OEMs who build standard machines, but customise each one to a particular application. There is a substantial market for this type of equipment in certain industries.

We currently have equipment from several companies who have developed and support their own proprietary soft logic systems. Typically
they build a machine up to a certain point without having a customer for it. When they get an order they then finish it off and use the soft logic software to quickly modify a standard program to provide the required special functions. The end customer can then treat the system as a black box which is never changed, or they can make minor modifications themselves if
they care to.

There is no special secret knowledge embedded in these proprietary soft logic systems. Apparently they developed their own systems because they don't feel comfortable relying on a third party. The customers of these OEMs
require long term support and service as a condition of doing business with them. If they used a third party soft logic supplier who then went out of business or dropped the product or changed it too much, the OEM would be stuck with supporting an orphaned control system. They apparently feel this is a business risk they don't want to take.

Given the above, I believe that an open source soft logic system would suit these OEMs much better than their own proprietary systems would. They would have to devote fewer internal resources to basic software development but could still take advantage of developments elsewhere (and contribute their own of course). They would always have the source code, so they would not be dependent upon someone else to maintain the product. They could also time major system software changes to their own product development schedule, rather than to someone else's.
If they needed to talk to a specific device or bus which was not currently supported, they could write the necessary software (as they do now). Talking to a wide variety of hardware isn't really a problem for these companies though as they don't actually have to do this. The machines are designed with certain I/O, and the customer buys it as is.
The Linux OS shouldn't really be an issue. I am not aware of a single system of the type I am referring to which uses Windows. They all use some other operating system (e.g. QNX or something similar). The end customer doesn't care, as it would never have occured to most of them that there actually is an operating system somewhere in the machine.

>#1 Is development underway or planned to create user friendly tools to
>accomplish what you described above for Puffin or other projects that you
>are aware of?
>
>#2 Big Picture: Once an OSS tool meets the expectations of project
>developers, should I believe that such tools will to continue to be
>refined to the point that the install-to-productivity process and learning
>curve would be comparable to a product such as Labview?
>
>I would love to see OSS like Linux achieve world domination, especially for
>operating systems and connectivity, but businesses depend on software tools
>for their survival, growth and profitability. If my software fails me, my
>ability to support my family is compromised.

I don't think this Linux PLC (or Puffin, or whatever it's called) will be a direct threat to traditional PLCs unless a company packages it
with special hardware and sells it as a system which works out of the box.
This is however quite a realistic long term possibility, especially for some of the smaller PLC manufacturers. They could sell it as commodity software running on proprietary hardware. This would do what IEC-1131-3 never achieved - make PLC programs portable between different manufacturers.
The larger PLC manufacturers have always been able to use the cost of programming software and the time involved in learning how a new PLC
works to help lock in their customers. If one or more smaller PLC manufacturers were to offer products which were software compatable with a
standard system, they would likely find much more acceptance than their current products do. They could still use proprietary hardware to target the
products at specific markets as long as it would still run the same basic soft logic system.

These companies could still support their products, just as they do now. The fact that they are including commodity software as part of their
systems doesn't really change the fact that they are selling a brand labelled product. I expect that in this situation end customers would still
specify a particular brand of PLC, based on distribution, spare parts, service, etc.

I don't think there will be a lot of interest in the Linux PLC outside of the original group until there is an actual basic working system that people can play with. I expect that the first priority of the team will be to get something useful running and worry about the sort of features that you or I would want later. Once they have something tangible working, they can attract the attention of other interested parties. These other interested parties could then contribute the sort of resources which are
required to provide what you want. Some examples of these other interested parties may be:

1) Large standard equipment OEMs (as mentioned above).
2) Small PLC manufacturers (as also mentioned above).
3) Associations of machine tool manufacturers. There are in certain countries large groups of small to medium size companies who build specialised machine tools, injection molding machines, and other such equipment. These companies will sometimes work together to promote their industry in general. They could work together on a project which benefits all of them for much the same reasons as the large companies mentioned in example #1.
4) State owned industrial research establishments. These exist in many countries to do research which assists companies which build or use industrial equipment or new production processes.
5) University Electrical Engineering departments. This is exactly the sort of research project which would be ideal for them. It can be worked on in small pieces, shouldn't take much cash, and has obvious utility. I expect to see a lot of interesting concepts coming from this source in future once something exists to provide a focus for activity.

**********************
Michael Griffin