> > > 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
> 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
>
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.
> 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
> > > 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
> -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 Ra
> 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
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
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
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 (EM
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
: 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 want
> ...
> 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
> 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
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
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
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
son.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 ni
gt; 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-
> > &
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
t;> 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 theor
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
engineerin
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
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
> 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
mail.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. T
> -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 exa
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
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
> 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
>
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
> 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
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
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
> > 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
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
> 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
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,
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
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
40 matches
Mail list logo
