Re: [Emc-users] OT: Synchronised motion using RS485/CAN bus motors

[N]

> > > The problem with relative is it turns again into the equivalent of a 
> > > toggle message.  Miss one and your position is wrong.  So I would
> > never do that.
> > 
> > Agree, almost. It is in most cases possible to use a 16 bit value and keep 
> > track of the overflows provided it does not move to many
> > counts in between each time. It is not uncommon Micro controller have 16 
> > bit encoder counter so software need to keep track of
> > overflows, not many rows of code but it must be there and work perfect.
> 
> I disagree.  What happens in the processor with encoder and motion output is 
> deterministic and you can use smaller counters and overflow interrupts etc.  
> It's tightly coupled.
> 
> A CAN message sent and ACK'd by _a_ node on the bus will _not_ be 
> retransmitted.  So the target motor that missed it will not know that it 
> missed it nor will the sender.  This is a fundamental issue with the CAN 
> protocol which is why toggle messages are a bad idea.
> 
> So PDO messages in CANopen are useful for information but not for commands 
> unless the commands are absolute.

Agree.

> For example a PDO that contains a SWITCH ON message that is missed and then a 
> short time later contains SWITCH OFF doesn't change the target node.  Just 
> the ON/OFF pulse was missed.  And that's a different problem.

Agree and had some discussions about it sometimes. Sending commands and there 
will be state machines that must be kept in sync. In CiA402 for servo motors 
there are some state machine for control-/status-word and I have not been able 
to put together current state from statusworld, it had been good if possible 
because if states come out of sync something will not work as expected, maybe 
it is possible from current sent controlword and statusword together but I have 
not been able to solve it perfect.

> One could send relative distances to a motor and then also use PDOs to report 
> position/velocity but what does the sender do if the position isn't yet what 
> it expected?  Could be any number or reasons why it's not there yet.  
> Mechanical load, periodic messages that are more often than the rate of 
> change of the motor.

Sending encoder value is an absolute distance but it may overflow so it must be 
sent often enough and it might be often enough even if a limited number of 
messages are missed.


Nicklas Karlsson


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] OT: Synchronised motion using RS485/CAN bus motors

[N]

> The way to handle things like overflows in real-world robots is to use
> real-wold units in the data.  The lower level controls on each motor does
> the conversion.   So the motor command is in radians per second and is in
> floating-point.   The encoder reports its angle in radians, in
> floating-point.

No matter what units are used if the number overflow software must keep track 
of it.

To use real world units you must have numbers with decimal point, in CANopen 
values are sent as integers, there are extra entries, scaling factors for units 
used for the values received/sent. It is also possible to send values as 
floating point and this datatype is named real in CANopen but this is less 
common. To use same unit as encoder happen to have have advantage no resolution 
is lost due to rounding.


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] OT: Synchronised motion using RS485/CAN bus motors

[Chris Albertson]

The way to handle things like overflows in real-world robots is to use
real-wold units in the data.  The lower level controls on each motor does
the conversion.   So the motor command is in radians per second and is in
floating-point.   The encoder reports its angle in radians, in
floating-point.

This allows for easier software reuse and importantly makes it easy to swap
in or out real hardware or simulation be redirecting were the data flows
to.   Maybe this "wastes bits" but development time and flexibility is what
matters.  Bits are cheap.

You can examine most of the code used in real systems pretty much
everything is on github these days.

On Sat, Aug 22, 2020 at 10:03 AM N  wrote:

> > > > I thought of one bus per leg, but the Raspberry Pi only supports two
> CAN
> > > > busses and I think this is a common limitation not just on the Pi.
>But
> > > > I think we just figured out that one CAD FD can do 12 motors at 20
> Hz.
> > >
> > > It is more or less possible to configure mapping of dictionary into
> PDOs sent in real so I expect values for more than one servo motor
> > > could be sent in each message, maybe a few. If driver use internal
> position control loop you could send back feedback at a lower rate,
> > > looking into standard for CANopen lower numbered PDO have higher
> priority and for each PDO number TPDO have higher priority
> > > than RPDO while it may make sense to do the opposite if possible to
> send back feedback at a lower rate.
> > >
> > >
> > > Nicklas Karlsson
> > >
> > I think it all depends on what a motor requires.
> > One byte for Enable/Direction/MotionType
> > Four bytes for signed position
> > Two bytes for Current/Torque/Velocity value?
> > That leaves one byte Maybe a max Current Limit value?
>
> In Canopen standard there is. A 16 bit control word index 6040h usually
> mapped to PDO sent periodically. A signed 32 bit position value 607Ah
> usually mapped to PDO sent periodically. It is possible to map other
> values. It might be possible to run drive without mapping to a periodic PDO
> or a PDO sent more seldom but but are not certain it is allowed according
> to standard and even if it is it might not work with the drive. Data sent
> is normally at least 48 bit and payload is 64 bit so there will values for
> one motor only in each message CAN-FD allow longer messages so here it
> might be possible to squeeze in values for more than one drive in each
> message. Then drives send back feedback each drive however neeed to send
> one message but if drive have internal feedback and does not make complain,
> bugs or other problems these values could be sent back more seldom.
>
> > A reply with 6 bytes might be position (4 bytes) and velocity(2 bytes)
>
> In canopen standard there is. A 16 status word index 6041h and 32 bit
> signed integer position actual value which I think is the value usually
> sent back but are not totally certain.
>
> > Both of those messages can't easily be packed into one shared with a
> second motor.  Not without going to perhaps signed relative position and
> signed velocity.
>
> You are right they can't in CAN but maybe in CAN-FD but only for values
> sent to drives and not feedback.
>
> > The problem with relative is it turns again into the equivalent of a
> toggle message.  Miss one and your position is wrong.  So I would never do
> that.
>
> Agree, almost. It is in most cases possible to use a 16 bit value and keep
> track of the overflows provided it does not move to many counts in between
> each time. It is not uncommon Micro controller have 16 bit encoder counter
> so software need to keep track of overflows, not many rows of code but it
> must be there and work perfect.
>
>
> Nicklas Karlsson
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>


-- 

Chris Albertson
Redondo Beach, California

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] OT: Synchronised motion using RS485/CAN bus motors

[John Dammeyer]

 
> You are right they can't in CAN but maybe in CAN-FD but only for values sent 
> to drives and not feedback.

CAN-FD is still in it's infancy.  The support is growing but it's not 
compatible with BASIC/FULL CAN on the bus at the same time so it's all or 
nothing.   

> 
> > The problem with relative is it turns again into the equivalent of a toggle 
> > message.  Miss one and your position is wrong.  So I would
> never do that.
> 
> Agree, almost. It is in most cases possible to use a 16 bit value and keep 
> track of the overflows provided it does not move to many
> counts in between each time. It is not uncommon Micro controller have 16 bit 
> encoder counter so software need to keep track of
> overflows, not many rows of code but it must be there and work perfect.

I disagree.  What happens in the processor with encoder and motion output is 
deterministic and you can use smaller counters and overflow interrupts etc.  
It's tightly coupled.

A CAN message sent and ACK'd by _a_ node on the bus will _not_ be 
retransmitted.  So the target motor that missed it will not know that it missed 
it nor will the sender.  This is a fundamental issue with the CAN protocol 
which is why toggle messages are a bad idea.

So PDO messages in CANopen are useful for information but not for commands 
unless the commands are absolute.

For example a PDO that contains a SWITCH ON message that is missed and then a 
short time later contains SWITCH OFF doesn't change the target node.  Just the 
ON/OFF pulse was missed.  And that's a different problem. 

One could send relative distances to a motor and then also use PDOs to report 
position/velocity but what does the sender do if the position isn't yet what it 
expected?  Could be any number or reasons why it's not there yet.  Mechanical 
load, periodic messages that are more often than the rate of change of the 
motor.

CAN as a medium is great for positioning or even detecting reported position 
and when found told to decelerate.  

John Dammeyer


> 
> 
> Nicklas Karlsson
> 
> 
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] OT: Synchronised motion using RS485/CAN bus motors

[N]

> > > I thought of one bus per leg, but the Raspberry Pi only supports two CAN
> > > busses and I think this is a common limitation not just on the Pi. But
> > > I think we just figured out that one CAD FD can do 12 motors at 20 Hz.
> > 
> > It is more or less possible to configure mapping of dictionary into PDOs 
> > sent in real so I expect values for more than one servo motor
> > could be sent in each message, maybe a few. If driver use internal position 
> > control loop you could send back feedback at a lower rate,
> > looking into standard for CANopen lower numbered PDO have higher priority 
> > and for each PDO number TPDO have higher priority
> > than RPDO while it may make sense to do the opposite if possible to send 
> > back feedback at a lower rate.
> > 
> > 
> > Nicklas Karlsson
> > 
> I think it all depends on what a motor requires. 
> One byte for Enable/Direction/MotionType
> Four bytes for signed position
> Two bytes for Current/Torque/Velocity value?
> That leaves one byte Maybe a max Current Limit value?

