On Jun 06, 2023, o1bigtenor via Dng wrote:
> Greetings
>
> I asked the first round question a few days ago and
> have received a whole pile of interesting information.
> (Seem to have spawned some other things too - - - lol.)
>
> Round 2 - - - the assumption has been that this is about
> linking actual systems together.
>
> I am going to ellide a number of different rounds of
> development to show how what I am trying to do is different
> than linking full sided computers together. (When I go
> looking for information on sensor networks and industrial
> control the contemporary 'gotta do it this way' seems to be
> 100% focused on wireless - - - when there is an electrically
> noisy environment - - - why? - - - its hard enough shielding
> cables never mind reading wireless information accurately
> AND well when you have pumps with vfds and other motors
> all contributing to electrical noise.)

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

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?


--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860