Re: [Emc-developers] normal.z=0.039370

[andy pugh]

On 12 October 2015 at 06:44, EBo  wrote:
> I agree with option #3.  The question is what g-code whould be
> defined/chosen?   How about G78.9 (a generalization of G17, G18, and
> G19)?

I note that G16 is spare and that whereas some G-code systems use G15
/ G16 to switch between polar and cartesian coordinates, LinuxCNC
already has polar coordinates without a mode-switch so will never need
those codes for that purpose.

I like the idea of arbitrary arcs in theory, but at the same time no
CAM system would know how to use it, and only a very small sub-set of
hand-coders would use it. However those that did might well be very
grateful.

I think it would end up like the polar-coordinate syntax, useful to
those that know about it, but not widely used.

(FWIW I use polar coordinates quite frequently, it is ideal for
MDI-ing a bolt circle)

-- 
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

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

Re: [Emc-developers] normal.z=0.039370

[Stuart Stevenson]

>
> --
>
> Message: 5
> Date: Mon, 12 Oct 2015 08:54:45 -0500
> From: Chris Lesiak 
> Subject: Re: [Emc-developers] normal.z=0.039370
> To: 
> Message-ID: <561bbba5.6020...@licor.com>
> Content-Type: text/plain; charset="windows-1252"; format=flowed
>
> On 10/12/2015 08:08 AM, andy pugh wrote:
> > I think we need to consider whether we want arbitrary arcs or
> > arbitrary working planes. They are not really the same thing. Out of
> > interest, with the Heidenhain code, what happens to the apparent XYZ
> > when you change plane? Are XYZ still in machine cartesian space, or
> > does the entire coordinate system shift?
>
> If you decide that arbitrary working plane is the way to go, you might
> also consider the Fanuc model.
>
> G68 X Y Z I J K R
>
Chris,
thanks for the clarification :)
heh - this IS the correct command - my memory was fuzzy


> X, Y, and Z specify the origin of the transformed coordinate system.  I,
> J, and K specify a vector about which the coordinate system is rotated
> by angle R.  It is possible to have two G68 transformations active at
> once, the second applied on top of the first.
>
> G69 cancels all G68 coordinate transformations.
>
> --
> Chris Lesiak
> Principal Design Engineer, Software
> LI-COR, Inc.
> chris.les...@licor.com
>
> Any opinions expressed are those of the author and
> do not necessarily represent those of his employer.
>
>
>
I think we should be able to probe coordinate rotations

Two points for a plane rotation and three for a complete coordinate system
orientation

thanks
Stuart

-- 
Addressee is the intended audience.
If you are not the addressee then my consent is not given for you to read
this email furthermore it is my wish you would close this without saving or
reading, and cease and desist from saving or opening my private
correspondence.
Thank you for honoring my wish.
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] normal.z=0.039370

[Chris Lesiak]

On 10/12/2015 08:08 AM, andy pugh wrote:
> I think we need to consider whether we want arbitrary arcs or 
> arbitrary working planes. They are not really the same thing. Out of 
> interest, with the Heidenhain code, what happens to the apparent XYZ 
> when you change plane? Are XYZ still in machine cartesian space, or 
> does the entire coordinate system shift? 

If you decide that arbitrary working plane is the way to go, you might 
also consider the Fanuc model.

G68 X Y Z I J K R

X, Y, and Z specify the origin of the transformed coordinate system.  I, 
J, and K specify a vector about which the coordinate system is rotated 
by angle R.  It is possible to have two G68 transformations active at 
once, the second applied on top of the first.

G69 cancels all G68 coordinate transformations.

-- 
Chris Lesiak
Principal Design Engineer, Software
LI-COR, Inc.
chris.les...@licor.com

Any opinions expressed are those of the author and
do not necessarily represent those of his employer.


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

Re: [Emc-developers] normal.z=0.039370

[TJoseph Powderly]

On 10/12/2015 08:08 AM, andy pugh wrote:
> On 12 October 2015 at 13:59, TJoseph Powderly  wrote:
>> Hint: you only need 2 angles, 3 is really overconstrained.
>> It ___really___ makes programming easy.
>> All programming is just like you had a trunnion table.
>
> You can do this already in LinuxCNC with kinematics, I think (not that
> that is necessarily the right way)
>
> I think we need to consider whether we want arbitrary arcs or
> arbitrary working planes. They are not really the same thing.
>
> Out of interest, with the Heidenhain code, what happens to the
> apparent XYZ when you change plane? Are XYZ still in machine cartesian
> space, or does the entire coordinate system shift?
>
tricky question because it requires some explanation of the Heidenhain 
way of thinking.
These plane tiltings were intended to be a modal change prior to calling 
very controlled user macros ( filled in by conversational dialogs )
These were crafted to avoid any misallignment of measuring systems.
In them, I inspected the current position, insured the current position 
was stable, then tipped the plane from HERE, so no jerk occured, THEN 
allowed motion. Motion was relative to the macro's start position (HERE)
The user moved in cartesian space PRIOR to tipping the plane and calling 
my macros. Exit of the macro UN-Tipped the plane.

Since Heidenhain has thousand of work offests arranged in tables 
(DATUMS), the use simply reference a datum to work at ( identify the 
Datum table and the index into that file ). That caused the DRO to 
change ( it was now measuring form the new datum ). Then he moved to 
0,0,0,0,0,0,0,0,0 and called the plane function ( tilt ) then the action 
( one of many macros for thread at arbitrary angles etc ).

Once tilted, the DRO acted like 'normal'. You could select an alternate
screen to display it in Machine coordinates or Cartesian. But, once 
tilted, its easier to think in terms of the new plane.

the sequence was
finish one detail
pick next detail datum
move there
tilt plane
call macro
...
rinse repeat

hey i just listed 2 of the controls on eBay if you'd liek to play ;)
works fine for mills but can do real 5 axis sink edm too.

i'd like to see how it could be done in kinematics
I hope to get back into this soon, moving now

HTH
TomP tjtr33

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

Re: [Emc-developers] normal.z=0.039370

[TJoseph Powderly]

On 10/12/2015 08:50 AM, Stuart Stevenson wrote:
> Gentlemen,
> On my Fanuc 15mb control I would use G68 and G69 to rotate the coordinate
> system.
> I was allowed to rotate any axis by an amount
>
> ex.
> G68 X0 Y0 Z1 R20 was a rotation of the XY plane by 20 degrees. I am not
> sure R was the correct symbol but the example still stands. I was only
> allowed to one of the planes XY, YZ, ZX at a time.
>
> A second G68 would then rotate one of the other planes by a specified
> amount.
> ex.
> G68 X1 Y0 Z0 R20 rotated the ZX plane 20 degrees.
>
>   I was allowed to use two G68 lines, one right after the other.
> ex.
> G68 X0 Y0 Z1 R20
> G68 X1 Y0 Z0 R20
> would rotate the XY plane by 20 degrees and then rotate the YZ plane by 20
> degrees giving me a 3D coordinate system to work in.
>
> G69 would cancel the G68 coordinate system modification.
>
> This allowed me to align the Z axis normal to any surface on a prismatic
> part and use all of the mill/drill cycles (G01, G02, G03, G81, ...) normal
> to the face of the part.
>
> This, to me, was a very useful feature and worked until the
> manufacturer/integrator changed the pulse generator switches and added
> three more steps.
> We now have X Y Z B C (unmarked) (unmarked) (unmarked)
> The three unmarked switches all the pulse generator to:
>
> 1: Move the Z axis as if it is a quill. This allows drilling at whatever
> angle the tool is pointing. I would call this the W axis.
>
> 2: Move the tool in a X axis facing motion with the XY plane rotated to a
> normal position to the Z axis. I would call this the U axis
>
> 3: The same as 2 but with the tool moving in a Y axis facing motion. I
> would call this the V axis
>
> After the integrator implemented this 'feature' G68/G69 no longer was a
> valid command.
>
> thanks
> Stuart
>
Yes Stuart, great example of tilting planes.
My dialogs asked 'rotaion about Z'  then 'Rotation from X+'
( I wrote a lot of user dialogs in Heidenhain, aka 'conversational' )
I also had a custom macro 'untilt' , as well as 'unshift' and 'unrot'
No parms for these, they just returned to normality.
tomp tjtr33

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

Re: [Emc-developers] normal.z=0.039370

[TJoseph Powderly]

On 10/12/2015 08:54 AM, Chris Lesiak wrote:
> On 10/12/2015 08:08 AM, andy pugh wrote:
>> I think we need to consider whether we want arbitrary arcs or
>> arbitrary working planes. They are not really the same thing. Out of
>> interest, with the Heidenhain code, what happens to the apparent XYZ
>> when you change plane? Are XYZ still in machine cartesian space, or
>> does the entire coordinate system shift?
>
> If you decide that arbitrary working plane is the way to go, you might
> also consider the Fanuc model.
>
> G68 X Y Z I J K R
>
> X, Y, and Z specify the origin of the transformed coordinate system.  I,
> J, and K specify a vector about which the coordinate system is rotated
> by angle R.  It is possible to have two G68 transformations active at
> once, the second applied on top of the first.
>
> G69 cancels all G68 coordinate transformations.
>
yes consider these as models
not the final implementation,
the PMAC and Aerotech solutions are also different
but Roberts suggestion that its an underlying translation
that rules the way the standard interpreter acts afterwards
is a good idea.
The user interface is separate from the benefit/action
TomP tjtr33

BTW when a simple ROTATE (not the 3D titl plane )
is used on Heidenhain, theres a
machine parm that allows the DRO to show the new X' and Y'
so radial moves make more sense.


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

Re: [Emc-developers] normal.z=0.039370

[andy pugh]

On 12 October 2015 at 13:59, TJoseph Powderly  wrote:
> Hint: you only need 2 angles, 3 is really overconstrained.
> It ___really___ makes programming easy.
> All programming is just like you had a trunnion table.

You can do this already in LinuxCNC with kinematics, I think (not that
that is necessarily the right way)

I think we need to consider whether we want arbitrary arcs or
arbitrary working planes. They are not really the same thing.

Out of interest, with the Heidenhain code, what happens to the
apparent XYZ when you change plane? Are XYZ still in machine cartesian
space, or does the entire coordinate system shift?

-- 
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

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

Re: [Emc-developers] normal.z=0.039370

[Stuart Stevenson]

Gentlemen,
On my Fanuc 15mb control I would use G68 and G69 to rotate the coordinate
system.
I was allowed to rotate any axis by an amount

ex.
G68 X0 Y0 Z1 R20 was a rotation of the XY plane by 20 degrees. I am not
sure R was the correct symbol but the example still stands. I was only
allowed to one of the planes XY, YZ, ZX at a time.

A second G68 would then rotate one of the other planes by a specified
amount.
ex.
G68 X1 Y0 Z0 R20 rotated the ZX plane 20 degrees.

 I was allowed to use two G68 lines, one right after the other.
ex.
G68 X0 Y0 Z1 R20
G68 X1 Y0 Z0 R20
would rotate the XY plane by 20 degrees and then rotate the YZ plane by 20
degrees giving me a 3D coordinate system to work in.

G69 would cancel the G68 coordinate system modification.

This allowed me to align the Z axis normal to any surface on a prismatic
part and use all of the mill/drill cycles (G01, G02, G03, G81, ...) normal
to the face of the part.

This, to me, was a very useful feature and worked until the
manufacturer/integrator changed the pulse generator switches and added
three more steps.
We now have X Y Z B C (unmarked) (unmarked) (unmarked)
The three unmarked switches all the pulse generator to:

1: Move the Z axis as if it is a quill. This allows drilling at whatever
angle the tool is pointing. I would call this the W axis.

2: Move the tool in a X axis facing motion with the XY plane rotated to a
normal position to the Z axis. I would call this the U axis

3: The same as 2 but with the tool moving in a Y axis facing motion. I
would call this the V axis

After the integrator implemented this 'feature' G68/G69 no longer was a
valid command.

thanks
Stuart

-- 
Addressee is the intended audience.
If you are not the addressee then my consent is not given for you to read
this email furthermore it is my wish you would close this without saving or
reading, and cease and desist from saving or opening my private
correspondence.
Thank you for honoring my wish.
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] normal.z=0.039370

[EBo]

On Oct 12 2015 10:01 AM, Stuart Stevenson wrote:
>
> I think we should be able to probe coordinate rotations
>
> Two points for a plane rotation and three for a complete coordinate 
> system
> orientation

If you only probe 2, there are special collinear cases which could 
still be two of the three standard planes.  I think you have to choose 
three to definitively define even the the three standard ones (without 
having to worry about special cases.

   EBo --


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

Re: [Emc-developers] normal.z=0.039370

[EBo]

On Oct 12 2015 9:42 AM, TJoseph Powderly wrote:
>
> BTW when a simple ROTATE (not the 3D titl plane )
> is used on Heidenhain, theres a
> machine parm that allows the DRO to show the new X' and Y'
> so radial moves make more sense.

I can see that being useful, but if that functionality was added to 
LCNC what would the interface look like?

   EBo --


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

Re: [Emc-developers] normal.z=0.039370

[TJoseph Powderly]

On 10/12/2015 12:20 PM, EBo wrote:
> On Oct 12 2015 9:42 AM, TJoseph Powderly wrote:
>>
>> BTW when a simple ROTATE (not the 3D titl plane )
>> is used on Heidenhain, theres a
>> machine parm that allows the DRO to show the new X' and Y'
>> so radial moves make more sense.
>
> I can see that being useful, but if that functionality was added to
> LCNC what would the interface look like?
>
> EBo --
>
>
> --
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
the dros stay the same, theres just a dialog ( and maybe a notification 
like tool number, that identifies the current translation values )

NB, often, you'll be moving the 'X' axis but if you watch the Machine 
coordinates, you will see many axis moving ;) Its a brain teaser for 
those unaccustomed to it

tomp tjtr33

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

Re: [Emc-developers] normal.z=0.039370

[TJoseph Powderly]

On 10/12/2015 12:11 PM, EBo wrote:
> On Oct 12 2015 10:01 AM, Stuart Stevenson wrote:
>>
>> I think we should be able to probe coordinate rotations
>>
>> Two points for a plane rotation and three for a complete coordinate
>> system
>> orientation
>
> If you only probe 2, there are special collinear cases which could
> still be two of the three standard planes.  I think you have to choose
> three to definitively define even the the three standard ones (without
> having to worry about special cases.
>
> EBo --
>
>
> --
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
yes people like to do this.
remember there is a loss of precision when you do this.
your stepper or sale cannot resolve the 1/2 or less units that
the translation incurs. thats why putting stuff on the table and 
indicating it in is a _good_ idea.
tomp tjtr33


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

[Emc-developers] Timing of realtime functions in uspace

[Pekka Roivainen]

Hello!

I'm building an ethernet based IO board to be used with LinuxCNC. I 
wrote a short webpage about my project on www.pekka.eu/cnc

Everything is working quite well, except for the write and read 
operations being too slow. I have two functions exported to HAL, read 
and write. The .time pin which is automatically exported to HAL for each 
function states that the execution time of the read and write functions 
are about 45ns and 4ns respectively. For debugging, I generated 
my own pins for both functions to measure the execution time of the 
function itself. I measure the execution time by calling 
rtapi_get_time() in the very beginning of the function and in the end. I 
calculate the difference and pass it to a HAL pin. By examining the 
values of these pins, I see that the execution times according to 
rtapi_get_time() are about 22ns and 18000ns for read and write. So 
it seems that the execution time stated by HAL is a bit more than double 
the execution time of the function itself. The 220us execution time for 
the read would be something that I'd expect from my hardware, but when 
it's doubled it starts to be too much for running servo thread with 1kHz.

Is this expected behavior? It sounds a bit strange to me, especially as 
the ratio between the two measurements is quite close to two. I have 
checked like million times that I don't have the functions added to the 
treads twice or something other stupid things, but I cannot seem to find 
anything like that. Does anyone have any hints?

I have tested my software with Debian Wheezy, kernel 3.2.0-4-rt-686-pae 
and with LinuxCNC versions 2.7.0~pre6 and 2.7.0.

Thank you for any comments.

Regards,
Pekka Roivainen


PS. This being my first post ever to this list, I want to express my 
greatest gratitude to all the developers of LinuxCNC. This is a 
fantastic piece of software.



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

Re: [Emc-developers] normal.z=0.039370

[EBo]

On Oct 12 2015 12:38 PM, TJoseph Powderly wrote:
> On 10/12/2015 12:11 PM, EBo wrote:
>> On Oct 12 2015 10:01 AM, Stuart Stevenson wrote:
>>>
>>> I think we should be able to probe coordinate rotations
>>>
>>> Two points for a plane rotation and three for a complete coordinate
>>> system
>>> orientation
>>
>> If you only probe 2, there are special collinear cases which could
>> still be two of the three standard planes.  I think you have to 
>> choose
>> three to definitively define even the the three standard ones 
>> (without
>> having to worry about special cases.
>>
> yes people like to do this.
> remember there is a loss of precision when you do this.
> your stepper or sale cannot resolve the 1/2 or less units that
> the translation incurs. thats why putting stuff on the table and
> indicating it in is a _good_ idea.
> tomp tjtr33

I'm actually a fan of taking statistically meaningful samples for such 
things.  I would have to look at the error propagation, but given 
sufficient samples you can resolve the 1/2 step transition as long as 
the errors are normally distributed.  That raises the question on how 
the bed/part/etc. would be sampled (to account for any swarf or 
deformations in the probed part, etc.).  That said, there is very good 
reason to indicate it in as you suggest.

   EBo --

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

Re: [Emc-developers] Timing of realtime functions in uspace

[Pekka Roivainen]

On 10/12/2015 11:27 PM, emc-developers-requ...@lists.sourceforge.net wrote:
> Date: Mon, 12 Oct 2015 13:27:36 -0700 (PDT)
> From: "Peter C. Wallace"
> Subject: Re: [Emc-developers] Timing of realtime functions in uspace
> To: EMC developers
> Message-ID:
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
> On Mon, 12 Oct 2015, Pekka Roivainen wrote:
>
>> >Date: Mon, 12 Oct 2015 22:55:03 +0300
>> >From: Pekka Roivainen
>> >Reply-To: EMC developers
>> >To:emc-developers@lists.sourceforge.net
>> >Subject: [Emc-developers] Timing of realtime functions in uspace
>> >
>> >Hello!
>> >
>> >I'm building an ethernet based IO board to be used with LinuxCNC. I
>> >wrote a short webpage about my project onwww.pekka.eu/cnc
>> >
>> >Everything is working quite well, except for the write and read
>> >operations being too slow. I have two functions exported to HAL, read
>> >and write. The .time pin which is automatically exported to HAL for each
>> >function states that the execution time of the read and write functions
>> >are about 45ns and 4ns respectively. For debugging, I generated
>> >my own pins for both functions to measure the execution time of the
>> >function itself. I measure the execution time by calling
>> >rtapi_get_time() in the very beginning of the function and in the end. I
>> >calculate the difference and pass it to a HAL pin. By examining the
>> >values of these pins, I see that the execution times according to
>> >rtapi_get_time() are about 22ns and 18000ns for read and write. So
>> >it seems that the execution time stated by HAL is a bit more than double
>> >the execution time of the function itself. The 220us execution time for
>> >the read would be something that I'd expect from my hardware, but when
>> >it's doubled it starts to be too much for running servo thread with 1kHz.
>> >
>> >Is this expected behavior? It sounds a bit strange to me, especially as
>> >the ratio between the two measurements is quite close to two. I have
>> >checked like million times that I don't have the functions added to the
>> >treads twice or something other stupid things, but I cannot seem to find
>> >anything like that. Does anyone have any hints?
>> >
>> >I have tested my software with Debian Wheezy, kernel 3.2.0-4-rt-686-pae
>> >and with LinuxCNC versions 2.7.0~pre6 and 2.7.0.
>> >
>> >Thank you for any comments.
>> >
>> >Regards,
>> >Pekka Roivainen
>> >
>> >
>> >PS. This being my first post ever to this list, I want to express my
>> >greatest gratitude to all the developers of LinuxCNC. This is a
>> >fantastic piece of software.
>
> Did you scale the hal times correctly? They are in CPU clocks, not ns
>
>
Thanks for this info Peter. I had no clue those times were presented as 
clock cycles. By checking lscpu, my laptop seems to run at 800MHz. The 1 
nanosecond scale I was expecting would be the same as 1GHz clock 
frequency so according to that the difference should be 1.25 and not 2. 
But I need to continue investigating with that new bit of info. Thanks 
again!

Pekka

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

Re: [Emc-developers] normal.z=0.039370

[Jullian]

Thanks, i will do some research on the TP codes.


2015年10月12日星期一，Robert Ellenberg  写道：
> Hi Julian,
>
> As you've discovered, the trajectory planner itself can already create
arcs
> in an arbitrary plane. However, the interpreter and canon only support the
> subset that Jeff mentioned. Internally, the TP's circular arc segment is
> defined with a start point, end point, center point, and normal vector.
> Depending on the normal vector, the result is either a circular arc in the
> plane perpendicular to the normal, or a helix with the helical axis along
> the normal vector. It would be possible to support arbitrary-plane arcs in
> linuxcnc if we added interpreter / canon / plotting support, but we'd have
> to decide how to support such a thing in G-code. Here are a few options I
> can see:
>
>
>1. Extend existing G2 / G3 with an additional mode to interpret (X Y Z)
>as the end point, and ( I J K) as the center point of a spherical arc
(with
>no helical component). This is nice because it wouldn't require any
>additional parameters. Unfortunately, as Brian pointed out, it breaks
down
>for 180 deg arcs.
>2. Create a from-scratch G code that accepts 9 parameters (X Y Z as end
>point, I J K as center, and 3 others for a normal). This would solve
the
>180 deg problem (as well as the clockwise / counterclockwise problem),
but
>will be a pain to get a valid normal direction. This would make sense
only
>if there was an existing standard that CAM or other CNC controllers
>supported, and we wanted to emulate it.
>3. Add a G code to specify an arbitrary normal vector for all circular
>arcs (i.e. generalize G17-G19). This would be nice because it
preserves the
>current G2 / G3 behavior, and having an explicit normal direction
solves
>the 180 deg problem. It would involve a bunch of changes (adding extra
>modal state for the normal vector, and re-writing canon's
arc-processing
>code to handle an arbitrary normal).
>
> I'd vote for (3) if anything because it doesn't change existing syntax,
and
> it would be easier to write G-code by hand to use it. Still, it's not
> something that can happen overnight due to the scope of the changes.  Is
> anyone else interested in this capability? It will be a few months before
I
> can devote serious time to it, but I'd be willing to take a crack at it
> eventually if there's enough demand.
>
> -Rob
> On Fri, Oct 9, 2015, 7:10 PM Jullian  wrote:
>
>> Thanks for the replies,
>> Now, it's sure that a generic 3D arc is not supported by g-code。
>> But in the LinuxCNC'' codes, it has the following code like:
>> typedef struct {
>> SphericalArc xyz;
>> PmCartesian abc;
>> PmCartesian uvw;
>> } Arc9;
>>
>> is not these codes to implement  the generic arbitrary arc??
>>
>> 2015-10-09 21:06 GMT+08:00 Jeff Epler :
>>
>> > On Fri, Oct 09, 2015 at 01:09:50PM +0800, Jullian wrote:
>> > > Thanks,Jeff,
>> > > no bug, it's my comprehension fault,
>> > >
>> > > What i wonder now is that how the LinuxCNC do a spherical 3D arc by
>> > G_Code
>> > > or by other way?
>> >
>> > As far as I know, LinuxCNC's gcode dialect does not allow specification
>> > of fully generic arcs.
>> >
>> > You can get arcs with the normal in the Z direction in G17.  In G18 or
>> > G19 you can get arbitrary mixtures of X and Y in the normal by using
>> > coordinate system rotation (G10's R value).  But right now you can't
get
>> > an arc where the normal has a Z component and an XY component.
>> >
>> > I'm not aware of any current project to change this, but it would not
be
>> > unwelcome.  One challenge is the gcode syntax: how do you specify the
>> > normal to be used?  I think many of the other layers of code are
>> > prepared to accept arbitrary arcs, though the preview plots may need
>> > additional modification.
>> >
>> > Jeff
>> >
>> >
>> >
>>
--
>> > ___
>> > Emc-developers mailing list
>> > Emc-developers@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/emc-developers
>> >
>>
>>
--
>> ___
>> Emc-developers mailing list
>> Emc-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-developers
>>
>
--
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net

Re: [Emc-developers] Emc-developers Digest, Vol 114, Issue 13 (Ethernet, STM32F407)

[Karlsson & Wang]

> > Date: Mon, 12 Oct 2015 22:55:03 +0300
> > From: Pekka Roivainen 
> > Reply-To: EMC developers 
> > To: emc-developers@lists.sourceforge.net
> > Subject: [Emc-developers] Timing of realtime functions in uspace
> > 
> > Hello!
> >
> > I'm building an ethernet based IO board to be used with LinuxCNC. I
> > wrote a short webpage about my project on www.pekka.eu/cnc
> >
> > Everything is working quite well, except for the write and read
> > operations being too slow. I have two functions exported to HAL, read
> > and write. The .time pin which is automatically exported to HAL for each
> > function states that the execution time of the read and write functions
> > are about 45ns and 4ns respectively. For debugging, I generated
> > my own pins for both functions to measure the execution time of the
> > function itself. I measure the execution time by calling
> > rtapi_get_time() in the very beginning of the function and in the end. I
> > calculate the difference and pass it to a HAL pin. By examining the
> > values of these pins, I see that the execution times according to
> > rtapi_get_time() are about 22ns and 18000ns for read and write. So
> > it seems that the execution time stated by HAL is a bit more than double
> > the execution time of the function itself. The 220us execution time for
> > the read would be something that I'd expect from my hardware, but when
> > it's doubled it starts to be too much for running servo thread with 1kHz.
> >
> > Is this expected behavior? It sounds a bit strange to me, especially as
> > the ratio between the two measurements is quite close to two. I have
> > checked like million times that I don't have the functions added to the
> > treads twice or something other stupid things, but I cannot seem to find
> > anything like that. Does anyone have any hints?
> >
> > I have tested my software with Debian Wheezy, kernel 3.2.0-4-rt-686-pae
> > and with LinuxCNC versions 2.7.0~pre6 and 2.7.0.
> >
> > Thank you for any comments.
> >
> > Regards,
> > Pekka Roivainen

I use the STM32F407 with the hostmot2 driver. I had some glitches at startup 
but today I added a small delay someone here suggested end then startup works 
perfect every time with two cards connected.

I have been running two axes with DC servo motors and ordinary encoders on one 
of the cards although both cards should be used to get 4 axis. I ran servo loop 
at 1kHz but expect somewhat faster will also work.

Nicklas Karlsson

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