In Canopen standard there is. A 16 bit control word index 6040h usually mapped 
to PDO sent periodically. A signed 32 bit position value 607Ah usually mapped 
to PDO sent periodically. It is possible to map other values. It might be 
possible to run drive without mapping to a periodic PDO or a PDO sent more 
seldom but but are not certain it is allowed according to standard and even if 
it is it might not work with the drive. Data sent is normally at least 48 bit 
and payload is 64 bit so there will values for one motor only in each message 
CAN-FD allow longer messages so here it might be possible to squeeze in values 
for more than one drive in each message. Then drives send back feedback each 
drive however neeed to send one message but if drive have internal feedback and 
does not make complain, bugs or other problems these values could be sent back 
more seldom.

> A reply with 6 bytes might be position (4 bytes) and velocity(2 bytes)

In canopen standard there is. A 16 status word index 6041h and 32 bit signed 
integer position actual value which I think is the value usually sent back but 
are not totally certain.

> Both of those messages can't easily be packed into one shared with a second 
> motor.  Not without going to perhaps signed relative position and signed 
> velocity.

You are right they can't in CAN but maybe in CAN-FD but only for values sent to 
drives and not feedback.

> The problem with relative is it turns again into the equivalent of a toggle 
> message.  Miss one and your position is wrong.  So I would never do that.

Agree, almost. It is in most cases possible to use a 16 bit value and keep 
track of the overflows provided it does not move to many counts in between each 
time. It is not uncommon Micro controller have 16 bit encoder counter so 
software need to keep track of overflows, not many rows of code but it must be 
there and work perfect.


Nicklas Karlsson


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] OT: Synchronised motion using RS485/CAN bus motors

[John Dammeyer]

> -Original Message-
> From: N [mailto:nicklas.karlsso...@gmail.com]
> Sent: August-22-20 5:28 AM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] OT: Synchronised motion using RS485/CAN bus motors
> 
> > I thought of one bus per leg, but the Raspberry Pi only supports two CAN
> > busses and I think this is a common limitation not just on the Pi. But
> > I think we just figured out that one CAD FD can do 12 motors at 20 Hz.
> 
> It is more or less possible to configure mapping of dictionary into PDOs sent 
> in real so I expect values for more than one servo motor
> could be sent in each message, maybe a few. If driver use internal position 
> control loop you could send back feedback at a lower rate,
> looking into standard for CANopen lower numbered PDO have higher priority and 
> for each PDO number TPDO have higher priority
> than RPDO while it may make sense to do the opposite if possible to send back 
> feedback at a lower rate.
> 
> 
> Nicklas Karlsson
> 
I think it all depends on what a motor requires. 
One byte for Enable/Direction/MotionType
Four bytes for signed position
Two bytes for Current/Torque/Velocity value?
That leaves one byte Maybe a max Current Limit value?

A reply with 6 bytes might be position (4 bytes) and velocity(2 bytes)

Both of those messages can't easily be packed into one shared with a second 
motor.  Not without going to perhaps signed relative position and signed 
velocity.

The problem with relative is it turns again into the equivalent of a toggle 
message.  Miss one and your position is wrong.  So I would never do that.

John


 
> 
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] OT: Synchronised motion using RS485/CAN bus motors

[N]

> I thought of one bus per leg, but the Raspberry Pi only supports two CAN
> busses and I think this is a common limitation not just on the Pi. But
> I think we just figured out that one CAD FD can do 12 motors at 20 Hz.

It is more or less possible to configure mapping of dictionary into PDOs sent 
in real so I expect values for more than one servo motor could be sent in each 
message, maybe a few. If driver use internal position control loop you could 
send back feedback at a lower rate, looking into standard for CANopen lower 
numbered PDO have higher priority and for each PDO number TPDO have higher 
priority than RPDO while it may make sense to do the opposite if possible to 
send back feedback at a lower rate.


Nicklas Karlsson


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] OT: Synchronised motion using RS485/CAN bus motors

[Chris Albertson]

I thought of one bus per leg, but the Raspberry Pi only supports two CAN
busses and I think this is a common limitation not just on the Pi. But
I think we just figured out that one CAD FD can do 12 motors at 20 Hz.


At any rate, I'm not going to be able to afford all those motors.  12 of
them at $300 each adds up.

On Fri, Aug 21, 2020 at 6:49 PM andy pugh  wrote:

> On Sat, 22 Aug 2020 at 02:22, Chris Albertson 
> wrote:
>
> > One other easy trick is to have two CAN busses one for left and the other
> > for right.
>
> One bus per leg makes sense to me. The intra-leg coupling needs to be
> a bit tighter than the inter-leg
>
> --
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is
> designed for the especial use of mechanical geniuses, daredevils and
> lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1912
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>


-- 

Chris Albertson
Redondo Beach, California

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] OT: Synchronised motion using RS485/CAN bus motors

[andy pugh]

On Sat, 22 Aug 2020 at 02:22, Chris Albertson  wrote:

> One other easy trick is to have two CAN busses one for left and the other
> for right.

One bus per leg makes sense to me. The intra-leg coupling needs to be
a bit tighter than the inter-leg

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] OT: Synchronised motion using RS485/CAN bus motors

[Chris Albertson]

I don't think it actually runs that fast, I think you calculated the
maximum rate possible with one motor on the bus.

More reasonable is to assume 20 updates per second and 12 motors on the
bus.  This rate could work.   I looked for 10 minutes through the Chetha
code in Gethub and foud they do update all the motors every "dt" but I
could not find where dt is set. But itis likely about 0.05 second.


One other easy trick is to have two CAN busses one for left and the other
for right.   You would never need to send data from one leg to the other so
this could work.

On Fri, Aug 21, 2020 at 4:45 PM Frank Tkalcevic 
wrote:

> I was looking in more detail at the MIT Cheetah and found this page -
>
> https://www.robotdigg.com/product/1667/MIT-Robot-Dog-high-torque-Joint-Motor
> -or-DD-Motor
> <https://www.robotdigg.com/product/1667/MIT-Robot-Dog-high-torque-Joint-Motor-or-DD-Motor>
>
> It says that each motor takes an 8 byte payload to drive a motor, and that
> motor then replies with a 6 byte packet.  After you add the CAN headers and
> trailers that is a total of 200 bits, best case, or about 416 updates per
> second for 12 motors on 1MHz bus.
>
> I was expecting the update rate to be a lot lower than that (I should have
> done the math).
>
>
> -Original Message-
> From: N [mailto:nicklas.karlsso...@gmail.com]
> Sent: Saturday, 22 August 2020 5:34 AM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] OT: Synchronised motion using RS485/CAN bus motors
>
> > ...
> > 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. ...
>
> Yes all devices need to read bus within the time it take to send one bit
> because of the arbitration used to send the message with highest priority
> first. With CAN-FD speed is increased after address is sent so that message
> could be larger.
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>


-- 

Chris Albertson
Redondo Beach, California

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] OT: Synchronised motion using RS485/CAN bus motors

[andy pugh]

On Sat, 22 Aug 2020 at 00:45, Frank Tkalcevic
 wrote:

> trailers that is a total of 200 bits, best case, or about 416 updates per
> second for 12 motors on 1MHz bus.
>
> I was expecting the update rate to be a lot lower than that

And you are assuming one bus.

On the cars I work on we have a private CAN between the engine and
gearbox, and then two high-speed CAN networks that both are on too.

Potentially they could run one bus per motor, but one bus per leg
would make sense.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] OT: Synchronised motion using RS485/CAN bus motors

[Frank Tkalcevic]

I was looking in more detail at the MIT Cheetah and found this page -
https://www.robotdigg.com/product/1667/MIT-Robot-Dog-high-torque-Joint-Motor
-or-DD-Motor

It says that each motor takes an 8 byte payload to drive a motor, and that
motor then replies with a 6 byte packet.  After you add the CAN headers and
trailers that is a total of 200 bits, best case, or about 416 updates per
second for 12 motors on 1MHz bus.

I was expecting the update rate to be a lot lower than that (I should have
done the math).


-Original Message-
From: N [mailto:nicklas.karlsso...@gmail.com] 
Sent: Saturday, 22 August 2020 5:34 AM
To: Enhanced Machine Controller (EMC)
Subject: Re: [Emc-users] OT: Synchronised motion using RS485/CAN bus motors

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

Yes all devices need to read bus within the time it take to send one bit
because of the arbitration used to send the message with highest priority
first. With CAN-FD speed is increased after address is sent so that message
could be larger.


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] OT: Synchronised motion using RS485/CAN bus motors

[N]

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

Yes all devices need to read bus within the time it take to send one bit 
because of the arbitration used to send the message with highest priority 
first. With CAN-FD speed is increased after address is sent so that message 
could be larger.


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] OT: Synchronised motion using RS485/CAN bus motors

[N]

> I think the question was intended to be more theoretical and asks about
> "exactly" synchronizing commands. The LinuxCNC/SPI solution is not
> that.  SPI works only because it is so fast that the error in
> synchronization is tiny and goes unnoticed.

Using a Micro controller it is possible to connect pwm output to CS signal and 
use it to trigger interrupt to send a message, receive may clock input so if 
needed it is possible to get really good synchronization with SPI and standard 
Micro controller if needed. In doubt there is any case this accuracy is needed 
or make a difference in practice but syncronize clock drift may be needed, 
especially if a FIFO is used.

> Here is a harder problem. Let's say I am in North America and by buddy
> lives in Europe and we want to each run clocks and we want them to stay in
> phase at a high level of accuracy.   To make matters worse assume this is
> the mid-1800s and the radio is not yet invented.  They actually solved this
> problem.  The solution was "mutually observed events" and we use this same
> solution today to keep widely dispersed machines in sync.   In the old
> days, they would observe one of Jupiter's moons from both America and
> Europe and assume they both say the moon transit the planet at the same
> time.  Orchestras use a conductor waving a stick who is "mutually
> observed" by all musicians.Same with a CAN bus, you could, if needed
> use a high priority "clock tick" message that all nodes see at the same
> time.

Know about it and it could be sursingly tricky to agree about event ordering.

> But in real-life.   We accept "close enough" and just us a SPI signal that
> is fast enough that no one notices the error.

Agree, used this approach many times and quite often there is plenty of other 
random variations.


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] OT: Synchronised motion using RS485/CAN bus motors

[dave engvall]

On 8/20/20 5:00 PM, Gregg Eshelman via Emc-users wrote:

What blows some people's minds is that the sum of two odd numbers is always an 
even number, the sum of two even numbers is also always an even number. The 
only way to get an odd number from adding any two numbers is one number must be 
odd.
That's a math feature often used in number collecting games where the object is 
to add up to an odd number like 21. The number of winners is easy to control by 
how many game pieces with an odd number are released. Get any odd number and 
you're a winner because it's super easy to collect the right even numbers to 
add together. Pepsi did that years ago where if you collected bottle caps 
totaling 21 they'd get you a pair of tickets to ANY event in the USA. Super 
Bowl, some big gaming convention, whatever.

 On Thursday, August 20, 2020, 12:48:51 AM MDT, Chris Albertson 
 wrote:
  What happens is these concepts get beaten into your brain so well that we
think we never learned them and it is just "common sense".  Not no it is
not common sense, the smartest people who ever lived spent much of their
life figuring out something in the mid 1600's and you learned it in 10
minutes and then forgot when.  But now it is dead-obvious that every whole
number is the product of a unique set of primes.  How could that NOT be
true?

So we are prone to say "It is obvious that..."

But then again no one is born knowing this and for most of human history,
no one knew this obvious fact.  But it becomes obvious after we forget
where we learned it.


Since we are obviously OT I will compound it. One of the tests for 
dementia is a count backwards from 100 by 7's. My wife does it in a 
subtract 3 , subtract 4 sequence. " I think it is obvious that"... the 
easy way to to subtract 10 add three. People are different in their 
approach to problem solving and that is what make them so 'interesting'. :-)


Dave

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users




___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] OT: Synchronised motion using RS485/CAN bus motors

[Gregg Eshelman via Emc-users]

What blows some people's minds is that the sum of two odd numbers is always an 
even number, the sum of two even numbers is also always an even number. The 
only way to get an odd number from adding any two numbers is one number must be 
odd. 
That's a math feature often used in number collecting games where the object is 
to add up to an odd number like 21. The number of winners is easy to control by 
how many game pieces with an odd number are released. Get any odd number and 
you're a winner because it's super easy to collect the right even numbers to 
add together. Pepsi did that years ago where if you collected bottle caps 
totaling 21 they'd get you a pair of tickets to ANY event in the USA. Super 
Bowl, some big gaming convention, whatever.

On Thursday, August 20, 2020, 12:48:51 AM MDT, Chris Albertson 
 wrote:  
 What happens is these concepts get beaten into your brain so well that we
think we never learned them and it is just "common sense".  Not no it is
not common sense, the smartest people who ever lived spent much of their
life figuring out something in the mid 1600's and you learned it in 10
minutes and then forgot when.  But now it is dead-obvious that every whole
number is the product of a unique set of primes.  How could that NOT be
true?

So we are prone to say "It is obvious that..."

But then again no one is born knowing this and for most of human history,
no one knew this obvious fact.  But it becomes obvious after we forget
where we learned it.  
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] OT: Synchronised motion using RS485/CAN bus motors

[Roland Jollivet]

Have you looked at the manual?

These drives are used on real machines...


On Wed, 19 Aug 2020 at 22:36, N  wrote:

> > Have a read on the manuals for the Yaskawa Legend 01  or 04
> >
> > It uses serial at 9600 !!! to command the drive.  (RS232 serial, or
> > ethernet interface)
> > The trick it uses is to send only new, relevant data, and not fixed
> packets
>
> Good enough for configuration but not coordinated movement in real time.
> Most drives have digital inputs for on/off, reverse/forward and analog
> input for speed. Guess you need an extra module/card to get a CAN interface.
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] OT: Synchronised motion using RS485/CAN bus motors

[John Dammeyer]

Oh yes.  I just mentioned the math courses.  Not the computer ones.  Most of 
the first year computer stuff was all done in APL.  Not exactly a database or 
text processing language so you can see how learning about random numbers and 
some of the other stuff can have labs attached.

One course, third year I think was a telcom course.  This was before the 
internet.  There were 5 labs over the 4 month term done in 5 different 
programming languages.

Then the compiler writing course.  Taught by Chris Thompson.
https://en.wikipedia.org/wiki/FLACC

The FLACC implementation of ALGOL-68 was written in 370 assembler and Chris was 
an great prof.  It was an amazing 4 years.  I wrote an RTOS for an Electrical 
Engineering Grad Project course.  Or then there was the MC6800 emulator written 
in IBM370 assembler during the assembler programming course.  I'll bet nowadays 
they don't even teach an assembler for an entire term.

How many people look at what the compiler generates?  Very important when 
writing for an M9S12 series processor with 512K flash, 32K ram but only 64K 
addressing.

John Dammeyer.



> -Original Message-
> From: Chris Albertson [mailto:albertson.ch...@gmail.com]
> Sent: August-19-20 11:23 PM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] OT: Synchronised motion using RS485/CAN bus motors
> 
> I'll bet that on top of the calculus and linear algebra they also covered
> discrete mathematics and some of the nifty things Allen Turning and John
> Von Neuman discovered about if machines will halt or not and the
> relationship between sets of grammars and sets of machines and you proved
> that a bubble sort has to result in the correct order of numbers in a list
> and that the traveling salesman problem was NP-complete.   I bet you really
> do remember the Prime Factor Theorem (every integer is the product of a
> unique set of primes)
> 
> I also found I forgot most of this but I got interested in the
> current (this century's) version of AI and robotics and found I needed to
> relearn linear algebra and calculus and some statistics.  I did a few of
> the Kahn Academy online courses.   I recommend it.  He teaches at the level
> you really need to know, slightly below the level at a place like UCLA.
> For years this stuff was not relevant but now AI has become a big linear
> algebra-based number cruncher.
> 
> On Wed, Aug 19, 2020 at 7:15 PM John Dammeyer 
> wrote:
> 
> > My computer science degree required 4 terms of calculus, 2 terms of linear
> > algebra, 2 terms of differential equations, 4 terms of physics and 2 terms
> > of statistics.  I think that was all of it.  I also took a nuclear physics
> > course that was quite interesting.  The diff equations were part of the
> > electrical engineering minor.
> >
> > Didn't really do much with astronomy so I really don't quite get how they
> > figured out the distance to the sun.  But I thought it was interesting as
> > is the book 'sapiens'.
> > https://www.amazon.com/Sapiens-Humankind-Yuval-Noah-Harari/dp/0062316095
> >
> > Oh and I remember almost none of all that math.  Too long ago.
> >
> > John Dammeyer
> >
> > > -Original Message-----
> > > From: Chris Albertson [mailto:albertson.ch...@gmail.com]
> > > Sent: August-19-20 6:59 PM
> > > To: Enhanced Machine Controller (EMC)
> > > Subject: Re: [Emc-users] OT: Synchronised motion using RS485/CAN bus
> > motors
> > >
> > > Yes,  If this is a theoretical discussion then at the end of all the
> > chains
> > > of reasoning it all comes to "mutually observed event".   If this is just
> > > engineering then it comes down to "the delay is so fast no one cares".
> > > -
> > > My background is computer science.   Computer science is a mash-up of
> > > mathematical theory and practical engineering.  In some classes we did
> > > proofs and others we built stuff.   It is kind of fun to look both ways.
> > >
> > > A real disaster happened at TRW some years back where us poor working
> > > minions were required to do proofs on the stuff we were building.
> >  Looking
> > > both ways at the same time did not work.
> > >
> > > On Wed, Aug 19, 2020 at 6:10 PM John Dammeyer 
> > > wrote:
> > >
> > > >
> > > >
> > > > > From: John Dammeyer [mailto:jo...@autoartisans.com]
> > > > > I was just reading a few weeks ago in the book "Sapiens" that the
> > early
> > > > explorers set up an experiment where they would observe an
> > > > > astronomical event from both Engla

Re: [Emc-users] OT: Synchronised motion using RS485/CAN bus motors

[Chris Albertson]

What happens is these concepts get beaten into your brain so well that we
think we never learned them and it is just "common sense".  Not no it is
not common sense, the smartest people who ever lived spent much of their
life figuring out something in the mid 1600's and you learned it in 10
minutes and then forgot when.  But now it is dead-obvious that every whole
number is the product of a unique set of primes.   How could that NOT be
true?

So we are prone to say "It is obvious that..."

But then again no one is born knowing this and for most of human history,
no one knew this obvious fact.  But it becomes obvious after we forget
where we learned it.

On Wed, Aug 19, 2020 at 8:35 PM John Dammeyer 
wrote:

> > From: dave engvall [mailto:dengv...@charter.net]
> > Ah, John,
> > In the words of way too many math professors, "It is obvious that ."
> .
>
> Hear hear!
>
> Having said that though I must admit I probably use more math than most.
> About 11 years ago I had to look up Airy Disk effect and then do the math
> to work out lamp positions.
>
> https://en.wikipedia.org/wiki/Airy_disk#Mathematical_formulation
>
> I think if anything that came from it all it's that the math courses gave
> me the confidence to attempt a solution.  It was really cool when the end
> result matched the math.
>
> John Dammeyer
>
>
> >
> > On 8/19/20 7:12 PM, John Dammeyer wrote:
> > > My computer science degree required 4 terms of calculus, 2 terms of
> linear algebra, 2 terms of differential equations, 4 terms of
> > physics and 2 terms of statistics.  I think that was all of it.  I also
> took a nuclear physics course that was quite interesting.  The diff
> > equations were part of the electrical engineering minor.
> > >
> > > Didn't really do much with astronomy so I really don't quite get how
> they figured out the distance to the sun.  But I thought it was
> > interesting as is the book 'sapiens'.
> > >
> https://www.amazon.com/Sapiens-Humankind-Yuval-Noah-Harari/dp/0062316095
> > >
> > > Oh and I remember almost none of all that math.  Too long ago.
> > >
> > > John Dammeyer
> > >
> > >> -Original Message-
> > >> From: Chris Albertson [mailto:albertson.ch...@gmail.com]
> > >> Sent: August-19-20 6:59 PM
> > >> To: Enhanced Machine Controller (EMC)
> > >> Subject: Re: [Emc-users] OT: Synchronised motion using RS485/CAN bus
> motors
> > >>
> > >> Yes,  If this is a theoretical discussion then at the end of all the
> chains
> > >> of reasoning it all comes to "mutually observed event".   If this is
> just
> > >> engineering then it comes down to "the delay is so fast no one cares".
> > >> -
> > >> My background is computer science.   Computer science is a mash-up of
> > >> mathematical theory and practical engineering.  In some classes we did
> > >> proofs and others we built stuff.   It is kind of fun to look both
> ways.
> > >>
> > >> A real disaster happened at TRW some years back where us poor working
> > >> minions were required to do proofs on the stuff we were building.
>  Looking
> > >> both ways at the same time did not work.
> > >>
> > >> On Wed, Aug 19, 2020 at 6:10 PM John Dammeyer  >
> > >> wrote:
> > >>
> > >>>
> > >>>> From: John Dammeyer [mailto:jo...@autoartisans.com]
> > >>>> I was just reading a few weeks ago in the book "Sapiens" that the
> early
> > >>> explorers set up an experiment where they would observe an
> > >>>> astronomical event from both England and the South Pacific.
> Something
> > >>> about either time or position.
> > >>>> I think it was Cook who was exploring at that point.  I'll have to
> dig
> > >>> through to see exactly what it was.
> > >>>> Still quite something to plan on observing something that will take
> you
> > >>> a year or more before you are even there to do the observing.
> > >>> Chapter 15, The marriage of science and empire.  James Cook was
> > >>> commissioned to take astronomers and others to the pacific to be
> there in
> > >>> 1769 to measure the duration of the transit that Venus makes across
> the
> > >>> sun.  Apparently measured from different places on earth results in
> simple
> > >>> trigonometry to determine the distance of the earth from the su

Re: [Emc-users] OT: Synchronised motion using RS485/CAN bus motors

[Chris Albertson]

I'll bet that on top of the calculus and linear algebra they also covered
discrete mathematics and some of the nifty things Allen Turning and John
Von Neuman discovered about if machines will halt or not and the
relationship between sets of grammars and sets of machines and you proved
that a bubble sort has to result in the correct order of numbers in a list
and that the traveling salesman problem was NP-complete.   I bet you really
do remember the Prime Factor Theorem (every integer is the product of a
unique set of primes)

I also found I forgot most of this but I got interested in the
current (this century's) version of AI and robotics and found I needed to
relearn linear algebra and calculus and some statistics.  I did a few of
the Kahn Academy online courses.   I recommend it.  He teaches at the level
you really need to know, slightly below the level at a place like UCLA.
For years this stuff was not relevant but now AI has become a big linear
algebra-based number cruncher.

On Wed, Aug 19, 2020 at 7:15 PM John Dammeyer 
wrote:

> My computer science degree required 4 terms of calculus, 2 terms of linear
> algebra, 2 terms of differential equations, 4 terms of physics and 2 terms
> of statistics.  I think that was all of it.  I also took a nuclear physics
> course that was quite interesting.  The diff equations were part of the
> electrical engineering minor.
>
> Didn't really do much with astronomy so I really don't quite get how they
> figured out the distance to the sun.  But I thought it was interesting as
> is the book 'sapiens'.
> https://www.amazon.com/Sapiens-Humankind-Yuval-Noah-Harari/dp/0062316095
>
> Oh and I remember almost none of all that math.  Too long ago.
>
> John Dammeyer
>
> > -Original Message-
> > From: Chris Albertson [mailto:albertson.ch...@gmail.com]
> > Sent: August-19-20 6:59 PM
> > To: Enhanced Machine Controller (EMC)
> > Subject: Re: [Emc-users] OT: Synchronised motion using RS485/CAN bus
> motors
> >
> > Yes,  If this is a theoretical discussion then at the end of all the
> chains
> > of reasoning it all comes to "mutually observed event".   If this is just
> > engineering then it comes down to "the delay is so fast no one cares".
> > -
> > My background is computer science.   Computer science is a mash-up of
> > mathematical theory and practical engineering.  In some classes we did
> > proofs and others we built stuff.   It is kind of fun to look both ways.
> >
> > A real disaster happened at TRW some years back where us poor working
> > minions were required to do proofs on the stuff we were building.
>  Looking
> > both ways at the same time did not work.
> >
> > On Wed, Aug 19, 2020 at 6:10 PM John Dammeyer 
> > wrote:
> >
> > >
> > >
> > > > From: John Dammeyer [mailto:jo...@autoartisans.com]
> > > > I was just reading a few weeks ago in the book "Sapiens" that the
> early
> > > explorers set up an experiment where they would observe an
> > > > astronomical event from both England and the South Pacific.
> Something
> > > about either time or position.
> > > >
> > > > I think it was Cook who was exploring at that point.  I'll have to
> dig
> > > through to see exactly what it was.
> > > >
> > > > Still quite something to plan on observing something that will take
> you
> > > a year or more before you are even there to do the observing.
> > > >
> > >
> > > Chapter 15, The marriage of science and empire.  James Cook was
> > > commissioned to take astronomers and others to the pacific to be there
> in
> > > 1769 to measure the duration of the transit that Venus makes across the
> > > sun.  Apparently measured from different places on earth results in
> simple
> > > trigonometry to determine the distance of the earth from the sun.
> > >
> > > Who knew.
> > >
> > > John
> > >
> > >
> > >
> > >
> > > ___
> > > Emc-users mailing list
> > > Emc-users@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/emc-users
> > >
> >
> >
> > --
> >
> > Chris Albertson
> > Redondo Beach, California
> >
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
>
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>


-- 

Chris Albertson
Redondo Beach, California

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] OT: Synchronised motion using RS485/CAN bus motors

[John Dammeyer]

> From: dave engvall [mailto:dengv...@charter.net]
> Ah, John,
> In the words of way too many math professors, "It is obvious that ." .

Hear hear!

Having said that though I must admit I probably use more math than most.  About 
11 years ago I had to look up Airy Disk effect and then do the math to work out 
lamp positions.  

https://en.wikipedia.org/wiki/Airy_disk#Mathematical_formulation

I think if anything that came from it all it's that the math courses gave me 
the confidence to attempt a solution.  It was really cool when the end result 
matched the math.

John Dammeyer


> 
> On 8/19/20 7:12 PM, John Dammeyer wrote:
> > My computer science degree required 4 terms of calculus, 2 terms of linear 
> > algebra, 2 terms of differential equations, 4 terms of
> physics and 2 terms of statistics.  I think that was all of it.  I also took 
> a nuclear physics course that was quite interesting.  The diff
> equations were part of the electrical engineering minor.
> >
> > Didn't really do much with astronomy so I really don't quite get how they 
> > figured out the distance to the sun.  But I thought it was
> interesting as is the book 'sapiens'.
> > https://www.amazon.com/Sapiens-Humankind-Yuval-Noah-Harari/dp/0062316095
> >
> > Oh and I remember almost none of all that math.  Too long ago.
> >
> > John Dammeyer
> >
> >> -Original Message-
> >> From: Chris Albertson [mailto:albertson.ch...@gmail.com]
> >> Sent: August-19-20 6:59 PM
> >> To: Enhanced Machine Controller (EMC)
> >> Subject: Re: [Emc-users] OT: Synchronised motion using RS485/CAN bus motors
> >>
> >> Yes,  If this is a theoretical discussion then at the end of all the chains
> >> of reasoning it all comes to "mutually observed event".   If this is just
> >> engineering then it comes down to "the delay is so fast no one cares".
> >> -
> >> My background is computer science.   Computer science is a mash-up of
> >> mathematical theory and practical engineering.  In some classes we did
> >> proofs and others we built stuff.   It is kind of fun to look both ways.
> >>
> >> A real disaster happened at TRW some years back where us poor working
> >> minions were required to do proofs on the stuff we were building.   Looking
> >> both ways at the same time did not work.
> >>
> >> On Wed, Aug 19, 2020 at 6:10 PM John Dammeyer 
> >> wrote:
> >>
> >>>
> >>>> From: John Dammeyer [mailto:jo...@autoartisans.com]
> >>>> I was just reading a few weeks ago in the book "Sapiens" that the early
> >>> explorers set up an experiment where they would observe an
> >>>> astronomical event from both England and the South Pacific.  Something
> >>> about either time or position.
> >>>> I think it was Cook who was exploring at that point.  I'll have to dig
> >>> through to see exactly what it was.
> >>>> Still quite something to plan on observing something that will take you
> >>> a year or more before you are even there to do the observing.
> >>> Chapter 15, The marriage of science and empire.  James Cook was
> >>> commissioned to take astronomers and others to the pacific to be there in
> >>> 1769 to measure the duration of the transit that Venus makes across the
> >>> sun.  Apparently measured from different places on earth results in simple
> >>> trigonometry to determine the distance of the earth from the sun.
> >>>
> >>> Who knew.
> >>>
> >>> John
> >>>
> >>>
> >>>
> >>>
> >>> ___
> >>> Emc-users mailing list
> >>> Emc-users@lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/emc-users
> >>>
> >>
> >> --
> >>
> >> Chris Albertson
> >> Redondo Beach, California
> >>
> >> ___
> >> Emc-users mailing list
> >> Emc-users@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/emc-users
> >
> >
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
> 
> 
> 
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] OT: Synchronised motion using RS485/CAN bus motors

[dave engvall]

Ah, John,
In the words of way too many math professors, "It is obvious that ." .

On 8/19/20 7:12 PM, John Dammeyer wrote:

My computer science degree required 4 terms of calculus, 2 terms of linear 
algebra, 2 terms of differential equations, 4 terms of physics and 2 terms of 
statistics.  I think that was all of it.  I also took a nuclear physics course 
that was quite interesting.  The diff equations were part of the electrical 
engineering minor.

Didn't really do much with astronomy so I really don't quite get how they 
figured out the distance to the sun.  But I thought it was interesting as is 
the book 'sapiens'.
https://www.amazon.com/Sapiens-Humankind-Yuval-Noah-Harari/dp/0062316095

Oh and I remember almost none of all that math.  Too long ago.

John Dammeyer


-Original Message-
From: Chris Albertson [mailto:albertson.ch...@gmail.com]
Sent: August-19-20 6:59 PM
To: Enhanced Machine Controller (EMC)
Subject: Re: [Emc-users] OT: Synchronised motion using RS485/CAN bus motors

Yes,  If this is a theoretical discussion then at the end of all the chains
of reasoning it all comes to "mutually observed event".   If this is just
engineering then it comes down to "the delay is so fast no one cares".
-
My background is computer science.   Computer science is a mash-up of
mathematical theory and practical engineering.  In some classes we did
proofs and others we built stuff.   It is kind of fun to look both ways.

A real disaster happened at TRW some years back where us poor working
minions were required to do proofs on the stuff we were building.   Looking
both ways at the same time did not work.

On Wed, Aug 19, 2020 at 6:10 PM John Dammeyer 
wrote:




From: John Dammeyer [mailto:jo...@autoartisans.com]
I was just reading a few weeks ago in the book "Sapiens" that the early

explorers set up an experiment where they would observe an

astronomical event from both England and the South Pacific.  Something

about either time or position.

I think it was Cook who was exploring at that point.  I'll have to dig

through to see exactly what it was.

Still quite something to plan on observing something that will take you

a year or more before you are even there to do the observing.
Chapter 15, The marriage of science and empire.  James Cook was
commissioned to take astronomers and others to the pacific to be there in
1769 to measure the duration of the transit that Venus makes across the
sun.  Apparently measured from different places on earth results in simple
trigonometry to determine the distance of the earth from the sun.

Who knew.

John




___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users



--

Chris Albertson
Redondo Beach, California

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users




___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] OT: Synchronised motion using RS485/CAN bus motors

[John Dammeyer]

My computer science degree required 4 terms of calculus, 2 terms of linear 
algebra, 2 terms of differential equations, 4 terms of physics and 2 terms of 
statistics.  I think that was all of it.  I also took a nuclear physics course 
that was quite interesting.  The diff equations were part of the electrical 
engineering minor.  

Didn't really do much with astronomy so I really don't quite get how they 
figured out the distance to the sun.  But I thought it was interesting as is 
the book 'sapiens'.
https://www.amazon.com/Sapiens-Humankind-Yuval-Noah-Harari/dp/0062316095

Oh and I remember almost none of all that math.  Too long ago.

John Dammeyer

> -Original Message-
> From: Chris Albertson [mailto:albertson.ch...@gmail.com]
> Sent: August-19-20 6:59 PM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] OT: Synchronised motion using RS485/CAN bus motors
> 
> Yes,  If this is a theoretical discussion then at the end of all the chains
> of reasoning it all comes to "mutually observed event".   If this is just
> engineering then it comes down to "the delay is so fast no one cares".
> -
> My background is computer science.   Computer science is a mash-up of
> mathematical theory and practical engineering.  In some classes we did
> proofs and others we built stuff.   It is kind of fun to look both ways.
> 
> A real disaster happened at TRW some years back where us poor working
> minions were required to do proofs on the stuff we were building.   Looking
> both ways at the same time did not work.
> 
> On Wed, Aug 19, 2020 at 6:10 PM John Dammeyer 
> wrote:
> 
> >
> >
> > > From: John Dammeyer [mailto:jo...@autoartisans.com]
> > > I was just reading a few weeks ago in the book "Sapiens" that the early
> > explorers set up an experiment where they would observe an
> > > astronomical event from both England and the South Pacific.  Something
> > about either time or position.
> > >
> > > I think it was Cook who was exploring at that point.  I'll have to dig
> > through to see exactly what it was.
> > >
> > > Still quite something to plan on observing something that will take you
> > a year or more before you are even there to do the observing.
> > >
> >
> > Chapter 15, The marriage of science and empire.  James Cook was
> > commissioned to take astronomers and others to the pacific to be there in
> > 1769 to measure the duration of the transit that Venus makes across the
> > sun.  Apparently measured from different places on earth results in simple
> > trigonometry to determine the distance of the earth from the sun.
> >
> > Who knew.
> >
> > John
> >
> >
> >
> >
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
> >
> 
> 
> --
> 
> Chris Albertson
> Redondo Beach, California
> 
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] OT: Synchronised motion using RS485/CAN bus motors

[Chris Albertson]

Yes,  If this is a theoretical discussion then at the end of all the chains
of reasoning it all comes to "mutually observed event".   If this is just
engineering then it comes down to "the delay is so fast no one cares".

My background is computer science.   Computer science is a mash-up of
mathematical theory and practical engineering.  In some classes we did
proofs and others we built stuff.   It is kind of fun to look both ways.

A real disaster happened at TRW some years back where us poor working
minions were required to do proofs on the stuff we were building.   Looking
both ways at the same time did not work.

On Wed, Aug 19, 2020 at 6:10 PM John Dammeyer 
wrote:

>
>
> > From: John Dammeyer [mailto:jo...@autoartisans.com]
> > I was just reading a few weeks ago in the book "Sapiens" that the early
> explorers set up an experiment where they would observe an
> > astronomical event from both England and the South Pacific.  Something
> about either time or position.
> >
> > I think it was Cook who was exploring at that point.  I'll have to dig
> through to see exactly what it was.
> >
> > Still quite something to plan on observing something that will take you
> a year or more before you are even there to do the observing.
> >
>
> Chapter 15, The marriage of science and empire.  James Cook was
> commissioned to take astronomers and others to the pacific to be there in
> 1769 to measure the duration of the transit that Venus makes across the
> sun.  Apparently measured from different places on earth results in simple
> trigonometry to determine the distance of the earth from the sun.
>
> Who knew.
>
> John
>
>
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>


-- 

Chris Albertson
Redondo Beach, California

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] OT: Synchronised motion using RS485/CAN bus motors

[John Dammeyer]

> From: John Dammeyer [mailto:jo...@autoartisans.com]
> I was just reading a few weeks ago in the book "Sapiens" that the early 
> explorers set up an experiment where they would observe an
> astronomical event from both England and the South Pacific.  Something about 
> either time or position.
> 
> I think it was Cook who was exploring at that point.  I'll have to dig 
> through to see exactly what it was.
> 
> Still quite something to plan on observing something that will take you a 
> year or more before you are even there to do the observing.
> 

Chapter 15, The marriage of science and empire.  James Cook was commissioned to 
take astronomers and others to the pacific to be there in 1769 to measure the 
duration of the transit that Venus makes across the sun.  Apparently measured 
from different places on earth results in simple trigonometry to determine the 
distance of the earth from the sun.

Who knew.

John




___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] OT: Synchronised motion using RS485/CAN bus motors

[John Dammeyer]

I was just reading a few weeks ago in the book "Sapiens" that the early 
explorers set up an experiment where they would observe an astronomical event 
from both England and the South Pacific.  Something about either time or 
position.

I think it was Cook who was exploring at that point.  I'll have to dig through 
to see exactly what it was.

Still quite something to plan on observing something that will take you a year 
or more before you are even there to do the observing.

John Dammeyer

> -Original Message-
> From: Chris Albertson [mailto:albertson.ch...@gmail.com]
> Sent: August-19-20 2:09 PM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] OT: Synchronised motion using RS485/CAN bus motors
> 
> I think the question was intended to be more theoretical and asks about
> "exactly" synchronizing commands. The LinuxCNC/SPI solution is not
> that.  SPI works only because it is so fast that the error in
> synchronization is tiny and goes unnoticed.
> 
> Here is a harder problem. Let's say I am in North America and by buddy
> lives in Europe and we want to each run clocks and we want them to stay in
> phase at a high level of accuracy.   To make matters worse assume this is
> the mid-1800s and the radio is not yet invented.  They actually solved this
> problem.  The solution was "mutually observed events" and we use this same
> solution today to keep widely dispersed machines in sync.   In the old
> days, they would observe one of Jupiter's moons from both America and
> Europe and assume they both say the moon transit the planet at the same
> time.  Orchestras use a conductor waving a stick who is "mutually
> observed" by all musicians.Same with a CAN bus, you could, if needed
> use a high priority "clock tick" message that all nodes see at the same
> time.
> 
> But in real-life.   We accept "close enough" and just us a SPI signal that
> is fast enough that no one notices the error.
> 
> On Tue, Aug 18, 2020 at 8:08 PM Frank Tkalcevic 
> wrote:
> 
> > > You subject line says RS485/CAN which are dramatically different from the
> > SPI based synchronous clocked serial interfaces.  Even RS485 and CAN are
> > dramatically different.
> >
> > Thanks for the replies...
> >
> > The question was around slower RS485/CAN.  I'm seeing a lot of actuators
> > (motor/gearbox/driver combinations) that are driven by CAN bus (MIT
> > cheetah).
> >
> > Brute speed seems to be a common solution, which I'm guessing protocols
> > like
> > EtherCAT rely on.
> >
> > Given the CAN bus speed limits - 1MHz, it doesn't seem possible to
> > send/receive messages to many motors at a typical LinuxCNC 1kHz rate.  Is
> > there some kind of "smarts" that let these control systems work smoothly at
> > lower update rates?
> >
> >
> >
> >
> >
> >
> >
> >
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
> >
> 
> 
> --
> 
> Chris Albertson
> Redondo Beach, California
> 
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] OT: Synchronised motion using RS485/CAN bus motors

[John Dammeyer]

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

Re: [Emc-users] OT: Synchronised motion using RS485/CAN bus motors

[Chris Albertson]

I think the question was intended to be more theoretical and asks about
"exactly" synchronizing commands. The LinuxCNC/SPI solution is not
that.  SPI works only because it is so fast that the error in
synchronization is tiny and goes unnoticed.

Here is a harder problem. Let's say I am in North America and by buddy
lives in Europe and we want to each run clocks and we want them to stay in
phase at a high level of accuracy.   To make matters worse assume this is
the mid-1800s and the radio is not yet invented.  They actually solved this
problem.  The solution was "mutually observed events" and we use this same
solution today to keep widely dispersed machines in sync.   In the old
days, they would observe one of Jupiter's moons from both America and
Europe and assume they both say the moon transit the planet at the same
time.  Orchestras use a conductor waving a stick who is "mutually
observed" by all musicians.Same with a CAN bus, you could, if needed
use a high priority "clock tick" message that all nodes see at the same
time.

But in real-life.   We accept "close enough" and just us a SPI signal that
is fast enough that no one notices the error.

On Tue, Aug 18, 2020 at 8:08 PM Frank Tkalcevic 
wrote:

> > You subject line says RS485/CAN which are dramatically different from the
> SPI based synchronous clocked serial interfaces.  Even RS485 and CAN are
> dramatically different.
>
> Thanks for the replies...
>
> The question was around slower RS485/CAN.  I'm seeing a lot of actuators
> (motor/gearbox/driver combinations) that are driven by CAN bus (MIT
> cheetah).
>
> Brute speed seems to be a common solution, which I'm guessing protocols
> like
> EtherCAT rely on.
>
> Given the CAN bus speed limits - 1MHz, it doesn't seem possible to
> send/receive messages to many motors at a typical LinuxCNC 1kHz rate.  Is
> there some kind of "smarts" that let these control systems work smoothly at
> lower update rates?
>
>
>
>
>
>
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>


-- 

Chris Albertson
Redondo Beach, California

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] OT: Synchronised motion using RS485/CAN bus motors

[N]

Quite often used a lot lower speed than maximum on CAN bus, in some cases cable 
is long and while in other cases an ordinary cable not optimized for maximum 
speed is used. Sometimes only slow communication is needed so possibility to 
reduce speed to accomodate these case are good.

> Yes, that works in your case where the cable is short.   But what if this
> were a CAN bus in a very noisy environment. So noisy that only slow speed
> could work.   Image an electric car and you want to keep the from and rear
> traction motors "balanced" so they don't work in opposition and you care
> about 0.1% gains in efficiency.   These are 120 horsepower three-phase
> motors working at 400 volts DC.  Your CAN bus is slow.  Your bos is nuts
> and demands you solution have a 50 year design lifetime in an
> automotive environment.   Tesla engineers solves this problem.
> 
> Now image you are given the same problem, Ok smaller moters, but this time
> the "cable" has to reach to Mars and has a 14 minute speed of light delay.
> And the environment is even worse than "automotive".   JPL engineers seem
> to have solved this. (They could be the same engineers.  Both places are
> within commute distance of my house and people here swap jobs every few
> years.)
> 
> Here is one of by favorite "synchronized motors" videos.  "Atlas is a 28
> degree of freedom machine.   All 28 motors are well synced
> https://youtu.be/knoOXBLFQ-s?t=42
> 
> Here is another.  They built by mear mortals at a much lower cost.  They
> use motors from quadcopter drones and some CNC'd metal parts. These are 12
> "axis" machines, with three motors and three rotary encoders per leg.
> These are "Open Source" so you can download the design files.
>  https://youtu.be/G6fMV1UPzkg?t=86
> 
> SO motor syncing is possible and is done.  The machine tool use case is
> actually easy compared to other things
> 
> 
> 
> 
> 
> On Tue, Aug 18, 2020 at 5:41 PM Gene Heskett  wrote:
> 
> > On Tuesday 18 August 2020 18:58:01 Frank Tkalcevic wrote:
> >
> > > An off topic question, not directly LinuxCNC related...
> > >
> > > How are motors on a serial bus controlled and synchronised?
> > >
> > > My only real control experience is with LinuxCNC with Mesa and
> > > parallel port hardware where commands and feedback and precisely
> > > timed.  Sending commands and receiving feedback over a serial link I
> > > would expect to cause synchronising problems, and the bandwidth would
> > > reduce the update rate.
> > >
> > > How are these issues handled?  I tried googling this, but didn't find
> > > much -  I wasn't sure what to search for.
> > >
> > By running the serial connection at many megabaud speeds. With spi, I am
> > issueing 32 bit command words with the pi's gpio's, writing to the 7i90
> > at 40 megabaud, and reading the 7i90's replies at 25 megabaud.  With a
> > transmission line only an inch long, its bulletproof.
> >
> > > Thanks,
> > > Frank
> > >
> > >
> > >
> > >
> > >
> > >
> > > ___
> > > Emc-users mailing list
> > > Emc-users@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/emc-users
> >
> >
> > Cheers, Gene Heskett
> > --
> > "There are four boxes to be used in defense of liberty:
> >  soap, ballot, jury, and ammo. Please use in that order."
> > -Ed Howdershelt (Author)
> > If we desire respect for the law, we must first make the law respectable.
> >  - Louis D. Brandeis
> > Genes Web page 
> >
> >
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
> >
> 
> 
> -- 
> 
> Chris Albertson
> Redondo Beach, California
> 
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] OT: Synchronised motion using RS485/CAN bus motors

[N]

> 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


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] OT: Synchronised motion using RS485/CAN bus motors

[Chris Albertson]

Yes, that works in your case where the cable is short.   But what if this
were a CAN bus in a very noisy environment. So noisy that only slow speed
could work.   Image an electric car and you want to keep the from and rear
traction motors "balanced" so they don't work in opposition and you care
about 0.1% gains in efficiency.   These are 120 horsepower three-phase
motors working at 400 volts DC.  Your CAN bus is slow.  Your bos is nuts
and demands you solution have a 50 year design lifetime in an
automotive environment.   Tesla engineers solves this problem.

Now image you are given the same problem, Ok smaller moters, but this time
the "cable" has to reach to Mars and has a 14 minute speed of light delay.
And the environment is even worse than "automotive".   JPL engineers seem
to have solved this. (They could be the same engineers.  Both places are
within commute distance of my house and people here swap jobs every few
years.)

Here is one of by favorite "synchronized motors" videos.  "Atlas is a 28
degree of freedom machine.   All 28 motors are well synced
https://youtu.be/knoOXBLFQ-s?t=42

Here is another.  They built by mear mortals at a much lower cost.  They
use motors from quadcopter drones and some CNC'd metal parts. These are 12
"axis" machines, with three motors and three rotary encoders per leg.
These are "Open Source" so you can download the design files.
 https://youtu.be/G6fMV1UPzkg?t=86

SO motor syncing is possible and is done.  The machine tool use case is
actually easy compared to other things





On Tue, Aug 18, 2020 at 5:41 PM Gene Heskett  wrote:

> On Tuesday 18 August 2020 18:58:01 Frank Tkalcevic wrote:
>
> > An off topic question, not directly LinuxCNC related...
> >
> > How are motors on a serial bus controlled and synchronised?
> >
> > My only real control experience is with LinuxCNC with Mesa and
> > parallel port hardware where commands and feedback and precisely
> > timed.  Sending commands and receiving feedback over a serial link I
> > would expect to cause synchronising problems, and the bandwidth would
> > reduce the update rate.
> >
> > How are these issues handled?  I tried googling this, but didn't find
> > much -  I wasn't sure what to search for.
> >
> By running the serial connection at many megabaud speeds. With spi, I am
> issueing 32 bit command words with the pi's gpio's, writing to the 7i90
> at 40 megabaud, and reading the 7i90's replies at 25 megabaud.  With a
> transmission line only an inch long, its bulletproof.
>
> > Thanks,
> > Frank
> >
> >
> >
> >
> >
> >
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
>
>
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> If we desire respect for the law, we must first make the law respectable.
>  - Louis D. Brandeis
> Genes Web page 
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>


-- 

Chris Albertson
Redondo Beach, California

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] OT: Synchronised motion using RS485/CAN bus motors

[N]

> Have a read on the manuals for the Yaskawa Legend 01  or 04
> 
> It uses serial at 9600 !!! to command the drive.  (RS232 serial, or
> ethernet interface)
> The trick it uses is to send only new, relevant data, and not fixed packets

Good enough for configuration but not coordinated movement in real time. Most 
drives have digital inputs for on/off, reverse/forward and analog input for 
speed. Guess you need an extra module/card to get a CAN interface.


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] OT: Synchronised motion using RS485/CAN bus motors

[Roland Jollivet]

Have a read on the manuals for the Yaskawa Legend 01  or 04

It uses serial at 9600 !!! to command the drive.  (RS232 serial, or
ethernet interface)
The trick it uses is to send only new, relevant data, and not fixed packets

Roland


On Wed, 19 Aug 2020 at 01:31, Frank Tkalcevic 
wrote:

> An off topic question, not directly LinuxCNC related...
>
> How are motors on a serial bus controlled and synchronised?
>
> My only real control experience is with LinuxCNC with Mesa and parallel
> port hardware where commands and feedback and precisely timed.  Sending
> commands and receiving feedback over a serial link I would expect to cause
> synchronising problems, and the bandwidth would reduce the update rate.
>
> How are these issues handled?  I tried googling this, but didn't find much
> -  I wasn't sure what to search for.
>
> Thanks,
> Frank
>
>
>
>
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] OT: Synchronised motion using RS485/CAN bus motors

[Chris Albertson]

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.

You can also use implied time tags where commands are sent in blocks and
the rule is to execute everything in a block at the start of (say) the next
time interval.Audio and video that is streamed over the Internet work
like that.   The audio and video are sent in "frames" and there is an
agreed frame rate and it all gets resynced by the display device.

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

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.





On Tue, Aug 18, 2020 at 4:31 PM Frank Tkalcevic 
wrote:

> An off topic question, not directly LinuxCNC related...
>
> How are motors on a serial bus controlled and synchronised?
>
> My only real control experience is with LinuxCNC with Mesa and parallel
> port hardware where commands and feedback and precisely timed.  Sending
> commands and receiving feedback over a serial link I would expect to cause
> synchronising problems, and the bandwidth would reduce the update rate.
>
> How are these issues handled?  I tried googling this, but didn't find much
> -  I wasn't sure what to search for.
>
> Thanks,
> Frank
>
>
>
>
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>


-- 

Chris Albertson
Redondo Beach, California

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] OT: Synchronised motion using RS485/CAN bus motors

[N]

