Today is...
Saturday, May 27, 2017
Welcome to the Modbus Community, about
the world's leading automation protocol.
parallel port driver
I have just uploaded a parallel port io driver, and a corresponding demo to the cvs
By Mario de Sousa on 13 November, 2000 - 11:56 am

Hi all,

I have just uploaded to the cvs a parallel port io driver, and a corresponding demo.

Basically you can map 1 bit linuxplc points onto the digital io points of the parallel port. Have a look through the example config files to get an idea of how to configure it.

The parallel port has some TTL outputs that can sink (but not source!) enough current to drive a led. It's fun to whach these leds following the lights of the vitrine.

Please note that the parport driver needs to run with root permissions to be able to access the parallel port. You can either execute the program when logged in as root, or set the program to suif root.

As root, execute:
$chown root parport; chmod u+s parport

Have fun,

Mario.

-------------------------------------------------
Mario J.R. de Sousa
msousa@fe.up.pt
----------------------------------------------

Cool!

For circuits to connect to the parallel port, see the Coffee mini-HOWTO.

(Hmm, I think I once had quite a different circuit running off a parallel port; if I come across it I'll put it somewhere - I think it had fewer parts than the Coffee mini-HOWTO one, because it used a reed relay.)

BTW, the directory should probably have been called ``parport'' rather than ``basic_parport'', but that's not important now... (Also, the duplication of the Chaser code is a poor habit; we should probably rationalize that, but not tonight.)

Jiri
--
Jiri Baum <jiri@baum.com.au>
What we do Every Night! Take Over the World!

By Mario de Sousa on 14 November, 2000 - 12:44 pm

> Cool!
> For circuits to connect to the parallel port, see the Coffee mini-HOWTO.

If you just want to test the thing and see some lights going on and off, you can either use a voltmeter or use a few leds. Check the README file in the /demo/basic_parport directory.

By the way Jiri, would you like to write a keyboard io module? Do you know how to interface to the keyboard, i.e. read the keypressed state of
a key?

I also need some help finishing the dsp module. Chetan seems to have too much work at the moment, and says maybe only next year. If nobody is willing to help out, then it will have to wait until the next release.

Like I said previously, if you are willing to help out, I can send you some .h files for you to write standard C, operating system independent, code. The dsp module is organized in blocks, so we can break this out for several people. If somebody is willing to help out, it doesn't mean you will have to do all the work. Just one or two blocks, like a filter function, etc... You say what you want to code. This is really very simple code for someone that knows the algorithms. I really don't have time (and above all will) to go through my books and refresh my memory on all these algorithms.

Mario.
-------------------------------------------
Mario J. R. de Sousa
msousa@fe.up.pt
-------------------------------------------

Mario de Sousa:

>By the way Jiri, would you like to write a >keyboard io module? Do you know how to interface >to the keyboard, i.e. read the keypressed state >of a key?

No, but I have an idea where I might find out... I'll have a look.

Jiri
--
Jiri Baum <jiri@baum.com.au>
What we do Every Night! Take Over the World!

By Mario de Sousa on 16 November, 2000 - 1:31 pm

> No, but I have an idea where I might find out... I'll have a look.
> Jiri

Hi Jiri,
I have been looking through the ncurses man pages but it seems that we can only get when a character key is pressed, which makes sense for
ncurses. What I would really like is to be able to know when _any_ key is pressed or not, including shift, ctrl, alt, num_lock, ...

I have been glancing through the kernel code, and it seems to have a generic keybaord driver, called by the pc_keyb, m68k, mac_keyb, ..., drivers. If we could have this generic driver make a call to a kernel module written by us, we could have our module keep a map in memory of the state of the keyboard keys. This info could then be read from normal user space processes through a char device. Unfortunately this scheme requires that the kernel be patched to make one single call to our kernel module. We can't just insert our kernel module. It does have the advantage of being portable to any architecture.

Another option would be to replace the keyboard interrupt handler. Unfortunatley this is not portable to any architecture, nor can I figure
out how to call the original interrupt handler to do the normal processing from our own interrupt handler.

I don't like the way I wrote the parport io driver either. It writes directly to the parallel port control registers. This is non portable, and only works for PC compatible platforms. The correct way of doing this seems to be to write a simple passthrough kernel module that uses the generic parport kernel module (the kernel has a module with this name already), which in turn calls the architecture dependent kernel module. If we were to do this, we could automatically support PCI, firewire, etc.. parallel ports. Unfortunately I haven't completely figured out how to use the generic parallel port. Once somebody could explain this, it would be a simple matter of writing a simple character device kernel module.

Sorry for rambling on. Just some thoughts.
Mario.

-----------------------------------------------
Mario J. R. de Sousa
msousa@fe.up.pt
-----------------------------------------------

Mario de Sousa:
> I have been looking through the ncurses man >pages but it seems that we can only get when a >character key is pressed, which makes sense for
> ncurses. What I would really like is to be able >to know when _any_ key is pressed or not, >including shift, ctrl, alt, num_lock, ...

The key observation (so to speak) is the program showkey which, in its default mode, actually goes:
jiri@legend> showkey
kb mode was XLATE

press any key (program terminates after 10s of last keypress)...
keycode 30 press
keycode 30 release
keycode 48 press
keycode 48 release
keycode 46 press
keycode 46 release

At that point, it was a simple matter to download the source, cut out all the other modes and hook it up to the linuxplc. Eventually, though, I'd
like to be able to use human-readable key names instead of keycodes.

Jiri
--
Jiri Baum <jiri@baum.com.au>
You know you've been hacking too long when ...
... reading a book you notice the word "From" at the beginning of a line.

By Oscar Esteban on 16 November, 2000 - 1:37 pm

> the other modes and hook it up to the linuxplc. > Eventually, though, I'd like to be able to use >human-readable key names instead of keycodes.

I agree on getting key names instead of scan codes. But remember you press keys which, depending on your language, will be mapped to different characters.

That's the advantage of having codes (independence of mapping). But I'm not sure if we would like to be map independent. After all, if someone should press 'A' to do something it would always be 'A', instead of the second key from the left in the middle row (in my keyboard). But then, you'd have to go through Linux's keyboard mapping, which sure are not in the kernel.

Concerning of the need of being in the console, it seems obvious to me. You can not tell about the state of the keys if the computer who can tell doesn't send it to you. And I don't think most telnets (or even terminal emulators) will...

> > the other modes and hook it up to the linuxplc. Eventually, though, I'd
> > like to be able to use human-readable key names instead of keycodes.

Oscar Esteban:
> I agree on getting key names instead of scan codes. But remember you
> press keys which, depending on your language, will be mapped to different
> characters.

Yes, therefore you need to look up the mapping (something like the dumpkeys(1) program does) and search in that.

I think for the time being I'll just write a perl script that gets the mapping from dumpkeys, sorts it alphabetically and writes it to a "keycode
chart" file, for the human to read.

> Concerning of the need of being in the console, it seems obvious to me.

Yes, it's obvious, just unfortunate.


Jiri
--
Jiri Baum <jiri@baum.com.au> You know you've been hacking too long when ...
... reading a book you notice the word "From" at the beginning of a line.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Gilles Allard on 20 November, 2000 - 11:25 am

I do not understand why such a utility cannot be developed for Xwindow terminals. I have a program named "keycode" that does that. It is running on
HPUX and it post keycodes on a text window. I'm pretty sure that text can be piped back to the host (X client if you prefer).
Here is a sample output of the program:

KeyPress event state 0x0, keycode 60 (keysym 0x68, h)
KeyRelease event state 0x0, keycode 60 (keysym 0x68, h)
KeyPress event state 0x0, keycode 26 (keysym 0xffe3, Control_L)
KeyRelease event state 0x4, keycode 26 (keysym 0xffe3, Control_L)
KeyPress event state 0x0, keycode 75 (keysym 0x6b, k)
KeyRelease event state 0x0, keycode 75 (keysym 0x6b, k)
KeyPress event state 0x0, keycode 84 (keysym 0x6c, l)
KeyRelease event state 0x0, keycode 84 (keysym 0x6c, l)

The program was supplied with a well-known SCADA program. It may be proprietary or from public-domain, I don't know (so I will not post the
program). If somebody in the group has some Xwindow programming experience, he (she) may look at the two attached files (one in this message and the second to follow). One is the usage text and the second is the output of "strings keycode".
'hope this helps
Gilles

By Gilles Allard on 20 November, 2000 - 11:33 am

The second file is attached.

Gilles Allard:
> I do not understand why such a utility cannot be developed for Xwindow
> terminals.

It can - just none of us's written it yet. What I've written works for the
console.

> I have a program named "keycode" that does that. It is running on HPUX
> and it post keycodes on a text window. I'm pretty sure that text can be
> piped back to the host (X client if you prefer).

Yup - either grab the keycode source and mangle it the way I've mangled
showkey(1), or write it from scratch - it'll be a very simple program.

> The program was supplied with a well-known SCADA program. It may be
> proprietary or from public-domain, I don't know (so I will not post the
> program).

I'd expect there'd be such a program supplied with X as a utility.
But like I said, it'll be a very simple program.

Jiri
--
Jiri Baum <jiri@baum.com.au>
You know you've been hacking too long when ...
... reading a book you notice the word "From" at the beginning of a line.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

I think we can probably assume for demonstration purposes that the target platform is PC. I don't see how writing a simple character device will allow you to properly manipulate bits on the port. A lot of times you have to do read-modify-write operations on the port and it would be tricky with a standard linux character driver and have atomic operations of this sort. (This is somewhat of speculation ... )

Isn't the (LPT1) parallel port pretty much a PC specific thing anyway??? (Pure Speculation)

