Back
[02:01:26] <micges> Tom_itx: yeah but I screw up one, one board in seven years :D
[04:01:04] <Tom_itx> the cost of learning
[07:26:50] <Tom_itx> micges the changes don't show up in the .zip here
[07:28:33] <Tom_itx> nor in /master/eeprom.c
[07:29:58] <Tom_itx> or did you fix it somewhere else like pci_boards.c
[07:36:10] <skunkworks> https://groups.yahoo.com/neo/groups/mach1mach2cnc/conversations/messages/147846
[07:36:56] <Tom_itx> what a shame!
[07:38:00] <skunkworks> Tom_itx, did you see linuxcnc logging step/dir?
http://ibin.co/23BDclOzXI5J
[07:38:21] <Tom_itx> nope
[07:38:42] <Tom_itx> hah RR
[07:39:14] <Tom_itx> x 3
[07:39:34] <skunkworks> :) ^ that was mach. THis is linuxcnc.
http://ibin.co/23BDKefM0Z9Z
[07:40:08] <skunkworks> that comes with mach - kinda like the linuxcnc splash screen - everone runs it.
[07:40:54] <skunkworks> so the bit file works great
[07:41:04] <Tom_itx> oh.. good
[07:41:24] <Tom_itx> mine would have but i had selected the wrong target chip
[07:41:31] <Tom_itx> 25 instead of 16
[07:41:47] <Tom_itx> the file was ~2x bigger than it should have been
[07:42:25] <skunkworks> unrecoverable?
[07:42:50] <Tom_itx> micges helped last night
[07:42:55] <skunkworks> oh good
[07:42:58] <Tom_itx> it's back to "normal"
[07:43:09] <Tom_itx> otherwise it would have taken jtag
[07:43:19] <Tom_itx> but in the process he improved mesaflash
[07:43:26] <skunkworks> awesome
[07:43:35] <Tom_itx> wiki reflects the change
[07:43:44] <Tom_itx> under 'mesa bitfiles' section
[07:43:55] <Tom_itx> gotta run
[08:19:43] <olli23> Hello one question to the whole community, does the interpreter of the momentary version of Linuxcnc do read ahead
[08:21:28] <archivist> "momentary version"?
[08:22:31] <archivist> the latest trajectory planner does have look ahead
[08:23:00] <skunkworks> if you mean the current released version (2.6.8) it has 1 segment look ahead. The next major release version 2.7 - has a N-lookahead planner.
[08:28:19] <olli23> So only one libe of code look ahead on the current version ?
[08:28:45] <olli23> I mean the current release version 2.68
[08:37:04] <archivist> yes. the new tp is in the very soon to be released 2.7
[08:42:30] <olli23> You I heard N-lines look ahead, is it actually user defined ?
[08:44:16] <skunkworks> it is an ini setting..
http://linuxcnc.org/docs/2.7/html/common/User_Concepts.html#sec:trajectory-control
[08:44:28] <skunkworks> defaults to 50
[08:45:20] <olli23> Very good, I read this before and always thought this parameter has something to do with arc smoothing :)
[08:45:33] <cradek> olli23: this number is very simplistic and is not sufficient to compare the behaviors of different programs
[08:45:45] <cradek> linuxcnc does not split arcs into lines
[08:45:56] <olli23> Okay
[08:45:56] <cradek> maybe say what particular problem you're having?
[08:46:45] <olli23> I have no problem, Iam planning a retrofit and want a good readahead for smooth 3d machining
[08:47:54] <olli23> Iam planning to do it in the next 3 months, does somebody know a rough date when the new 2.7 version will be released ? I don't want to use a devel version
[08:48:00] <cradek> what kind of machine?
[08:48:18] <olli23> Vertical milling center
[08:48:41] <olli23> 3 axis servos very dynamic
[08:49:04] <cradek> with a dynamic high acceleration machine, even 2.6 will give fine performance
[08:49:27] <olli23> Yes I think so too
[08:49:28] <cradek> perhaps measure the acceleration and velocity of the current control and experiment with the simulator version of linuxcnc with those settings
[08:49:42] <cradek> you can try 2.6 or 2.7 in simulator mode
[08:50:01] <olli23> Okay do you know when 2.7 will be released ?
[08:50:16] <olli23> Maybe you have a rough date for me
[08:50:42] <cradek> no, sorry, we don't set release dates, but 2.7 is far along in the stabilization cycle
[08:51:10] <olli23> Okay so nearly perfect :)
[08:51:16] <cradek> yes nearly!
[08:51:22] <cradek> brb
[08:53:08] <olli23> I have a friend that wants to use linuxcnc too, he asked howmany lines the new interpreter can read ahead, so I can tell him there is a setting and default is 50 lines ?
[10:16:37] <skunkworks> https://github.com/grbl/grbl/wiki/Development-Path-and-Future-Needs
[10:16:43] * skunkworks hugs linuxcnc
[10:17:34] <ssi> 4th axis capability: Not high on the priority list, since no one has a 4th axis yet to test it on.
[10:17:37] <ssi> lol
[10:17:49] <cradek> wait it doesn't have jogging?
[10:17:53] <skunkworks> nope
[10:17:58] <ssi> Synchronized spindle: Synchronizing the spindle with axes movement would be a great challenge.
[10:17:58] <cradek> how can that even
[10:18:02] <ssi> GREAT CHALLENGE
[10:18:33] <cradek> even though we've had threading for like 10 years I still get a kick out of using it
[10:18:44] <cradek> I'm still proud of it :-)
[10:18:56] <skunkworks> :) you should be.
[10:19:43] <cradek> I was so happy with my screws I updated timeguy.com for the first time in a year
[10:20:01] <ssi> haha
[10:20:09] <skunkworks> It is impressive what they have done with the arduino.. I have to remember to bring one and do some logging of it's motion
[10:25:30] <skunkworks> wow - that just sounds scary
[10:25:32] <skunkworks> https://github.com/grbl/grbl/wiki/Configuring-Grbl-v0.9#11---junction-deviation-mm
[10:26:00] <skunkworks> For example, if the G-code path has a sharp 10 degree turn coming up and the machine is moving at full speed, this setting helps determine how much the machine needs to slow down to safely go through the corner without losing steps
[10:29:22] <skunkworks> it kinda sounds like they are also doing circular arc blending.
[10:29:59] <skunkworks> https://onehossshay.wordpress.com/2011/09/24/improving_grbl_cornering_algorithm/
[10:43:33] <pcw_home> sounds like they are limiting the vector acceleration not per axis limits
[12:28:59] <skunkworks> zlog
[12:52:34] <micges> Tom_itx: I see changes here
[12:53:05] <Tom_itx> did you do something different than you had me do?
[12:53:23] <Tom_itx> other than comment out those lines
[12:53:34] <micges> yes
[12:53:41] <Tom_itx> ok that explains it
[12:53:47] <Tom_itx> does it work the same?
[12:53:50] <micges> but letme check, it was 4am
[12:53:59] <Tom_itx> or can you recover by board name now?
[12:54:57] <micges> that check you commented out should be in another if with .recover
[12:55:44] <Tom_itx> i suppose i could test it but i kinda hate to mess it up again
[12:56:09] <micges> don't
[12:56:47] <micges> it's 99% same code but instead of comment out there is one more if
[12:56:48] <Tom_itx> is the if(board->recover == 0) a new line?
[12:56:52] <micges> yes
[12:56:57] <Tom_itx> ok i see it hten
[12:56:58] <Tom_itx> then
[12:57:23] <Tom_itx> still use 6i25 for all?
[12:57:27] <micges> Me or Peter or someone else will check it
[12:57:32] <micges> yes
[12:57:37] <Tom_itx> alright
[12:58:01] <Tom_itx> gotta run
[12:58:13] <micges> yeah me too
[19:55:47] <skunkworks> zlog
[20:01:00] <Tom_itx> awfully quiet
[20:03:08] <skunkworks> Too quiet.
[20:06:39] <Tom_itx> that RR post you showed me what was the significance of the numbers on the right?
[20:06:59] <Tom_itx> it looked to me that mach had higher feeds?
[20:24:18] <skunkworks> peak acc/vell
[20:25:17] <skunkworks> cavel
[20:25:23] <skunkworks> heh
[20:26:04] <skunkworks> vel
[20:28:34] <skunkworks> acceleraation calculated from velocity
[20:30:58] <Tom_itx> that's the result from your encoder inputs?
[20:31:47] <Tom_itx> i think they're too busy digging their way outta software upgrades
[20:41:24] <skunkworks> I am pretty sure they are correct as the linuxcnc logging is pretty close - just a little over 30in/s^2 - and you can manually calculate the acc from the slope of the velocity.