Reply by rickman April 4, 20172017-04-04
On 4/3/2017 10:59 PM, David Lesher wrote:
> rickman <gnuarm@gmail.com> writes: > > >> Why don't you just get a controller that includes Ethernet to start with? > > The controllers we have seen are 6-12X the price of this approach. > >> I haven't seen where you explain why you are only looking at PLC >> controllers rather than generic CPU boards. > >>From how you have explained your needs so far, there is >> nothing in a PLC that you will use that is different from a CPU >> board. From what I can see, you would do well with a Raspberry >> Pi or a Beagle Bone Black type board. Ethernet included and >> tons of support (metric tons even). > > This controller has value-added in integration, packaging, input > protection and such. They have done things we will not have to > ourselves. > > We looked at Beagles but want to avoid the issues with > supporting a Linux device. (& that would be far more overkill.) > >> So what do you get with a PLC that you don't get with one of the *many* >> CPU boards? > > I've not found an Arduino case/touchscreen/AD/input protection/ etc > that we can plug in and fly with. Suggestions?
The first problem is I don't know what your requirements are. The second problem is I usually get paid for this sort of thing. When you say things like you "want to avoid the issues with supporting a Linux device", that makes me think there are many more issues to deal with that you haven't explained. The term "input protection" is entirely vague. There can potentially be a huge list of such requirements that you need to detail before anyone can try to find hardware for you. -- Rick C
Reply by David Lesher April 3, 20172017-04-03
rickman <gnuarm@gmail.com> writes:


