Industrial I/O level translator for DIO48

C

Thread Starter

Curt Wuollet

Hi All Back to the hardware world. I have a project with my day job employer to do a terminal board to translate from the DIO 48 ttl I/O to industrial levels. This is part of a critical automation project so it should happen and happen soon. They are debating whether to offer this as a product or release it to LPLC. Either way we eliminate a roadblock. I had to include the option of selling it to get approval for the project. Right now, I have to focus on making it. To keep it as simple as possible, I looked at a few typical projects for IO count and came up with the fact that most of what we do uses about twice as many inputs as outputs. I am looking at 32 in, 15 out for the DIO 48 or 16 in 7 out when used with a DIO24 or single 8255 card.. One output in any case is used as an output enable as the 8255 pins are indeterminate until programmed and startup safety demands outputs off until valid. It should be usable with two DIO 24 cards also, you would want to control initialization order. This conveniently uses a single DP8311 and 8 quad optoisolators. I am still pondering adding photo darlingtons to the outputs for completely isolated I/O. We don't need this for our application and it raises the connector count and cost. No point in having isolated outputs if the commons are all bussed together, perhaps groups of 4 or 8 is a good compromise. I haven't hit on a way to make it din rail mountable that wouldn't cost too much in low volume, but I'll be thinking about it. Suggestions, as always are welcomed. just thought I'd pass along the good news. Regards cww _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
S

Scott Whitlock

--- Curt Wuollet <[email protected]> wrote: > many inputs as outputs. I am looking at 32 in, 15 > out for the DIO 48 or 16 > in 7 out when used with a DIO24 or single 8255 > card.. One output in any case > is used as an output enable as the 8255 pins are > indeterminate until > programmed and startup safety demands outputs off > until valid. Good thinking... I would, however, like to suggest that you make this some kind of option -- since someone might want all 8 outputs, for instance, and be willing to hardwire the output enable some other way.(?) I don't know if this is possible. Cheers, Scott _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
C

Curt Wuollet

No, this I know from experience. The hardware starts immediately on powerup. The 8255 on init is all inputs. This turns on all outputs until the PC has booted and loaded an OS and the driver is loaded and the controlling program has set the direction and state of the pins. If you have motors and valves and other physical devices controlled by the outputs this is almost always bad. Using one output as an enable isn't a perfect solution either, but the outputs stay off until you have control. You might be able to get this behavior by installing pulldowns on the pins instead of pullups but strange things could happen as you diddle bits to set the direction and mode of the ports. I had to do a hurried rev .01 of a board to include this once. I will think this through again just to see if there's another way. I don't think so because we don't have any way to write to the board until the software is loaded. It would be nice if there were a chip with a tiny bit of prom for the direction and mode registers but, everyone seems to use the 8255 and live with it's idiosyncrasies. It's a problem inherent with a programmable port, any default you choose will be wrong part (most) of the time. An addressable flop on the board would be a good fix, but I'm working with an "off the shelf" DIO48. Regards cww _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
M
Maybe the problem is the definition of on and off for your outputs?? We use 8255 based boards quite often in PC (QN/X) based systems and have no problems. The outputs stay OFF (because they are inputs) until you setup the direction bits and command the output to go on. However ... we are connecting them to OPTO22 boards. These modules are looking for a **current-SINK** to ground before they turn on. If you have defined output-ON as a logic-high, you will get bitten. Output-ON must be a current sink. Mark _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
C

Curt Wuollet

Hi Mark Yes, that's part of the problem. Since the 8255 has little drive capability I am using a DP8311 as a buffer. It has TTL inputs and high is on. The 8255 is also set up to drive ttl and can sink more current than it can source, making pullups to set inputs to a definite state more attractive than pulldowns. I think the pulldown resistor value to reliably keep the buffer off might be too low for the 8255 outputs to override. Unfortunately the number of monolithic IC's that work with 24 volt levels and high currents is quite limited. I am looking at other peripheral drivers but none I've seen offer the attributes of the 8311. That doesn't mean they don't exist but the research is slow and tedious. Another way would be to get the H series card with higher drive capability. Of course it also costs more. That's the challange, I want to keep the cost down to a buck a port with industrial specs. (In addition to the card) Otherwise I'd just buy the OPTO racks and be done. This problem is easy to solve at $10.00 a port. At < $4.00 we have to work a little harder but it can be done. Regards cww _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
J

Johan Bengtsson

Putting in an additional 74240 would solve that problem and not cost that much. (see my other post on this subject) /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/ ---------------------------------------- _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
J

Johan Bengtsson

You reserve one output because outputs are indeterminate until initialized - why? This output are not initialized either right? that means you have to make a circuit that can handle that and only react when it is initialized AND set to a certiain value. I assume this certain value will be 0 and you are going to use a pull up resistor (if needed) to ensure it is read as high until it is properly initialized as being an output, and until you set it low. If this way of solving the problem seems good enough, then why not simply reverse the logic in the output stage, ie use low as the active signal state, use pull up resistors to ensure all the outputs are high until properly initialized and turned low by the program. The output stage can then simply reverse this again to actually produce a high output when the output are set in the program. As long as this happens transparently to the user and is as safe as it could. Regardless of what, it won't be any safer anyway, since that first output will be uninitialized too. Why sacrifice one bit when it doesn't do anything better. /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/ ---------------------------------------- _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
T

