On 5/4/2017 10:30 PM, Robert Wessel wrote:
> On Thu, 4 May 2017 13:17:18 -0700, Don Y <blockedofcourse@foo.invalid>
> wrote:
>
>> On 5/4/2017 12:53 PM, Robert Wessel wrote:
>>> On Thu, 4 May 2017 10:52:40 -0700, Don Y <blockedofcourse@foo.invalid>
>>> wrote:
>>>
>>>> I'd like to come up with a scheme that I could apply to a variety of
>>>> similarly "open ended" network configurations -- that have very
>>>> different physical characteristics (e.g., a 10 ft long chain
>>>> and a 300 ft long chain -- trading data rate for network size)
>>>
>>> At some point you need to worry about reinventing Ethernet. And many
>>> MCU's are available with Ethernet for a very small incremental cost.
>>> Although perhaps not at the very low end. A huge advantage is that
>>> you can punt much of the infrastructure to the customer ("It's
>>> Ethernet, deal with it.").
>>
>> Depends on the nature of the "messages" being passed -- their
>> content and frequency.
>>
>> E.g., would you spring for the cost of a NIC, MCU capable
>> of supporting a TCP (or even just UDP) "stack" -- just to
>> command individual hammer drivers on/off at some sub-sonic rate?
>
> I'm not sure I can answer that definitively, even for myself, but as a
> first order approximation, if it's a separate box, the first choice of
> interconnect should be Ethernet or one of its wireless cousins (WiFi,
> Bluetooth), if a wireless connection is required. And UDP+IP does not
> impose much of a burden, even on a OS-less MCU.
Why the "separate box" criteria? Should car manufacturers replace
CAN with Ethernet? Should PC manufacturers use ethernet to connect
their floppy disk drive to the CPU (on the other end of the
motherboard)? See my pinball machine example, elsewhere, this thread.
Should the pushbutton controls for my garage door opener use ethernet
frames to pass "open" and "close" commands to the actuator head?
Or, individual keystrokes from the external keypad to the controller
in the actuator?
> Which is not to say that there aren't going to be exceptions. But I'm
> pretty sure things are at the point where you need to justify *not*
> using Ethernet on an external connection.
Should my doorbell use an ethernet connection? My thermostat to
talk to the furnace?
As I said, it depends on the nature of the data ("messages") being
exchanged and their frequency. My CCTV cameras are IP based -- because
they move a fair bit of data, continuously, and I need (choose) a bit of
processing power AT the camera. It's easier to run CAT5 with a PoE
injector than to run a separate power connection and coaxial video
cable back to <something>. Esp if I want to be able to add more
cameras without having to upgrade an N-port "camera card" in a PC...
(N = 4 or 8)
>> OTOH, running a bunch of wires from *one* set of hammer drivers
>> (accessed "in parallel" from an MCU port) out to a bunch of
>> solenoids dramatically changes how you wire them, how you
>> deal with expansion, etc.
>
> Direct drive stuff is one obvious exception. But you're asking about
> devices you're sending packets to.
Why can't I send packets to solenoids? Again, see the pinball example.
One wall of the house is glass. Blinds on each window. Do I run
ethernet to each window? Or, do I install a "blind controller"
<somewhere> and pass messages over a low speed serial interface
to tiny motes mounted on the motors for each of the individual
blinds:
3OPEN
causes the 4th motor "from here" -- "external" to "here" -- to open
while:
2CLOSE
causes the 3rd motor to close.
>> With Ethernet, you'd have to ensure each node had a unique address
>> so you could distribute the message to all and know that the
>> right node acted on it -- AND, that no OTHER node acted on it!
>
> Any device claiming to be Ethernet should have the process for
> attaching a unique MAC address well established. Use the MAC number
> as the device serial number (pre-pend some of your own digits for
> sanity, on the sticker you attach to the outside of the device).
But, then they aren't IDENTICAL devices!
I can rephrase my problem and claim I'm using MCU's with serial
numbers laser etched into their silicon from the factory. Now,
I have a means of uniquely identifying each device -- even if I
talk to them using CAN or any other transport layer. No need
to rely on wiring "position" to identify a device!
Remove the MAC address and solve the problem with ethernet.
I.e., you have to ADD the MAC address back in -- or, some other
"unique identifier".
Apples-apples.
>> By interposing each node in a serial chain, a node need not
>> care about it's "address" -- it's *implied* (when the ID byte
>> is 0, the message is for you. Otherwise, its for someone
>> DOWNSTREAM from you). So, you can produce identical devices
>> and still treat them as individually unique.
>>
>> Of course, this makes binding addresses to physical nodes
>> a separate issue: you either carefully document the
>> physical (electrical?) order of the nodes at deployment
>> *or* introduce a "configuration step" in which you
>> empirically derive the (address,node) mapping.
>>
>> "I just activated node 1. What do you see as having
>> changed in the field? OK, I'll write that down. Now
>> proceeding to node 2..."
>>
>> This would be tedious *if* the field configuration changed,
>> often. But, if it is largely static and only updated as
>> needs evolve (or, in response to failures), then its almost
>> assumed that some degree of manual intervention will be
>> required (i.e., someone has to swap out the defective node
>> or splice a new node into the chain <somewhere> -- which
>> may not be at the *end*)
>
> The implied address approach doesn't really fix the problem. Sure
> someone attached *something* to port 7 of controller 13, but did they
> do that correctly?
Sure, someone bought a box of 50 model 123 Ethernet valve controllers.
And, I can now "see" the controller that they just cabled to my system.
Did they attach the correct device? Did they wire it to the correct
valve? Or, is it wired to a light bulb, instead?
Using a different transport protocol doesn't tell you anything
about the outside world.
> IOW, is that water valve on 13/7 actually attached
> to the cold supply to the motor cooling system, or did someone attach
> it to the hot water line to the reactor heater?
Is the water valve on 12:34:56:78:9A:BC port 7 actually attached
to the cold supply to the motor cooling system, or did someone attach
it to the hot water line to the reactor heater?
Or, to the hand towel dispenser in the men's room?
> Or is what they
> plugged into 13/7 actually attach the electrical power switch for the
> ammonia pump motor? Or heck, maybe it *is* an actual accelerometer,
> of the type you wanted, but did they plug the X axis one into 13/7
> like the should have, or did they get the Y or Z axis one?
How is any of this made BETTER or mode robust/reliable by using Ethernet?
> There are also diagnostic advantages to being able see the entire
> network from one place.
Why can't I see the daisy-chained devices?
> It also offers some opportunities for
> redundancy (controller 13 appears to be unresponsive, have the
> monitoring system send a predefined safeing command to all the devices
> 13 was supposed to be controlling).
How do you *talk* to those devices if the controller that handles them
is unresponsive? Why does ethernet to an unresponsive controller
give you that ability but daisy-chain to an unresponsive controller
doesn't?
That's a separate design issue. And, you have to decide how much you
want to invest in your solution to address those conditions.
If I sense a water leak in the house, I have no way of knowing
WHERE it is. Perhaps a toilet is "running on". Or, maybe a
hose to the washing machine has ruptured. Or, someone left a
faucet partially open. (all have happened, here)
In my case, I can shut off water TO THE HOUSE. But, not to the
toilet, individually. Or, the faucet. So, the magnitude of the
leak weighs into how I attempt to protect the house. If it's a slow
leak, chances are, its a toilet running on or a faucet that wasn't
turned off completely. Send a message to the occupants -- even if
they are away on vacation. If no response, maybe let the leak
continue (running up the water bill for this month) *or* shut off
the house supply -- until you *need* to turn it back on (e.g., to
water the yard).
If I wanted more options in handling this "failure", I'd spend
more resources on better isolating the source of the leak AND
limiting the damage that it could potentially cause.
If I want to be able to turn off ALL the solenoids because I
suspect one solenoid controller may be crashed with its
solenoid engaged (which could cause it to burn up), then I'd
add a disconnect in the power feed to the "solenoid bus".
Or, a special disconnect for just that one solenoid.
> If you need higher levels of
> redundancy, having two Ethernet ports on devices is also easy, and
> having two parallel sets of Ethernet switches, with a few
> interconnects, leaves you with two links to any device.
So, the lights on the pinball machine's playfield should have *two*
ethernet connections? The irrigation valves should similarly have two?
> Certainly the setup and verification procedures will be *different*. I
> see modest-to-large advantages in a fair number of situations for the
> Ethernet approach, and small-to-modest advantages for the custom
> approach in (fewer others), and a majority where it's a wash.
I'd be interested in the modest-to-large advantages you see in
controlling individual irrigation valves. Or, lights/actuators on
a pinball machine playfield. Or, the lighted pushbuttons on a
large broadcast studio video mixer:
<https://www.shutterstock.com/video/clip-12972671-stock-footage-broadcast-tv-studio-production-vision-switcher-broadcast-video-mixer-pan-right.html>
(Do you really think there is one *giant* PCB hiding behind all of those
LPB's and a gazillion "output drivers" wired, in parallel, to service
all those lamps/buttons? Or, do you think, perhaps, they are organized
in IDENTICAL subassemblies hiding behind the top cover and wired
together using some sort of message passing bus? Do you think it is
Ethernet based? Think about what the messages being passed around,
there, are likely to contain.)