Towards a unified specification for photographic motion control device networks

One thing I'd like to add in there is a minimum response time from nodes to masters, to prevent bus lock-up.  That is to say, consider the following situation:

A master is polling > 10 devices, one of the devices takes 5 seconds to respond - the master is held in a timing wait for 5 seconds during this period, and is unable to poll other devices.

The current implementation works around this by timing out (literally, less than 100mS for response or you're considered in a failed state), but this means that the node may push data back onto the bus at some point in the future, prospectively interrupting an ongoing communication.  By establishing a maximum response time, we get around some of the ModBus issues (where it is common for devices to spend a minute or more in formulating a response) by simply throttling any device that doesn't respond. 

We could still have the "bad data on the bus" issue, but with clear guidelines on timing, we could minimize this and encourage compliance for bad actors on the bus.
I think it's great that you bring up the different kinds of devices which could be on the bus - this is why I really want to stop short of specifying anything that's below the protocol header in the datagram, aside from a few key commands which would be necessary to identify devices on the bus (device identifier and device version).  It is important that the spec does strongly indicate these command so that any master or software designer is able to effectively determine if the device he is speaking with speaks a language he understands.

One of the areas I'm still wondering about is broadcast traffic:

• How best to limit broadcast traffic to specific audiences?
• Should a broadcast packet specify which device identifier and version its command should be processed by?
• Would it be necessary to define families of devices, which are distinct but understand a set of broadcast commands?
• For example: a 'start' command is useful for any device which executes an ongoing program based on pre-configured system parameters [e.g. nanomoco]
• Whether or not broadcast traffic should elicit a response?
• If a response is expected:
•  how do we sequence responses effectively such that they don't trample each other on the bus?
• There are a number of algorithms which could be applied here, but we could apply an ARP-like discovery protocol which, with a little ingenuity, could have real-time memory for the address table on the wire.  Or, with less ingenuity, we could implement a requirement on masters to poll before broadcasting - however, with a bus at 57.6k, we run into discovery issues much like those of IPv6, wherein the time required to poll the given address set exceeds the available time for activity.  (It's not nearly at the same magnitude, but one of the issues we ran into in network discovery on ipv6, is it took longer than the expected life of the universe to contact every address on the network within any reasonably sized mask, and wait for a timeout or response. In this case, monitoring arp traffic is highly useful.)
• how does the master differentiate one response from the next
• do we need to add device source headers to the response packets?
• If a response is not expected: how can we observe success or failure at the system level?
• It is possible to force the state of the common line C in such a manner that we could know whether every device that heard the command and understood it succeeded, but this is pretty hackish.

!c

Creating families of devices should be no big deal, the harder part is making a registry of them and keeping it up to date =)
If we look at the current packet format (very much simplified here):
break header | target address | code | dlen

We can augment it as follows for command packets:

break header | pkt type | target address | target family | code | dlen
and, for response packets:
break header | pkt type | target address | src address | code | dlen

With pkt type, we don't need a lot of values, so we could use the first 4 bits for packet type, and the last four for flags, should they be needed (like 'do not respond' =)  -- we don't need a source address on command packets unless we loosen up to allow more than one master on the bus (but it's really no big deal for masters to discard responses to commands they didn't initiate - this is basic programming activity, and the model libraries would take care of this already).

The resolving of order of response is trickier, but if we had some ARP ability, the master could indicate in the target address field (since the pkt code would already indicate 'broadcast') which device address is the highest it is speaking to... Then, the remainder of devices could use a timeout queue - if you see a higher address than you respond in 1mS, wait 500uS, otherwise go ahead and respond.  This still gets tricky and still requires some ARP-like ability.  I almost hesitate to say there shouldn't be a broadcast response, but that makes life a lot more difficult.  I'm not sure this is a problem we have today, but it would make network discovery in the client I'm working on a LOT easier.  (Vs. polling and timing out ~65k addresses, which takes about 650 seconds if we allow a 10mS timeout waiting for responses, or 65 seconds with a 1ms timeout.) 

Life would be great if we pulled address space back to 8-bits. That means complete network polling could be done in 1/4 of a second per link in the star.  We'd likely have network address crossover, which isn't as big of a deal as it sounds in star topologies.  (The current client libraries I've written identify devices by their network port AND their address.)  Cutting it back to 8-bits would also mean that the new response format would only add one byte to the existing packet length vs. three.

Now, as for capabilities of the atmeg328p - it all depends on what one is doing, and how one is doing it. =)  There's a heck of a lot going on in that 15k (and only 500 bytes of pre-allocated memory!), it could've been done using all of the 32k, but with prudence and optimization, we can always do more than we imagined.  Of course, some devices will obviously require more oomph, but I think a single camera/motor axis is well-served with a 328p, until one wants to go really high speed and needs more CPU time to exceed the steps-per-second bottleneck.  (Assuming one wants to run high voltage, high current =)  As they say, "if we put more space, people will just use it." *grin*

In the near horizon, there're 16- and 32-bit processors worth considering, which each provide more memory and more cpu time (in addition to faster arithmetic).  But, I don't think it's a today problem =)

!c

Chris,

1) My goal is to target a standard which hardware developers will be happy to include in their products such that DIY users can then have a consistent interface with which to interact with these products when creating their own systems. 

2) Hopefully very little via the abstraction layer