> > From: Frank Tkalcevic [mailto:fr...@franksworkshop.com.au]
> > > You subject line says RS485/CAN which are dramatically different from the
> > SPI based synchronous clocked serial interfaces.  Even RS485 and CAN are
> > dramatically different.
> > 
> > Thanks for the replies...
> > 
> > The question was around slower RS485/CAN.  I'm seeing a lot of actuators
> > (motor/gearbox/driver combinations) that are driven by CAN bus (MIT
> > cheetah).
> > 
> > Brute speed seems to be a common solution, which I'm guessing protocols like
> > EtherCAT rely on.
> > 
> > Given the CAN bus speed limits - 1MHz, it doesn't seem possible to
> > send/receive messages to many motors at a typical LinuxCNC 1kHz rate.  Is
> > there some kind of "smarts" that let these control systems work smoothly at
> > lower update rates?
> > 
> Most CAN based Step or Servo motors can operate in position or speed mode.  
> In speed mode you can also set torque values.   They work well for say pick 
> and place or tool changers etc.  And anything else where you might want 
> precision motion or torque control.
> 
> Generally the motors come in two flavours supporting either J1939 or CANopen. 
>  Recall I mentioned that CAN messages have 11 bit IDs and up to 8 data bytes. 
>  To set up or control a motor you send Service Data Object messages (SDO) 
> writing to the device object dictionary (OD).  You get information back by 
> reading from the OD.
> 
> When working with CAN bus it's handy to have some sort of dongle for 
> receiving and sending messages.  Once such device is a CANUSB from Lawicel I 
> Sweden.
> www.canusb.com

And an application to read/write the dictionary using an .eds or .dcf file.


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] OT: Synchronised motion using RS485/CAN bus motors

[N]

CANopen have a special sync message which is used for synchronization. You 
probably want cyclic synchronization communication, messages are sent anywhere 
within communication period and start to be used then synchronization message 
is sent. Synchronization message may have som jitter, it does not interrupt a 
message currently being sent but have hight priority so it will be sent before 
other messages with lower priority, not sure if it may be time stamped to 
increase accuracy if needed.

With cyclic communication receiver know then message is expected and may turn 
off motor if not received as expected, for example if cable is removed. CAN bus 
have small messages which is usually a good choice for real time since it is 
common messages are small but need to be sent often.


> An off topic question, not directly LinuxCNC related...
> 
> How are motors on a serial bus controlled and synchronised?  
> 
> My only real control experience is with LinuxCNC with Mesa and parallel port 
> hardware where commands and feedback and precisely timed.  Sending commands 
> and receiving feedback over a serial link I would expect to cause 
> synchronising problems, and the bandwidth would reduce the update rate.
> 
> How are these issues handled?  I tried googling this, but didn't find much -  
> I wasn't sure what to search for.
> 
> Thanks,
> Frank


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] OT: Synchronised motion using RS485/CAN bus motors

[Frank Tkalcevic]

> You subject line says RS485/CAN which are dramatically different from the
SPI based synchronous clocked serial interfaces.  Even RS485 and CAN are
dramatically different.

Thanks for the replies...

The question was around slower RS485/CAN.  I'm seeing a lot of actuators
(motor/gearbox/driver combinations) that are driven by CAN bus (MIT
cheetah).

Brute speed seems to be a common solution, which I'm guessing protocols like
EtherCAT rely on.

Given the CAN bus speed limits - 1MHz, it doesn't seem possible to
send/receive messages to many motors at a typical LinuxCNC 1kHz rate.  Is
there some kind of "smarts" that let these control systems work smoothly at
lower update rates? 








___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] OT: Synchronised motion using RS485/CAN bus motors

[John Dammeyer]

Hi Frank,

> -Original Message-
> From: Frank Tkalcevic [mailto:fr...@franksworkshop.com.au]
> Sent: August-18-20 3:58 PM
> To: 'Enhanced Machine Controller (EMC)'
> Subject: [Emc-users] OT: Synchronised motion using RS485/CAN bus motors
> 
> An off topic question, not directly LinuxCNC related...
> 
> How are motors on a serial bus controlled and synchronised?
> 
> My only real control experience is with LinuxCNC with Mesa and parallel port 
> hardware where commands and feedback and precisely
> timed.  Sending commands and receiving feedback over a serial link I would 
> expect to cause synchronising problems, and the
> bandwidth would reduce the update rate.
> 
> How are these issues handled?  I tried googling this, but didn't find much -  
> I wasn't sure what to search for.

You subject line says RS485/CAN which are dramatically different from the SPI 
based synchronous clocked serial interfaces.  Even RS485 and CAN are 
dramatically different.

First let's describe the 3 protocols.
RS485 is based on a UART and refers to the differential bus signal levels which 
can be logic high, logic low or high impedance.  The drivers allow multi-master 
communications as long as nodes don't try and send at the same time.

UARTs use a bit rate called baud which includes 2 or 3 extra bits called start 
and stop to allow devices to detect the beginning of a message.  So each 8 bit 
byte actually takes at least 10 bits of signal time or 11 bits (less common) if 
2 stop bits are used.  Aside from 110 baud the rates are generally multiplied 
by 2 each time.  So 300, 600, 1200, 2400, 4800, 9600 etc.  At 9600 there are 
960 bytes per second with each byte using 10 bits.

CAN bus is a true CSMA/CR system.  Collision Sense, Multiple Access with 
Collision Recovery.  Not a true differential signal since the recessive or no 
signal has both wires at 2.5V relative to ground.  Ie. It's a 3 wire system 
that requires a ground... somewhere...
The messages consist of an ID part, length part, 8 bytes of data part and a CRC 
part plus a few extra bits.  

The advantage of CAN bus is that it can arbitrate when two messages start at 
exactly the same time.  The message with the lowest value ID part wins and 
keeps sending while the other node(s) change over to listen mode.  A message is 
considered successfully sent when the sender part of the message called an ACK 
slot is filled with an ACK bit by any node that correctly received the message. 
 

The bit rates for FULL CAN will run up to 1Mbps but of that 64 bits data and 11 
or 29 bits of ID the overhead is almost double with an average of 135 bits if 
there are 8 bytes.  
Note CAN rates are bits per second.  Not baud. 

Finally SPI is a synchronous master controlled system.  The master asserts a 
chip select and then provides a bit on the MOSI line during a clock bit while 
reading the MISO signal at almost  the same time.  So it can be bidirectional.  

Some SPI can go up to 40MHz but generally runs up to 10MHz.  That means if the 
master was sending 1000 bytes of 8 bits each, the time to do this is 80 uSec.  
So a controller could provide a number of blocks of step pulses with a system 
step rate of 1MHz and have plenty of time to also read back all the inputs at 
the same time.

For example:  Send out 32 bits representing outputs while reading in 32 bits 
representing inputs.  Do this at 10Mbs the time taken is 6.4uS.  

And again, not baud.  Bits per second.

I think Peter Wallace might be able to provide a simple explanation of how and 
what the system sends to maintain high step rates.

John Dammeyer

> 
> Thanks,
> Frank
> 
> 
> 
> 
> 
> 
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] OT: Synchronised motion using RS485/CAN bus motors

[Gene Heskett]

On Tuesday 18 August 2020 18:58:01 Frank Tkalcevic wrote:

> An off topic question, not directly LinuxCNC related...
>
> How are motors on a serial bus controlled and synchronised?
>
> My only real control experience is with LinuxCNC with Mesa and
> parallel port hardware where commands and feedback and precisely
> timed.  Sending commands and receiving feedback over a serial link I
> would expect to cause synchronising problems, and the bandwidth would
> reduce the update rate.
>
> How are these issues handled?  I tried googling this, but didn't find
> much -  I wasn't sure what to search for.
>
By running the serial connection at many megabaud speeds. With spi, I am 
issueing 32 bit command words with the pi's gpio's, writing to the 7i90 
at 40 megabaud, and reading the 7i90's replies at 25 megabaud.  With a 
transmission line only an inch long, its bulletproof.

> Thanks,
> Frank
>
>
>
>
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] OT: Synchronised motion using RS485/CAN bus motors

[Frank Tkalcevic]

An off topic question, not directly LinuxCNC related...

How are motors on a serial bus controlled and synchronised?  

My only real control experience is with LinuxCNC with Mesa and parallel port 
hardware where commands and feedback and precisely timed.  Sending commands and 
receiving feedback over a serial link I would expect to cause synchronising 
problems, and the bandwidth would reduce the update rate.

How are these issues handled?  I tried googling this, but didn't find much -  I 
wasn't sure what to search for.

Thanks,
Frank






___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users