perhaps you could just have a non hardware specific function call something like:

UNSIGNED CHAR Value = ReadParPort( INT PORT)
WriteParPort(UNSIGNED CHAR Value, INT PORT)

and if someone wants to run it on machine "x" they just insert some simple one or two line code.

I guess that I think that what you have done so far, Mario, is good enough for the scope of LPLC for now.

(Has anyone heard of anyone wanting to run LPLC on any other platform besides Intel??? This seems strange to me.)

~Ken

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Mario de Sousa on 14 November, 2000 - 12:49 pm

Sorry Jiri, I've been reading my last email and it seems I am asking you in particular for help on finishing the dsp module.

Actually I asking anybody who nows the algorithms to help out here.

>I also need some help finishing the dsp module. Chetan seems to have
>too much work at the moment, and says maybe only next year. If nobody is
>willing to help out, then it will have to wait until the next release.
>Like I said previously, if you are willing to help out, I can send you
>some .h files for you to write standard C, operating system independent,
>code. The dsp module is organized in blocks, so we can break this out
>for several people. If somebody is willing to help out, it doesn't mean
>you will have to do all the work. Just one or two blocks, like a filter
>function, etc... You say what you want to code. This is really very
>simple code for someone that knows the algorithms. I really don't have
>time (and above all will) to go through my books and refresh my memory
>on all these algorithms.

Mario.
------------------------------------------------
Mario J. R. de Sousa
msousa@fe.up.pt
--------------------------------------------------

By Thomas B. O'Hanlan on 6 March, 2001 - 9:37 am

I've been out of the country til recently. Please fill me in on what you are thinking about a Parallel Printer Port I/O card. Sealevel Systems, as well as others would be interested in buiding something like this. Thanks Tom -----Original Message----- From: linuxplc-admin@linuxplc.org [mailto:linuxplc-admin@linuxplc.org]On Behalf Of Mario de Sousa Sent: Tuesday, March 06, 2001 4:12 AM To: linuxplc@linuxplc.org Subject: LinuxPLC: Parallel port driver "Campbell, David (Ex AS17)" wrote: > > > Hugh Jack wrote: > *snip* > > But the PPLC will be free - and will run on 'obsolete' PCs - > > the parallel port will provide a nice IO card. > > Could someone take a quick look at the lp driver in the kernel? > If it still has my name on it then I will quickly through together > the stuff required to make this a reality (complete with circuit > board design if required). > It already is a reality. I did this a couple of months ago. Been playing with it since then ;-) Check out the parport module under the /io/parport directory of the cvs. _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 7 March, 2001 - 10:16 am

Hi Tom. What might really be handy for using the parallel port and 8255 type cards are level translators from TTL to 24 volt logic. I have been designing these into my testers, but small inexpensive "packaged" translators would answer a perennial problem with using PC's for control. The various relay cards, etc. do the job but are large and expensive. An 8311 for outputs and optoisolators for inputs would work fairly well and the cost could be reasonable with multiple devices per package. The 8311 provides 16 OC high current peripheral drivers in one package. I'm sure there are octal optoisolators, etc. Regards cww _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Campbell, David (Ex AS17) on 7 March, 2001 - 10:25 am

