Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > sci.electronics.design > #453501 > unrolled thread

Output boards, SPI vs I2C

Back to article view | Back to sci.electronics.design

Contents

  Output boards, SPI vs I2C David Lesher <wb8foz@panix.com> - 2017-03-25 02:46 +0000
    Re: Output boards, SPI vs I2C krw@notreal.com - 2017-03-24 23:25 -0400
      Re: Output boards, SPI vs I2C David Lesher <wb8foz@panix.com> - 2017-03-26 04:13 +0000
    Re: Output boards, SPI vs I2C rickman <gnuarm@gmail.com> - 2017-03-25 14:04 -0400
      Re: Output boards, SPI vs I2C David Lesher <wb8foz@panix.com> - 2017-03-26 04:11 +0000
        Re: Output boards, SPI vs I2C rickman <gnuarm@gmail.com> - 2017-03-26 02:37 -0400
          Re: Output boards, SPI vs I2C David Lesher <wb8foz@panix.com> - 2017-03-26 14:41 +0000
            Re: Output boards, SPI vs I2C rickman <gnuarm@gmail.com> - 2017-03-26 12:47 -0400
              Re: Output boards, SPI vs I2C David Lesher <wb8foz@panix.com> - 2017-03-26 19:49 +0000
                Re: Output boards, SPI vs I2C rickman <gnuarm@gmail.com> - 2017-03-27 10:49 -0400
                  Re: Output boards, SPI vs I2C Jasen Betts <jasen@xnet.co.nz> - 2017-03-27 18:41 +0000
                    Re: Output boards, SPI vs I2C Martin Riddle <martin_ridd@verizon.net> - 2017-03-27 19:07 -0400
                      Re: Output boards, SPI vs I2C Jasen Betts <jasen@xnet.co.nz> - 2017-03-28 08:03 +0000
                      Re: Output boards, SPI vs I2C Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-03-28 10:44 -0400
                        Re: Output boards, SPI vs I2C Jasen Betts <jasen@xnet.co.nz> - 2017-03-28 18:59 +0000
                          Re: Output boards, SPI vs I2C Martin Riddle <martin_rid@verizon.net> - 2017-03-28 15:37 -0400
                            Re: Output boards, SPI vs I2C David Lesher <wb8foz@panix.com> - 2017-04-03 17:49 +0000
                              Re: Output boards, SPI vs I2C rickman <gnuarm@gmail.com> - 2017-04-03 15:18 -0400
                                Re: Output boards, SPI vs I2C David Lesher <wb8foz@panix.com> - 2017-04-04 02:59 +0000
                                  Re: Output boards, SPI vs I2C rickman <gnuarm@gmail.com> - 2017-04-04 00:54 -0400
                  Re: Output boards, SPI vs I2C David Lesher <wb8foz@panix.com> - 2017-03-28 05:08 +0000
                    Re: Output boards, SPI vs I2C rickman <gnuarm@gmail.com> - 2017-03-28 02:16 -0400
    Re: Output boards, SPI vs I2C Martin Riddle <martin_ridd@verizon.net> - 2017-03-27 19:03 -0400
      Re: Output boards, SPI vs I2C David Lesher <wb8foz@panix.com> - 2017-03-28 03:28 +0000
        Re: Output boards, SPI vs I2C rickman <gnuarm@gmail.com> - 2017-03-28 00:38 -0400
          Re: Output boards, SPI vs I2C David Lesher <wb8foz@panix.com> - 2017-03-28 14:47 +0000

Page 1 of 2  [1] 2  Next page →

#453501 — Output boards, SPI vs I2C

I pondering a microcontroller project that will need a number (say 24)
output relays.

Is there a reason to use I2C over SPI? It looks like there are 8-channel
boards of both ilks, and I don't know if one has an advantage in this case.

-- 
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

[toc] | [next] | [standalone]

#453510

On Sat, 25 Mar 2017 02:46:33 +0000 (UTC), David Lesher
<wb8foz@panix.com> wrote:

>I pondering a microcontroller project that will need a number (say 24)
>output relays.
>
>Is there a reason to use I2C over SPI? It looks like there are 8-channel
>boards of both ilks, and I don't know if one has an advantage in this case.

I2C across connectors isn't recommended.  SPI is far more robust,
though can be a bit more complicated in large systems.

[toc] | [prev] | [next] | [standalone]

#453680

krw@notreal.com writes:

