:: Re: [DNG] Request for information -…
Page principale
Supprimer ce message
Répondre à ce message
Auteur: o1bigtenor
Date:  
CC: dng
Sujet: Re: [DNG] Request for information - - re: networking - - round 2
On Tue, Jun 6, 2023 at 7:32 AM Antony Stone
<Antony.Stone@???> wrote:
>
> On Tuesday 06 June 2023 at 14:26:03, Didier Kryn wrote:
>
> > Le 06/06/2023 à 14:24, Dan Purgert via Dng a écrit :
> > >
> > > Industrial sensor "networks" tend to be serial protocols that are "not
> > > ethernet" (CANBUS, MODBUS, some vendor-proprietary thing, etc.), given
> > > the overheads necessary for ethernet in general (cost, complexity,
> > > etc.).


Hmmm - - - - except I'm finding modbus-tcp/ip . . .
> > >
> > > Then, once everything is aggregated at the main control panel of the
> > > machine, the machine will then potentially talk ethernet to the rest of
> > > the production floor (or rather probably some master control
> > > dashboard).
> > >
> > >> [...]
> > >>
> > >> This is what the network is for - - - for oversight control and
> > >> assessment. Can I use a 192.168.0.0/16 network to run something like
> > >> this?
> > >
> > > Sensors tend to already speak one of a few generally well-defined
> > > protocols (e.g. SPI, I2C, some variation of 1-wire, or even analog
> > > values, amongst other things), so why not just use those options instead
> > > of needing an intermediary controller to cram their data into ethernet
> > > frames?
> >
> >      This seems to me the most sensible option, most certainly cheaper
> > than Ethernet.


Dunno about that cheaper - - - RS-485 16 port hub is as much money as a
16 port switch - - - - cheaper if I use ones without aggregation.
(price looking just now)

>
> I also completely agree that:
>
> (a) this is the way things are commonly done
> (b) for very good reasons
> (c) which include simplicity and cheapness
>
> Nobody even seems to have mentioned the power aspects of this setup yet, and I
> think trying to implement sufficient devices to convert individual sensor
> readings into ethernet, along with sufficient switches to connect everything
> together, would require a very substantial amount of electricity.
>
> Aggregation devices such as Dan has outlined, with a consequentially far
> smaller network, would be a lot less demanding on power requirements.
>
>

Whilst I understand the 'commonly done' aspect I'm wondering if that's
more a function of 'that's the way we've always done it' ?

It is a little cheaper to put a RS-485 addon onto a microcontroller. I'm still
stuck with a very very low limit on the number of addresses available - - -
250 in fact - - - - that sounds like a lot - - - but - - - - with
stage one burning
through addresses at a rate of 4 to 6 per 'work node and looking forward to
a stage x (haven't started planning for possible inbetweens etc etc so dunno
how many) where there might be 15 to 20 - - - - PER 'work node' . . .

At this point I'm not really seeing any serious advantages to modbus - - - -
canbus - - - - hard limits are far lower (max 127 nodes) so I'm not even going
to look any further. Modbus might be useful but then I'm looking at
modbus-tcp/ip
and we're right back in the lan game.

I'm wondering if price differences between bare sensors and sensors that are
already integrated into a sensing apparatus are not large enough to totally
obliterate any cost effectiveness when comparing integrated sensors and
bare sensors + microcontroller. (Just 2 years ago I couldn't find a pressure
sensor for -15 - 0 psi levels for under $300 here in NA and $140 out of the
far-east - - - today same is for $150 or so in NA and down to the $25 range
out of the far-east. Those are some significant changes! (Now if you look at
offerings from Scheider - - - - they still want well over $400 each - - - -
so they have a good supported product - - - - doesn't mean that I can afford
to support Schneider on a 10:1 cost differential - - - - even if I did have the
money that I would be buying!!!!)

Looking for details to either show that what I've been finding is incorrect or
new information to point even further down the road.

TIA