Back
[05:53:26] <jthornton> seb, I didn't see the branch was 2.6 when I looked at 2000.docs build
[07:52:37] <KGB-linuxcnc> 03John Thornton 052.7 6dd7dcf 06linuxcnc 10(5 files in 2 dirs) Docs: rename remap file to reflect the contents * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6dd7dcf
[07:52:37] <KGB-linuxcnc> 03John Thornton 052.7 56a8c4c 06linuxcnc 10docs/src/hal/rtcomps.txt Docs: add more information to pwmgen * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=56a8c4c
[07:52:38] <KGB-linuxcnc> 03John Thornton 052.7 91e4e1e 06linuxcnc 10docs/src/config/moveoff.txt Docs: add important info from man file to documents. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=91e4e1e
[08:34:02] <KGB-linuxcnc> 03John Thornton 052.7 77d7050 06linuxcnc 10(5 files in 2 dirs) Docs: rename core components file to reflect the contents * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=77d7050
[09:32:31] <linuxcnc-build> build #3241 of 1200.rip-lucid-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1200.rip-lucid-i386/builds/3241 blamelist: John Thornton <bjt128@gmail.com>
[10:02:27] <JT-Shop> fix on the way
[10:07:08] <KGB-linuxcnc> 03John Thornton 052.7 120f256 06linuxcnc 10docs/src/Master_Documentation_es.txt 10docs/src/index_es.tmpl Docs: don't forget to change the spanish index and master * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=120f256
[12:12:34] <seb_kuzminsky> mozmck: axis is a maze of twisty passages
[12:57:17] <JT-Shop> lol
[13:00:57] <jepler> it was such a beautiful piece of software once
[13:01:10] <jepler> too bad it had to change to better suit the needs of its users
[13:01:25] <jepler> </whiny software developer voice>
[13:02:19] <mozmck> heh!
[13:02:43] <mozmck> So, is that redundant?
[13:03:19] <JT-Shop> seb_kuzminsky, where does this page get generated?
http://www.linuxcnc.org/docs/2.7/
[13:04:21] <jepler> what, "whiny" and "software developer"?
[13:04:41] <jepler> yes, at first glance anyway the ensure_mode call seems redundant
[13:05:00] <jepler> I'd look at the history of those lines to better understand how they got that way, though
[13:06:11] <pcw_home> JT-Shop: I wonder is a note should be added to the integrators manual in the home_use_index section about required hal index-enable connections
[13:08:04] <pcw_home> not really sure where info at that level should go
[13:09:45] <pcw_home> also in section 5.3.7 of the integrators manual"
[13:09:47] <pcw_home> "The position that the joint will go to upon completion of the homing sequence. After detecting the index pulse, and setting the"
[13:09:48] <pcw_home> should probably be something like
[13:09:50] <pcw_home> "The position that the joint will go to upon completion of the homing sequence. After detecting the home switch or index pulse, and setting the"
[13:11:04] <jepler> .. that block was added in 2007 "make 'pause' button work properly in MDI mode, so that it is possible to continue after issuing 'M0' in mdi mode"
[13:11:35] <mozmck> Hmm, how do you search history for that?
[13:12:16] <jepler> well .. normally I'd "just" use git gui blame, but because there is a revision in between that accidentally totally deleted .../axis.py it was a bit more complicated
[13:12:32] <mozmck> The whole block was? What it looks like though, is that the ensure_mode() call will never actually do anything, because if we are not in one of those modes the line before will have returned from the function.
[13:12:44] <jepler> right, that's what I see too
[13:12:45] <mozmck> I see.
[13:13:04] <jepler> before that revision, there was no 'if task_mode not in ... : return'
[13:13:06] <jepler> just ensure_mode
[13:13:44] <mozmck> I was mainly just curious, because I'm having to re-invent the wheel in my GUI and I was looking at hal_actions and axis to see how to do it :)
[13:13:47] <jepler> this is rev c963df7
[13:14:20] <jepler> sigh
[13:14:56] <jepler> you have identified that we already have 2 copies of this code
[13:14:59] <mozmck> It's mainly because I made those light-buttons, and I don't know how to make them use hal_actions (yet).
[13:15:01] <jepler> you really should avoid writing a third one
[13:15:16] <mozmck> That's true.
[13:15:40] <mozmck> I will have to figure out where to put the code to consolidate it though.
[13:16:01] <jepler> ideally you could delete twice as many lines as you add in the process, and still have the new functionality you need for your new thing
[13:16:17] <jepler> (for everything that is in both axis and hal_actions (which I am not familiar with))
[13:16:41] <jepler> sigh, we have so many copies of everything and it's terrible
[13:17:08] <mozmck> hal_actions are Action objects used in Gladevcp. They can be attached to buttons and etc, and control the state of the buttons as well as execute code when activated.
[13:17:38] <mozmck> A really nice concept actually for GUI stuff.
[13:19:34] <JT-Shop> pcw_home, will do
[13:24:10] <pcw_home> unfortunately adding the A,B and Index-in pins to hostmot2 have mislead
[13:24:11] <pcw_home> at least a couple of people into thinking the index-in pin can be used for index operations
[13:27:20] <pcw_home> (Its really only for debugging or re-purposing encoder pins as GP 5V inputs)
[13:29:25] <Roguish> pcw_home and JT-Shop: THANK YOU. THANK YOU, THANK YOU.
[13:36:54] <cradek> +# Copyright 2004, 2005, 2006 Jeff Epler <jepler@unpythonic.net> and
[13:36:55] <cradek> +# Chris Radek <chris@timeguy.com>
[13:37:04] <cradek> good grief it's 11 years old
[13:39:57] <jepler> cradek: oh dear, is our software a tween?
[13:40:00] <jepler> no wonder it's so moody
[13:43:15] <cradek> nah, it's very stable for a 11-year-old
[13:46:25] <mozmck> I ran (simulated) a cut using G64 P0.1, and here is the backplot:
http://pasteboard.co/1IeuYPxP.png
[13:47:08] <mozmck> Why did it miss the straight lines on the inner star but did fine on the outer star? This is current 2.7
[13:48:37] <cradek> the corner arcs make the path completely different
[13:49:09] <cradek> I don't like the result very much, but is it within 0.1?
[13:49:44] <cradek> I'm only guessing, but it might not be working how rob intended
[13:50:45] <mozmck> I guess it's within .1 - I'm not sure how to tell other than comparing to the distance the other points are from the path.
[13:51:10] <cradek> it looks like a good test case to show that particular behavior
[13:51:35] <cradek> might not hurt to make a bug report, because I do kind of think it might be unintended
[13:52:00] <mozmck> Ok, I guess the bug reports are on sourceforge?
[13:52:04] <cradek> yes
[13:52:59] <cradek> please attach the image and gcode directly there
[13:53:05] <mozmck> Ah, ok.
[13:53:28] <pcw_home> yeah, you would think it would follow more closely when its possible
[13:55:35] <pcw_home> is that .1"? maybe that big a tolerance has not been tested
[14:04:23] <pcw_home> Hmm what would be the best way to write more than 32 bits of data to a hal component (say up to 8 u32s )?
[14:04:25] <pcw_home> multiple u32s pins and a parameter that says how many are active would work but is a bit klunky
[14:04:55] <cradek> there's no good way
[14:07:06] <pcw_home> Yeah no array types
[14:11:12] <pcw_home> looking into making a hostmot2 module for laser modulation but 32 bits only gets me to 32 KHz at a 1 KHz servo thread
[14:13:15] <pcw_home> especially for Ethernet where you can't have a base thread
[14:20:01] <jepler> this is a similar problem to any attempt to graft serial communication onto hal
[14:21:03] <jepler> in the original rtapi, there were FIFOs, which I think were byte-oriented and had an upper size fixed at creation time, but they were never exposed as objects in HAL and they don't appear at all in newer rtapi implementations like uspace
[14:21:47] <jepler> some places, like in halstreamer/halsampler/halscope, we basically rolled our own FIFOs based on shared memory areas instead
[14:24:37] <jepler> I bet it's not hard to add FIFOs to uspace rtapi (they're just unix named pipes), but I'm not sure what it would look like to connect them in hal
[14:26:19] <mozmck> I saw some talk that there are FIFOs in "that other linux cnc software"
[14:26:25] <jepler> shrug
[14:26:39] <mozmck> But I don't know what they are for.
[14:27:48] <pcw_home> for simple time based raster (not multi axis painting) a fixed block size is OK
[14:28:31] <pcw_home> as soon as you use stepgen or encoder clocking then a real FIFO is needed
[14:33:05] <pcw_home> That is, for a time based raster clock, using lower order bits of the DPLL accumulator as the raster clock gives you
[14:33:07] <pcw_home> perfect long term sync with the servo thread so a fixed block of raster data every servo thread works
[14:34:55] <seb_kuzminsky> ooh! i think i found the race in halui that's causing the halui/mdi test to fail sometimes
[14:37:15] <seb_kuzminsky> http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob;f=src/emc/usr_intf/halui.cc;h=39fc60ccda9d179dc56a46272bdc3dd2157c96f7;hb=HEAD#l1122
[14:37:19] <seb_kuzminsky> "switch to mdi mode if needed
[14:37:41] <seb_kuzminsky> it sends the command to switch task to mdi mode, which waits for task to receive the command but not to report it done
[14:38:00] <seb_kuzminsky> then it checks if the task mode is now mdi, and fails silently if not
[14:38:45] <seb_kuzminsky> i think it needs a call to emcCommandWaitDone() after sendMdi()
[14:38:48] <seb_kuzminsky> testing that now...
[14:39:59] <seb_kuzminsky> it took ~12,000 passes of halui/mdi to repro the failure we saw on the buildbot, on my dev machine
[14:40:24] <jepler> a "library" form of the realtime part of halstreamer would allow more than 1 sample to be read out per cycle
[14:40:37] <jepler> and the userspace part just stays halstreamer
[14:47:55] <pcw_home> just using multiple u32s is probably OK for now (even 4 u32s 128KHz so <1 mill at 100 IPS)
[14:48:52] <pcw_home> its gets harder if you need Analog/PWM so more than 1 bit/pixel
[16:05:11] <mozmck> bug report filed - I hope it is clear enough. I did more testing and attached more images.
[18:06:50] <KGB-linuxcnc> 03John Thornton 052.7 0f2aa4d 06linuxcnc 10docs/src/config/ini_homing.txt Docs: add info on index-enable and home * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0f2aa4d
[18:07:02] * jthornton takes the rest of the day off
[18:23:23] <KGB-linuxcnc> 03Chris Radek 052.7 960678e 06linuxcnc 10docs/html/gcode.html Docs: G64 now optionally takes Q * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=960678e
[18:58:16] <mozmck> cradek: regarding bug 426: according to the docs, "when you activate G64 P- Q- it turns on the naive cam detector", so I thought the NCD would be off if I did not specify Q
[18:59:03] <cradek> I think P is NCD tolerance and Q is motion tolerance [and an unspecified Q defaults to the P value]
[18:59:12] <cradek> but I haven't looked at the docs or the source
[18:59:44] <mozmck> According to the docs it's the other way around.
[18:59:58] <mozmck> http://www.linuxcnc.org/docs/2.7/html/gcode/gcode.html#sec:G64
[19:00:15] <mozmck> bbl
[19:00:27] <cradek> I agree the docs disagree with my memory
[19:14:53] <kwallace_shop> Hello. I just installed a new LinuxCNC 2.6.8 and tried remapping with the sample M400.ngc, but I get "M code greater than 199" , which makes me think 2.6.8 doesn't do remapping?
[19:29:40] <kwallace_shop> Oops, it helps to edit the proper .ini file.
[19:36:27] <kwallace_shop> All better now.
[20:51:34] <skunkworks> P is path tollerence. Q is NCD. If you just specify a P then Q=P
[21:20:23] <cradek> so he might want to try Q0 ?
[22:08:30] <skunksleep> I don't know the issue but q0 would turn the ncd off
[22:13:46] <skunksleep> http://www.cnczone.com/forums/linuxcnc-formerly-emc2-/206712-software.html#post1453550
[22:14:07] <skunksleep> And a few post down
[22:33:43] <mozmck> skunksleep: setting Q0 worked.
[22:33:47] <mozmck> Thanks!
[22:34:09] <mozmck> See bug 426 to see what the issue (or non-issue now I guess) was.
