Re: [Emc-users] Thoughts on a Python script to calculate estimated run time, for G code and my first hacked sub routine

2014-10-16 Thread Gene Heskett
On Wednesday 15 October 2014 12:00:38 Sebastian Kuzminsky did opine
And Gene did reply:
 On 10/15/14 4:07 AM, Frank Tkalcevic wrote:
  I was so annoyed that the estimates for my 3d printing jobs were so
  far off (estimated 2 hours, took 8) that I modified the axis code. 
  It looks at the Velocity and acceleration of each axis and tries to
  calculate a more accurate time.  It only looks at moves - no G64 or
  probing.  It isn't perfect, but much closer.
  
  The attached file is the changes - a new gcode_properties function
  and some additional routines.
  
  My version of linuxcnc is pretty old, so a diff or patch wouldn't be
  useful.
 
 That change looks good to me, thanks.
 
 I pasted all the parts of your file into appropriate-seeming places in
 axis.py, and it runs, so that's good.  But i think something's off with
 the estimate still.
 
 I did some testing with the sim/axis/axis config.
 
 Your code's estimate for the splash screen gcode is 2:09, which is
 within a second of the measured runtime.  The current version of Axis
 in the master branch estimates 2.1 minutes, so they agree on this
 one.
 
 But the estimate for 3D_Chips.ngc is way off.  The current master
 version of Axis estimates 0:46, your code estimates 3:44, and measured
 runtime is 1:11.  So I think there's some work to do still.

I haven't played with that one for a while, but that estimated time of 
3.44 is still way faster that it will run cutting air on my machine.  
Estimated time is 13.3 minutes on my machine (without these patches, most 
recent 2.6.3 install), cutting air runtime was 14:30 at the speed limits 
of my toy just now.  Fairly close IOW.

I actually made that in a 2x6x6 block of pine, years ago, and would have 
done it in maple if it looked good, but because of the limited length of 
the flutes of my mill, had to do 3 passes to get to full depth.  I had 
bookends in mind, but in pine it was at best so ugly its pretty. :)

My point is that the simulator, a 2.7.pre build, does run faster here, 
noticeably faster.
 
 I pushed your updated version to git.linuxcnc.org as a branch called
 'seb/master/ftkalcevic-axis-estimate', for wider testing and in case
 you want to refine the code.


Cheers, Gene Heskett
-- 
There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order.
-Ed Howdershelt (Author)
Genes Web page http://geneslinuxbox.net:6309/gene
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Thoughts on a Python script to calculate estimated run time, for G code and my first hacked sub routine

2014-10-16 Thread Frank Tkalcevic
Yeah, I don't have the latest trajectory planner.  3d_chips was one of my
test files and came out ok without G64 settings.

Any suggestions on how to estimate with G64?



 -Original Message-
 From: Todd Zuercher [mailto:zuerc...@embarqmail.com]
 Sent: Thursday, 16 October 2014 3:16 AM
 To: Enhanced Machine Controller (EMC)
 Subject: Re: [Emc-users] Thoughts on a Python script to calculate
estimated
 run time, for G code and my first hacked sub routine
 
 My guess is the new tool planner's G64 settings are throwing off the
 estimate.  Try the real time with tighter G64 PXXX, and I suspect your
results
 will differ.
 
 - Original Message -
 From: Sebastian Kuzminsky s...@highlab.com
 To: Enhanced Machine Controller (EMC) emc-
 us...@lists.sourceforge.net
 Sent: Wednesday, October 15, 2014 12:00:38 PM
 Subject: Re: [Emc-users] Thoughts on a Python script to calculate
estimated
 run time, for G code and my first hacked sub routine
 
 On 10/15/14 4:07 AM, Frank Tkalcevic wrote:
  I was so annoyed that the estimates for my 3d printing jobs were so
  far off (estimated 2 hours, took 8) that I modified the axis code.  It
  looks at the Velocity and acceleration of each axis and tries to
  calculate a more accurate time.  It only looks at moves - no G64 or
  probing.  It isn't perfect, but much closer.
 
  The attached file is the changes - a new gcode_properties function and
  some additional routines.
 
  My version of linuxcnc is pretty old, so a diff or patch wouldn't be
useful.
 
 That change looks good to me, thanks.
 
 I pasted all the parts of your file into appropriate-seeming places in
axis.py,
 and it runs, so that's good.  But i think something's off with the
estimate still.
 
 I did some testing with the sim/axis/axis config.
 
 Your code's estimate for the splash screen gcode is 2:09, which is within
a
 second of the measured runtime.  The current version of Axis in the master
 branch estimates 2.1 minutes, so they agree on this one.
 
 But the estimate for 3D_Chips.ngc is way off.  The current master version
of
 Axis estimates 0:46, your code estimates 3:44, and measured runtime is
1:11.
 So I think there's some work to do still.
 
 I pushed your updated version to git.linuxcnc.org as a branch called
 'seb/master/ftkalcevic-axis-estimate', for wider testing and in case you
want
 to refine the code.
 
 
 --
 Sebastian Kuzminsky
 


--
 Comprehensive Server Monitoring with Site24x7.
 Monitor 10 servers for $9/Month.
 Get alerted through email, SMS, voice calls or mobile push notifications.
 Take corrective actions from your mobile device.
 http://p.sf.net/sfu/Zoho
 ___
 Emc-users mailing list
 Emc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-users
 


--
 Comprehensive Server Monitoring with Site24x7.
 Monitor 10 servers for $9/Month.
 Get alerted through email, SMS, voice calls or mobile push notifications.
 Take corrective actions from your mobile device.
 http://p.sf.net/sfu/Zoho
 ___
 Emc-users mailing list
 Emc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-users


--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Thoughts on a Python script to calculate estimated run time, for G code and my first hacked sub routine

2014-10-16 Thread Sebastian Kuzminsky
On 10/16/14 12:22 AM, Frank Tkalcevic wrote:
 Yeah, I don't have the latest trajectory planner.  3d_chips was one of my
 test files and came out ok without G64 settings.

 Any suggestions on how to estimate with G64?

You'd need to duplicate the functionality of the trajectory planner to 
get G64P right.  And then keep it up to date as the TP changes...

The only alternative i can think of is to somehow run the real 
trajectory planner and redirect its actual commanded waypoints away from 
the joint controllers and into your runtime estimator.

That might be useful for other reasons too (better bounds checking, 
easier testing of the TP, etc), but it'll be slower than either of the 
two current estimators.


-- 
Sebastian Kuzminsky

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Thoughts on a Python script to calculate estimated run time, for G code and my first hacked sub routine

2014-10-15 Thread Frank Tkalcevic
I was so annoyed that the estimates for my 3d printing jobs were so far off
(estimated 2 hours, took 8) that I modified the axis code.  It looks at the
Velocity and acceleration of each axis and tries to calculate a more
accurate time.  It only looks at moves - no G64 or probing.  It isn't
perfect, but much closer.

The attached file is the changes - a new gcode_properties function and some
additional routines.

My version of linuxcnc is pretty old, so a diff or patch wouldn't be useful.

Frank 





 -Original Message-
 From: Sebastian Kuzminsky [mailto:s...@highlab.com]
 Sent: Thursday, 9 October 2014 1:45 AM
 To: Enhanced Machine Controller (EMC)
 Subject: Re: [Emc-users] Thoughts on a Python script to calculate
estimated
 run time, for G code and my first hacked sub routine
 
 On 10/8/14 9:01 AM, Schooner wrote:
  First Q
 
From Axis
 
  File  Properties
 
  Brings up the properties of the currently loaded gcode including
  estimated run time
 
  Always underestimates as it takes no account of time used in
  acceleration and deceleration to/from the required Feed speed
 
 Yep, the estimate is off.  It's based on the gcode only, and does not take
into
 account important things like machine acceleration and spindle
acceleration
 as you say, as well as things like tolerance (G64 P) and probing.
 
 The only way I can think of to improve the estimate would be to run the
 motion controller, disconnected from actual motion, and see how long the
 motion actually takes.  That's probably possible, but it's not a small
change to
 design  implement.
 
 
 --
 Sebastian Kuzminsky
 


--
 Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve
 PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you
 Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to
 PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
 http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.cl
 ktrk
 ___
 Emc-users mailing list
 Emc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-users
class AxisParam:
def __init__(self, vel, acc):
self.vel = vel
self.acc = acc

def StraightExecutionTime( self, distance, feedrate ):

t = 0.0
if feedrate is None:
v = self.vel
elif feedrate  self.vel:
v = self.vel
else:
v = feedrate

distance = abs(distance)
a = self.acc

if distance  0:
# calc time and distance to accelerate to v
# v = at
# s = 1/2 a t^2 + v0 t,  assume v0 = 0
t = v / a
s =  1.0 / 2.0 * a * t *t

# check if accelerating to v then decelerating to v fits in the 
distance
if 2.0*s  distance:
t = 2.0 * t + (distance - 2.0*s) / v
else:
t = 2.0*math.sqrt( 2.0 * (distance/2.0) / a )

#print distance=,distance, a=, a, v=, v, t=, t
return t

def CalcExecutionTime( axis_params, start_point, end_point, feedrate=None ):
distance = sum( (s-e)**2 for s, e in zip(start_point, end_point))
distance = math.sqrt(distance)

longest_time = 0
for ap,start,end in zip(axis_params, start_point, end_point ):
if not ap is None:
f = feedrate
if not feedrate is None:
f = feedrate * abs(end-start)/distance
time = ap.StraightExecutionTime( end - start, f )
if time  longest_time:
longest_time = time
return longest_time

def CalcArcExecutionTime( ap, arcfeed ):
# Arcs have already been converted into line segments.
# We calculate absolute distance travelled in dx, dy, dz, etc
# and estimate the time in each axis.  This wont take into
# account an axis with low acceleration, but should be close enough.
time = 0
last_line = 0
last_feed = 0
arclen = [0,]*9
segcount = 0
for arcseg in arcfeed:
# Each record contains, line number, start, end, feedrate.
# We determine the end of an arc when the line # changes or the feed 
changes
line = arcseg[0]
start = arcseg[1]
end = arcseg[2]
feed = arcseg[3]

if line != last_line or feed != last_feed:
if segcount  0:
t = CalcExecutionTime( ap, [0,]*9, arclen, last_feed )
time += t

arclen = [0,]*9
segcount = 0

# sum the distance travelled in each axis
for i in range(0,9):
arclen[i] += abs(end[i]-start[i])
segcount += 1

last_feed = feed
last_line = line

if segcount  0:
t = CalcExecutionTime( ap, (0,)*9, arclen, last_feed )
time += t

return time

#Replace in class TclCommands(nf.TclCommands):

def 

Re: [Emc-users] Thoughts on a Python script to calculate estimated run time, for G code and my first hacked sub routine

2014-10-15 Thread Sebastian Kuzminsky
On 10/15/14 4:07 AM, Frank Tkalcevic wrote:
 I was so annoyed that the estimates for my 3d printing jobs were so far off
 (estimated 2 hours, took 8) that I modified the axis code.  It looks at the
 Velocity and acceleration of each axis and tries to calculate a more
 accurate time.  It only looks at moves - no G64 or probing.  It isn't
 perfect, but much closer.

 The attached file is the changes - a new gcode_properties function and some
 additional routines.

 My version of linuxcnc is pretty old, so a diff or patch wouldn't be useful.

That change looks good to me, thanks.

I pasted all the parts of your file into appropriate-seeming places in 
axis.py, and it runs, so that's good.  But i think something's off with 
the estimate still.

I did some testing with the sim/axis/axis config.

Your code's estimate for the splash screen gcode is 2:09, which is 
within a second of the measured runtime.  The current version of Axis in 
the master branch estimates 2.1 minutes, so they agree on this one.

But the estimate for 3D_Chips.ngc is way off.  The current master 
version of Axis estimates 0:46, your code estimates 3:44, and measured 
runtime is 1:11.  So I think there's some work to do still.

I pushed your updated version to git.linuxcnc.org as a branch called 
'seb/master/ftkalcevic-axis-estimate', for wider testing and in case you 
want to refine the code.


-- 
Sebastian Kuzminsky

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Thoughts on a Python script to calculate estimated run time, for G code and my first hacked sub routine

2014-10-15 Thread Todd Zuercher
My guess is the new tool planner's G64 settings are throwing off the estimate.  
Try the real time with tighter G64 PXXX, and I suspect your results will differ.

- Original Message -
From: Sebastian Kuzminsky s...@highlab.com
To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net
Sent: Wednesday, October 15, 2014 12:00:38 PM
Subject: Re: [Emc-users] Thoughts on a Python script to calculate estimated run 
time, for G code and my first hacked sub routine

On 10/15/14 4:07 AM, Frank Tkalcevic wrote:
 I was so annoyed that the estimates for my 3d printing jobs were so far off
 (estimated 2 hours, took 8) that I modified the axis code.  It looks at the
 Velocity and acceleration of each axis and tries to calculate a more
 accurate time.  It only looks at moves - no G64 or probing.  It isn't
 perfect, but much closer.

 The attached file is the changes - a new gcode_properties function and some
 additional routines.

 My version of linuxcnc is pretty old, so a diff or patch wouldn't be useful.

That change looks good to me, thanks.

I pasted all the parts of your file into appropriate-seeming places in 
axis.py, and it runs, so that's good.  But i think something's off with 
the estimate still.

I did some testing with the sim/axis/axis config.

Your code's estimate for the splash screen gcode is 2:09, which is 
within a second of the measured runtime.  The current version of Axis in 
the master branch estimates 2.1 minutes, so they agree on this one.

But the estimate for 3D_Chips.ngc is way off.  The current master 
version of Axis estimates 0:46, your code estimates 3:44, and measured 
runtime is 1:11.  So I think there's some work to do still.

I pushed your updated version to git.linuxcnc.org as a branch called 
'seb/master/ftkalcevic-axis-estimate', for wider testing and in case you 
want to refine the code.


-- 
Sebastian Kuzminsky

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Thoughts on a Python script to calculate estimated run time, for G code and my first hacked sub routine

2014-10-15 Thread Karlsson Wang
How about running the actual machine empty for one cycle?

Nicklas Karlsson



On Wed, 15 Oct 2014 21:07:28 +1100
Frank Tkalcevic fr...@franksworkshop.com.au wrote:

 I was so annoyed that the estimates for my 3d printing jobs were so far off
 (estimated 2 hours, took 8) that I modified the axis code.  It looks at the
 Velocity and acceleration of each axis and tries to calculate a more
 accurate time.  It only looks at moves - no G64 or probing.  It isn't
 perfect, but much closer.
 
 The attached file is the changes - a new gcode_properties function and some
 additional routines.
 
 My version of linuxcnc is pretty old, so a diff or patch wouldn't be useful.
 
 Frank 
 
 
 
 
 
  -Original Message-
  From: Sebastian Kuzminsky [mailto:s...@highlab.com]
  Sent: Thursday, 9 October 2014 1:45 AM
  To: Enhanced Machine Controller (EMC)
  Subject: Re: [Emc-users] Thoughts on a Python script to calculate
 estimated
  run time, for G code and my first hacked sub routine
  
  On 10/8/14 9:01 AM, Schooner wrote:
   First Q
  
 From Axis
  
   File  Properties
  
   Brings up the properties of the currently loaded gcode including
   estimated run time
  
   Always underestimates as it takes no account of time used in
   acceleration and deceleration to/from the required Feed speed
  
  Yep, the estimate is off.  It's based on the gcode only, and does not take
 into
  account important things like machine acceleration and spindle
 acceleration
  as you say, as well as things like tolerance (G64 P) and probing.
  
  The only way I can think of to improve the estimate would be to run the
  motion controller, disconnected from actual motion, and see how long the
  motion actually takes.  That's probably possible, but it's not a small
 change to
  design  implement.
  
  
  --
  Sebastian Kuzminsky
  
 
 
 --
  Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve
  PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you
  Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to
  PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
  http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.cl
  ktrk
  ___
  Emc-users mailing list
  Emc-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/emc-users

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Thoughts on a Python script to calculate estimated run time, for G code and my first hacked sub routine

2014-10-10 Thread linden
Thanks John,

 I will keep this in mind if i need to calculate run times more 
precisely.

Just out of curiosity how dose LinuxCNC deal with sub routines,  if, or, 
wile, logic ect.  I am assuming it reads ahead does the calculations and 
spit out standard g code to the interpreter where it is then read and 
converted to hardware commands with a little magic in-between ;-)
 Why I am asking is I am finding it much easer to program and 
simulate with Linuxcnc. There are many more functions than the Dynapath 
Delta 20 control on my Tree J 325 it will only take raw g code more or 
less and is pretty picky about the formatting. If I can get raw G code 
from the interpretor into a text file. Then I could probably figure out 
how to write a post possessor with bash to format it how I need and do a 
few other checks to make it work until I upgrade to a pc and toss the 
Dynapath.
 I have some time on my hands at the moment but no access to my toys 
other than a laptop and intermittent internet. Now is my chance to learn 
and play around with the software side of things. One day probable as 
soon as some thing needs repairing with the Dynapath system I will tear 
it all out and convert to LinuxCNC and some newer spindle and servo 
drives. Tryng to do as much home before then as possible.
 Thanks to all the people that have worked on this great project 
and made it open for the likes of me to poke, explore, and play around 
to see how it work and how things have been done by people that know 
what they are doing?

linden


On 14-10-09 08:11 PM, John Thornton wrote:
 If you need the exact time to run a file create a simulator with the
 same acceleration and velocity settings as your machine. Add the time
 component to the simulator then run your file.

 JT

 On 10/8/2014 10:01 AM, Schooner wrote:
 First Q

From Axis

 File  Properties

 Brings up the properties of the currently loaded gcode including
 estimated run time

 Always underestimates as it takes no account of time used in
 acceleration and deceleration to/from the required Feed speed

 regards



 --
 Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
 Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
 Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
 Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
 http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
 ___
 Emc-users mailing list
 Emc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-users

 --
 Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
 Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
 Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
 Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
 http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
 ___
 Emc-users mailing list
 Emc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-users


--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Thoughts on a Python script to calculate estimated run time, for G code and my first hacked sub routine

2014-10-09 Thread John Thornton
If you need the exact time to run a file create a simulator with the 
same acceleration and velocity settings as your machine. Add the time 
component to the simulator then run your file.

JT

On 10/8/2014 10:01 AM, Schooner wrote:
 First Q

   From Axis

 File  Properties

 Brings up the properties of the currently loaded gcode including
 estimated run time

 Always underestimates as it takes no account of time used in
 acceleration and deceleration to/from the required Feed speed

 regards



 --
 Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
 Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
 Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
 Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
 http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
 ___
 Emc-users mailing list
 Emc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-users


--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Thoughts on a Python script to calculate estimated run time for G code and my first hacked sub routine

2014-10-08 Thread Gene Heskett
On Wednesday 08 October 2014 08:36:06 linden did opine
And Gene did reply:
 Hello
  I have been reading along on this mailing list for a few weeks now
 and playing with Linuxcnc Axis simulator in my free time. Both have
 been very informative and I have learned a lot. There are two items I
 was wondering if I could get a comment on.
 
 #1 Dose any one have a python script or other program that will
 calculate estimated machine time for a .ngc file. PyCam will give you
 an estimate for the Gcode it generates. I have looked through the
 source code and I cant find any thing. I have no programming back
 ground and don't know what I am looking for witch dose not help;-)
 
 #2 Can some one have a look at the following .ngc code with sub routine
 and give me any suggestions or comments regarding the layout
 programming logic ect. Please be ruthless I have no programming or CNC
 back ground;-)
 
 thank for sharing,
 
   Linden
 
 
 %
 ; Cutoff sub V1.0
 ; Written by hand Linden
 ;
 ;Copyright GNU Public License V3)
 ;Credit  - Igor Chudov, Original cutoff sub script
 ;I have hacked Igors original script to do what I needed and take all
 responsibility for the messiness as I am not a programmer at all
 ;-
 ; Not Production Tested !   Feeds, depth of cut, and Speeds not set
 ;
 ; TO DO:  Determine spindle direction requirements set actual speeds
 and feeds
 ;---
 ; Material
 ;- Aluminum
 ;
 ; Procedure:
 ;- Square off end of rough stock with multiple passes of end mill.
 Cut in one direction only, pull back in x plane for return for next
 path. ;
 ; Tools:
 ;#4 1/2 end mill,
 ;
 ;;;
 ;; ; Subroutines used in this script:
 ;
 ocutoff sub
#width = #1   (Width of part in Y)
#depth = #2   (milling depth, negative)
#milld = #3   (end mill diameter)
#frate = #4   (milling rate)
#zstep = #5   (Z step, positive, optional if 0 uses half end mill
 diameter)
#dir = #6  (0 for X+ {right} end of material 1 for X- {left}
 end of material)
#Sspeed = #7  (Spindle Speed)
 
#extra = [ #milld/2+0.01 ]; (Finnish cutting width of cut plus
 1/2 cuter diameter plus 0.01 )
#z = 0
 
 G91(Set to relative Coordinates)
 
 G0 Y[-#extra]
 
 F #frate
 
  oif1 if [ #dir EQ 0]
  #diroffset1 = [ -1 ]
  #diroffset2 = [ 1 ]
  M3  S[#Sspeed]
  oif1 else
  #diroffset1 = [ 1 ]
  #diroffset2 = [ -1 ]
  M4  S[#Sspeed]
  oif1 endif
 
  oif2 if [#zstep EQ 0]
  #zstep = [ #milld/2 ]
  oif2 endif
 
 oloop1 while [ 1 ]
  #z = [#z - #zstep]
  #zmove = #zstep
 
  oif3 if [#z LT #depth]
  #zmove = [ #zmove - [#depth - #z] ]
  #z = #depth
  oif3 endif
 
 G0 Z[ -#zmove ]
 
  oif4 if [ #dir ]
  G1 Y[[#width + 2*#extra]*[#diroffset1]]
  #dir = 0
  oif4 else
  X[[#diroffset1]*[#extra]]
  G0 Y[-[#width + 2*#extra]*[#diroffset1]]
  X[[#diroffset2]*[#extra]]
  #dir = 1
  oif4 endif
 
 
  oif5 if [ #z LE #depth]
  oloop1 break
  oif5 endif
 
 oloop1 endwhile
 
 
 G0 Z[[-#depth]+[#extra]] (Withdraw to safe height start height plus
 1/2 cutter diameter)
 
 G4 P3 (Dwell  for 1 second)
 
 G90(Set back to absolute Coordinates)
 
 ocutoff endsub
 
 ;
 ;
 ; Clear and set Machine Parameters:
 
 G17(Contour plane is XY Z = spindle)
 G54(Coordinate system 1 touch off zero not machine home)
 G20(All units in inches G21 mm)
 G90(Absolute Distances)
 G40(Cancel diameter comp)
 G49(Cancel length offset)
 G80(Cancel Canned cycles)
 G94(Feed/Minute mode)
 ;G64 Pn.n(Path Blending how dose this work what sould i put for
 settings)
 
 ;
 ; Start message for operator
 
 (MSG, Cut off sub will be run twice cutting both ends of bar in fixture
 1. Set fixture 1 in mill Part 0 reference is surface of material and
 centre of centre hole. Tool 4 is 1/2 inch end mill Press pause button
 to continue.)
 ;
 ;;;
 
 ;
 ;Tool change and Program Start
 
 M0(Pause)
 
 M6 T4 (Tool change tool 4)
 
 G0 X-1.000 Y1.000 Z0.000 (Rapid to cut start position)
 
 ocutoff call [2.00](Width of cut in Y) [-1.00](Total depth of
 cut,negative number) [0.500](end mill diameter) [150](Feed speed)
 [.125](Depth of cut each pass) [0](0 X+ right hand end 1 X- left hand
 end)  [1000] (Spindle Speed)
 
 G0 X3.000 Y1.000 Z0.000 (Rapid to cut start position)
 
 ocutoff call [2.00](Width of cut in Y) [-1.00](Total depth of
 cut,negative number) [0.500](end mill diameter) [150](Feed 

Re: [Emc-users] Thoughts on a Python script to calculate estimated run time, for G code and my first hacked sub routine

2014-10-08 Thread Schooner
First Q

 From Axis

File  Properties

Brings up the properties of the currently loaded gcode including 
estimated run time

Always underestimates as it takes no account of time used in 
acceleration and deceleration to/from the required Feed speed

regards



--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Thoughts on a Python script to calculate estimated run time, for G code and my first hacked sub routine

2014-10-08 Thread Sebastian Kuzminsky
On 10/8/14 9:01 AM, Schooner wrote:
 First Q

   From Axis

 File  Properties

 Brings up the properties of the currently loaded gcode including
 estimated run time

 Always underestimates as it takes no account of time used in
 acceleration and deceleration to/from the required Feed speed

Yep, the estimate is off.  It's based on the gcode only, and does not 
take into account important things like machine acceleration and spindle 
acceleration as you say, as well as things like tolerance (G64 P) and 
probing.

The only way I can think of to improve the estimate would be to run the 
motion controller, disconnected from actual motion, and see how long the 
motion actually takes.  That's probably possible, but it's not a small 
change to design  implement.


-- 
Sebastian Kuzminsky

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Thoughts on a Python script to calculate estimated run time, for G code and my first hacked sub routine

2014-10-08 Thread Gene Heskett
On Wednesday 08 October 2014 10:44:58 Sebastian Kuzminsky did opine
And Gene did reply:
 On 10/8/14 9:01 AM, Schooner wrote:
  First Q
  
From Axis
  
  File  Properties
  
  Brings up the properties of the currently loaded gcode including
  estimated run time
  
  Always underestimates as it takes no account of time used in
  acceleration and deceleration to/from the required Feed speed
 
 Yep, the estimate is off.  It's based on the gcode only, and does not
 take into account important things like machine acceleration and
 spindle acceleration as you say, as well as things like tolerance (G64
 P) and probing.
 
 The only way I can think of to improve the estimate would be to run the
 motion controller, disconnected from actual motion, and see how long
 the motion actually takes.  That's probably possible, but it's not a
 small change to design  implement.

And not that big a deal Seb.  We all by know by now its a SWAG.  To bill 
machine time from that would be a mistake.

Cheers, Gene Heskett
-- 
There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order.
-Ed Howdershelt (Author)
Genes Web page http://geneslinuxbox.net:6309/gene
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users


Re: [Emc-users] Thoughts on a Python script to calculate estimated run time for G code and my first hacked sub routine

2014-10-08 Thread linden
Thanks Sebastian  Shooner for the comments, and Gene for running my code,

 The file properties estimation of run time is exactly what I was 
looking for. I intend to use it for path optimization in my code rather 
than job estimation. I am comparing code to code. The actual run time I 
m not to concerned with,  taking into account the time I will take for 
manual tool changes the differences from acceleration ect. are more or 
less erelivant in the grand scheme of things.

 I currently have a Tree Journeyman 325 complete with dynapath 20 
controller sitting in a sea-can and a little 2' by 3' router table with 
a Geckodrive G540  and steppers both are waiting for a better home. I 
would like to mount my little plasma cutter to the the router table as 
it is not very rigid (don't think I would what to run more than a Dremel 
on it for router) The Tree was running when I disconnected it but I 
would like to eventually get rid of the Dynapath stuff as I am not smart 
enough to fix it when components on the boards start to die and the 
calender is starting to catch up with the capacitors and other bits and 
pieces. Would also like to change out the 3 phase yaskawa vfd for a 
newer one that accepts single phase input as a 40  or 50 amp single 
phase plug inare easer to find. First I will get it up and running the 
way it is.

 Some where along the way I am sure I will have some more questions 
to ask and maybe one day I will be able to answer a few,

Linden


*//* 
https://www.google.com/search?biw=1366bih=590q=eventually+changespell=1sa=Xei=bbU1VMH-LsGvuQTC44KIAwved=0CBkQvwUoAA
 


On 14-10-08 09:57 PM, Gene Heskett wrote:
 On Wednesday 08 October 2014 08:36:06 linden did opine
 And Gene did reply:
 Hello
   I have been reading along on this mailing list for a few weeks now
 and playing with Linuxcnc Axis simulator in my free time. Both have
 been very informative and I have learned a lot. There are two items I
 was wondering if I could get a comment on.

 #1 Dose any one have a python script or other program that will
 calculate estimated machine time for a .ngc file. PyCam will give you
 an estimate for the Gcode it generates. I have looked through the
 source code and I cant find any thing. I have no programming back
 ground and don't know what I am looking for witch dose not help;-)

 #2 Can some one have a look at the following .ngc code with sub routine
 and give me any suggestions or comments regarding the layout
 programming logic ect. Please be ruthless I have no programming or CNC
 back ground;-)

 thank for sharing,

Linden


 %
 ; Cutoff sub V1.0
 ; Written by hand Linden
 ;
 ;Copyright GNU Public License V3)
 ;Credit  - Igor Chudov, Original cutoff sub script
 ;I have hacked Igors original script to do what I needed and take all
 responsibility for the messiness as I am not a programmer at all
 ;-
 ; Not Production Tested !   Feeds, depth of cut, and Speeds not set
 ;
 ; TO DO:  Determine spindle direction requirements set actual speeds
 and feeds
 ;---
 ; Material
 ;- Aluminum
 ;
 ; Procedure:
 ;- Square off end of rough stock with multiple passes of end mill.
 Cut in one direction only, pull back in x plane for return for next
 path. ;
 ; Tools:
 ;#4 1/2 end mill,
 ;
 ;;;
 ;; ; Subroutines used in this script:
 ;
 ocutoff sub
 #width = #1   (Width of part in Y)
 #depth = #2   (milling depth, negative)
 #milld = #3   (end mill diameter)
 #frate = #4   (milling rate)
 #zstep = #5   (Z step, positive, optional if 0 uses half end mill
 diameter)
 #dir = #6  (0 for X+ {right} end of material 1 for X- {left}
 end of material)
 #Sspeed = #7  (Spindle Speed)

 #extra = [ #milld/2+0.01 ]; (Finnish cutting width of cut plus
 1/2 cuter diameter plus 0.01 )
 #z = 0

 G91(Set to relative Coordinates)

 G0 Y[-#extra]

 F #frate

   oif1 if [ #dir EQ 0]
   #diroffset1 = [ -1 ]
   #diroffset2 = [ 1 ]
   M3  S[#Sspeed]
   oif1 else
   #diroffset1 = [ 1 ]
   #diroffset2 = [ -1 ]
   M4  S[#Sspeed]
   oif1 endif

   oif2 if [#zstep EQ 0]
   #zstep = [ #milld/2 ]
   oif2 endif

  oloop1 while [ 1 ]
   #z = [#z - #zstep]
   #zmove = #zstep

   oif3 if [#z LT #depth]
   #zmove = [ #zmove - [#depth - #z] ]
   #z = #depth
   oif3 endif

  G0 Z[ -#zmove ]

   oif4 if [ #dir ]
   G1 Y[[#width + 2*#extra]*[#diroffset1]]
   #dir = 0
   oif4 else
   X[[#diroffset1]*[#extra]]
   G0 Y[-[#width + 2*#extra]*[#diroffset1]]
   X[[#diroffset2]*[#extra]]
   #dir = 1
   oif4 endif


   oif5 if [ #z LE #depth]
   oloop1 break
  

Re: [Emc-users] Thoughts on a Python script to calculate estimated run time for G code and my first hacked sub routine

2014-10-08 Thread Gene Heskett
On Wednesday 08 October 2014 18:21:06 linden did opine
And Gene did reply:
 Thanks Sebastian  Shooner for the comments, and Gene for running my
 code,
 
  The file properties estimation of run time is exactly what I was
 looking for. I intend to use it for path optimization in my code rather
 than job estimation. I am comparing code to code. The actual run time I
 m not to concerned with,  taking into account the time I will take for
 manual tool changes the differences from acceleration ect. are more or
 less erelivant in the grand scheme of things.
 
  I currently have a Tree Journeyman 325 complete with dynapath 20
 controller sitting in a sea-can and a little 2' by 3' router table with
 a Geckodrive G540  and steppers both are waiting for a better home.

The calendar may be catching up with the caps in the gecko too.  We had 
reports of one channel getting flaky several times.

 I
 would like to mount my little plasma cutter to the the router table as
 it is not very rigid (don't think I would what to run more than a
 Dremel on it for router)

Even the dremel is a poor choice, the chuck is sitting in an elastomeric 
bearing holder, and is NOT directly connected to the armature.  Something 
that is directly connected, and therefore considerably more rigid, a 
Proxon perhaps?  They also mount better  easier.

 The Tree was running when I disconnected it
 but I would like to eventually get rid of the Dynapath stuff as I am
 not smart enough to fix it when components on the boards start to die
 and the calender is starting to catch up with the capacitors and other
 bits and pieces. Would also like to change out the 3 phase yaskawa vfd
 for a newer one that accepts single phase input as a 40  or 50 amp
 single phase plug inare easer to find. First I will get it up and
 running the way it is.
 
  Some where along the way I am sure I will have some more questions
 to ask and maybe one day I will be able to answer a few,
 
 Linden

[...]

Cheers, Gene Heskett
-- 
There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order.
-Ed Howdershelt (Author)
Genes Web page http://geneslinuxbox.net:6309/gene
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users