Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)

[Steve Blackmore]

On Mon, 23 Apr 2012 09:05:17 +0300, you wrote:

>2012/4/23 Steve Blackmore :
>>
>> What is ja3?
>
>Joints_axes3 branch in master git repository.
>
>> Is it any wonder that Joe Public has such a poor
>> opinion of EMC/LinuxCNC!! - I've been here 4 years and you've yet to
>> convince me it's not a closed shop speaking in a secret language.
>
>Steve, no offence, I do not think that I am the one to start teaching
>or giving lessons to anybody, I just think that Your attitude harms
>the project too. If You are here for 4 years, then I would expect that

None taken.

>You not only use this application, but also support it. If not with
>any input in code, then at least with some help in answering questions
>of new users and/or spreading positive information about the project
>thus improving the opinion of Joe Public. Unfortunately from Your
>posts in this mailing list and some of Your posts I have seen in
>web-forums I have not seen anything of that, so I have not yet
>understood, why are You here, because it seems to me that You are much
>more a fan of Mach.

I do give credit where it's due. I've often praised EMC/LinuxCNC, and
did so recently in the Mach forum regarding its threading and spindle
behaviour but being selective without giving the whole picture is very
misleading. 

I use LinuxCNC for anything where threading is involved, for everything
else I use a 5 year old version of Mach as it behaves much more Fanuc
like with CV, feed hold etc. The current Mach offerings are buggy as
hell and unreliable.

>On the other hand, I do appreciate Your critics and the weak points of
>the LinuxCNC You have pointed out, like the jog-during-feedhold. The
>thing is that I (probably others as well, but I can speak only for
>myself here) appreciate it as long as it is constructive and has any
>argumentation. For me it helps to understand, where LinuxCNC stands,
>when compared with other CNC controllers (and I do have to provide
>these comparisons with argumentation to my customers, before I get a
>contract with a new customer).

I do a lot of support, development and OEM testing - my nature to call a
spade, a spade - it's what I get paid to do. I don't get upset by
criticism, but sometimes others do and it's got me sacked a few times -
but I've always been able to wear my "told you so" t-shirt proudly a
ways down the line :)

I'll try and keep my comments to myself and leave you guys to it.

Steve Blackmore
--

--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] LinuxCNC & Sandybridge

[Charles Steinkuehler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 4/22/2012 11:25 PM, Karl Schmidt wrote:
> On 04/21/2012 09:37 PM, Charles Steinkuehler wrote:
>> Never mind...I chroot'd into the LinuxCNC Ubuntu install from a 
>> parallel Debian wheezy installation, which allowed me to grab 
>> build-essentials and the Intel e1000e driver source off the 'net.
>> I also installed the linux-image-generic-lts-backport-natty
>> (2.6.38) as a fall-back if I ever need newer HW support
>> temporarily until I can build it for the 2.6.32 RTAI kernel.
> 
> What happens if you use the RTAI kernel in Debian?
> 
> http://packages.debian.org/squeeze/rtai  - stable is using 2.6.32
> kernel


I haven't tested this.  The 2.6.32 kernel is pretty dated (I'm already
building custom modules for it to talk to my motherboard chipset and
it's just going to get worse going forward).  If sticking with 2.6.32
is desired/required, I would think the Debian package would be fine if
you didn't want to just use the Ubuntu LinuxCNC install.

For now, I'm using the Ubuntu Live-CD install for testing with the
RTAI 2.6.32 kernel.

> You could go to testing and the linux-image-3.2.0-2-rt-amd64
> kernel? http://packages.debian.org/wheezy/linux-image-rt-amd64


I'm working on getting that building and operational as a separate
project.  Some other folks have been doing work with the mainline
kernels and the PREEMPT_RT kernel configuration option.  Check the dev
list archives for a few recent threads about this.

> Is there something special about the LinuxCNC patch?


There's not a LinuxCNC patch AFAIK.  Both the RTAI patches and the
PREEMPT_RT patches are general efforts to make the Linux kernel more
responsive for real-time applications.  LinuxCNC sits on top of the
new kernel real-time capabilities but doesn't require any kernel
patching specific _just_ to LinuxCNC.

- -- 
Charles Steinkuehler
char...@steinkuehler.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+VZJ4ACgkQLywbqEHdNFw5xQCg90+eBn5+NxOjxtXV3h5TrFHE
yXsAnif3VWJbhLwVDAX8Lx5FA+W5ljXh
=bOPN
-END PGP SIGNATURE-

--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)

[andy pugh]

On 23 April 2012 01:31, Steve Blackmore  wrote:

> What the f^^^ is ja3?

It isn't really of much relevance to the general user at the moment,
but it is a development branch in which there is no longer an explicit
link between "axes" and "joints". There are places in the current
software where there is an explicit assumption that Axis X is Motor 0
for example, which leads to some inelegancies with non-cartesian
machines such as robots.

It is possible to use JA3, and some people do, but it very much a
work-in-progress.

-- 
atp
The idea that there is no such thing as objective truth is, quite simply, wrong.

--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)

[Kent A. Reed]

On 4/23/2012 2:24 AM, Michael Haberler wrote:
> let's discuss terminology for a minute (paths vs gcode segments)
>
> we have:
> 1. linear G-code programs (no oword control structures)
> 2. G-code with arbitrary control structures
> 3. Some other yet-to-be-invented language for machine control.
>
> execution of any such program generates a path (sequence of moves), which is 
> input to the trajectory planner.
>
> <...>
>
> So for these features the language really drops out of the picture (although 
> it might supply parameters to drive operations on paths), which is why I used 
> the term 'path history'.

As an aside, the choice of language (and the nature of the program 
written in it) will still determine how much work the interpreter has to 
do before a warning sign can loom into view in the headlights (to borrow 
Eric's phraseology) of the trajectory planner. It may not be an issue in 
developing an architecture, but it may still be a performance consideration.
> Any preprocessor-based solution to one of these problems also needs to 
> generate the path, operate on it, and then regenerate matching G-code (which 
> will be the fun part of any such venture).

Not that my opinion as a bystander counts for much, but I'm acutely 
uncomfortable with a preprocessor-based solution as the only effort, in 
part because it annoys me to think of all the work some of us did in the 
80s and 90s to make sure IGES and PDES/STEP could pass NURBS curves and 
surfaces into and out of CAD systems as required in real-world designs 
like cars, ships, airplanes, and most consumer products. First the CAD 
system creates them, then the CAM system destroys them, then a 
preprocessor tries to infer them. Sigh. At a suitable level of 
abstraction, the same problem exists in the CAD world where people keep 
trying to convert back and forth between CAD models consisting of BRep, 
CSG, or other geometric representations and visualization models 
consisting of tessellated surfaces such as triangular meshes. So-called 
surface-reconstruction software demands a premium price in today's market.

On the other hand, those users who see the need can pursue a 
preprocessor-based solution now, not waiting for a better solution that 
may or may not appear at some date in the future. I've never believed in 
letting the perfect be the enemy of the good. If a better solution does 
show up in future, so much the better. One can never have too many tools:-)

Regards,
Kent

PS - sorry for my brain spasm over "CRC" yesterday. A nudge from Andy, a 
new day, a cup of fresh coffee, concentration on subtractive instead of 
additive manufacturing and I'm back in the right ballpark.

--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Fixed Dwell

[dave]

On Sun, 22 Apr 2012 07:25:26 +0100
Mike Bennett  wrote:

> Hi
> 
> I'm nearing the end of building a DIY gantry router.  The router I'm
> using has soft start, so takes several seconds to come up to speed.
> I realise I could add dwell commands to the G-Code, but is it
> possible to add a fixed dwell to Linux CNC after spindle start.
> 
> From reading other posts I see that HAL has a spindle-at-speed input
> that is intended to be used with encoders, but could it be used with
> a timer?
> 
> Mike
> 
> 
> 
> On 22 Apr 2012, at 00:12, charles green  wrote:
> 
> > optimum value for planning ahead for a possible stop or maximum
> > acceleration change:  take current feed for current block and
> > maximum possible accel of machine to get distance required for
> > stop.  then next N blocks that cover that distance, and apply
> > appropriately modified feeds to them.
> > 
> > think of a gcode file as a matrix, each row would correspond to a
> > block, the first several columns are all the various gcodes, the
> > next several are all the various x1..xn axes, then several columns
> > covering offset vectors, feeds, spindle, various Ms, etc.  then
> > just tack on another column that is the achievable feed.  when file
> > is loaded to controller, it gets scanned to fill in the values in
> > the actual feetrate column.  maybe there is another similar column
> > for actual spindle speed that gets filled in similarly, in case
> > it's being used like a c axis to get coordinated revolution.
> > 
> > at program execution, the calculated realistic values columns are
> > used to generate motion. soft program stops during execution may
> > run out a few blocks.  estops are an emergency situation, so who
> > knows..  single stepping is usual one line check based on stop at
> > end of block.
> > 
> > are there not already some 'hidden' columns x1'..xn' that result
> > from cutter radius compensation?
> > 
> > i guess i'm thinking of linear programs, so in the case of loops
> > and subroutine calls, the end result is a much longer list of
> > actually executed blocks.  maybe it never ends (= bad gcode).
> > probing would also not fit the scheme very well - maybe consider
> > probing blocks to be bounded in the code by stops?  or, what if
> > there were choices between more flavors of operation:  advanced
> > lookahead flavor would not allow nuts in it like conditional loops
> > or surprise probings; crazy probe scanner routine mode wouldnt have
> > the texture advantage of nice feedrate smoothness.
> > 
> > 
> > 
> > --- On Sat, 4/21/12, Viesturs Lācis 
> > wrote:
> > 
> >> From: Viesturs Lācis 
> >> Subject: Re: [Emc-users] Trajectory planning and other topics from
> >> a EMC(LinuxCNC) newbie (TheNewbie) To: "Enhanced Machine
> >> Controller (EMC)"  Date:
> >> Saturday, April 21, 2012, 12:58 PM 2012/4/21 Jon Elson
> >> :
> >>> 
> >>> The real problem I see is that RATIONAL G-code that was
> >> correctly written to
> >>> perform a particular operation cannot be executed as
> >> fast as the machine and
> >>> drives COULD allow it to go, due to the stop on next
> >> block requirement.
> >> 
> >> I agree.
> >> What I see the big issue for solving this in trajectory
> >> planner or
> >> whatever _inside_ LinuxCNC is that I do not see, how to
> >> determine by
> >> some hard facts, what is the best way to determine the
> >> lookup amount.
> >> Certain number of lines or a certain travel distance? Ok,
> >> when the
> >> method is chosen, how to determine, what is the optimum
> >> value?
> >> 
> >> That is why I am in favor of adding a separate filter, which
> >> would
> >> take the code and rephrase it to what is really in there -
> >> either arcs
> >> or splines/nurbs. In this case the file would be processed,
> >> when
> >> loaded (I have not really understood, when it would be
> >> processed in
> >> the first variant - also on loading or on the fly, when it
> >> is
> >> executed), so it definitely would not affect realtime
> >> performance,
> >> because the file would not be executed at that time. I think
> >> that
> >> waiting 10-20 seconds for the PC to recalculate the path and
> >> find,
> >> what curves would fit the existing profile, defined by tiny
> >> G1s.
> >> 
> >> Viesturs
> >> 

G4 P 

is meant to delay movement while the spindle gets up to speed. 

Dave
> >> --
> >> For Developers, A Lot Can Happen In A Second.
> >> Boundary is the first to Know...and Tell You.
> >> Monitor Your Applications in Ultra-Fine Resolution. Try it
> >> FREE!
> >> http://p.sf.net/sfu/Boundary-d2dvs2
> >> ___
> >> Emc-users mailing list
> >> Emc-users@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/emc-users
> >> 
> > 
> > --
> > For Developers, A Lot Can Happen In A Second.
> > Boundary is the first to Know...and Tell You.
> 

Re: [Emc-users] Fixed Dwell

[gene heskett]

On Monday, April 23, 2012 01:54:59 PM dave did opine:
> > >> 
> > >> Viesturs
> 
> G4 P 
> 
> is meant to delay movement while the spindle gets up to speed.
> 
> Dave

Which works fine Dave, BUT must be written into every piece of code that 
will be executed.  Far better IMO to configure linuxcnc, in the hal file, 
to do it automatically so there aren't any "I forgot" surprises.  And some 
snippets posted here in the last days would appear to handle that nicely, 
either with a fixed delay, or even by a spindle_at_speed signal if a valid 
one can be derived from the hardware itself.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: 
An American's a person who isn't afraid to criticize the president but is
always polite to traffic cops.

--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] axis-remote issues

[Les Newell]

I am trying to use axis-remote and get the following error when I try to 
send a command to Axis:

emc@emc-desktop:~$ axis-remote --reload
X server insecure (must use xauth-style authorization); command ignored

Has anyone else come across this and if so, how did you get around it?

Les

--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] axis-remote issues

[andy pugh]

On 23 April 2012 19:22, Les Newell  wrote:

> X server insecure (must use xauth-style authorization); command ignored
>
> Has anyone else come across this and if so, how did you get around it?

It looks like Michael Haberler has had the problem, and fixed it:
http://code.google.com/p/heekscnc/source/detail?r=1240

-- 
atp
The idea that there is no such thing as objective truth is, quite simply, wrong.

--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] axis-remote issues

[Dewey Garrett]

A work around for this (or at least a similar problem occuring with Ubuntu
10.04 and tk8.5) was incorporated in axis (v2.5 or later):

http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=commit;h=e863002919cd1fc0c8395abbe29fcec14e5c1cae


You can also try the shell commands directly as:

$   xhost -SI:localuser:gdm -SI:localuser:root

on the machine displaying axis (the XServer)
-- 
Dewey Garrett


--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)

[Steve Blackmore]

On Mon, 23 Apr 2012 17:01:30 +0100, you wrote:

>On 23 April 2012 01:31, Steve Blackmore  wrote:
>
>> What the f^^^ is ja3?
>
>It isn't really of much relevance to the general user at the moment,
>but it is a development branch in which there is no longer an explicit
>link between "axes" and "joints". There are places in the current
>software where there is an explicit assumption that Axis X is Motor 0
>for example, which leads to some inelegancies with non-cartesian
>machines such as robots.
>
>It is possible to use JA3, and some people do, but it very much a
>work-in-progress.

Thanks for the explanation Andy.

Steve Blackmore
--

--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Trajectory planning and other topics from a EMC(LinuxCNC) newbie (TheNewbie)

[Chris Morley]

I was searching the web and came across this paper:
about nurbs planning including s curve acceleration.

www.cadanda.com/CAD_4_1-4__34.PDF

Above my pay grade but interesting.

I was also thinking it would be interesting to discuss
the frame work of a linuxcnc3.

Is it useful to start clean on everything?
What would we drop and/or add to a must-have list.
What would the goals be?
What have we learned so far good and bad?
Who would actually be interested in doing the work?
And on the side of that who would/could document the
innards of linuxcnc so some less skilled programmers 
could contribute.

Just to start the discussion:

I think HAL as a whole would be pretty much just used 
as is. I'm sure some technical things could be improved
but the  modularity, flexibility and relative simplicity of
HAL sure makes it a winner.

Personally I'd like to see the languages pared down to
C,C++, and python. Which it seems we are mostly going
that way anyways.

I would think that it would be a long term goal much like JA3.

Of course I'm thinking on the developers side, what do integrators
wish for?  I mean besides jog while paused :)
Is S curve acceleration or look ahead really a wanted feature?
Are people happy with the GUI/ screen options that are starting
to open up?
 
Chris M
  
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users