Back
[08:23:39] <skunkworks> there are 2 outstanding issues with robs branch. Fails interp/bad and 'Already Splitting on ID...' error.
[08:24:31] <skunkworks> The 'Already Splitting on ID...' is not new - it is acutally in 2.7. I have not seen it cause any constraint violations.
[08:24:55] <skunkworks> Rob would like to fix it though
[09:51:59] <seb_kuzminsky> skunkworks: cool, tanks
[09:52:01] <seb_kuzminsky> *thanks
[09:52:13] <seb_kuzminsky> also: sob (but that's easy)
[09:54:02] <skunkworks> righty
[09:54:04] <skunkworks> right
[15:44:31] <andypugh> Does the tool-path history in the Axis preview show the commanded position or the feedback position? (Or does it depend on what the DRO is set to show? )
[15:45:59] <seb_kuzminsky> feedback, i think
[15:46:53] <cradek> commanded, I think
[15:47:12] <cradek> I'd check the source :-)
[15:47:23] <alex_joni> feedback
[15:47:41] <alex_joni> with encoders you can move the cone by hand ..
[15:47:53] <alex_joni> (at least it used to..)
[15:56:28] <seb_kuzminsky> alex_joni: i assume you're in estop when you're doing that? i think i estop, motion's command follows the feedback, so it doesn't jump when you come out of estop later
[15:56:38] <cradek> double pt[9] = { status->motion.traj.position.tran.x - status->task.toolOffset.tran.x, ...
[15:59:30] <cradek> so yeah, commanded
[16:00:13] <cradek> if it was actual, encoder jitter would quickly fill up the whole thing
[16:00:28] <cradek> while stopped, I mean
[16:02:11] <alex_joni> seb_kuzminsky: ah, right.. that must be it
[16:02:29] <alex_joni> even if not in estop. if you move more than ferror, it will quickly go to estop
[16:03:01] <cradek> to machine off
[16:03:18] <alex_joni> that
[16:06:50] <andypugh> Right, so bad servo tuning can’t show up in the Axis toolpath?
[16:10:26] <cradek> don't think so
[16:10:33] <cradek> what are you working on?
[16:12:57] <skunkworks> there is show commanded postion vs actual position.. does that also do the preview?
[16:13:24] <cradek> nope
[16:18:31] <skunkworks> wait - if you move the axis around manually - the plot moves.. so it is displaying feedback..
[16:19:14] <alex_joni> nope
[16:19:29] <alex_joni> I assumed the same, but if you move it by hand you probably are in machine off state
[16:19:42] <alex_joni> and in machine off, lcnc just takes the feedback and loops it back as command
[16:20:03] <alex_joni> (so on the next machine on, there's no difference between command and feedback and you get a jump)
[16:20:07] <skunkworks> huh
[17:11:02] <andypugh> cradek: It’s a forum question. He gets funny-shaped circles, but they look funny on the preview. So I think we can conclude that it is nothing to do with servo tuning.
[17:14:41] <andypugh> http://www.linuxcnc.org/index.php/english/forum/38-general-linuxcnc-questions/28813-oblong-pockets-odd-geometry-root-cause-ideas#55349
[17:33:53] <skunkworks> http://electronicsam.com/images/KandT/testing/Screenshot%20from%202015-01-26%2012:27:40.png
[17:34:14] <skunkworks> http://electronicsam.com/images/KandT/testing/Screenshot%20from%202015-01-26%2017:09:32.png
[17:34:23] <skunkworks> new/old trajectory planner
[17:35:59] <seb_kuzminsky> andypugh: the gui runs in non-realtime, so it only samples the machine position when it feels like it
[17:36:25] <seb_kuzminsky> if the machine follows a nice circle but the gui only updates a few times as it goes around, it'll look like a polygon
[17:37:16] <andypugh> It looks like a tight-circle and low-accel problem initially.
[17:37:47] <seb_kuzminsky> skunkworks: is the 12:27:40 picture the new tp in 2.7? and the 17:09:32 is from 2.6?
[17:37:49] <andypugh> The problem is that the machine is _not_ following a nice circle
[17:38:12] <seb_kuzminsky> andypugh: yikes
[17:38:52] <andypugh> (Not my machine)
[17:39:54] <seb_kuzminsky> OP has 200 us latency, that might be acceptable since they're using mesa hardware
[17:40:56] <seb_kuzminsky> andypugh: i like your suggestion of lowering speed and observing the purple line
[17:41:35] <andypugh> I learn a lot from trying to answer questions :-)
[17:41:55] <PCW> a 120 ipm 200 usec is only a bogus 0.4 mill indicated error so not too likely to cause trouble
[17:42:35] <PCW> and likely only for a single sample
[17:46:06] <skunkworks> seb - 17:09:32 is 2.6 - 12:27:40 is from robs branch based on 2.7. performance should be pretty close to the same.
[17:46:27] <seb_kuzminsky> ool
[17:46:29] <seb_kuzminsky> *c
[17:46:48] <seb_kuzminsky> let's pretend that we dont see the constraint violation in 2.6
[17:46:53] <PCW> I am in a flurry of cut/pasting DPLL sampling of the quadrature encoders into hm2 ATM so even that glitch will be fixable
[17:46:55] <PCW> but I think low accel or some other TP setup problem seems most likely
[17:47:27] <skunkworks> seb_kuzminsky: you noticed that?
[17:47:31] <seb_kuzminsky> no
[17:48:25] <skunkworks> :) there are some pretty large acc violations in 2.6 under certain situations.. large as in 5in/s^2 higher.. (nothing like mach) ;)
[17:49:45] <PCW> probably impossible to notice without measuring though
[17:50:37] <skunkworks> I was seeing some odd blending in 2.6 with arcs and high speeds - could that be the issue?
[17:52:11] <micges> skunkworks: got sample gcode violating acc?
[17:53:40] <micges> (in 2.6)
[17:54:42] <seb_kuzminsky> g-code & matching ini would be interesting
[17:56:45] <skunkworks> http://article.gmane.org/gmane.linux.distributions.emc.devel/14024/match=constraint
[17:57:46] <seb_kuzminsky> SPACOUT1.ngc
[17:57:48] <seb_kuzminsky> thx
[17:58:00] <seb_kuzminsky> ooh, it's nice & short too
[17:59:14] <seb_kuzminsky> do you have the ini that you saw the problem on?
[17:59:21] <seb_kuzminsky> was it a standard sim config?
[18:00:17] <skunkworks> umm... I would have to look.
[18:04:35] <seb_kuzminsky> i'll just try it win sim/axis and bug you if that doesnt do it
[18:07:17] <skunkworks> I think it was just my standard 30in/s^2 acc and 500ipm config.
[18:20:26] <Tom_itx> PCW, i was supposed to remind you about something today...
[18:20:56] <Roguish> PCW: I have both my broken 5i20's fixed. Thanks for the help. Hey is there a doc to translate bit file names to what they do?
[18:21:23] <Tom_itx> the new mesaflash will
[18:21:37] <Tom_itx> err if it's loaded that is
[18:21:54] <Tom_itx> svst is generally stepper i think
[18:21:58] <Tom_itx> svss is servo i think
[18:23:23] <micges> sv -servo, ss - smart serial, st - stepper
[18:24:04] <PCW> Tom_itx JTAG pcb
[18:24:56] <Roguish> micges: ok, that's part of it. there's lots more. Is there a document of some sort? somewhere? PCW?
[18:25:15] <seb_kuzminsky> Roguish: each .bit file comes with a .pin file that tells you the pinout
[18:25:31] <seb_kuzminsky> is that what you're ooking for?
[18:25:35] <seb_kuzminsky> *l
[18:27:27] <PCW> mesaflash will make pin files now
[18:27:45] <Tom_itx> pretty cool tool
[18:28:02] <Roguish> seb_kuzminsky: in the software download for the 5i24, there are 75 bit files. some things are obvious, most are not.
[18:31:51] <Tom_itx> E coast better get home
[18:33:24] <Tom_itx> Roguish do you have something specific you're looking for?
[18:36:06] <Roguish> Tom_itx: a client is cooking up a machine and is not sure of the configuration yet. I would like to know all the current configurations to show him what is available.
[18:36:37] <Tom_itx> if it's not there it can be made
[18:37:22] <Tom_itx> they are a bit cryptic but there's only so much you can get in a filename
[18:37:42] <Roguish> seb_kuzminsky: in the Mesa downloaded file that has the 75 configurations, there are no pin files (that is no files with .pin extension.
[18:38:23] <Tom_itx> unzip all the files
[18:38:29] <Roguish> Tom_itx: exactly, I'm sure there is some logic in the name, just what is the logic?
[18:38:32] <PCW> you can always look at the source pinout files
[18:38:35] <Tom_itx> there is in mine under the hostmot2 subdir
[18:38:53] <Tom_itx> i generally do just what PCW suggests
[18:39:05] <Tom_itx> you'll eventually figure out a pattern
[18:39:36] <Tom_itx> or wait until you know what he needs and ask somebody
[18:39:44] <seb_kuzminsky> skunkworks: do you have a gcode file that violates constraints in 2.7, before rob's fixes?
[18:42:05] <Tom_itx> is 2.7 stable enough to run?
[18:42:15] <Tom_itx> not a production machine...
[18:42:50] <seb_kuzminsky> Tom_itx: i think so
[18:42:58] <seb_kuzminsky> i think it's better than 2.6 now
[18:43:19] <Tom_itx> once i get all my parts in and get the control back up i'll load it
[18:43:26] <Tom_itx> i loaded 2.6 the other day
[18:43:54] <skunkworks> was there a constraint violation that rob was fixing? wow - I have to look back.. I am drawing a blank.
[18:43:58] <Tom_itx> i'll need to add those TP variables to the ini won't I?
[18:44:06] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 8a0a9ee 06linuxcnc 10src/emc/usr_intf/stepconf/stepconf.py stepconf: remove a debug print * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8a0a9ee
[18:44:28] <seb_kuzminsky> Tom_itx: no ini changes needed for the new TP, it's enabled by default
[18:44:30] <skunkworks> Tom_itx: no.. It defaults to sane values
[18:45:03] <seb_kuzminsky> here are the ini settings if you want to futz with them, but that's not needed:
http://linuxcnc.org/docs/2.7/html/config/ini_config.html#sub:TRAJ-section
[18:45:12] <Tom_itx> i had added some ARC-BLEND stuff to one some time back...
[18:45:22] <seb_kuzminsky> skunkworks: maybe i'm misunderstanding what rob's working on
[18:45:39] <seb_kuzminsky> i thought "it must be a violation" but i guess it could be a performance improvement
[18:45:41] <Tom_itx> i think some of them have changed or been eliminated since then
[18:45:45] <skunkworks> seb_kuzminsky: let me go back through my notes...
[18:46:06] <seb_kuzminsky> Tom_itx: yikes! that'd be good to fix before the next 2.7 pre-release
[18:46:52] <Tom_itx> heh
[18:47:02] <Tom_itx> that was back when it was rob's branch iirc
[18:47:44] <seb_kuzminsky> git never forgets
[18:48:26] <skunkworks> seb_kuzminsky: oh - it was the issue with just x-y machines..
[18:49:24] <seb_kuzminsky> Tom_itx: git thinks John Thornton added that documentation last june
[18:49:47] <seb_kuzminsky> skunkworks: ah, xy machines not using their full accel and running slower than they should?
[18:49:50] <Tom_itx> i have them commented out now
[18:50:01] <Tom_itx> i'll go back thru it again when i get ready to load 2.7
[18:50:25] <skunkworks> seb_kuzminsky: that too.
[18:50:29] <Tom_itx> just waiting on a slow boat from china
[18:52:20] <seb_kuzminsky> hmm, some of the ini variables appear to be unused by the code in 2.7
[18:53:43] <skunkworks> he also did some spiral stuff I don't understand
[18:54:18] <seb_kuzminsky> yeah i didnt understand that either, it looked to me like spirals were working right before that
[18:54:54] <skunkworks> so - constraint violations with xy only machines, slower Z axis causeing xy moves to be slower, some refactoring and spiral stuff
[18:58:02] <seb_kuzminsky> oh wait, so xy machines *do* violate constraints?
[18:58:14] <seb_kuzminsky> (i wish we had automated tests for this stuff)
[18:58:33] <seb_kuzminsky> [TRAJ]ARC_BLEND_FALLBACK_ENABLE appears to be totally unused
[19:02:43] <seb_kuzminsky> bbl
[19:04:11] <linuxcnc-build_> build #1085 of 1403.rip-wheezy-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1403.rip-wheezy-amd64/builds/1085 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[19:22:21] <linuxcnc-build_> build #2938 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2938 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[19:24:40] <skunkworks> seb_kuzminsky: yes
[19:25:42] <seb_kuzminsky> skunkworks: can you send me the gcode (& ini if you have it ) that violates constraints in the current 2.7 branch?
[19:26:52] <skunkworks> sure
[19:27:16] <seb_kuzminsky> huh, that build failure just now is a weirdo:
[19:27:17] <seb_kuzminsky> Running test: /home/buildslave/emc2-buildbot/wheezy-amd64/rip-wheezy-amd64/build/tests/near.0
[19:27:20] <seb_kuzminsky> halrun: Realtime already running. Use 'halrun -U' to stop existing realtime session.
[19:27:23] <seb_kuzminsky> *** /home/buildslave/emc2-buildbot/wheezy-amd64/rip-wheezy-amd64/build/tests/near.0: FAIL: test run exited with 1
[19:27:47] <andypugh> seb_kuzminsky: Problem with the previous test not exiting?
[19:27:57] <seb_kuzminsky> that's a vanilla kernel running a simulator build
[19:28:15] <seb_kuzminsky> andypugh: sure looks like a race with the previous test, yeah
[19:37:07] <skunkworks> seb_kuzminsky: that sounds right.. I think it was figured that falling back to parabolic blending if it was faster wasn't worth it.
[21:58:05] <skunkworks> seb_kuzminsky:
http://electronicsam.com/images/KandT/testing/plasma.tar.gz
[21:58:44] <skunkworks> should open the gcode file and everything. Huge constraint violations in 2.6+ and fixed in robs branch
[22:33:12] <skunkworks> sorry 2.7+
[22:33:38] <seb_kuzminsky> thanks skunkworks
[22:36:29] <skunkworks> hope it works :)
[22:36:47] <skunkworks> or doesn't work - depending on how you look at it.
[22:38:06] <seb_kuzminsky> now that the sliding door on the wife's van is fixed i hope to have an evening to look at it :-/
[22:38:13] <seb_kuzminsky> some time
[22:38:16] <seb_kuzminsky> good night!
