Re: PIC ring buffer (and SNAP traffic visibility)

Quoting RepRap Forum Mailer :

>> We'd also have to change that so that the host still tells X it's
>> the master,
>> but then _X_ tells Y it's the slave (the ring should make that
>> trivial to do).
>
> It's doable, but it might be simpler if X tells the host "I'm done
> being master" (in the same packet it tells the host that move is
> completed?) , and then the host tells Y to be master? That way the
> host is in some sense more "in control" of the action, and
> (significantly!) CommDebug will show all that action for
> troubleshooting. If we have PICs talking among themselves, as you
> propose, we'll need a "network monitor" board that sniffs every TX
> output at high impedance, or something, just so we can get a network
> traffic capture of all traffic...

The problem with that is this situation: X is master and is drawing
line 1. It also has line 2 buffered internally waiting to go. X has
told Y that Y is the slave. X finishes line 1. It queues up a
"finished line 1" packet to the host and immediately starts drawing
line 2 with Y still the slave as before. No traffic at all has to go
round the ring between the end of line 1 and the start of line 2, and
that is the ideal we want to achieve.

The "finished line 1" signal ambles round the ring in a leisurely
fashion as line 2 is being drawn, and the host then sends a "draw line
3" packet to X, the transmission speed of which is equally
non-time-critical.

The alternative (and this is probably even better) would be that when
the machine is initialised the host tells X it's the master and Y it's
the slave until further notice. I think in practice, though any PIC
could become master in principle, the host would always tell X to be
master for an entire run. That way there is no inter-PIC comms (which,
as you quite rightly say, would be a real pain to debug).

> BTW, this change will probably make Eric M. very happy, since it
> appears that the delays between segments are a major issue for his
> machine at the moment!

Yes - Ed's stalled too on refining the parameters for Darwin, as fixing
this problem will make all lines a lot smoother, and - until that
happens - there's no point in trying to find maximum reliable plotting
speeds and the like.

Best wishes

Adrian

Dr Adrian Bowyer
[staff.bath.ac.uk]
[reprap.org]
_______________________________________________
Developers mailing list
Developers@reprap.org
[reprap.org]

Adrian writes,

> The alternative (and this is probably even better) would be that when
> the machine is initialised the host tells X it's the master and Y it's
> the slave until further notice. I think in practice, though any PIC
> could become master in principle, the host would always tell X to be
> master for an entire run. That way there is no inter-PIC comms (which,
> as you quite rightly say, would be a real pain to debug).

I think this is the way to go. Speed *and* "debug-ability" :-)

Not quite incidentally: have we established that the delays now being seen are definitely a result of the time it takes packets to get around the ring? Given 8 byte packets (64 bits) and 19200bps, we would theoretically be able to get 19200/64 = 300 packets per second across one link; that's a 3.3mS delay, which should be very tolerable (20mS total round trip delay for 5 boards and a host). I'm therefore speculating that there is a larger delay in each PIC forwarding packets not destined for its own SNAP address? Have we quantified that "PIC forwarding delay" time, and looked at any possibility of reducing it?

Jonathan

This is probably a stupid question, but wouldn't it be more efficient to use a star network instead of a ring? That way the message would go directly to the pic in question and back instead of doing the rounds of all the other pics on the ring. It would seem, anyway.