> Curt Wuollet wrote: > The 8311 provides 16 OC high current peripheral drivers in > one package. I'm sure there are octal optoisolators, etc. http://www.findchips.com/ look for optocoupler and duck!! (a lot of matches, need something to filter them...) 90+% of optocouplers are 6/8 pin packages (eg: 1 optocoupler per package). There are a couple of quad channel devices. For example: PS2702-4NEC which is listed at USD$2.55 each (Just a touch over $.74 per device). David Campbell _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 7 March, 2001 - 2:53 pm

Hi Dave and all. I'll let someone else deal with the PC parallel port, the variations have always scared me off. Since I have done most of this to build testers with DAQ cards and 8255 type digital ports, I looked around a little and they even have some OI's with back to back led diodes that would let us closely match what is in use now. (strap to + or - as common) Since I need this functionality for paying projects, I have considered doing the design and releasing the schematics and artwork to the LPLC project. We could even do kits, but that comes very close to commercialism. Sealevel could also add this to their boards for a nominal cost increment and we would have real industrial IO available assuming they could justify the certifications, blah, blah, that matter to the automation industry. To roll our own, the remaining problem to be solved is that the 8255 boards can be programmed as inputs or outputs in groups of 4 or 8. For maximum flexibility a translator board would need 20 ins and 23 outs (one output is needed to disable the outputs until initialized for safety) This would bump the cost a little. If we compromise and settle for 16 in and 16 outs this would mean that you would always have at least 8 inputs or 7 outputs and the balance the other. Switching adds cost, I was thinking of using dip switches or some such to connect a 8255 pin to the correct buffer depending on whether it's an input or output. I looked briefly at configuring as a bus, with OC outputs we could do this but, I don't think the automation crowd is ready for pins that can switch from being inputs to being outputs in software :^). There don't seem to be any 24V tristate buffers. All thoughts on how to do this most cleverly would be appreciated. We have the direction state of the IO groups as that is programmed on initialization. Could we automap? I'll start lobbying for the release of the design. If that's not possible, I may do it on my time but that is pretty limited just lately. I would like one "real" option to answer the question of "what can I do with it". Perhaps someone not directly involved in the project would make kits or at least boards available. For that matter, if my day job company were to offer kits, would that be a conflict of interest? Regards cww _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Willy Smith on 7 March, 2001 - 4:42 pm

Curt and others, Finally! Something I may be able to help with. Point me to a pinout of what comes off those 8255 boards (ribbon? d-sub?). I'll design a schematic, board, etc., and put it in the public domain. I'll use Eagle, so it can be edited under Linux or Winkers, and used free by students. I have made an I/O board with software switchable inputs/outputs. The chip is an MC33298. You don't need any other parts, but it runs on SPI so we probably can't use it for this app. It can sink 24V at .5 amp per channel (8), and if it's an input, the logic threshold is >4 volts = on. Give me pinouts, I'll come up with a concept and post it. Regards, Willy Smith Costa Rica _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Hugh Jack on 9 March, 2001 - 3:16 pm

Hi, I would suggest keeping the steps small and simple. First, why not a simple board with optoisolators for 24Vdc inputs, and triacs on outputs for 120Vac outputs that plugs directly into the parallel port - no cables. Just do it with 4 in and 4 out and have connections on a terminal strip. Make the board a small footprint, no wider than the DB-25 connector, and longer than necessary. This board can be used directly with Mario's PPT driver. Things that can be left for later might be; - separate breakout boards - fuses, reverse voltage protection, etc. - different output types - transistors, relays, etc. - shift regiesters for banked IO outputs - soucing/sinking/autoswitching inputs - analog IO - etc. If the board layout is done with Eagle, I will fabricate some boards here (on a PCB mill) and give them to students in a course that starts in two months (May). I would also be willing to run some extra boards for others in the Puffin group. Hugh _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Willy Smith on 9 March, 2001 - 3:23 pm

Hi, What about forgetting a parallel port interface and using something like the attached? I think these modules cost about $20 in quantities, we could make a board that accepts one of these and then put eight "generic" I/Os per board. Then all you need is an Ethernet port to do as many I/Os as you wish. Regards, Willy _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Campbell, David (Ex AS17) on 9 March, 2001 - 3:24 pm