>Why don't you just get a controller that includes Ethernet to start with?
The controllers we have seen are 6-12X the price of this approach.
>I haven't seen where you explain why you are only looking at PLC >controllers rather than generic CPU boards.
>From how you have explained your needs so far, there is >nothing in a PLC that you will use that is different from a CPU >board. From what I can see, you would do well with a Raspberry >Pi or a Beagle Bone Black type board. Ethernet included and >tons of support (metric tons even).
This controller has value-added in integration, packaging, input protection and such. They have done things we will not have to ourselves. We looked at Beagles but want to avoid the issues with supporting a Linux device. (& that would be far more overkill.)
>So what do you get with a PLC that you don't get with one of the *many* >CPU boards?
I've not found an Arduino case/touchscreen/AD/input protection/ etc that we can plug in and fly with. Suggestions? -- A host is a host from coast to coast.................wb8foz@nrk.com & no one will talk to a host that's close.......................... Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433
Reply by rickman April 3, 20172017-04-03
On 4/3/2017 1:49 PM, David Lesher wrote:
> I've been looking at other PLC controller offerings, and thus > far the <http://www.digital-loggers.com/plchw.html> comes out > ahead; it does a lot of what we need in a package with a good > price. Alternatives I've found either cost far more or require > lots of integration. (I've just been pointed at the Siemens Logo > line and am looking into it now.) > > The Digital Logger has other things we don't need but we can > ignore them. It does not have one important item, wired > Ethernet. > > I'm pondering how that could be added outboard. What we need is > really a terminal server: serial from the PLC on the one side, > and TCP/IP on the other. You can buy such in a shiny box for > say $100 <http://www.antaira.com/products/STE-501C?gclid=CIDYyKbRiNMCFdyEswod5E8AnQ> > or less for boxless <http://www.mouser.com/ds/2/224/XPort_DS-220314.pdf> > The latter requires making a PCB, worrying about power, etc. > Any alternatives you're aware of?
Why don't you just get a controller that includes Ethernet to start with? I haven't seen where you explain why you are only looking at PLC controllers rather than generic CPU boards. From how you have explained your needs so far, there is nothing in a PLC that you will use that is different from a CPU board. From what I can see, you would do well with a Raspberry Pi or a Beagle Bone Black type board. Ethernet included and tons of support (metric tons even). So what do you get with a PLC that you don't get with one of the *many* CPU boards? -- Rick C
Reply by David Lesher April 3, 20172017-04-03
I've been looking at other PLC controller offerings, and thus
far the <http://www.digital-loggers.com/plchw.html> comes out
ahead; it does a lot of what we need in a package with a good
price. Alternatives I've found either cost far more or require
lots of integration. (I've just been pointed at the Siemens Logo
line and am looking into it now.)

The Digital Logger has other things we don't need but we can
ignore them.  It does not have one important item, wired
Ethernet.

I'm pondering how that could be added outboard. What we need is
really a terminal server: serial from the PLC on the one side,
and TCP/IP on the other. You can buy such in a shiny box for
say $100  <http://www.antaira.com/products/STE-501C?gclid=CIDYyKbRiNMCFdyEswod5E8AnQ>
or less for boxless <http://www.mouser.com/ds/2/224/XPort_DS-220314.pdf>
The latter requires making a PCB, worrying about power, etc.
Any alternatives you're aware of?


-- 
A host is a host from coast to coast.................wb8foz@nrk.com
& no one will talk to a host that's close..........................
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433
Reply by Martin Riddle March 28, 20172017-03-28
On 28 Mar 2017 18:59:51 GMT, Jasen Betts <jasen@xnet.co.nz> wrote:

>On 2017-03-28, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote: >> On 03/27/2017 07:07 PM, Martin Riddle wrote: >>> On 27 Mar 2017 18:41:59 GMT, Jasen Betts <jasen@xnet.co.nz> wrote: >>> >>>> On 2017-03-27, rickman <gnuarm@gmail.com> wrote: >>>>> On 3/26/2017 3:49 PM, David Lesher wrote: >>>>>> rickman <gnuarm@gmail.com> writes: >>>>>> >>>>>>>> Not sure I follow; there is SPI on the board, but thinking out >>>>>>>> loud, we would have to add selection to the existing SPI users, >>>>>>>> the display, touch screen, and flash..... >>>>>> >>>>>>> Flash??? The other stuff is up to you. I"m just talking about the 24 >>>>>>> relays. You didn't mention the other items. Is everything going to be >>>>>>> on the 8 digital outputs? >>>>>> >>>>>> I was talking about using the existing I2C or SPI system to also >>>>>> drive the outboard relay boards. It's mentioned only in passing in the >>>>>> writeup. >>>>> >>>>> Yes, I saw that. I don't have the various web pages open at the moment, >>>>> but you may have trouble using the built in SPI port because each port >>>>> will need an enable. If you go this route you will need to use I2C. >>>> >>>> save some pins: use a 4017 for the enable. >>>> >>> >>> 74HC138 Mux, 3 to 8 >>> >>> Cheers >>> >> >> Using a 4017 is pretty gnarly--how do you avoid !CS glitches? If you >> had a '595 buffered SIPO register on there, every time you hit its chip >> select, its output register gets loaded with whatever garbage is in the >> shift reg at the time. > >the 4017 has an enable pin but that means using 3 outputs to drive it. > >is the '138 guaranteed glitch free? > >> Since that would require that each shift register be loaded with the >> correct data at nearly all times, you might as well daisy chain them and >> use one chip select. > >yeah, if your interface parts support that, it seems the best way to go. > >> Cheers >> >> Phil Hobbs >>
Never had a problem using a standard MUX like the 138. If I need a park position I leave one output free and set the Mux to that. Cheers
Reply by Jasen Betts March 28, 20172017-03-28
On 2017-03-28, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:
> On 03/27/2017 07:07 PM, Martin Riddle wrote: >> On 27 Mar 2017 18:41:59 GMT, Jasen Betts <jasen@xnet.co.nz> wrote: >> >>> On 2017-03-27, rickman <gnuarm@gmail.com> wrote: >>>> On 3/26/2017 3:49 PM, David Lesher wrote: >>>>> rickman <gnuarm@gmail.com> writes: >>>>> >>>>>>> Not sure I follow; there is SPI on the board, but thinking out >>>>>>> loud, we would have to add selection to the existing SPI users, >>>>>>> the display, touch screen, and flash..... >>>>> >>>>>> Flash??? The other stuff is up to you. I"m just talking about the 24 >>>>>> relays. You didn't mention the other items. Is everything going to be >>>>>> on the 8 digital outputs? >>>>> >>>>> I was talking about using the existing I2C or SPI system to also >>>>> drive the outboard relay boards. It's mentioned only in passing in the >>>>> writeup. >>>> >>>> Yes, I saw that. I don't have the various web pages open at the moment, >>>> but you may have trouble using the built in SPI port because each port >>>> will need an enable. If you go this route you will need to use I2C. >>> >>> save some pins: use a 4017 for the enable. >>> >> >> 74HC138 Mux, 3 to 8 >> >> Cheers >> > > Using a 4017 is pretty gnarly--how do you avoid !CS glitches? If you > had a '595 buffered SIPO register on there, every time you hit its chip > select, its output register gets loaded with whatever garbage is in the > shift reg at the time.
the 4017 has an enable pin but that means using 3 outputs to drive it. is the '138 guaranteed glitch free?
> Since that would require that each shift register be loaded with the > correct data at nearly all times, you might as well daisy chain them and > use one chip select.
yeah, if your interface parts support that, it seems the best way to go.
> Cheers > > Phil Hobbs >
-- This email has not been checked by half-arsed antivirus software
Reply by David Lesher March 28, 20172017-03-28
rickman <gnuarm@gmail.com> writes:


>The I2C port is a hardware interface on the MCU, so it will have a >driver in software so that it will be easy to program. If you are happy >with the I2C relay board, there is no reason to use the SPI port. You >just need to set the address switches differently on each of the relay >boards so that there are no address conflicts including the other I2C >peripherals like the display.
I thought the display was on the SPI bus. The choice is also a function of what relay boards of each ilk I find. I expected to find lots, and have not. -- A host is a host from coast to coast.................wb8foz@nrk.com & no one will talk to a host that's close.......................... Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433
Reply by Phil Hobbs March 28, 20172017-03-28
On 03/27/2017 07:07 PM, Martin Riddle wrote:
> On 27 Mar 2017 18:41:59 GMT, Jasen Betts <jasen@xnet.co.nz> wrote: > >> On 2017-03-27, rickman <gnuarm@gmail.com> wrote: >>> On 3/26/2017 3:49 PM, David Lesher wrote: >>>> rickman <gnuarm@gmail.com> writes: >>>> >>>>>> Not sure I follow; there is SPI on the board, but thinking out >>>>>> loud, we would have to add selection to the existing SPI users, >>>>>> the display, touch screen, and flash..... >>>> >>>>> Flash??? The other stuff is up to you. I"m just talking about the 24 >>>>> relays. You didn't mention the other items. Is everything going to be >>>>> on the 8 digital outputs? >>>> >>>> I was talking about using the existing I2C or SPI system to also >>>> drive the outboard relay boards. It's mentioned only in passing in the >>>> writeup. >>> >>> Yes, I saw that. I don't have the various web pages open at the moment, >>> but you may have trouble using the built in SPI port because each port >>> will need an enable. If you go this route you will need to use I2C. >> >> save some pins: use a 4017 for the enable. >> > > 74HC138 Mux, 3 to 8 > > Cheers >
Using a 4017 is pretty gnarly--how do you avoid !CS glitches? If you had a '595 buffered SIPO register on there, every time you hit its chip select, its output register gets loaded with whatever garbage is in the shift reg at the time. Since that would require that each shift register be loaded with the correct data at nearly all times, you might as well daisy chain them and use one chip select. Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC Optics, Electro-optics, Photonics, Analog Electronics 160 North State Road #203 Briarcliff Manor NY 10510 hobbs at electrooptical dot net http://electrooptical.net
Reply by Jasen Betts March 28, 20172017-03-28
On 2017-03-27, Martin Riddle <martin_ridd@verizon.net> wrote:
> On 27 Mar 2017 18:41:59 GMT, Jasen Betts <jasen@xnet.co.nz> wrote: > >>On 2017-03-27, rickman <gnuarm@gmail.com> wrote: >>> On 3/26/2017 3:49 PM, David Lesher wrote: >>>> rickman <gnuarm@gmail.com> writes: >>>> >>>>>> Not sure I follow; there is SPI on the board, but thinking out >>>>>> loud, we would have to add selection to the existing SPI users, >>>>>> the display, touch screen, and flash..... >>>> >>>>> Flash??? The other stuff is up to you. I"m just talking about the 24 >>>>> relays. You didn't mention the other items. Is everything going to be >>>>> on the 8 digital outputs? >>>> >>>> I was talking about using the existing I2C or SPI system to also >>>> drive the outboard relay boards. It's mentioned only in passing in the >>>> writeup. >>> >>> Yes, I saw that. I don't have the various web pages open at the moment, >>> but you may have trouble using the built in SPI port because each port >>> will need an enable. If you go this route you will need to use I2C. >> >>save some pins: use a 4017 for the enable. >> > > 74HC138 Mux, 3 to 8
yeah, almost as good. -- This email has not been checked by half-arsed antivirus software
Reply by rickman March 28, 20172017-03-28
On 3/28/2017 1:08 AM, David Lesher wrote:
> rickman <gnuarm@gmail.com> writes: > > >> I'm no expert on PLC, but if you aren't using any of the >> hardware I would suggest you get a microcontroller board >> instead. There are TONs of good products that are smaller and >> more cost effective. But I believe PLCs often have a special >> language for programming, ladder logic. I didn't think it was >> used much even for PLCs though. > > We don't want ladder-logic. This box was suggested by folks > using them & the programmer is happy so far. > > Its advantages are it's already built, has most of the > functionality we need in one box, and is inexpensive vs. the > labor of building anything.
I'm not sure what "already built" means other than the obvious thing. But why wouldn't other boards be "already built"? Are you saying this comes in a box? Does that include the relay boards? If you need to put the relay boards in another box, why not put it all in one box?
> We will be using other aspects, such as the analog inputs, RTC, > and the touch screen.
Analog inputs are not uncommon on CPU boards along with RTC and touch screen. In fact, all this is extremely common.
> If you are aware of a different unit (....no matter if it's > called a PLC or an X-15) that does what this one does, plus a > wired Ethernet port, suggestions welcome.
You can get a Raspberry Pi for a number between $5 and $35 including a 40 pin header with serial, SPI and I2C ports along with 3.3 volt GP I/O. It is easy to find an analog input module to plug into the header and it is easy to find RTC and touch screen LCDs. I don't know just how the unit you are looking at is packaged. But if you are happy with it, go for it. I'm just saying that there is a lot on the PLC that you aren't using. In fact, all the stuff that you aren't using is what makes a typical PLC different from a CPU card. So it just seemed a bit out of line. But the price for this PLC is pretty good actually. My brother is using one that is a *lot* more money. -- Rick C