>>Is there a reason to use I2C over SPI? It looks like there are 8-channel
>>boards of both ilks, and I don't know if one has an advantage in this case.

>I2C across connectors isn't recommended.  SPI is far more robust,
>though can be a bit more complicated in large systems.

By this you mean ribbon cable jumpers & headers are ixnay?

-- 
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

[toc] | [prev] | [next] | [standalone]

#453581

On 3/24/2017 10:46 PM, David Lesher wrote:
> I pondering a microcontroller project that will need a number (say 24)
> output relays.
>
> Is there a reason to use I2C over SPI? It looks like there are 8-channel
> boards of both ilks, and I don't know if one has an advantage in this case.

I2C is a serial bus (with a spec) with all devices connected in 
parallel.  SPI is a functional description rather than a real spec, but 
is so simple it is not hard to make it work.  SPI devices can be 
connected in parallel with separate select pins, or all in series being 
controlled as one long shift register.

I2C runs at a basic rate of 100 kbps with a 400 kbps mode as well as 
faster modes at 1 Mbps and up.  400 kbps is generally supported, but the 
faster modes are not universal.  SPI runs at whatever speed the devices 
work at.

I2C has a protocol that you will need to program.  SPI specified no 
protocol other than shifting data in and out.  Any protocol is defined 
by the slaves you choose.

All things being equal (whatever that means as I2C and SPI have very 
little equal) I would pick SPI for driving 24 relays because the 
"protocol" should be very simple (shift out the data) and I2C can be 
more complex to implement.

I'd probably wire three boards serially and see if that works.  If not, 
I would wire them in parallel with three separate chip selects.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#453679

rickman <gnuarm@gmail.com> writes:



....

>All things being equal (whatever that means as I2C and SPI
>have very little equal) I would pick SPI for driving 24 relays
>because the "protocol" should be very simple (shift out the
>data) and I2C can be more complex to implement.

>I'd probably wire three boards serially and see if that works.
>If not, I would wire them in parallel with three separate chip
>selects.

This would be driven by a
<http://www.digital-loggers.com/plchw.html> 
which claims to support both flavors.

Data rate is virtally irrelevent here; I need a response time
far slower than the relays themselves are.....

My hand may be forced by what boards are actually available. I
found <https://www.industrologic.com/r8spiprod.htm> and 
<http://lightsosoft.com/sites/default/files/I2C-Relay8-H_040813_1240.pdf>
but many other boards are not what they seem to be, or are from across the pond.
<http://jap.hu/electronic/relay_module.html>

Not sure I grasp "wire three boards serially" but we can spare chip select 
outputs.
-- 
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

[toc] | [prev] | [next] | [standalone]

#453697

On 3/26/2017 12:11 AM, David Lesher wrote:
> rickman <gnuarm@gmail.com> writes:
>
>
>
> .....
>
>> All things being equal (whatever that means as I2C and SPI
>> have very little equal) I would pick SPI for driving 24 relays
>> because the "protocol" should be very simple (shift out the
>> data) and I2C can be more complex to implement.
>
>> I'd probably wire three boards serially and see if that works.
>> If not, I would wire them in parallel with three separate chip
>> selects.
>
> This would be driven by a
> <http://www.digital-loggers.com/plchw.html>
> which claims to support both flavors.

I can't find how this "PLC Hardware" item fits into their product line. 
Your web page shows this item, but every page I find on their site only 
points to a wifi PLC.  Is this the same thing?  They also have videos on 
every page which I hate!

Oh, I see.  The page you link to is for the "hardware" and the other 
pages are a general PLC page and a software PLC page, etc.  $89 sounds 
like a bargain.


> Data rate is virtally irrelevent here; I need a response time
> far slower than the relays themselves are.....
>
> My hand may be forced by what boards are actually available. I
> found <https://www.industrologic.com/r8spiprod.htm> and

The manual for this one says it uses optoisolators on the inputs with a 
1 kohm current limiting resistor.  They recommend a minimum of 0.5 mA 
current, bit prefer 10 mA.  10 mA would require 12 volt drive.  The 
digital outputs on the PLC are open collector relay drivers.  They will 
be compatible and you can use the power supply to the PLC as the common 
power to the + terminal on each of the three SPI signals.  Or I think I 
see a direct input connector for the open collector outputs, J1.  They 
don't mention using these inputs, but what's the diff?  The optos will 
be less sensitive to noise I expect.  There is some irony in that they 
are using the same relay drivers your PLC uses for the digital outputs.

This unit has no serial output, so the SPI protocol will require this 
unit to be used *only* in the parallel mode with a dedicated strobe.

To drive 24 relays will use five digital outputs.


> <http://lightsosoft.com/sites/default/files/I2C-Relay8-H_040813_1240.pdf>

This board seems to be I2C only.  That would require I2C support in your 
PLC.  Does the PLC have that in the software?


> but many other boards are not what they seem to be, or are from across the pond.
> <http://jap.hu/electronic/relay_module.html>

Another I2C board.

> Not sure I grasp "wire three boards serially" but we can spare chip select
> outputs.

Normally SPI devices have a serial data input MOSI (master out, slave 
in) and and serial output MISO (care to guess what this one means?).  If 
you connect the MISO of the first module to the MOSI of the second 
module, etc before connecting the MISO of the last module to the MISO of 
the master module it will form a daisy chain of N * 8 bits.  So the PLC 
will need to shift out 24 bits before removing the strobe.  But the one 
SPI relay board has no serial output (MISO) and must be used in 
parallel.  Then the PLC output will drive all the MOSI (aka data) inputs 
together as well as a PLC output that will drive all the Clock inputs 
together.  The Strobe signals will all have to be separate.

With I2C, you just wire the two outputs to each of the two inputs on all 
three boards (with a pullup resistor somewhere in the path).  The relay 
boards will need to have jumpers to set a unique address on the bus. 
Each byte you wish to send to control a set of relays requires two 
bytes, one to set the address and one to set the data.

Just a comment, some of the lightsosoft.com documentation isn't so 
clear.  I'm not sure how to wire up the I2C interface.  This is what 
they say:

The specific pins you need for I2C communications are:

TB19, “SDA”
TB20, “SCL”
TB18, “GND”
TB19, “5V”

I see none of these notations in any of the illustrations.  I could make 
an educated guess, but why can't they make it clear in the manual *AND* 
on the board?  The notation they show looks like JTAG and SPI labels. 
Ask if they have an SPI version of the board.  I bet they do.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#453754

rickman <gnuarm@gmail.com> writes:

>> This would be driven by a
>> <http://www.digital-loggers.com/plchw.html>
>> which claims to support both flavors.

>Oh, I see.  The page you link to is for the "hardware" and the other 
>pages are a general PLC page and a software PLC page, etc.  $89 sounds 
>like a bargain.


>> Data rate is virtally irrelevent here; I need a response time
>> far slower than the relays themselves are.....
>>
>> My hand may be forced by what boards are actually available. I
>> found <https://www.industrologic.com/r8spiprod.htm> and

>The manual for this one says it uses optoisolators on the inputs with a 
>1 kohm current limiting resistor.  They recommend a minimum of 0.5 mA 
>current, bit prefer 10 mA.  10 mA would require 12 volt drive.  The 
>digital outputs on the PLC are open collector relay drivers.  They will 
>be compatible and you can use the power supply to the PLC as the common 
>power to the + terminal on each of the three SPI signals.  Or I think I 
>see a direct input connector for the open collector outputs, J1.  They 
>don't mention using these inputs, but what's the diff?  The optos will 
>be less sensitive to noise I expect.  There is some irony in that they 
>are using the same relay drivers your PLC uses for the digital outputs.

Yes, I noticed that aspect.

>This unit has no serial output, so the SPI protocol will require this 
>unit to be used *only* in the parallel mode with a dedicated strobe.

>To drive 24 relays will use five digital outputs.

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.....

>> <http://lightsosoft.com/sites/default/files/I2C-Relay8-H_040813_1240.pdf>

>This board seems to be I2C only.  That would require I2C support in your 
>PLC.  Does the PLC have that in the software?

<http://www.digital-loggers.com/plchw.html>
I2C Memory Expansion Socket

There is a 32K socketed EEPROM that can be used for non-volatile
storage that's also connected to the I2C bus.  Because it has
a large write-endurance, EEPROM is usually the best place to
store data that's frequently updated.  Other 5V chips a standard
8 pin DIP package such as FRAM, SRAM, Larger EEPROM etc can be
substituted. The pinout is

1 = AO
2 = A1
3 = A2
4 = GND
5 = SBA
6 = SCL
7 = TEST (grounded) 
8 = 5V VCC.  
`
The socket could also be used as an expansion port via an 8-pin
ribbon cable plug.  Although it's a bit inconvenient, this chip
has been located beneath the clock module to gain space for
reprogramming headers.


>> but many other boards are not what they seem to be, or are from across the pond.
>> <http://jap.hu/electronic/relay_module.html>

>Another I2C board.

>> Not sure I grasp "wire three boards serially" but we can spare chip select
>> outputs.

>Normally SPI devices have a serial data input MOSI (master out, slave 
>in) and and serial output MISO (care to guess what this one means?).  If 
>you connect the MISO of the first module to the MOSI of the second 
>module, etc before connecting the MISO of the last module to the MISO of 
>the master module it will form a daisy chain of N * 8 bits.  So the PLC 
>will need to shift out 24 bits before removing the strobe.  But the one 
>SPI relay board has no serial output (MISO) and must be used in 
>parallel.  Then the PLC output will drive all the MOSI (aka data) inputs 
>together as well as a PLC output that will drive all the Clock inputs 
>together.  The Strobe signals will all have to be separate.

>With I2C, you just wire the two outputs to each of the two inputs on all 
>three boards (with a pullup resistor somewhere in the path).  The relay 
>boards will need to have jumpers to set a unique address on the bus. 
>Each byte you wish to send to control a set of relays requires two 
>bytes, one to set the address and one to set the data.

Do you echo krw's concerns on I2C cabling?

>Just a comment, some of the lightsosoft.com documentation isn't so 
>clear.  I'm not sure how to wire up the I2C interface.  This is what 
>they say:

>The specific pins you need for I2C communications are:

>TB19, SD
>TB20, SCL
>TB18, GND
>TB19, 5V

>I could make an educated guess, but why can't they make it     
>clear in the manual *AND* on the board?                        

I have asked such questions about every board I have found so far.

-- 
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

[toc] | [prev] | [next] | [standalone]

#453770

On 3/26/2017 10:41 AM, David Lesher wrote:
> rickman <gnuarm@gmail.com> writes:
>
>>> This would be driven by a
>>> <http://www.digital-loggers.com/plchw.html>
>>> which claims to support both flavors.
>
>> Oh, I see.  The page you link to is for the "hardware" and the other
>> pages are a general PLC page and a software PLC page, etc.  $89 sounds
>> like a bargain.
>
>
>>> Data rate is virtally irrelevent here; I need a response time
>>> far slower than the relays themselves are.....
>>>
>>> My hand may be forced by what boards are actually available. I
>>> found <https://www.industrologic.com/r8spiprod.htm> and
>
>> The manual for this one says it uses optoisolators on the inputs with a
>> 1 kohm current limiting resistor.  They recommend a minimum of 0.5 mA
>> current, bit prefer 10 mA.  10 mA would require 12 volt drive.  The
>> digital outputs on the PLC are open collector relay drivers.  They will
>> be compatible and you can use the power supply to the PLC as the common
>> power to the + terminal on each of the three SPI signals.  Or I think I
>> see a direct input connector for the open collector outputs, J1.  They
>> don't mention using these inputs, but what's the diff?  The optos will
>> be less sensitive to noise I expect.  There is some irony in that they
>> are using the same relay drivers your PLC uses for the digital outputs.
>
> Yes, I noticed that aspect.
>
>> This unit has no serial output, so the SPI protocol will require this
>> unit to be used *only* in the parallel mode with a dedicated strobe.
>
>> To drive 24 relays will use five digital outputs.
>
> 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?

SPI Data -->>--  |
                  |--- To all SPI controlled device ports
SPI Clk  -->>--  |

SPI Sel1 -->>--  |--- To SPI relay unit 1 Sel input

SPI Sel2 -->>--  |--- To SPI relay unit 2 Sel input

SPI Sel3 -->>--  |--- To SPI relay unit 3 Sel input

Five signals for 3 relay boards.


The display, touch screen and other things they talk about connecting 
through SPI or I2C connect directly to the CPU.  This will not be the 
same as using the digital outputs.  If you want to use the dedicated 
I/Os on the CPU for the relay drivers you might as well not use the PLC 
but get a CPU card instead and save some bucks.  What does the PLC unit 
do for you exactly?  Does it provide a way of programming it that you 
understand well that an Arduino won't?


>>> <http://lightsosoft.com/sites/default/files/I2C-Relay8-H_040813_1240.pdf>
>
>> This board seems to be I2C only.  That would require I2C support in your
>> PLC.  Does the PLC have that in the software?
>
> <http://www.digital-loggers.com/plchw.html>
> I2C Memory Expansion Socket
>
> There is a 32K socketed EEPROM that can be used for non-volatile
> storage that's also connected to the I2C bus.  Because it has
> a large write-endurance, EEPROM is usually the best place to
> store data that's frequently updated.  Other 5V chips a standard
> 8 pin DIP package such as FRAM, SRAM, Larger EEPROM etc can be
> substituted. The pinout is
>
> 1 = AO
> 2 = A1
> 3 = A2
> 4 = GND
> 5 = SBA
> 6 = SCL
> 7 = TEST (grounded)
> 8 = 5V VCC.
> `
> The socket could also be used as an expansion port via an 8-pin
> ribbon cable plug.  Although it's a bit inconvenient, this chip
> has been located beneath the clock module to gain space for
> reprogramming headers.

