> -----Original Message-----
> From: N [mailto:nicklas.karlsso...@gmail.com]
> Sent: August-19-20 1:46 PM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] OT: Synchronised motion using RS485/CAN bus motors
>
> > The usual technical solution for exact synchronization where commands must
> > go over a shared media is to time-tag the commands with the time when the
> > command is to be executed then send the commend in advance of that time.
> > On a fast bus like CAN you only have to send the command a few
> > milliseconds in advance. But on a slow channel such as a radio link to a
> > rover on Mars, they send commands hours or a day in advance.
>
> In CANopen over a CAN bus standard method a sync message is used for this
> purpose. Periodic PDOs are sent anywhere within
> communication period and started to be used then sync message is received,
> usually COB-ID 0x80 but may be configured to other.
>
> > On CAN you can take advantage of the fact that all devices read the bus at
> > the same time. Each reader decides what information it wants to read and
> > ignore the rest so a time-sync heartbeat could be implemented if the nodes
> > all needed to be time synchonized. So on CAN if it were needed I'd invent
> > a protocol that did something like this: "motor A, On the mark, you are to
> > move to X", "motor B, On the mark, you are to move to Y", "MARK".
>
> Sync is used for this purpose. The fact that all devices read the bus at the
> same time may have some advantages, no crossing of
> messages may have some advantages then things should be agreed upon.
>
> > For a robot on Mars, I would send a table of instructions where the first
> > column is the time to execute and the second column is the instruction
> > itself. I would send the table then have the rover read it back to me to
> > verify. Then at some later time, the wheels would move and so on.
>
> Read something in the CANopen about receive FIFO but are uncertain about
> possibility to verify if properly received, guess simplest
> would be if receiver make complain if expected message not received in time
> so it could be resent and in such case some missing
> messages could be expect without loss of any functionality. It will also work
> for coordinated motion but add some delay but if path is
> known beforehand this is not a problem. FIFO will work for CNC path but EDM
> will be worse.
>
> Nnicklas Karlsson
CAN is a broadcast network using the "one to many" model and the associated
high level protocols understand this. I've been paid well to solve the "roll
your own" protocols that don't quite understand the concept.
So a CANopen SDO message is a request for information from a specific node #
that is contained in the identifier. If the target node doesn't respond in a
particular amount of time the sender can ask again or mark that node as
possibly having a problem. That's an even higher level application issue.
At the lowest level the sender may well have had the message ACK'd by a node.
Just perhaps not the node in question. That's why you never ever ever send
'toggle' messages over CAN bus.
The PDO messages are configured by the end user to contain a number of
different Object Dictionary entries. These are also launch and forget.
There's no hand shaking involved in these. So although you might send a PDO
with XYZ and A values (16 bits each) the XY and A might well have received it
but the Z missed it.
That can happen in that noisy environment mentioned previously where Z has gone
into what is called the Error Passive State. At this point if noise corrupts a
message for Z but not for the others then it can't mark it with an ERROR FLAG
and so the message won't be resent. Now Z is out of sync with the rest.
Many years ago in collaboration with one of the semiconductor manufacturers I
designed and we built what was called a CAN Bus Message Marker. It used a
custom CAN engine inside an FPGA to listen for particular IDs and then mark
those messages n times with an ERROR flag. It was a deterministic method of
moving a single CAN receiver and/or transmitter into Error Warning, Error
Passive and Bus Off.
The point of the tool was to verify that the supplier of the CAN based
equipment was handling low level CAN errors correctly. That was in 1995.
John Dammeyer
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