3) An RS-485 bus and something that can read data off of it
4) Backwards-compatibility is desired, but if the device lacked some hardware to speak to other devices in a multi-node bus, then it would be very difficult to support it in the same standard. 

I don't think most users would think anything more of the standard than the standard they use to communicate between an arduino and a PC for example.  One really doesn't consider what it takes to send a proper signal down to the USB port, and then how to properly time the signals between sending and receiving to transmit the right data in the right way, most of the time.

!c

Addressing a couple of points brought up:

--- Why the need for replies?

Replies serve several functions, the first is an assurance of receipt.  In the most simple of systems, one can operate generally by "sending and forgetting," and certainly for some devices the users' end result may be met even if a device loses one or two commands, but a failure to receive a move command on an axis that is expected to position the camera in relation to another axis can result in destruction of property - if the user expected the camera to be clear of an obstacle.  A failure to receive a change of direction, or a stop command can result in damage as well.  A well-designed system would have a feature to put the entire setup into a safe mode should a critical action not be taken.

A second key function is to query devices about information which they may best be aware of.  Take, for example, I ask something to move 5,000 steps - as a remote observer, I can call up the other and ask "have you taken all of those steps yet? no? I'll come back later." without this ability, I can only presume that my instructions were dutifully followed.  One presumes that everything is working fine, until it's evident that it isn't.  Over time, the amount of data that must remain in one device's "head" to recall what the possible state is of a network performing a complex activity will quickly saturate its capacity unless it has quite a bit of memory.  By spreading that memory through the network, rather than centralizing it we could effectively use less-expensive devices.  Additionally, there are many use-cases for software to poll a series of devices and inquire about their current state for display to the user.

Having support for this feature will allow us to enable people to build well-designed systems for a wide variety of use-cases, and this is why I suggest it be part of this standard.

--- Why the complicated packet structure?

It's not a question of "if," but "when" a byte is read out of sequence.  A device starts running while another device is receiving a command.  One of the arguments to the other device's command has the same value as a command for this device.  The newly-started device has no way of determining whether or not that really is a command intended for it.
Consider also, that a multi-byte command is sent, and the command value byte is lost in transmission - the argument now becomes the command.
The proposed break header seeks to resolve this by indicating a sequence of bytes, which shall be defined as illegal in any other use of this protocol*.  In such a manner, any device waiting a command may know within 5 bytes of data, at a maximum whether or not they are at the start, or in the middle of a command and this ambiguity is cleared.
Having cleared this ambiguity, we can move on to another aspect of this packet structure: addressing.  Once we know that a device address is at a specific location in the packet, and we know for sure that we're at this location, we can now disambiguate the target of a command reliably, and easily ignore things that aren't meant for us - even if we don't know the language that is being spoken to the other device.
The data length is important, as data can be missed from the middle or end of the chain of bytes as well. You'll find a data length of some sort in pretty much every algorithm ever written to take data from one source to the next.  (Even if hidden from you in higher-level languages.)  Without knowing the expected length of a record of data, we have no way of knowing when to stop - except to get a flow sequence that would inform us.  But, such flow sequences do not tell us whether we missed data we should have been expecting.  In this manner, any device may know for certain whether or not all expected bytes were received. 

Of course, we can't know for sure that we received each byte as it was expected to be received, but we at least know whether or not data was left on the floor.

* - that's why the whole thing about breaking up 4byte values with a break character, to ensure that 0|0|0|0|0|255 is not a valid sequence otherwise.

--- How can this be made easy enough to use?

In general, this is easily abstracted from any consumer.  A simple object-oriented interface can be provided to do things as simply as asking simple questions "send a command," "did I receive a command recently?"

If you'd like to talk about interaction models, I'd love to.

!c

One thing I'd like to cover as well, is about the reference implementation (i.e. the libraries), and how they can encourage vendors to produce devices which any DIY person or hacker can ensure that they know how to speak to, while still having the ability to add mocobus control to an existing proprietary application without fear of having to share code for an existing commercial application that is not open-source.  I.e., encouraging adoption of the mocobus standard to software developers that currently sell proprietary products.
We can, through a simple licensing scheme, enforce openness for devices on the bus, while allowing proprietary control interfaces running on a PC, etc.  Here's my thought on it:

- Device-level libraries released under GPLv3 terms
- Client-level libraries released under LGPLv3 terms, with shared library targets

This would mean that anyone who embeds the device-level C++ libraries, or any derivative of them, into a device must share the code for their device, if the device uses a single memory space for its code.  If it supports the concept of multiple distinct memory spaces for running programs (such as an embedded linux device), the vendor only must share the part which embeds the device-level libraries, such as the bus communication elements.  This ensures that anyone receiving such a device may know the protocol it speaks.

The client-level libraries being LGPL, however, would mean the only thing that has to be shared is any change to the client libraries, allowing existing software vendors to quickly add support for mocobus devices without fear of having to open-source their entire application. 

My take on it is that without some license-level enforcement on the device end, if the mocobus were to become popular, we would see a plethora of devices which are completely closed being sold to live on these buses, which completely eliminates the value of this standard for the DIY/hacker crowd.  However, any requirement to fully open-source a client application when you use the client libraries would mean most software vendors would not add support via the client libraries - and since rolling one's own re-implementation of these libraries would be cumbersome, it would reduce adoption amongst software vendors, thereby reducing the number of devices developed.

Thoughts?

!c