Back
[08:22:21] <skunkworks> well hell. It is very hard to test short line segment performance in mach - the demo version has a 500 line limit.
[08:23:52] <skunkworks> It stops loading 3d_chips before the feet :)
[08:28:27] <skunkworks> (after modifying it so that it is using #numbers instead of #<variables>
[08:31:51] <KGB-linuxcnc> 03git 05master 0e4abe8 06linuxcnc 10src/configure.in * configure: run libgl1-mesa-dri workaround test after libGL has been tested for
[08:52:42] <jepler> skunkworks: that's enough to run half of spiral.ngc from linuxcnc 2.3 (before it was written as a gcode loop with @-angular notation
[08:52:46] <jepler> )
[08:53:51] <jepler> iirc it's the latter part of the spiral which is at a small radius
[08:53:59] <jepler> you can retrieve that from your git clone easily: git show bac2a137a7387685cddc02c3b61515a93ddf060c^:nc_files/spiral.ngc
[08:54:02] <jepler> hah easily
[08:55:11] <jepler> git show v2.3.0:nc_files/spiral.ngc
[08:55:39] <skunkworks> heh
[08:55:54] <skunkworks> thanks - I will give it a try
[08:57:49] <skunkworks> or..
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob;f=nc_files/spiral.ngc;hb=6459ac67d56814c163142ed2c1bb7842de49a483
[08:57:51] <skunkworks> ;)
[08:59:13] <skunkworks> actaully probably
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob;f=nc_files/spiral.ngc;hb=93afe18f6202f1706953fb668809693675d8a4cc
[09:29:32] <linuxcnc-build> build #1009 of deb-hardy-rt-binary-i386 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-hardy-rt-binary-i386/builds/1009 blamelist: Michael Haberler <git@mah.priv.at>
[09:32:20] <linuxcnc-build> build #1007 of deb-hardy-sim-binary-amd64 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-hardy-sim-binary-amd64/builds/1007 blamelist: Michael Haberler <git@mah.priv.at>
[09:34:02] <linuxcnc-build> build #1006 of deb-hardy-sim-binary-i386 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-hardy-sim-binary-i386/builds/1006 blamelist: Michael Haberler <git@mah.priv.at>
[09:55:59] <skunkworks> spiral starts out running at about 450ipm... vs about 100ipm on linuxcnc. quite a difference..
[10:06:25] <skunkworks> with g64p.1q.1 it takes about 20 seconds :) (inches)
[10:06:47] <skunkworks> peaks at around 250ipm
[10:08:30] <skunkworks> (unless I am doing something wrong.)
[10:13:39] <skunkworks> In my mind I would have thought doubling the accelleration within linuxcnc would have performed closer - but even quadroupling it still ran only 200ipm.
[10:17:21] <skunkworks> hmm - is that even right? If I run arcspiral I get a peak of the same - 200ipm
[10:17:52] <skunkworks> is it physically possible to go over 400ipm with 30in/sec/sec acc?
[10:18:30] <skunkworks> (at around a 2 inch radius?)
[10:32:30] <skunkworks> yes it is.. If I create a circle (g2) in linuxcnc with a radius of 2 - it runs at 464 ipm. But arc spiral - which has sort arc segments runs at 100ipm
[10:33:01] <skunkworks> (at acc of 30ipm)
[10:33:49] <skunkworks> (at the outer diameter)
[10:34:01] <skunkworks> *(at acc of 30)
[10:40:21] <skunkworks> am I making sense?
[10:40:22] <skunkworks> ;)
[10:42:43] <skunkworks> with an acceration of 30in/sec/sec and 500ipm max - linuxcnc will run a 2 inch rad circle at 464ipm. but if the arc is made up of lines or shorter arcs it runs at 100ipm (ish)
[10:44:41] <skunkworks> How could I checkout the snapshot of linuxcnc where chris had started using full accelleation instead of acc/2 ?
[10:49:48] <skunkworks> (but that doesn't make sense - I would think if I doubled the accelleration in linuxcnc I would then aproach the 464ipm.. Or am I thinking wrong?
[11:47:06] <ssi> I'm guessing it has to do with the fact that the point between each arc segment is considered a "corner", and therefore exact path is limiting accel into those corners?
[12:21:43] <skunkworks> It probably comes down to that it has to be able to stop at the end of the next line segment.
[12:22:16] <skunkworks> *segment
[12:25:51] <skunkworks> (but I am just a arm chair user)
[14:58:35] <skunkworks> A little more testing... It seems for short segments (lines or arcs) (atleast a few that I have tested - mainly arcspiral and spiral..) linuxcnc seems to run about 1/4 the velocity of the other software. no minding of P's and Q's seem to help. you can get close to 1/2 the velocity - but the tollerance is pretty high :)
[14:59:18] <skunkworks> so for high speed routers - I can see this being an issue.
[15:00:39] <skunkworks> not an issue for me..
[15:03:31] <skunkworks> Tort though - seems to run about the same. (mostly arcs which make sense)
[15:08:59] <skunkworks> (large arcs)
[16:47:39] <JT-Shop> skunkworks: what accel setting are you using?
[16:48:46] <JT-Shop> my max accel on the plasma is 125 and my max vel is 7
[17:11:08] <skunkworks> 30 and 8.333
[17:11:21] <skunkworks> acc/velocity - same in mach
[17:12:47] <skunkworks> testing spiral and arc spiral - with those settings and strait g64 both peak at about 100ipm on the outside edge..
[17:13:11] <skunkworks> a circle that diameter in linuxcnc will do 450ipm..
[17:13:22] <skunkworks> (g2/3)
[17:15:00] <skunkworks> I am sure it is just a limitation of current look ahead..
[17:17:25] <skunkworks> which seems to be what mach does at the outside of sprial - starts out at about 450ipm..
[17:20:49] <JT-Shop> all of my machines the max accel is 10-20 times the max vel
[17:24:10] <andypugh> I am trying to experiment with gdb, but it appears to want to start an executable, and I am not sure which ones (if any) work.
[17:34:42] <skunkworks> well - I think I set the accelleration to 120in/sec/sec and still didn't reach 450ipm at the outside edge
[17:36:59] <jepler> andypugh: in principle, any userspace program can be debugged with gdb.
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?DebuggingRtapi if you want to debug a "realtime" component on a sim system (may not work with the fancy new userspace realtimes though, I have never tried it but I know some stuff is organized different)
[17:37:07] <jepler> you can also attach to an already-running program instead of starting a program...
[17:37:57] <andypugh> I am trying to connect from Eclipse to gdbserver, which may be a step too far.
[17:38:01] <jepler> gdb --pid=12345
[17:38:06] <jepler> oh I know nothing about eclipse, sorry
[17:38:36] <andypugh> (And this is also a kernel module, though I am only trying to debug the init code)
[17:39:26] <andypugh> I have reverted to "rtapi_print" every second line...
[17:41:56] <andypugh> But I was moderately impressed by a Youtube video I watched where a guy was single-stepping through code running on a Beaglebone from the Eclipse IDE on his PC.
[17:44:17] <andypugh> Looks like I will need to sort out why I can't currently create a run-in-place too.
[17:44:45] <andypugh> (probably related to the git repository being on an NFS mount, perhaps I need to reconsider that)
[17:46:39] <skunkworks> eclipse?
[17:48:51] <andypugh> Well, adding the rtapi_print functions seems to have fixed the bug. That's annoying :--)
[18:55:01] <andypugh> So, I took out the print statements, and as if by magic, it crashes again. This is a walk-across the room and pull the plug crash too.
[18:55:13] <andypugh> Very strange