Hugh Jack wrote > I would suggest keeping the steps small and simple. > First, why not a simple board with optoisolators for > 24Vdc inputs, and triacs on outputs for 120Vac outputs > that plugs directly into the parallel port - no cables. Just a *tiny* little point here, just make sure that the PCB tracks can handle 220Vac[*]. Then the incremental change for Europe would be to replace the triac with one rated for the higher voltage (most triacs have the same package style). David Campbell [*] Aus power standard is 240V while European standard 220V. The specs for Aus have a much tighter voltage margin which allow it to be compliant with the European standard! (eg: sits in the top end of the band). _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Petr Baum on 8 March, 2001 - 10:00 am

Hi all Puffins, -----Original Message----- From: Curt Wuollet <cwuollet@cpinternet.com> >I'll let someone else deal with the PC parallel port, the variations have always >scared me off. >Since I have done most of this to build testers with DAQ cards and 8255 type >digital ports, Please, take into account that Linux users in teens bracket are likely to accept PC parallel port most enthusiastically -(and they are likely to become Puffin's best advocates). It would be nice if parts would be easy to obtain everywhere and if there would be very low requirements for assembly technology (soldering etc). E.g. if one of standard breadboard systems can be used, it would double number of finished systems ... most likely... They may also lack safety-oriented habits which are second nature to most professionals and attached documentation should provide at least basic recommendations and warnings for use of PC parallel port for control of mains-driven appliances (somebody somewhere will use Puffin to switch on a kettle by 8 AM for sure!). Petr -- <petr@baum.com.au> Petr Baum P.O.Box 2364, Rowville 3178, Australia fax +61-3-97643342 _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 8 March, 2001 - 1:13 pm

Hi Pitr and all There are kits for the parallel port already. And yes, there are solutions like the OPTO racks that work with 8255 type cards already and let you plug in modules. Said modules are awful spendy. Perhaps fine for commercial projects but discouraging for us poor folks. The reason I'm considering doing this is I think it can be done closer to 1 USD per port than 10 or more. By using dense packages we can get a lot more ports per buck. And yes Willy, I'll post a pinlist for the DIO48 I've got They are regular .1" double header connectors that work with IDC's for ribbon cable If you want to do this in eagle and it produces the Gerber files most proto fabs want, go for it. I was gonna use this as a vehicle to try out PCB, a free PCB layout tool that I'd tried before but which didn't do Gerber lightwriter files until recently. I'd been doing boards with a free DOS package under dosemu. (Yes, I know, but time was short) There was a hook with Eagle somewhere, I think you had to get a fax to Germany or something and I never suceeded. I also know of a fab that's got unfilled capacity and may offer good pricing. It's AP circuits of Alberta Canada. But, again, are automation types ready for pins that can be either? I've never seen that on automation gear. And opto isolators are almost a requirement for stuff that goes from machine to machine. Why don't we pool our research? Regards cww _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Petr Baum on 8 March, 2001 - 3:36 pm

>There are kits for the parallel port already. And yes, there are >solutions like the OPTO racks that work with 8255 type cards >already and let you plug in modules. Said modules are awful >spendy. Perhaps fine for commercial projects but discouraging >for us poor folks. The reason I'm considering doing this is I >think it can be done closer to 1 USD per port than 10 or more. >By using dense packages we can get a lot more ports per buck. IMHO commercial projects are unlikely to go for combination of [ desktop PC + Puffin + LPT ], so we can safely ignore their needs as far as this little exercise is concerned. Who may be interested / tempted - - Linux fans who want to try everything Linuxish - students/kids who want to play with control (X-mas tree blinking Morse code etc) - hobbyists (model trains, automatic feeding of pet lizards, pigeon return time logging etc.) - semi-professionals: farmers etc., who can never justify cost of "real" automation but who may need simple control sequences for their particular trade. All these people need system, which is cheap, does not require much learning, is reasonably reliable and easy to get. (The last group - semi-professionals - may go for more costly solution, if they found cheap solution useful but failing on reliability. So it is nice to have hardware upgrade - module racks - path for them.) >And opto isolators >are almost a requirement for stuff that goes from machine >to machine. Why don't we pool our research? I am sure that all approaches so far suggested have some merits and will be useful, if they are developed and available. We are also almost at stage where "Puffin Users Group" web site, collecting successful hardware designs and projects is needed. Cheers Petr _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 9 March, 2001 - 12:57 pm

I quite agree on the printer port attachment, although the EMC project does use this. For the IO cards, I want to produce "real" industrial IO that companies can be comfortable with for "real" applications. This would mean that as soon as code is ready people can do industrial control with it. They can do this with Ethernet and modbus/tcp IO from an existing automation company now, I believe (correct me if I'm wrong :^) ) But to get pilot projects going, I think we need a clear, easy, inexpensive way to do "real" work or directly replace what IA folks are using now. It would be even better if this could be a single package, ie, an 8255 type card with industrial type I/O built in. And that is not out of the question as there isn't much on one of these cards, but for right now, an inexpensive add-on that "industrializes" the inexpensive TTL IO cards seems like a good approach to have something solid soon. I hate the answer I have to give when people ask "What can I do with it" I think it's also important that they don't have to change what they are doing out past the terminal strip. Regards cww _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Jiri Baum on 8 March, 2001 - 10:06 am

Curt Wuollet: > To roll our own, the remaining problem to be solved is that the 8255 > boards can be programmed as inputs or outputs in groups of 4 or 8. For > maximum flexibility a translator board would need 20 ins and 23 outs (one > output is needed to disable the outputs until initialized for safety) > This would bump the cost a little. The other way is to make the isolators pluggable modules. This too bumps up the cost, but OTOH gives the option of different levels of isolation and different kinds of output (solid-state versus relay). Then again, such systems already exist (or at least did ten years ago), so we don't need to do anything to have them. Just point people at them. If it's just a board design without actual hardware, it's probably easiest to just design all the combinations, there ain't that many of them. (Or design a board where relevant bits can be populated one way or the other.) > All thoughts on how to do this most cleverly would be appreciated. We > have the direction state of the IO groups as that is programmed on > initialization. Could we automap? Theoretically yes, but in practice it would defeat the point of using 8255. > Perhaps someone not directly involved in the project would make kits or > at least boards available. As I wrote above, at least one such system is available - in-computer board (8255-based), connected via ribbon cable to a break-out board, which has pluggable modules (input, output, solid-state, relay, 240V etc). > For that matter, if my day job company were to offer kits, would that be > a conflict of interest? Probably not all that much. Jiri -- Jiri Baum <jiri@baum.com.au> Q: Why did the chicken cross the Moebius Strip? A: To get to the other... um... er... --r.h.f.r _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Jiri Baum on 8 March, 2001 - 10:22 am

Jiri Baum: > As I wrote above, at least one such system is available - in-computer board > (8255-based), connected via ribbon cable to a break-out board, which has > pluggable modules (input, output, solid-state, relay, 240V etc). Petr Baum: # supplied by Advantech: # PCL-722 emulates 8255 (a few of them?) # PCLD-7216 I/O module carrier Jiri -- Jiri Baum <jiri@baum.com.au> Q: Why did the chicken cross the Moebius Strip? A: To get to the other... um... er... --r.h.f.r _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Johan Bengtsson on 9 March, 2001 - 1:11 pm

<huge clip> >kits or at least boards available. For that matter, if my day job company were >to offer kits, >would that be a conflict of interest? Perhaps, but I don't think so. This would not be the only I/O solution anyway. /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: johan.bengtsson@pol.se Internet: http://www.pol.se/ ---------------------------------------- _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

I think there's only a conflict of interest if you steered the design work toward your own proprietary designs or existing products that are unique. This is meant to be OPEN, after all. If a certain I/O paradigm fits best, let any board manufacturer make kits if they can make a dime on it, as long as there is nothing to prevent other manufacturers from making compatible kits! It almost makes me wonder if there is a schematic-level equivalent to a GPL or LGPL (as Curt touched on in his posting). We could create schematic "building blocks" to support the software design that are free for any equipment manufacturer to encorporate into their board or system-level designs. Wouldn't that be a hoot if board manufacturers who add circuitry to our building blocks also had to release their schematics to the cause... Rufus In a message dated 3/7/01 11:00:07 AM Eastern Standard Time, cwuollet@cpinternet.com writes: << Subj: Re: LinuxPLC: Parallel port driver Date: 3/7/01 11:00:07 AM Eastern Standard Time I'll let someone else deal with the PC parallel port, the variations have always scared me off. <custom design snipped> Since I need this functionality for paying projects, I have considered doing the design and releasing the schematics and artwork to the LPLC project. We could even do kits, but that comes very close to commercialism. <technical considerations snipped> Perhaps someone not directly involved in the project would make kits or at least boards available. For that matter, if my day job company were to offer kits, would that be a conflict of interest? _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc