# parallel port driver

M

#### Mario de Sousa

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:

C

#### Curt Wuollet

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 [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

W

#### Willy Smith

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 [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

P

#### Petr Baum

Hi all Puffins, -----Original Message----- From: Curt Wuollet <[email protected]> >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 -- <[email protected]> Petr Baum P.O.Box 2364, Rowville 3178, Australia fax +61-3-97643342 _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

J

#### Jiri Baum

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 <[email protected]> Q: Why did the chicken cross the Moebius Strip? A: To get to the other... um... er... --r.h.f.r _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc