In reply to Armin Steinhoff: The PC/104 systems are for "embedded" use, with all the advantages and disadvantages that this brings. If someone is trying to run off the shelf software, they had better research whether it will run on that specific board before using PC/104. On the other hand, if you are writing custom software and want to bury a computer down inside a machine in a difficult environment, then PC/104 is probably a very good choice.

If someone is not sure what they are doing, want something that is very similar in capability to a desktop system, and don't have a particularly difficult environment, then one of the small form factor PC formats might be a better choice.

I just had a look at some PC/104 CPU boards, and there seem to be two classes. The run of the mill variety are 100 to 133 MHz. The high performance ones are 400MHz. to 1.4GHz. The faster ones however often need special heat sink arrangements to get rid of the heat and some use CPU fans.

There are faster and slower PC/104 CPU boards, but even the fastest PC/104 CPU board is much slower than the typical desktop PC sold today. Not only are the CPUs clocked slower, but most of them use CPUs that have a lower instructions per clock rate.

This *is* to cut power consumption and heat output (which are more or less the same thing). Most of the applications they are used in need to be fanless and often do not have any external ventilation. Desktop PCs today often have massive fan systems to keep their CPUs and graphics cards from melting down (some even have liquid cooling systems). Most PC/104 CPUs are fanless and many don't even need heat sinks.

In embedded applications, often slower is better. Getting rid of heat is a major design consideration so it is best not to generate the heat in the first place. This make the job of the programmer more difficult, as they have to write more efficient software to get the same job done.

The Mini-ITX systems that I mentioned have the same restrictions. Mini-ITX boards that are intended for industrial use come in fan and fanless versions. The fanless versions are always slower than the fan-equipped versions. To get rid of the fan, they have to clock the CPU slower. The slower Mini-ITX boards are roughly comparable to the faster PC/104 boards (and often use the same CPUs).

Cases for Mini-ITX boards are typically ventilated, often with auxiliary fans. There are sealed enclosures for Mini-ITX, but these have special hardware to connect the CPU heat sink directly with a finned heat sink on the outside of the case. Getting rid of heat from a small case is a problem even for a board that only consumes 14 or 15 watts.

The other small form factor SBCs probably have similar feature and restrictions to either the PC/104 or Mini-ITX. As so long as you are using an x86 type CPU, they are all working with more or less the same chips and the same laws of physics. Other CPUs such as POWER, MIPS, ARM, etc. have different parameters, but that was outside the scope of our original discussion.

 

In further reply to Armin Steinhoff: The comments I originally made with regards to PC/104 have to be taken in context with the subject of this thread. In the particular application in question, I was cautioning Dirk to be sure that PC/104 was suitable for what he was doing, and that it could be that a small form factor PC may be a better choice.

To better summarise what I was saying with regards to PC/104 systems.

1) PC/104 is an embedded format. This has advantages, but also imposes restrictions.

2) PC/104 will be slower than a conventional desktop PC and with less RAM. This doesn't mean that it is too slow for any job, but for example you wouldn't want to try to run MS Windows Vista on one (if it is even possible).

3) "Typical" PC/104 systems come with or have available a tailored Linux distribution, but they don't have a complete compiler suite on board. This means that MAT programs would have to be cross-compiled on a separate PC and downloaded to the PC/104 system.

4) An interpreter may work, but a fast byte code or threaded interpreter should be used.

5) Off the shelf soft logic systems may run, but the user would have to check in detail as to whether that specific soft logic system will run on that specific CPU board.

 

A few months ago, Marc Sinclair mentioned that a recent Siemens HMI (TP177) is running on Linux.

 

In reply to Dirk: Most of the soft logic systems on the market today were developed at least 5 to 10 years ago. The market concept for most of them (including Siemens WinAC) is that the user buys a copy of the software, and then sticks the CD into a desktop computer that they bought from a local computer store or ordered on-line from one of the big vendors.

When the soft logic software was being designed (5 or more years ago), any consumer grade computer that you bought came with some version of MS Windows. Linux was well supported (at least from 5 years ago), but only in the professional server market. You can buy desktop PCs today from Dell, HP, etc. with Linux, but that is a more recent development.

IsaGraf supports a wider array of platforms, but they seem to have been targetting a slightly different market than companies like Siemens. Siemens was targetting the same market as people who were buying their conventional PLCs, while IsaGraf appear to have been targetting more sophisticated users, such as companies building standard machinery.

About 10 years ago, a number of PLC customers (including General Motors) were promoting the idea of a standard PC based automation platform that would free them from vendor lock-in. The idea was to run soft logic systems on PC hardware with a Microsoft OS.

Although there were some applications, the idea never found much popularity. In my opinion, the original concept didn't really address any of the real problems, and added some very serious ones of its own.

It didn't solve the problem of vendor lock-in because the promoters were fixated on the hardware and didn't consider the rest of the system. They could now choose hardware from third party PC vendors, but were still running proprietary application software on a proprietary operating system. Switching soft logic vendors still meant your existing PLC programs and programming software couldn't be used with the new soft logic systems.

In exchange for no real benefit, we got fragile PC hardware and an operating system whose best known feature was the "blue screen of death". To top it off, the soft logic systems were usually more expensive than an equivalent conventional PLC in the same application.

If all you wanted to do is run some basic ladder logic to control a machine, a conventional PLC wasn't a bad choice. Modern ones aren't that expensive and they're ready to go out of the box. A soft logic system wasn't a good choice if you were just trying to save a bit of money.

Step forward to today however, and we have a different situation. Compact, rugged PC systems with no moving parts are off the shelf for a reasonable price. Linux and BSD operating systems are available which are reliable, simple, and well suited to these applications. Both free and non-free soft logic systems are available.

What's missing is really two things. One is packaging and documentation. Packaging is putting a complete system together, or at least offering all the pieces with a guaranty that they will work together. People don't want to hunt around to get one bit here and another bit there and then hope they all work together. Look at the questions we get all the time along the lines of "will software 'x' and software 'y' work together on Windows Vista Ultimate French Version?".

Compare that to installing software on a typical Linux distro using a package manager. You start up the package manager, type in a search term for what you are looking for, and then choose the package you want out of the selections available. A few clicks, and everything you need is installed and working in minutes. For soft logic systems to become that easy to use on Linux, people will have to package them for Debian, Ubuntu, Fedora and Mandriva. Packaging isn't hard, but someone has to do it.

The other thing that has been missing is the end user motivation. As I said earlier, if you are just trying to save money on your Allen Bradley or Siemens PLCs, then look at cheaper vendors such as Koyo. Where the motivation to use a soft logic system comes however is when you are trying to do things which conventional PLCs do poorly or not at all. Conventional PLCs are poor at things like processing or storing large amounts of data. They aren't good at working with hardware or software from other vendors or integrating into a larger system.

Where soft logic systems might start to show their real advantages is when controlling the machine is only a small part of what they need to do. In other words, where the soft logic system has the advantage is when it is an addition to another system rather than a stand alone controller.

 

That one's easy. If you wish to be a MS "partner" and get the info you need to compete in the majority market, you will be pressured to be all MS. And if you sell into the Linux market, for example, your pricing and perks will go south. At one time, it was actually written into the agreements. They've probably had to get more subtle since the monopoly convictions. And Siemens _is_ doing things with Linux, but between the exclusive licensing and the monopoly bias and hegemony on the consumer side, it's pretty hard to develop a customer base to sell a product into. MS has spent a great deal of effort in making it difficult to jump ship and they have been very effective. Margins in all aspects of the PC business are such that very little pressure can make you unprofitable. Having to pay retail for Windows for example, would eat all of the profit in the general computing class machines. They can easily get their way and as you can see if you look at it objectively, they have, with few exceptions. Any guesses why IBM got out of the PC business? And why puppet organizations with open in their name, standardize on Microsoft technology? These things are invisible from inside the monopoly but become obvious quickly if you try to do business outside.

Regards

cww

 

I think you're missing the substantial numbers of companies that provide programmable automation controllers (the name coined to refer to these
software-enabled embedded computers because the phrase "SoftPLC" is a trademark) complete with packaging, system design assistance and a host of
system integrators that are effective and experienced. Just off the top of my head:

National Instruments
Opto22
Wago
Phoenix Contact
Advantech

There are certainly others, but it is 5 am in a hotel room, so I might be forgiven if I left anybody out.

Most of these systems are using WinXPembedded or WinCC. These controllers have been around long enough now that their usability and durability is no longer in question.

As Dick Morley said, when talking about the PLC, "It was always a computer. We called it a controller so we wouldn't scare the operators."

Walt Boyes
Editor in Chief
Control magazine
www.controlglobal.com
blog:Sound OFF!! http://www.controlglobal.com/soundoff
_________________

Putman Media Inc.
555 W. Pierce Rd. Suite 301
Itasca, IL 60143
630-467-1301 x368
[email protected]

 

Hello all,

Yes, this is one view of the usage of soft logics.

Soft logic applications have big advantages if you have to integrate many different subsystems.

For instance... a graphical application of a driver display can have interfaces to fieldbus systems, C++ coded control tasks and an embedded text database (SQL). It does also communicate to different hardware subsystems besides the GUI interface. It does in general a lot of computing for the animated GUI and the verification or conversion of input data.

This is more or less typical for soft logic systems, but such a kind of integration isn't possible with a ladder logic based standard controller.

BTW... QNX6 offers in the meantime very interesting features for secure control applications... multi-core support makes sure that computing power is always available and additionally the partitioning of CPU time makes sure that all critical tasks will get the necessary CPU time.

Best Regards,

Armin Steinhoff http://www.steinhoff-automation.com

 

I have not seen anything that proves this. Actually talking to them included. At least, as far as WinAC is concered, I don't know about their true PLCs.

Dirk

 

And you have the choice of Windows or Windows. Any color you want as long as it's black, or in this case, blue.

Regards
cww

 

And in general the "Green PCs" have more speed/watt than older designs. There is no reason the same chipsets can't be done in PC104 and leave all the media spigots off and achieve even better ratios. It's just extremely unlikely that they will do this for $65.00. In capability/$ it's gonna be awful hard to beat entries like the PC2500 and leaving stuff out won't lower cost much.

Regards
cww

 

In reply to Walt Boyes: Dirk's question was why most of the PC based soft logic systems seemed to require MS Windows as the OS. He hasn't been too specific about what his planned projects are, but they seem to involve a soft logic system being closely integrated with some other software on a PC based system.

As for as the products you metion (NI, Opto22, Advantech, etc.), I would call them PLCs. They are dedicated controllers running on custom hardware. That's what a PLC is. The "programmable automation controller" phrase seems to be more a marketing term than anything else.

The discussion about "packaging" referred back to his questions about using a soft logic system with a Linux OS on a PC. Most Linux distributions have a "package manager" that takes care of installing and removing software. Preparing the software and documentation for easy installation is called "packaging" and is done by the software authors or by someone else ("package maintainers").

The description probably doesn't mean much to anyone who has only used MS Windows, because Windows package management is extremely primitive to non-existent (it's pretty much a free-for-all when it comes to installing software). None the less, Linux users perceive software packages in the following hierarchy: supported or core packages > extra packages > packages outside the repository > unpackaged > CVS.

Right now, all the free automation related projects for Linux seem to be in the "unpackaged" to "CVS" zone. That's not a problem for people who know what they are doing, but it's a barrier to most people who aren't interested in anything outside their distribution's repositories.

 

In reply to Dirk: Siemens uses Linux as an embedded OS in some of their products (as do other companies). I doubt that many of their sales reps would know much about it though, as they don't generally know what embedded operating systems they use in any of their other products.

Siemens also has their own private Linux distribution they call "Siemens Industrial Linux". Their consulting arm uses this in projects for things like integrating your production lines to your ERP system. Unless you are a really big company with lots of money to spend though, they won't talk to you.

Neither of the above has much relevance to your project though. Embedded operating systems are invisible to the user, and I doubt that you will ever deal with their integration consultants. Siemens Industrial Linux isn't available for download, so don't waste time worrying about that either.

 

You see, the strategy is working :^). Even Siemens can't afford to upset Bill. That's why it's kept very quiet and a lot of things will run on Linux with no outward indication from firms that have a large exposure to Microsoft pricing and support.

Once they figure out how to get their neck out of the noose, you will start to see Penguins all over. Certainly in the EU first, where they don't own _all_ of the politicians and can't make it effectively illegal to open things up under the sheepskin of IP protection.

Regards
cww

 

They are not PLCs. The difference between a PLC and a PAC is the rigid
proprietary OS of the PLC, versus the more open capabilities of PACs to use
different OSes, like Windows and Linux. PACs have more capabilities, are
more open, and are designed to be interfaced with control systems more
easily than PLCs. I respectfully disagree that it is more marketing than
anything else. I will not debate the degree of openness among available
OSes. Even Linux can be construed as "not open" if somebody wants to waste
the hot air.

The fact is, I/O and field controllers are becoming more powerful, more
capable and more interfaceable every day...and more like a network node than
a standalone piece of electronics.

This is getting very interesting from the enterprise control point of view.

Walt Boyes
Editor in Chief
Control magazine
www.controlglobal.com
blog:Sound OFF!! http://www.controlglobal.com/soundoff
_________________

Putman Media Inc.
555 W. Pierce Rd. Suite 301
Itasca, IL 60143
630-467-1301 x368
[email protected]

 

In reply to Walt Boyes: I had a look at the products you listed, and found the following information.

National Instruments - The NI system is basically a small form factor PC in a Compact PCI rack with Labview. What about if I put a Mini-ITX board in a nice box and loaded it with Labview? Would that be a PAC, or do I have to charge $5000 for the motherboard like NI before it qualifies? I would call this a PC based system.

Opto22 with PAC Project - The Opto-22 system seems to be genuinely something different. However, it appears to be primarily oriented towards small scale process industries rather than being a general purpose system. If you want to say that it has a combination of features that puts it somewhere between a PLC and a small scale DCS, then I won't argue with you over it. So, we'll call this one a "PAC".

Wago. They don't use the term "PAC". The closest they have would be the 758 series running the CoDeSys IEC 61131-3 on RT-Linux. Why is this not a PLC?

Phoenix Contact with PC WORX - This is simply their IEC 61131-3 software running on their PLC-like hardware. Why is this not a PLC?

Phoenix Contact with Steeplechase VLC (flowcharts) running on their PLC-like hardware. Why is this not a PLC?

Phoenix Contact with "High-level language". This is just a set of interface libraries for their I/O to allow you to write C++ or VB programs on their MMI panels (or PCs). It's not a PLC, but I don't see how it can qualify as a "PAC" (even though they list it as one).

Advantech - Their "PAC" is the ADAM-5500. This has the Datalight ROM-DOS OS and lets you program in Borland C++ 3.0 for DOS. I'm sure that brings back old memories for a lot of people, but what is so special about putting an SBC into a nice rack?

Now let's deal with your qualifying points in turn:

> The rigid proprietary OS of the PLC, versus the more open capabilities of
> PACs to use different OSes, like Windows and Linux. <

How do you know what OS is used in any particular PLC (if it uses one at all)? The newer ones probably use something like VxWorks, or even an embedded Linux. Perhaps you are trying to say that you can run third party application software on the "PAC" hardware as well as the manufacturer's own offerings. That is probably the case for the NI hardware, as it is really just a small form factor PC. For any of the others though, I have my doubts.

> PACs have more capabilities, <

Labview may be better at test systems than a PLC, but it is probably not as good for typical machine control. I've already agreed that the Opto-22 system is something different, so I won't argue that further. Of the remaining systems, two are just IEC 61131-3 (just like a PLC), one uses flow charts (just like some PLCs), and two just let you bang away at a 'C' compiler (which I suppose in a way qualifies as "more capabilities").

> are more open, <

The NI system is a PC, so I suppose we can call that "open". Now, what does "open" mean with respect to the rest? Why is the Opto-22 system "open"?

> are designed to be interfaced with control systems more easily than PLCs <

Er, PLCs *are* control systems. You're going to have to explain that one a little better I think.

So out of 7 possible "PACs", we have one for which there appears to be a genuine case (Opto-22), one PC based system (NI), three PLCs running IEC 61131-3 or flowcharts, and two which are basically barebones systems for which you write your own software in C.

If we look at the Opto-22 web site to see why they think it qualifies as a "PAC", we see the following points.

> Operate using a single platform in multiple domains, including logic,
motion, drives, and process control. <

Doesn't AB Contrologix do this as well?

> Employ a single development platform using common tagging and a single
database for development tasks across a range of disciplines.
>
> Be programmable using software tools capable of designing control programs
to support a process that "flows" across several machines or units, integrating multiple domains into a single system. <

Siemens calls this "Totally Integrated Automation" for their S7 product line.

> Tightly integrate controller hardware and software. <

A PLC is tightly integrated.

> Provide efficient processing and I/O scanning. <

And, a PLC processes I/O efficiently.

> Operate on open, modular architectures that mirror industry applications,
from machine layouts in factories to unit operation in process plants <

This is a bit vague, but it might be the real meat of what makes the Opto-22 system different.

> Employ de-facto standards for network interfaces, languages, and protocols,
allowing data exchange as part of networked multi-vendor systems. <

This has more to do with being a minor vendor as the same is true for most small PLC vendors as well. If you have a small market share, you can't afford to play the proprietary protocol game.

So, if there is a difference between a "PAC" and a PLC, then it seems to be a fairly subtle one.

 

dear,

i am trying to develop the same plc functionality in pc, hope you have already done that.. did you do it by using soft logic plc's or by writing a code in C. if u did in C will u explain me how to do it.

 

I have done this in Python. I have a project called MBLogic at:

http://sourceforge.net/projects/mblogic

It includes a complete soft logic system, web based HMI, field device connection via Modbus/TCP (client and server), and various other features. There are also stand alone libraries that you can use to write custom programs, including a soft logic library that you can use to add PLC like functionality in other programs (e.g. in a production test system).

There is a project web site at:
http://mblogic.sourceforge.net/

If the information there that doesn't answer your questions I would be happy to further discuss whatever it is you are trying to do. It would help however if you would tell us what the actual objective is that you are trying to achieve. There are multiple ways of approaching this problem depending on what you are trying to do.

 

A PLC really isn't very hard to emulate.

Interface some IO to your computer. For what I did this was a DIO48
card that uses an OSS driver.

Init the card and set inputs and outputs.

Begin loop:
Read the inputs.
Solve the desired logic based on the inputs.
Write the outputs.
End loop:

IF I can find it, I'll post the small PLC I wrote for Linux.
It's in two parts:

A PLC part that does the above.
A viewer part that shows the memory map.

Regards
cww

 

With the moderators indulgence, here is how I did it in C on Linux.
You need to put an mem= statement in the bootargs to reserve 1 meg
above what Linux uses. Set it to 1meg less than what you have and
edit the programs to use that address. The solve function has a couple
example lines. This code was actually controlling an automation cell.
This uses ncurses and runs on the console or an xterm. Doing the IPC
this way would allow a kernelspace process (eg RTLinux) to join in the
fun. To add your process you simply pull in the map code and you can
read and write to the map directly and hence the IO.

smio.c

___________________________________________________________________
> #include <sys/types.h>
> #include <stdlib.h>
> #include <signal.h>
> #include <unistd.h>
> #include <fcntl.h>
> #include <string.h>
> #include <time.h>
> #include <ctype.h>
> #include <math.h>
> #include <sys/mman.h>
> #include <sys/ioctl.h>
> #include "dio.h"
> #define TRUE 1
> #define MAP_ADDRESS (31*0x100000) /* 1 mb less than total ram */
> #define BYTE unsigned char
> #define WORD unsigned short
> #define LONG unsigned long
> #define i1 get_i(2,8)
> #define i2 get_i(2,9)
> #define i3 get_i(2,10)
> #define i4 get_i(2,11)
> #define i5 get_i(2,12)
> #define i6 get_i(2,13)
> #define i7 get_i(2,14)
> #define i8 get_i(2,15)
> #define i9 get_i(2,0)
> #define i10 get_i(2,1)
> #define i11 get_i(2,2)
> #define i12 get_i(2,3)
> #define i13 get_i(2,4)
> #define i14 get_i(2,5)
> #define i15 get_i(2,6)
> #define i16 get_i(2,7)
> #define i17 get_i(1,8)
> #define i18 get_i(1,9)
> #define i19 get_i(1,10)
> #define i20 get_i(1,11)
> #define i21 get_i(1,12)
> #define i22 get_i(1,13)
> #define i23 get_i(1,14)
> #define i24 get_i(1,15)
> #define q1 set_o(0,7)
> #define q2 set_o(0,6)
> #define q3 set_o(0,5)
> #define q4 set_o(0,4)
> #define q5 set_o(0,3)
> #define q6 set_o(0,2)
> #define q7 set_o(0,1)
> #define q8 set_o(0,0)
> #define q9 set_o(0,15)
> #define q10 set_o(0,14)
> #define q11 set_o(0,13)
> #define q12 set_o(0,12)
> #define q13 set_o(0,11)
> #define q14 set_o(0,10)
> #define q15 set_o(0,9)
> #define q16 set_o(0,8)
> #define q17 set_o(1,7)
> #define q18 set_o(1,6)
> #define q19 set_o(1,5)
> #define q20 set_o(1,4)
> #define q21 set_o(1,3)
> #define q22 set_o(1,2)
> #define q23 set_o(1,1)
> #define q24 set_o(1,0)
> #define cq1 clr_o(0,7)
> #define cq2 clr_o(0,6)
> #define cq3 clr_o(0,5)
> #define cq4 clr_o(0,4)
> #define cq5 clr_o(0,3)
> #define cq6 clr_o(0,2)
> #define cq7 clr_o(0,1)
> #define cq8 clr_o(0,0)
> #define cq9 clr_o(0,15)
> #define cq10 clr_o(0,14)
> #define cq11 clr_o(0,13)
> #define cq12 clr_o(0,12)
> #define cq13 clr_o(0,11)
> #define cq14 clr_o(0,10)
> #define cq15 clr_o(0,9)
> #define cq16 clr_o(0,8)
> #define cq17 clr_o(1,7)
> #define cq18 clr_o(1,6)
> #define cq19 clr_o(1,5)
> #define cq20 clr_o(1,4)
> #define cq21 clr_o(1,3)
> #define cq22 clr_o(1,2)
> #define cq23 clr_o(1,1)
> #define cq24 clr_o(1,0)
>
> char *DevName = "/dev/dio48H_1A";
> char DevNameIO[20];
> int Mode = 0;
> int Status;
> int mfd;
> BYTE bReg;
>
> int fd_1A, fd_1B, fd_1C;
> int fd_2A, fd_2B, fd_2C;
> unsigned short value;
>
> typedef struct
> {
> unsigned short reg[512];
> float alg[512];
> int flags;
> } LMAP;
>
> LMAP *mapp;
>
> /* Forward Declarations */
>
> void setup_io(void);
> void close_io(void);
> void read_io(void);
> void write_io(void);
> void solve(void);
> int get_i(short reg,short bit);
> void set_o(short reg,short bit);
> void clr_o(short reg,short bit);
>
>
> main(int argc,char *argv[])
> {
>
> /* Let's do the nasty stuff first */
> /* We are using 1mb of ram excluded from the linux mm as shared memory */
> /* By typedef'ing our struct and mmaping it at MAP_ADDRESS we in effect */
> /* allocate it in the shared memory translated into user space. If this */
> /* seems like FM to you, don't feel bad, I had to read the kernel sources */
> /* to figure out where we actually allocate anything. hint, the compiler */
> /* did it */
>
> /* Note, I should check if there is a way to get and drop perms for */
> /* /dev/mem without running as root or chmod'ing /dev/mem. I don't */
> /* think ioperm() covers this. (security) */
>
> if(( mfd = open("/dev/mem",O_RDWR)) < 0)
> {
> perror("dev/mem open failed");
> exit(1);
> }
> mapp = (LMAP *) mmap( 0,sizeof(LMAP),PROT_READ | PROT_WRITE,MAP_SHARED,mfd,MAP_ADDRESS);
> if(MAP_FAILED == mmap)
> {
> perror("mmap failed");
> exit(1);
> }
> close(mfd);
>
> /* We should now have a shared memory map with no fuss. The code above */
> /* should be copied into all the map users. The declarations will go */
> /* into a common header file for abstraction. */
>
>
> setup_io();
> mapp->flags = 0;
>
> while( TRUE )
> {
> while(mapp->flags != 0) ;
> mapp->flags = 1;
> read_io();
> solve();
> write_io();
> mapp->flags = 0;
> usleep(1000);
> }
> }
> void setup_io(void)
> {
> strcpy(DevNameIO, "/dev/dio48H_1A");
> if ((fd_1A = open(DevNameIO, O_RDWR )) < 0)
> {
> perror("DevNameIO");
> printf("error opening device %s\n", DevNameIO);
> exit(2);
> }
> strcpy(DevNameIO, "/dev/dio48H_1B");
> if ((fd_1B = open(DevNameIO, O_RDWR )) < 0)
> {
> perror(DevNameIO);
> printf("error opening device %s\n", DevNameIO);
> exit(2);
> }
> strcpy(DevNameIO, "/dev/dio48H_1C");
> if ((fd_1C = open(DevNameIO, O_RDWR )) < 0)
> {
> perror(DevNameIO);
> printf("error opening device %s\n", DevNameIO);
> exit(2);
> }
>
> strcpy(DevNameIO, "/dev/dio48H_2A");
> if ((fd_2A = open(DevNameIO, O_RDWR )) < 0)
> {
> perror("DevNameIO");
> printf("error opening device %s\n", DevNameIO);
> exit(2);
> }
> strcpy(DevNameIO, "/dev/dio48H_2B");
> if ((fd_2B = open(DevNameIO, O_RDWR )) < 0)
> {
> perror(DevNameIO);
> printf("error opening device %s\n", DevNameIO);
> exit(2);
> }
> strcpy(DevNameIO, "/dev/dio48H_2C");
> if ((fd_2C = open(DevNameIO, O_RDWR )) < 0)
> {
> perror(DevNameIO);
> printf("error opening device %s\n", DevNameIO);
> exit(2);
> }
> ioctl(fd_1A, DIO_SET_DIRECTION, PORT_INPUT);
> ioctl(fd_1B, DIO_SET_DIRECTION, PORT_INPUT);
> ioctl(fd_1C, DIO_SET_DIRECTION, LOW_PORT_INPUT);
> ioctl(fd_1C, DIO_SET_DIRECTION, HIGH_PORT_INPUT);
> ioctl(fd_2A, DIO_SET_DIRECTION, PORT_OUTPUT);
> ioctl(fd_2B, DIO_SET_DIRECTION, PORT_OUTPUT);
> ioctl(fd_2C, DIO_SET_DIRECTION, LOW_PORT_OUTPUT);
> ioctl(fd_2C, DIO_SET_DIRECTION, HIGH_PORT_OUTPUT);
> }
> void close_io(void)
> {
> close(fd_1A);
> close(fd_1B);
> close(fd_1C);
> close(fd_2A);
> close(fd_2B);
> close(fd_2C);
> }
> void write_io(void)
> {
> BYTE buf[3];
> /* mapp->reg[0] = ~ mapp->reg[0]; */ /* toggle for testing */
> buf[0] = mapp->reg[0] & 0x00ff;
> buf[1] = mapp->reg[0] >> 8;
> buf[2] = mapp->reg[1] & 0x00ff;
> write(fd_2A,&buf[0],1) ;
> write(fd_2B,&buf[1],1) ;
> write(fd_2C,&buf[2],1) ;
> }
> void read_io(void)
> {
> WORD buf = 0;
> WORD shft = 0;
> read(fd_1A,&shft,1) ;
> shft <<= 8;
> buf = mapp->reg[1] & 0x00ff ;
> mapp->reg[1] = shft | buf;
> shft = 0;
> buf = 0 ;
> read(fd_1B,&buf,1) ;
> read(fd_1C,&shft,1) ;
> shft <<= 8 ;
> shft |= buf;
> mapp->reg[2] = shft;
> }
> void solve(void)
> {
> if(i21 || i23 ) q23; else cq23;
> if(i22 || i24 ) q24; else cq24;
> }
> int get_i(short reg,short bit)
> {
> if(mapp->reg[reg] & (0x01 << bit)) return(1);
> else return(0);
> }
> void set_o(short reg,short bit)
> {
> mapp->reg[reg] |= (0x01 << bit);
> }
> void clr_o(short reg,short bit)
> {
> mapp->reg[reg] &= ~(0x01 << bit);
> }

_____________________________________________________________

smdisp.c

_______________________________________________________________


> #include <ncurses/ncurses.h>
> #include <sys/types.h>
> #include <stdlib.h>
> #include <signal.h>
> #include <unistd.h>
> #include <fcntl.h>
> #include <string.h>
> #include <time.h>
> #include <ctype.h>
> #include <math.h>
> #include <sys/mman.h>
> #include <sys/ioctl.h>
> #define MAP_ADDRESS (500*0x100000) /* 1 mb less than total ram */
> #define BYTE unsigned char
> #define WORD unsigned short
> #define LONG unsigned long
> #define DR 18
> #define BC 3
> #define FC 6
> #define UPDATE 10
> #define DREGS 512
> #define FREGS 512
>
> int mfd;
>
> unsigned short value;
>
> WINDOW *w1,*w2;
> char *statp,tdatetime[20];
>
> /* vars for time routines */
> long t;
> struct tm *tp, *localtime();
>
> /* Demo map, 512 packed 16 bit I/0 regs, 512 32 bit float regs, 32 bit flags */
> /* This would be a lot of points, but allows for counters and such.*/
> /* 512 floats would be a lot of analog I/O, allows for fp math regs. */
>
> typedef struct
> {
> unsigned short reg[512];
> float alg[512];
> int flags;
> } LMAP;
>
> /* This map struct would be mmap()ed onto shared memory */
> /* Like this for Fred Proctor's method */
>
>
> int hep = 0;
> int key;
> int ccols = 3;
> int nregs = 512;
> int mode = 0;
> char rtype = 'r';
>
>
> void showbitz(unsigned short s,char *t); /* forward dec */
> void quit(void);
> void set_outs(void);
> void setup_io(void);
> void close_io(void);
> void read_io(void);
> void write_io(void);
>
> LMAP *mapp,*zapp;
> LMAP zap;
> main(int argc,char *argv[])
> {
> int i,count;
>
> /* Let's do the nasty stuff first */
> /* We are using 1mb of ram excluded from the linux mm as shared memory */
> /* By typedef'ing our struct and mmaping it at MAP_ADDRESS we in effect */
> /* allocate it in the shared memory translated into user space. If this */
> /* seems like FM to you, don't feel bad, I had to read the kernel sources */
> /* to figure out where we actually allocate anything. hint, the compiler */
> /* did it */
>
> /* Note, I should check if there is a way to get and drop perms for */
> /* /dev/mem without running as root or chmod'ing /dev/mem. I don't */
> /* think ioperm() covers this. (security) */
>
> if(( mfd = open("/dev/mem",O_RDWR)) < 0)
> {
> perror("dev/mem open failed");
> exit(1);
> }
> mapp = (LMAP *) mmap( 0,sizeof(LMAP),PROT_READ | PROT_WRITE,MAP_SHARED,mfd,MAP_ADDRESS);
> if(MAP_FAILED == mmap)
> {
> perror("mmap failed");
> exit(1);
> }
> close(mfd);
>
> /* We should now have a shared memory map with no fuss. The code above */
> /* should be copied into all the map users. The declarations will go */
> /* into a common header file for abstraction. */
> zapp = &zap ;
>
>
> initscr();
> start_color();
> init_pair(1,COLOR_WHITE,COLOR_BLUE);
> init_pair(2,COLOR_WHITE,COLOR_RED);
> init_pair(3,COLOR_BLUE,COLOR_GREEN);
> init_pair(4,COLOR_RED,COLOR_BLACK);
> init_pair(5,COLOR_BLACK,COLOR_RED);
> bkgdset(COLOR_PAIR(1) | ' ');
> bkgd(COLOR_PAIR(1) | ' ');
> attron(COLOR_PAIR(1));
> keypad(stdscr,TRUE);
>
> w1 = newwin(18,7,4,1);
> wbkgdset(w1 , COLOR_PAIR(1) | ' ');
> wbkgd(w1 , COLOR_PAIR(1) | ' ');
> w2 = newwin(18,70,4,9);
> wbkgdset(w2 , COLOR_PAIR(1) | ' ');
> wbkgd(w2 , COLOR_PAIR(1) | ' ');
>
> while( TRUE )
> {
> form();
> halfdelay(UPDATE);
> key = getch();
> switch(key)
> {
> case 'q': quit();
> break;
> case 's': set_outs();
> break;
> case 'b':
> {
> rtype = 'b';
> ccols = BC;
> mode = 0 ;
> nregs = DREGS;
> }
> break;
> case 'f':
> {
> rtype = 'f';
> ccols = FC;
> mode = 1;
> nregs = FREGS;
> }
> break;
> case 'd':
> {
> rtype = 'd';
> ccols = FC;
> mode = 2;
> nregs = DREGS;
> }
> break;
> case 'h':
> {
> rtype = 'h';
> ccols = FC;
> mode = 3;
> nregs = DREGS;
> }
> break;
> case KEY_DOWN:
> {
> hep += DR * ccols;
> if(hep > nregs - DR*ccols) hep = nregs - DR*ccols;
> }
> break;
> case KEY_UP:
> {
> hep -= DR * ccols;
> if(hep < 0) hep = 0;
> }
> break;
> default :;
> }
> }
> endwin();
>
> }
> form()
> {
> int i,c;
> char str[17];
> char lab[7];
> time(&t);
> tp = localtime(&t);
> sprintf(tdatetime,"%02d/%02d %02d:%02d:%02d",tp->tm_mon +1 ,tp->tm_mday,tp->tm_hour,tp->tm_min,tp->tm_sec);
> clear();
> wclear(w1);
> wclear(w2);
> curs_set(0);
> noecho();
> box(stdscr,ACS_VLINE,ACS_HLINE);
> mvaddstr(1,2,"LPLC I/O Map Display");
> mvaddstr(1,60,tdatetime);
> mvaddch(2,0,ACS_LTEE);
> mvaddch(2,79,ACS_RTEE);
> move(2,1);
> hline(ACS_HLINE,78);
> if(mode == 0) mvaddstr(3,1," REG 7654321076543210 7654321076543210 7654321076543210");
> if(mode == 0) mvaddstr(1,23,", Binary Bus Order MSB--LSB 2 <-0 ");
> if(mode == 1) mvaddstr(1,23,", Float Registers ");
> if(mode == 2) mvaddstr(1,23,", Digital Registers in Decimal ");
> if(mode == 3) mvaddstr(1,23,", Digital Registers in Hexidecimal");
> mvaddch(22,0,ACS_LTEE);
> mvaddch(22,79,ACS_RTEE);
> move(22,1);
> hline(ACS_HLINE,78);
> for(i = 0 ; i <= DR ; i++)
> {
> sprintf(lab,"%c%04d",rtype,hep + i * ccols);
> mvwaddstr(w1,i,1,lab);
> }
> while (mapp->flags != 0); /* wait for IO to finish */
> mapp->flags = 1; /* set in use flag */
> *zapp = *mapp ; /* copy struct (snapshot)*/
> mapp->flags = 0; /* reset in use flag */
>
> for(i = 0 ; i <= DR ; i++)
> for(c = 0 ; c < ccols ; c++)
> {
> if(mode == 0) showbitz(zapp->reg[hep + i * ccols + c],str);
> if(mode == 1) sprintf(str,"%+g",zapp->alg[hep + i * ccols + c]);
> if(mode == 2) sprintf(str,"%d",zapp->reg[hep + i * ccols + c]);
> if(mode == 3) sprintf(str,"%04x",zapp->reg[hep + i * ccols + c]);
> if(mode == 0) mvwaddstr(w2,i,(ccols - c - 1) *(70/ccols) + 3,str);
> else mvwaddstr(w2,i, c *(70/ccols) + 3,str);
> }
> refresh();
> wrefresh(w1);
> wrefresh(w2);
>
> }
> void set_outs()
> {
> char ans[20];
> int type = 0;
> int reg = 0;
> unsigned int val = 0;
> curs_set(1);
> echo();
> mvaddstr(23,2,"Digital or Analog ? : (d/a) :");
> refresh();
> mvgetstr(23,33,ans);
> if(ans[0] == 'a') type = 1;
> refresh();
> mvaddstr(23,2,"Register?: ");
> refresh();
> mvgetstr(23,12,ans);
> reg = atoi(ans);
> if(type) mvaddstr(23,2,"Value? (float): ");
> else mvaddstr(23,2,"Value? (hex): ");
> mvgetstr(23,16,ans);
> sscanf(ans,"%x",&val);
> while(mapp->flags != 0); /* wait til io is done */
> mapp->flags = 1; /* set in use flag */
> *zapp = *mapp; /* copy shared to local */
> if(type) zapp->alg[reg] = atof(ans);
> else zapp->reg[reg] = (unsigned short) val;
> *mapp = *zapp; /* copy local to shared */
> mapp->flags = 0; /* reset in use flag */
>
>
> }
>
> void showbitz(unsigned short s,char *t)
> {
> int i;
> for( i = 0 ; i < 16 ; i++)
> {
> if(s & (0X01 << i)) t[15 - i] = '1' ;
> else t[15 - i] = '0';
> }
> t[16] = '\0';
> }
> void quit(void)
> {
> endwin();
> exit(1);
> }

________________________________________________________
It's a long post, but much simpler than trying to explain it
without context.

Regards
cww