On 10/24/2013 10:09 PM, Robert Ellenberg wrote:
> Thanks for your input. I think you're right about the second "const". I
> added it for the extra checking from the compiler, to prevent the dumb
> bugs from accidentally changing pointer. It's a lot of extra verbiage
> just for that one benefit, tho
Hi Sebastian,
Thanks for your input. I think you're right about the second "const". I
added it for the extra checking from the compiler, to prevent the dumb bugs
from accidentally changing pointer. It's a lot of extra verbiage just for
that one benefit, though.
The reason I put the const after th
On 10/24/2013 11:23 AM, Robert Ellenberg wrote:
> It seems like the "right" way is to pass pure inputs by reference using
> constant pointers:
I almost agree!
I think the right way to pass big inputs is to use pointers to constant
memory.
> Instead of this:
>
> pmCartCartDot(PmCartesian v1,
On 10/24/2013 01:02 PM, Jeff Epler wrote:
> The main problem would be if there are any out-of-tree users of these
> routines. Since it's C there's no function overloading, so we can't
> provide both signatures under the same name. So that means the
> alternatives are something like:
> * do noth
On 10/24/2013 3:19 PM, Robert Ellenberg wrote:
> That's a good point about the out-of-tree users, though I wonder if it
> would be better for them to use a standalone libnml version. If there's a
> lot of pushback from other users, I can make the few call-by-reference
> changes I need under a diffe
On Oct 24 2013 2:23 PM, John Morris wrote:
> On 10/24/2013 02:06 PM, andy pugh wrote:
>> On 24 October 2013 19:55, John Morris wrote:
>>
>>> I believe that these restrictions mean that neither the LinuxCNC
>>> project
>>> nor anyone else may distribute EtherCAT drivers in source code form
>>> or
On 10/24/2013 02:06 PM, andy pugh wrote:
> On 24 October 2013 19:55, John Morris wrote:
>
>> I believe that these restrictions mean that neither the LinuxCNC project
>> nor anyone else may distribute EtherCAT drivers in source code form or
>> otherwise, since with EtherCAT drivers, the software
That's a good point about the out-of-tree users, though I wonder if it
would be better for them to use a standalone libnml version. If there's a
lot of pushback from other users, I can make the few call-by-reference
changes I need under a different name.
To be clear, a total overhaul isn't strictl
On 24 October 2013 19:55, John Morris wrote:
> I believe that these restrictions mean that neither the LinuxCNC project
> nor anyone else may distribute EtherCAT drivers in source code form or
> otherwise, since with EtherCAT drivers, the software would essentially
> become an 'EtherCAT device' s
The main problem would be if there are any out-of-tree users of these
routines. Since it's C there's no function overloading, so we can't
provide both signatures under the same name. So that means the
alternatives are something like:
* do nothing
* break out-of-tree users
* provide the call-by
I've pasted Gerd Hoppe's reply to my inquiry below
Sadly, Gerd makes it quite clear that one needs a technology license
from Beckhoff to distribute an EtherCAT 'device', including a master
software stack, and that it is required to 'maintain compatibility' and,
as a special restriction in the case
In working on the trajectory planner and kinematics, I've noticed that
there is a lot of translation between the EmcPose struct and array-like
data. Examples include (in master):
- emc/kinematics/gantrykins.c:32
- emc/kinematics/5axiskins.c:39
- emc/kinematics/tp.c (multiple)
Could EmcPo
On 10/24/2013 1:23 PM, Robert Ellenberg wrote:
> Hi All,
>
> Many posemath functions (like pmCartCartDot, for example) pass compound
> data types like PmCartesion and PmPose by value. Is there a specific reason
> for this design choice?
>
>
Robert:
The posemath library predates LinuxCNC by a numb
Hi All,
Many posemath functions (like pmCartCartDot, for example) pass compound
data types like PmCartesion and PmPose by value. Is there a specific reason
for this design choice?
It seems like the "right" way is to pass pure inputs by reference using
constant pointers:
Instead of this:
pmCartC
Hi Sam,
I have an entry for line-arc intersections, which have the same
limitations as arc-line (just the order is flipped).
-Rob
On Thu, Oct 24, 2013 at 11:48 AM, sam sokolik wrote:
> you are missing arc-line transitions in your table is this an
> oversite?
>
>
> https://www.dropbox.co
Great! Thanks again for working on this!
sam
On 10/24/2013 10:58 AM, Robert Ellenberg wrote:
> Hi Sam,
> I have an entry for line-arc intersections, which have the same
> limitations as arc-line (just the order is flipped).
>
> -Rob
>
>
> On Thu, Oct 24, 2013 at 11:48 AM, sam sokolik wrote:
>
you are missing arc-line transitions in your table is this an oversite?
https://www.dropbox.com/s/o5he7ijpplkvc8r/Trajectory%20Lookahead%20with%20Arcs.pdf
thanks
sam
On 10/24/2013 10:08 AM, Robert Ellenberg wrote:
> It is possible to do it on the parabolic blends as well. That was actuall
On Thu, Oct 24, 2013 at 09:38:12AM +0800, Yishin Li wrote:
> The license stated from IgH EtherCAT Master for Linux :
> All the source code available through IgH is licensed under the GPLv2
> license.
> http://www.etherlab.org/en/ethercat/index.php
Read on to the paragraph just below, which reads "
It is possible to do it on the parabolic blends as well. That was actually
the original plan. The downside of doing it that way is that the it's hard
to isolate tangential acceleration from the total acceleration, since they
aren't always perpendicular. It also makes the trapezoidal velocity profil
On 2013-10-24 15:30, Kent Reed wrote:
> On Thu, Oct 24, 2013 at 6:15 AM, Michael Haberler wrote:
>
>> src/emc has some 56 references to fields called 'heartbeat', but its
>> unclear what the intent and semantics are - AFAICT the only using code is
>> in xemc.cc where it is used for some kind of ch
On 24 October 2013 15:00, Robert Ellenberg wrote:
> The good news is, we don't have to do any optimization for the conventional
> blends. The idea of using arcs is to create a tangent path that doesn't
> need any blending, but there will be cases where that's not easy, so we
> fall back to tradit
Hi Andy,
The good news is, we don't have to do any optimization for the conventional
blends. The idea of using arcs is to create a tangent path that doesn't
need any blending, but there will be cases where that's not easy, so we
fall back to traditional blending. In this case, the segments start a
On Thu, Oct 24, 2013 at 6:15 AM, Michael Haberler wrote:
> src/emc has some 56 references to fields called 'heartbeat', but its
> unclear what the intent and semantics are - AFAICT the only using code is
> in xemc.cc where it is used for some kind of change detection.
>
> Any idea what that field
On 10/24/2013 02:32 AM, Robert Ellenberg wrote:
> Hi All,
> I've made some progress on the trajectory lookahead features. To test
> the idea of blending with arc segments, I modified the code to be able to
> follow a tangent path without slowing down. There's no blending done in the
> code yet,
>>And the whole licensing thing irritates me.
I agree.. I find it as appealing as filling out tax forms.
Dave
On 10/24/2013 5:05 AM, andy pugh wrote:
> On 24 October 2013 02:38, Yishin Li wrote:
>
>> The license stated from IgH EtherCAT Master for Linux :
>> All the source code available thr
src/emc has some 56 references to fields called 'heartbeat', but its unclear
what the intent and semantics are - AFAICT the only using code is in xemc.cc
where it is used for some kind of change detection.
Any idea what that field was supposed to serve? it looks a bit like 'lets see
whether thi
On 24 October 2013 08:32, Robert Ellenberg wrote:
> https://www.dropbox.com/s/o5he7ijpplkvc8r/Trajectory%20Lookahead%20with%20Arcs.pdf
Something I am not quite clear on is whether it is still possible to
run the "rising tide" optimisation on a conventionally-blended path?
--
atp
If you can't f
On 24 October 2013 02:38, Yishin Li wrote:
> The license stated from IgH EtherCAT Master for Linux :
> All the source code available through IgH is licensed under the GPLv2
> license.
> http://www.etherlab.org/en/ethercat/index.php
The Etherlab EtherCAT Master does appear to be a normal GPL proj
Hi All,
I've made some progress on the trajectory lookahead features. To test
the idea of blending with arc segments, I modified the code to be able to
follow a tangent path without slowing down. There's no blending done in the
code yet, but it's able to follow G-code program that's been pre-mad
29 matches
Mail list logo
