Messages about installing and using EMC

Eric H. Johnson | 2 Feb 2007 23:05

Re: Help with CVS

John, et al,

After digging through the documentation a little more, what I see is that
lcdproc is distributed as debian packages, which should make integrating
with EMC fairly easy. Further, the interface is via a standard tcp socket.
Thus no language specific interface is required, although a common interface
module could be written to standardize the interface between lcdproc and
EMC.

Thus from the perspective of EMC, it could include just the binary package,
or create a sub-branch which includes all of the lcdproc source code too.
Unlike classic ladder, it appears that no modifications to lcdproc would be
required to use it with EMC. Which means the latest binaries should always
be compatible, unless of course an upgrade was made which broke backwards
compatibility.

What would be the recommended approach, from the perspective of the EMC
source code? Obviously the binary install would include just the binaries.
But should the lcdproc source code be included with the EMC source code, or
should that always run from the binaries, and just reference lcdproc as a
separate open source project?

Regards,
Eric

> (This is me speaking as in individual developer who happens 
> to be on the board, not speaking for the board as a whole.)
> 
> I really don't want any developers to feel that they need 
> "board approval"

(Continue reading)

Eric H. Johnson | 3 Feb 2007 14:53

Re: Including LCDproc in EMC - was: Help with CVS

Hi all,

After going through more of the LCDproc documentation, it looks to me as
though it can mostly be made an ordinary dependent package of EMC, like
tk/tcl, python or ncurses. LCDproc itself is split into servers and clients,
where only the server needs to be included and where clients would be added
the same way as any other EMC user interface (tkemc, axis, etc). Optionally,
only the drivers supported by these user interfaces could be included, or
more generically, include all of them.

What is above my pay grade at this point is how EMC itself gets packaged. I
did not find instructions for that on linuxcnc.org. The instructions for
packaging LCDproc are as follows:

-- CREATING DISTRIBUTION SPECIFIC PACKAGES --------------------------

Instead of manually configuring, compiling and installing LCDproc you
may use the support files in the LCDproc source tree to create an
installation package specific to your distribution

Debian:
      - Rename the .tgz file with the sources to lcdproc_VERSION.orig.tar.gz
        cp lcdproc-VERSION.tgz lcdproc_VERSION.orig.tar.gz
      - Extract the source tar ball
        tar xvzf lcdproc_VERSION.orig.tar.gz
      - Copy the debian/ directory below scripts/ to the root of the
        source tree
	  cp -a lcdproc-VERSION/scripts/debian lcdproc-VERSION/
      - Generate .deb debian package
	  cd lcdproc-VERSION/

(Continue reading)

Kenneth Lerman | 5 Feb 2007 15:23

Interpreter Error Messages and Configuration Question


In my continuing quest to improve the interpreter, I've come across a couple
of issues where I'd like some guidance.

The change I'm working on now has two aspects:

1 -- If there is a call to a subroutine that has not already been defined,
the interpreter first looks to see if there is another file that defines the
o-word. It does this by looking for a file named oNNNN (where NNNN is the
number of the o-word).

2 -- If there is no such file, it then starts skipping forward in the
current file until it finds the o-word. If there is no such o-word in the
current file, it is an error.

This capability allows files that have been executed in this manner to
reference o-words in other files with a limitation of the maximum number of
subroutine levels. At the present time, this is set at ten, but could easily
be increased.

This facility would let us have libraries of gcode that would be included by
reference. The next step would be to support named o-words. So,
o<InterpolateCircle>   would be a valid o-word, and would cause the file
InterpolateCircle to be loaded. (In the case of named o-words, I would not
put the letter 'o' in front of the name.)

The following issues arise:

1 -- What directory (or directories) should the interpreter look in for the
file oNNNN?  Some alternatives are: (a) a fixed directory, (b) specify a

(Continue reading)

Ray Henry | 5 Feb 2007 16:13

Re: Interpreter Error Messages and Configuration Question


Hi Ken

Thank you for your continuing quest.

On Mon, 2007-02-05 at 09:23 -0500, Kenneth Lerman wrote:
> In my continuing quest to improve the interpreter, I've come across a couple
> of issues where I'd like some guidance.
> 
> The change I'm working on now has two aspects:
> 
> 1 -- If there is a call to a subroutine that has not already been defined,
> the interpreter first looks to see if there is another file that defines the
> o-word. It does this by looking for a file named oNNNN (where NNNN is the
> number of the o-word).
> 
> 2 -- If there is no such file, it then starts skipping forward in the
> current file until it finds the o-word. If there is no such o-word in the
> current file, it is an error.

Some systems do place all of the subroutines at the end rather than the
beginning of a program so this should be a good addition.  I also like
very much the idea of the ability to use libraries of common
subroutines.  I'd be much less enthusiastic about us supplying a library
as a part of a distribution.  

> This capability allows files that have been executed in this manner to
> reference o-words in other files with a limitation of the maximum number of
> subroutine levels. At the present time, this is set at ten, but could easily
> be increased.

(Continue reading)

petr ruzicka | 5 Feb 2007 13:31

Picon

EMC2 Ubuntu 6.06, Emc 2.0.5 contouring performance.

Gents,

Finally reinstalled my emc2 and retuned it and
dicovered a interesting problem that might be worth
investigating.
Before I start here are the HW specs. P4 1.8Ghz, 512Mb
ram, ac servo motors (Yaskawa SDGA model running in
torque mode )Machine maximum speed is 8400mm/min with
std acc of 450 and 650 for max. Standart f-error on
all axes is below 0.03mm at top speed. 
When simple nc code is run, machine runs perfectly,
when a circle nc code (simplest ) with g3 and g2 code
is loded and executed, machine will run smoothly and
will run at full speed. When loaded 3D contouring
pattern (code is heavier ) with arcs machine will jerk
a bit but will still run say satisfactory, (reaches
6500mm/min)  when the same pattern is loaded but code
without arcs, and executed machine jerks, and
performane goes to the drain. (jerks, slow feed (max
1500mm/min )
When looking at the scope from the servopacks ,
sequence 1 runs , accels, torque and speed lines are
smooth and clean , 2nd one has more peaks and third
one is a real mess. (will post some pics of graphs in
next post ). Since EMC2 has no lookahead and from what
I've understood that it only looks for the next move
for acc/dec param, would this be a limitation of the
whole system? Is here a workaround?, or has emc2
reached it's performance limit? Any comments are
appreciated.

(Continue reading)

anders | 8 Feb 2007 10:23

Picon

Re: EMC2 Ubuntu 6.06, Emc 2.0.5 contouring performance.

Hello,  Petr
I'm not sure this will help but, do you have blending enabled(G64 Px.xxx)?
That should help you keep your feedrate up while contouring.

http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?TrajectoryControl

/Anders

petr ruzicka skrev:
> Gents,
>
> Finally reinstalled my emc2 and retuned it and
> dicovered a interesting problem that might be worth
> investigating.
> Before I start here are the HW specs. P4 1.8Ghz, 512Mb
> ram, ac servo motors (Yaskawa SDGA model running in
> torque mode )Machine maximum speed is 8400mm/min with
> std acc of 450 and 650 for max. Standart f-error on
> all axes is below 0.03mm at top speed. 
> When simple nc code is run, machine runs perfectly,
> when a circle nc code (simplest ) with g3 and g2 code
> is loded and executed, machine will run smoothly and
> will run at full speed. When loaded 3D contouring
> pattern (code is heavier ) with arcs machine will jerk
> a bit but will still run say satisfactory, (reaches
> 6500mm/min)  when the same pattern is loaded but code
> without arcs, and executed machine jerks, and
> performane goes to the drain. (jerks, slow feed (max
> 1500mm/min )
> When looking at the scope from the servopacks ,

(Continue reading)

petr ruzicka | 8 Feb 2007 13:30

Picon

Re: EMC2 Ubuntu 6.06, Emc 2.0.5 contouring performance.

Thank you all for input, I've increesed the acc rate
and seems to help a lot. will update to 2.1 next week,
will keep posting improovements.

Cheers
--- anders <anders@...> wrote:

> Hello,  Petr
> I'm not sure this will help but, do you have
> blending enabled(G64 Px.xxx)?
> That should help you keep your feedrate up while
> contouring.
> 
>
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?TrajectoryControl
> 
> 
> /Anders
> 
> petr ruzicka skrev:
> > Gents,
> >
> > Finally reinstalled my emc2 and retuned it and
> > dicovered a interesting problem that might be
> worth
> > investigating.
> > Before I start here are the HW specs. P4 1.8Ghz,
> 512Mb
> > ram, ac servo motors (Yaskawa SDGA model running
> in

(Continue reading)

Mario | 8 Feb 2007 18:18

Re: EMC2 Ubuntu 6.06, Emc 2.0.5 contouring performance.

So it was the trajectory planner then
On 2/8/07, petr ruzicka <RUZIP@...> wrote:
> Thank you all for input, I've increesed the acc rate
> and seems to help a lot. will update to 2.1 next week,
> will keep posting improovements.
>
>
> Cheers
> --- anders <anders@...> wrote:
>
> > Hello,  Petr
> > I'm not sure this will help but, do you have
> > blending enabled(G64 Px.xxx)?
> > That should help you keep your feedrate up while
> > contouring.
> >
> >
> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?TrajectoryControl
> >
> >
> > /Anders
> >
> > petr ruzicka skrev:
> > > Gents,
> > >
> > > Finally reinstalled my emc2 and retuned it and
> > > dicovered a interesting problem that might be
> > worth
> > > investigating.
> > > Before I start here are the HW specs. P4 1.8Ghz,

(Continue reading)

Mario | 5 Feb 2007 14:40

Re: EMC2 Ubuntu 6.06, Emc 2.0.5 contouring performance.

skutocne asi tie obrazky budy nutne na porozumenie
I think that the pictures might be necessary to understand your setup
and behaviour :)

BTW even manual says that the arcs introduce inaccuracy and especially
mentions arcs that are not defined by their center.

On 2/5/07, petr ruzicka <RUZIP@...> wrote:
> Gents,
>
> Finally reinstalled my emc2 and retuned it and
> dicovered a interesting problem that might be worth
> investigating.
> Before I start here are the HW specs. P4 1.8Ghz, 512Mb
> ram, ac servo motors (Yaskawa SDGA model running in
> torque mode )Machine maximum speed is 8400mm/min with
> std acc of 450 and 650 for max. Standart f-error on
> all axes is below 0.03mm at top speed.
> When simple nc code is run, machine runs perfectly,
> when a circle nc code (simplest ) with g3 and g2 code
> is loded and executed, machine will run smoothly and
> will run at full speed. When loaded 3D contouring
> pattern (code is heavier ) with arcs machine will jerk
> a bit but will still run say satisfactory, (reaches
> 6500mm/min)  when the same pattern is loaded but code
> without arcs, and executed machine jerks, and
> performane goes to the drain. (jerks, slow feed (max
> 1500mm/min )
> When looking at the scope from the servopacks ,
> sequence 1 runs , accels, torque and speed lines are

(Continue reading)

Jeff Epler | 5 Feb 2007 14:39

Re: EMC2 Ubuntu 6.06, Emc 2.0.5 contouring performance.

Are you sure that the acceleration you have specified is the maximum
your machine can do?  On the (teeny) machine I have the most experience
with, the acceleration time, (maxvel) / (maxaccel), is 0.017 seconds.
On your machine, (maxvel) / (maxaccel) is .24 seconds.  As a gross
simplification, the trajectory planner enters "pathological" territory
when the time for a move is less than the time to accelerate from a stop
to the feed rate.

In emc 2.1.0, "G64 P-" (continuous mode with path tolerance) mode
will combine multiple G1 moves into a single motion when they are within
a tolerance value of a single straight line.  It is hoped that this mode
will do better with CAM output like the code you seem to be dealing
with.  This mode is most effective with code that contains only G1
moves (no arcs), because it will never combine a G1 with a G2 or G3.

If neither of these help, then it sounds like your best bet is to have
your CAM software create output *with* arcs, since you get up to
6500mm/min that way.

Jeff

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Chris Radek | 5 Feb 2007 15:34

Re: EMC2 Ubuntu 6.06, Emc 2.0.5 contouring performance.

On Mon, Feb 05, 2007 at 07:39:29AM -0600, Jeff Epler wrote:
> As a gross
> simplification, the trajectory planner enters "pathological" territory
> when the time for a move is less than the time to accelerate from a stop
> to the feed rate.

At this stage it does slow down, but my testing doesn't show
jerkiness.  Can you make your ini and a sample of the gcode
available?  There might be a tweak that will clean it up.

Also like Jeff said, using G64 P-  (tolerance mode) will likely
help a lot if using EMC2.1.

Chris

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

jmkasunich | 2 Feb 2007 20:35

Picon

Re: Help with CVS

"Eric H. Johnson" <ejohnson@...> wrote:

> OTOH, this is a much more significant addition to EMC, certainly far more 
> than my modest immediate objectives. It seems to me an addition of this 
> magnitude should go through the board as far as approval, setting up how to 
> organize it in the overall structure, etc. Like classic ladder, it makes EMC 
> dependent, at least in some small degree, to an external open source 
> development. Hence the success of that portion is based on how well this 
> external development is supported. 
> 
> I will begin looking into it, but I will not add anything to EMC (CVS) 
> without some level of approval. My program, emclcd, at this point is just a 
> place holder, so nothing has been lost at this point. I, of course, would 
> appreciate any advice on how to proceed with this development. 

(This is me speaking as in individual developer who happens to be on the
board, not speaking for the board as a whole.)

I really don't want any developers to feel that they need "board approval"
to make additions to EMC.  Yes, it is important that things be discussed
on the developers list, especially things that will add significant new
dependencies to EMC.  But nobody should be discouraged from contributing
code.

It this specific case, as with classicladder, only a subset of users are
going to use the new functionality.  As long as the build system can skip
building the new additions when their dependencies are unavailable, I see
absolutely no reason why you shouldn't go ahead.  Just make sure that 
configure tests for the dependencies, and if they aren't present, it prints
something like "Warning: foo missing, bar will not be built", instead of

(Continue reading)

Return

Return to gmane.linux.distributions.emc.devel.

Project Web Page

Messages about installing and using EMC

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane