PIC ring buffer

As you know (though I'm !*$!ed if I can find the old thread...) we want to put a short ring buffer in the PICs where they store where to move next so there is no delay between the end of one move and the start of the next.

One problem is that Simon's code is wonderfully and elegantly symmetrical: if dx > dy for a move, the X controller is master and the Y is slave; contra contra. But this gives a problem when one move is finished and the master needs to stop being X and become Y - the buffer has somehow to switch between the two.

Proposal: any controller can be the master for any move. So, if X (say) is master and dx > dy, then X steps x a few times, then sends a slave pulse to Y to step y once, and so on. But if dy > dx X still sends out the sync signals - it just sends more to Y than it does "to itself". At the moment, I think the host tells X it's the master and Y it's the slave (or vice versa). 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). That way, X (or Y, but not both) can just pull things to do off its buffer and do them ad infinitum.

I don't think this'll be a big code change at all, and all the programs for all the axes will still be identical. But the host will be able to make many moves just by talking to one controller repeatedly, so that controller can buffer them up.

Is now the moment to add the extra sync line and have complete symmetry between X, Y and Z so the machine can move in any straight line in 3D?

>
> Is now the moment to add the extra sync line and
> have complete symmetry between X, Y and Z so the
> machine can move in any straight line in 3D?

yes. if you look in the electronics threads, we're starting on v1.3 of the universal board. this would be a fantastic time to add those sync lines. also, if you could weigh-in on the changes i'm suggesting, that would be fantastic.

Quoting RepRap Forum Mailer :

> yes. if you look in the electronics threads, we're starting on v1.3
> of the universal board. this would be a fantastic time to add those
> sync lines. also, if you could weigh-in on the changes i'm
> suggesting, that would be fantastic.

Lines are already there in the circuit and the connectors, so it's just
bits of wire...

Let me know when the final design is ready before its ordered, can you
- I'd like to check it over.

Best wishes

Adrian

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

Adrian,

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

Basically, I fear that debugging when you can't see half the network traffic would be quite "interesting"... any concrete ideas on how to avoid or overcome that and still allow PIC-to-PIC network traffic? [We could *maybe* allow "debug trace packets", so X can be put into a mode where it sends a packet P to Y and then sends a debug trace packet to the host that has all of P as its data payload?? But it feels pretty ugly.]

Of course, if you're going to do the firmware changes yourself and can debug it all anyway, in true mystic genius fashion, then my objection has little merit :-) But I'm to be useful at all in debugging / troubleshooting a network, I'd *really* prefer to be able to see *all* the traffic, rather than just part of it.

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!

Jonathan