See my comments above.


>>> but many other boards are not what they seem to be, or are from across the pond.
>>> <http://jap.hu/electronic/relay_module.html>
>
>> Another I2C board.
>
>>> Not sure I grasp "wire three boards serially" but we can spare chip select
>>> outputs.
>
>> Normally SPI devices have a serial data input MOSI (master out, slave
>> in) and and serial output MISO (care to guess what this one means?).  If
>> you connect the MISO of the first module to the MOSI of the second
>> module, etc before connecting the MISO of the last module to the MISO of
>> the master module it will form a daisy chain of N * 8 bits.  So the PLC
>> will need to shift out 24 bits before removing the strobe.  But the one
>> SPI relay board has no serial output (MISO) and must be used in
>> parallel.  Then the PLC output will drive all the MOSI (aka data) inputs
>> together as well as a PLC output that will drive all the Clock inputs
>> together.  The Strobe signals will all have to be separate.
>
>> With I2C, you just wire the two outputs to each of the two inputs on all
>> three boards (with a pullup resistor somewhere in the path).  The relay
>> boards will need to have jumpers to set a unique address on the bus.
>> Each byte you wish to send to control a set of relays requires two
>> bytes, one to set the address and one to set the data.
>
> Do you echo krw's concerns on I2C cabling?

It's not an absolute on leaving the CPU board.  But both SPI and I2C are 
sensitive to noise and poor impedance matches.  If your wire runs are 
short you should be ok.  Use ribbon cable with every other wire a ground 
or twisted pairs with a signal wire mated with a ground.  How far apart 
are the PLC and the relay boards?


>> Just a comment, some of the lightsosoft.com documentation isn't so
>> clear.  I'm not sure how to wire up the I2C interface.  This is what
>> they say:
>
>> The specific pins you need for I2C communications are:
>
>> TB19, SD
>> TB20, SCL
>> TB18, GND
>> TB19, 5V
>
>> I could make an educated guess, but why can't they make it
>> clear in the manual *AND* on the board?
>
> I have asked such questions about every board I have found so far.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#453794

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.

>The display, touch screen and other things they talk about connecting 
>through SPI or I2C connect directly to the CPU.  This will not be the 
>same as using the digital outputs.  If you want to use the dedicated 
>I/Os on the CPU for the relay drivers you might as well not use the PLC 
>but get a CPU card instead and save some bucks.  What does the PLC unit 
>do for you exactly?  Does it provide a way of programming it that you 
>understand well that an Arduino won't?

No, because I'm not the programmer at all; (To paraphrase Bob
Pease) <https://tinyurl.com/kby566u> I just solder wires. 
Two people working with it suggested this platform for this project.

....

>> Do you echo krw's concerns on I2C cabling?

>It's not an absolute on leaving the CPU board.  But both SPI and I2C are 
>sensitive to noise and poor impedance matches.  If your wire runs are 
>short you should be ok.  Use ribbon cable with every other wire a ground 
>or twisted pairs with a signal wire mated with a ground.  How far apart 
>are the PLC and the relay boards?

A few inches; directly adjacent.

-- 
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

[toc] | [prev] | [next] | [standalone]

#453877

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.


>> The display, touch screen and other things they talk about connecting
>> through SPI or I2C connect directly to the CPU.  This will not be the
>> same as using the digital outputs.  If you want to use the dedicated
>> I/Os on the CPU for the relay drivers you might as well not use the PLC
>> but get a CPU card instead and save some bucks.  What does the PLC unit
>> do for you exactly?  Does it provide a way of programming it that you
>> understand well that an Arduino won't?
>
> No, because I'm not the programmer at all; (To paraphrase Bob
> Pease) <https://tinyurl.com/kby566u> I just solder wires.
> Two people working with it suggested this platform for this project.

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.

Arduinos mostly are programmed in Python.  Everything can be programmed 
in Forth.  I'm working with Mecrisp these days.  Commercial versions of 
Forth are SwiftForth from Forth, Inc https://www.forth.com/ and VFX from 
MPE (Microprocessor Engineering) http://www.mpeforth.com/.

Not likely you can change the programmer's point of view, but if they 
are suggesting using a PLC just to get a CPU they aren't very informed 
in my opinion.


>>> Do you echo krw's concerns on I2C cabling?
>
>> It's not an absolute on leaving the CPU board.  But both SPI and I2C are
>> sensitive to noise and poor impedance matches.  If your wire runs are
>> short you should be ok.  Use ribbon cable with every other wire a ground
>> or twisted pairs with a signal wire mated with a ground.  How far apart
>> are the PLC and the relay boards?
>
> A few inches; directly adjacent.

Make sure your power connections are solid and direct.  A few inches 
won't hurt.  I2C isn't magic.  It uses a pullup resistor, about 4.7 
kohms sticks in my mind.  All devices on the bus are open collector.  It 
should be pretty robust.  You can use a smaller value pull up resistor 
to get a bit more noise robustness.  Just check all the data sheets to 
make sure they can pull the lower value resistor to ground.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#453909

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.

>>> The display, touch screen and other things they talk about connecting
>>> through SPI or I2C connect directly to the CPU.  This will not be the
>>> same as using the digital outputs.  If you want to use the dedicated
>>> I/Os on the CPU for the relay drivers you might as well not use the PLC
>>> but get a CPU card instead and save some bucks.  What does the PLC unit
>>> do for you exactly?  Does it provide a way of programming it that you
>>> understand well that an Arduino won't?
>>
>> No, because I'm not the programmer at all; (To paraphrase Bob
>> Pease) <https://tinyurl.com/kby566u> I just solder wires.
>> Two people working with it suggested this platform for this project.
>
> 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.
>
> Arduinos mostly are programmed in Python.  Everything can be programmed 
> in Forth.  I'm working with Mecrisp these days.  Commercial versions of 
> Forth are SwiftForth from Forth, Inc https://www.forth.com/ and VFX from 
> MPE (Microprocessor Engineering) http://www.mpeforth.com/.
>
> Not likely you can change the programmer's point of view, but if they 
> are suggesting using a PLC just to get a CPU they aren't very informed 
> in my opinion.
>
>
>>>> Do you echo krw's concerns on I2C cabling?
>>
>>> It's not an absolute on leaving the CPU board.  But both SPI and I2C are
>>> sensitive to noise and poor impedance matches.  If your wire runs are
>>> short you should be ok.  Use ribbon cable with every other wire a ground
>>> or twisted pairs with a signal wire mated with a ground.  How far apart
>>> are the PLC and the relay boards?
>>
>> A few inches; directly adjacent.
>
> Make sure your power connections are solid and direct.  A few inches 
> won't hurt.  I2C isn't magic.  It uses a pullup resistor, about 4.7 
> kohms sticks in my mind.  All devices on the bus are open collector.  It 
> should be pretty robust.  You can use a smaller value pull up resistor 
> to get a bit more noise robustness.  Just check all the data sheets to 
> make sure they can pull the lower value resistor to ground.
>


-- 
This email has not been checked by half-arsed antivirus software 

[toc] | [prev] | [next] | [standalone]

#453927

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

[toc] | [prev] | [next] | [standalone]

#453971

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 

[toc] | [prev] | [next] | [standalone]

#453988

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

[toc] | [prev] | [next] | [standalone]

#454028

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 

[toc] | [prev] | [next] | [standalone]

#454030

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

[toc] | [prev] | [next] | [standalone]

#454926

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

[toc] | [prev] | [next] | [standalone]

#454953

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

[toc] | [prev] | [next] | [standalone]

#455010

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

[toc] | [prev] | [next] | [standalone]

#455028

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | sci.electronics.design

csiph-web