:: Re: [DNG] Request for information -…
Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Didier Kryn
Fecha:  
A: dng
Asunto: Re: [DNG] Request for information - - re: networking - - round 2
Le 06/06/2023 à 14:24, Dan Purgert via Dng a écrit :
> 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?
>

    This seems to me the most sensible option, most certainly cheaper
than Ethernet.