Thomas B. O'Hanlan

A well designed 8255 based I/O card will have pullups on the individual bits, 74ls245 bidirectional buffers, and control logic (external to the 8255) that decodes the mode control word and sets the direction of the '245 buffers. this logic is reset at power on, and assumes input mode until changed by initialization code. the outputs would then be high at power-up, allowing very little leakage current to flow, and any active-low, current sinking device (ie: Solid State Relay) would be off. There are many 8255 boards that just bring out the unbuffered 8255 pins, and these cause problems, as Curt has mentioned. _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
C

Curt Wuollet

Hi Johan [email protected] wrote: > You reserve one output because outputs are indeterminate > until initialized - why? > > This output are not initialized either right? that means > you have to make a circuit that can handle that and only > react when it is initialized AND set to a certiain value. > I assume this certain value will be 0 and you are going > to use a pull up resistor (if needed) to ensure it is read > as high until it is properly initialized as being an > output, and until you set it low. > > If this way of solving he problem seems good enough, then > why not simply reverse the logic in the output stage, ie > use low as the active signal state, use pull up resistors > to ensure all the outputs are high until properly > initialized and turned low by the program. Actually the 8311 has OC NPN outputs, but your logic still holds. If I had a non-inverting version of the 8311 I would do this. I am still checking if I can use pulldowns and they can keep a TTL input off reliably. That would give us the bit back. And it is a little safer as you can initialize that port last. The main problem is over by the time you can initialize the ports anyway. With three writes you can get things set up. It's that interval where we have to deal with the 8255 default behavior. It comes up with all pins inputs. Since it's MOS they float. To set them to a definite state the board lets you install pullups or pulldowns. So far, so good. But the 8311 inputs, being ttl type, go high even without the pullups. That's the problem because it turns on the outputs. I can install pulldowns instead of pullups, but a pulldown value that keeps the 8311 inputs low may draw more current than the 8255 can safely source when I want an input high. Now, as a mitigating factor, the 8311 inputs will source some current and the 8255 only has to make up the rest. It's those values that I need to check out over temperature, Vcc and parameter distribution to ensure reliability before I can commit to using pulldowns. I'm still looking at alternatives. Regards cww _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
J

Johan Bengtsson

Well, may be so, but I think Curt was out after something fixed concerning what is inputs and outputs to reduce cost but still have buffers. /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/ ---------------------------------------- _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
C
Hi Tom I agree that a little extra silicon goes a long ways to solve this issue. Unfortunately the unbuffered cards are the majority and they are cheap and reasonably standardized. That's why I am making the effort to overcome the shortcomings. I can design once and work with several boards. I have a way that's proven safe. The public doesn't want to give up a pin. The customer is always right, I am searching for a better way. Unfortunately, I haven't found anything better than the 8311. Actually, three of any cheap old hex inverters should fix the problem. This is what I'm leaning towards at the moment, but I hate to lose the real estate. Regards cww _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
Hello Everyone, I have noticed that there are several inquiries and developments about hardware in the threads lately. I have done extensive work in designing hardware for industrial controls and I think that this is one area that I would be able to contribute greatly. I am considering releasing some work that I have done on an open hardware specification that will allow for an open interface to IO boards. This hardware spec is independant of platform and protocol. It will be fast, simple, and flexible. I have already done most of the work and have more than half of a spec designed, but directions changed at my company and I got assigned to a different task. The idea is to have a standard interconnect system and form factor that will allow for several IO boards to be plugged into a backplane. The interface requires very minimal interface to the bus (i.e. it can be fast, simple, and cheap). The interface between the controller and this system will be in the form of a bus coupler, which could be parallel, serial, field bus, ethernet, whatever, it is not important because the IO boards are abstracted from this complexity. If you all think this is a good idea I will approach my employer about releasing the spec and any current and future hardware designs on the web. They probably wont have a problem with it since it has absolutely nothing to do with our product, and we could use any help from the outside. I have been working on this a long time and I know that the project will benefit from the open source community mentality. Please let me know what you think. Kenneth Emmons Jr QA Technology Company, Inc. _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
C
I'm already on to a better solution. I had shied away from darlington arrays as a buffer as their reliability was dismal back when I was doing component failure analysis. After a long talk with a couple of silicon engineers, they have convinced me that the processes used now give a much improved SOA and hence higher reliability. I also found some in octal packages instead of the odd seven neccessitated by 16 pin dips. Since they have sinking inputs that seems to solve the general problem. I still have the problem of linux possibly probing the addresses on startup. I believe there is a way to configure around this. The really great quad optoisolators from Toshiba are almost impossible to get. They must really be that good. I may sub some lesser ones with the same pinout in the meantime. Since folks here on the list seem to agree on Eagle, I installed it and will actually, get this, _buy the software_ ! I threw that in for those that say I just want everything for nothing. I have no problem with $50.00 for a board layout package that runs on Linux. I would not however, pay to run it on Windows, of course, that's extremely unlikely anyway. I do feel a little bad about not using the OSS PCB package but, it would be useful to have a common format for hardware projects. Regards cww _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
C
Hi All An Update on the translator board. I didn't get Eagle as the board will be too large with screw terminals to fit in the lite version and the standard and pro versions are too spendy unless I do more board work. I decided that my company will do the board design and artwork in pcb which is free. I should have artwork next week sometime and it will belong to the project. My day job can then use it or not when they decide something but development for LPLC will go on. I did ask CadSoftusa if they make exceptions for OSS projects but I wouldn't hold my breath. Regards cww _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
Hello Curt, I have looked at the Beckoff/Wago solution, in fact I have one taken apart in my office right now, and it uses soem kind of serial bus for its modules that the bus coupler communicates witht he IO modules with. This kind of bus is nice for packaging, but the speeds aren't there. (and lets face it, the open source community can't invest in injection molds) We experimented with a profibus bus coupler and found that even though profibus is so fast, the internal bus of the IO modules was our bottleneck. More to the point, the Wago modules use a custom ASIC internally to deal with the bus transfers which is inherently expensive for just about any volume for the individual company/user. I am going to makes a couple definitions for sake of conversation: Bus Coupler: Board that acts as the IO racks master. It communicates through some kind of fieldbus, like profibus, devicenet, ehternet, parallel port, etc. Internal Bus: The bus that the Pluggable IO cards use to get IO information from the Bus coupler. But my proposed architecture *is* a backplane system with *some* kind of bus coupler, hopefully many different flavors. Parallel interface is the cheapest and simplest to understand and implement. I am envisioning using a backplane style system that utilizes industry standard packaging hardware and very common connectors, such as a relatively small pin count (less than 40) 0.1" dual row right angle headers, which are cheap, reliable, and you can find anywhere. I want something that will allow people to design their own interfaces without having to invest in custom ASIC design or having to purchase a $25 PLD or FPGA device to handle interfacing to the bus coupler. What do you think, Curt?? Is this worthwhile in your mind? I was kind of hoping that an open architecture like this would allow us to design common bus couplers (like the ethernet we have been discussing) without having to adapt it to everyones needs ... i.e. you simply arrange the boards in your system to accommodate what you need to get the job done. I was hoping that I would get more of a response from other people, perhaps I am not properly communicating my idea, or the power of having such a system. The problem is that I have to talk to my employer before releasing my current specs to the public, but I don't want to ask if there is no interest. I am very good at writing specs and very good at designing hardware, and I have had many years experience in automation, so this is my niche with regards to this project and I am chomping at the bit to contribute. ~Ken _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
W
Hi List, The ASIC is made by Beckhoff. I talked to them a couple of years ago, it's proprietary and they won't release it. They were considering selling the chips, but I don't know if they ever did make them available on the open market. Anyway, there are some other generic chips out there that you could do practically the same thing with (such as SPI, I2C, etc). In my experience with using such systems in automation, SPI is a better choice because it has less overhead per data byte transferred, and can run at much higher speeds. Willy At 12:06 PM 3/26/01 -0500, Ken Emmons Jr. wrote: >Hello Curt, ><snip> >More to the point, the Wago modules use a custom ASIC internally to deal with the bus transfers which is inherently expensive for just about any volume for the individual company/user. _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
Hi Willy, Yes. I know what you mean about different serial protocols and I investigated it, but when point counts get high there is no way that you can meet time critical deadlines on the order of single milliseconds. The spec that I am suggesting would be especially useful for high point counts and high performance applications, but would of course handle low end stuff because it is inexpensive. A system that I am thinking of would only require somebody who wants to develop an IO module to put down a 74XX series glue logic chip and a 74XX decoder chip for 8 bits of IO ... jsut add another glue chip for more banks of 8. And if you prefer CPLDs or FPGAs, thats cool too, but you don't need to use them. The only reason to go serial at the internal bus level is to get an attractive packaging scheme similar to the Wago system, but at that point you also need to make injection molds, design custom contacts ... it starts getting ridiculous. Is there another reason to consider serial transfer (not talking field bus here, just internal IO bus to the bus coupler)?? Thanks for the input. :eek:) ~Ken _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
C
Hi Ken Just a short note, I gotta get some stuff done. Yes, that's very close to what I have been trying to get funding to build. I see a SOC to run Linux with ethernet, serial, etc. AND a fast low pin count bus into which we could plug small cheap function modules. I started investigating I2C for this and using SIMM sockets for the modules. Pin headers would work too. With this basic unit we could do serial protos and ethernet protos. For the others, we could stack cards on a PC104 bus or something like that. We probably can't do devicenet, profibus, etc. cards ourselves as you have to belong to the millionaires club to get "certified" . Obviously I think it's worthwhile. This could also be a home for LPLC and run as a standalone or in a distributed setup. There was a lot of interest in a din rail mount unit. I2C is non-optimal so I'm looking for another way. I2C has a lot of cool features like A/D's and D/A's but the chips for high digital point counts aren't around. Regards cww _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
Top