# Where we are (long)

C

#### Curt Wuollet

Hi Jiri

Again, I am simply communicating what people tell me. If nothing else, I will attempt to translate and demonstrate using said API. The documentation is good, where I had a problem was getting my arms around what's going on. I think I can find time to do that. You'll know when you get a bunch of stupid questions:^)

Keep up the good work

Regards
cww
> Actually, the basic comprehensible API'' has been available and basically stable since May-July (May is the date of my announcement, July is the date at the bottom of doc/smm/tutorial.txt).
>
> There have been additions since then, some of which actually impacted on existing code, but they've been rare and in general we tried to go through the whole CVS tree and put them in ourselves. (This may not have been done with the synch library yet, but things will run without it.)
>
> At times I/we have made various efforts to alert people to its existence, from the original announcement, files in doc/smm, to the recent post on "the plc_set() function", with varying levels of success

yep

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

A

#### Ahnen, Richard

I'm a new lurker to LinuxPLC as well as novice in the world of Linux. I'm optimistic that LinuxPLC can make as big a dent in "control" as Linux has made in the server market. I applaud this open effort and its potential. I have been at the front of some early WinCE HMI/control efforts and have been bloodied as many as you have. I would love to see(& be a part of) any
effort that takes a chunk out of Bill's wallet.

But I fall into the category as Peter Whalley mentioned " Most of use are system engineers not software developers. Those that do software
development do it in LL or FBD etc and not C.". You can add BASIC & PASCAL to my programming talents but my C programming days are over(for the near future) yet I think I have much to offer in scope, direction, & marketing beyond the generation of the code itself.

No this wasn't a typo...Marketing. Whether this softplc is "free" & open or not, At the end of the day you still have to convince somebody to use it. Unfortunately in the automation business this falls into having some acceptance in the 1st and 2nd tier automotive suppliers who are a tough(& sometimes stubborn) group.

Why are integrators, OEMs, and customers going to use/want LinuxPLC?

* Unchallenged Cost competitiveness
* Ease of use and familiarity(IEC1131 helps here)
* Plenty of available off the shelf platforms and accessories
* Drivers for all the popular fieldbusses
* Scalability (embedded to workstation)
* Compatibility with existing & future I/O offerings
* Nice hooks to MIS systems: Oracle, SQL, etc.
* As good or better features than the competition (SteepleChase,
Think & Do, Frameworx, ISaGRAF, etc.)
* Proven speed,reliablility, and robustness
* It's on the customer's spec list

Some worthwhile features that I don't see in the banter back & forth are:

* Online Editing...which I think is a must for a large compliment of
potential LinuxPLC users.
* Debug tools like: strip charting, histograms, & the like...(watch
windows are lame!)
* A "ToolBox" to make use of modules of code (self instantiating
like in FrameWorx)

I also noticed some discord in discussions of I/O networks. There really are only a few choices if you want mass appeal(acceptance) and a short time
to market...

If you look at all the well established I/O vendors in the Automation arena, the all have a few common offerings...CAN based(whether its DeviceNet, CANopen, or SDS) and/or Profibus. CAN based I/O will undoubtedly be less expensive to produce due to the wide selection of chipsets & historical applications.

Ethernet is up & coming, but I( and many others) believe that Ethernet will be best applied in the Peer-to-Peer and Process Industry I/O level
communications. It doesn't really make sense to use it for localized "station" control which is tending to Industrially hardened (>IP56). This
holds doubly true for control platforms that tend to come equipped with one Ethernet port...you don't want to try to update a program while trying to control I/O. Leave the hubs and switches for Peer-to-Peer coms and communication to intelligent devices like Vision & Motion platforms.

USB and Firewire should not be forgotten as alternatives (or supplements) to Ethernet especially for current & future motion & vision platforms.

To keep target platforms as low cost as possible, LinuxPLC should be ported initially to readily available "canned" Linux ready SBC's.

I have done lots of research for available hardware:

Applied Data systems has a ready to rock Linux platform, with 10/100 Ethernet, CAN, multiple serial ports, analog digital I/O, Flat Panel
controllers, and battery backed RAM. Some even have integrated power supplies for less than $600 OEM!!!!! http://www.applieddata.net/masterspecs.html ZF micro's NetDisplay is Linux ready and comes with Integrated 12.1 or 15.1 TFT touchscreens for less than$1600 list!
http://www.zflinux.com/netdisplay.html

I believe these are the type of platforms that will allow the LinuxPLC to compete head to head with the corporate offerings of the new WinCE3.0
machines. I would be happy to work with anyone that has connections to package the above (or other) processors.

Thanks for giving me this venue to express myself.

Richard Ahnen
R&D Engineer
Gilman
305 W. Delavan Drive
Janesville, WI 53547-1367
phone: (608) 741-4787
fax: (608) 757-7028
email: [email protected]

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

J

#### Jiri Baum

Ahnen, Richard:
> Why are integrators, OEMs, and customers going to use/want LinuxPLC?

* not a single-supplier product

(Or something similar, eg "if it doesn't have source it's not software".)

> Some worthwhile features that I don't see in the banter back & forth are:

> * Online Editing...which I think is a must for a large compliment
> of potential LinuxPLC users.

This has been discussed. Doing on-line changes well is difficult and is unlikely to make it into version 1. Unless somebody has a brainwave and a
month of coding time to spare

> * Debug tools like: strip charting, histograms, & the like...(watch
> windows are lame!)

Actually, I'd call these HMI rather than debug tools (why make the distinction?) and they will be there... as soon as somebody writes them.

> * A "ToolBox" to make use of modules of code (self instantiating
> like in FrameWorx)

I'm not sure what you refer to exactly, but I assume this would be the feature of the programming tools, which are also at the "as soon as somebody writes them" stage.

Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World!

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc