#linuxcnc-devel | Logs for 2013-07-03

Back
[00:09:36] <ssi> got it... something's changed between the version of hm2_7i43 I based this skeleton on and the current code tree i'm working in
[00:10:08] <ssi> I had #define HM2_BCC_MAX_BOARDS (4), and the parens were flipping out the rtapi module parser
[01:12:33] <memleak> im gettin sleepy, good night all
[06:02:54] <KGB-linuxcnc> 03jthornton 05v2.5_branch b538aa7 06linuxcnc 10docs/src/examples/mpg.txt
[06:02:55] <KGB-linuxcnc> Docs: fix example code
[06:02:55] <KGB-linuxcnc> Thanks to Tom for spotting this and fixing the example
[06:02:55] <KGB-linuxcnc> Signed-off-by: John Thornton <jthornton@gnipsel.com>
[06:11:17] <jthornton> odd the terminal window hung up after Total 6 (delta 5), reused 0 (delta 0) and seems to be waiting on something
[06:44:42] <linuxcnc-build> build #1137 of lucid-amd64-sim is complete: Failure [4failed compile runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/1137 blamelist: John Thornton <jthornton@gnipsel.com>
[06:56:15] <linuxcnc-build> build #1134 of checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1134 blamelist: John Thornton <jthornton@gnipsel.com>
[07:17:40] <jepler> ssi: it's a difference in how loadrt parameters work between kernel 2.6+ and userspace, hm2_7i43 when running in kernelspace wouldn't encounter a problem; in a userspace thread model it would
[08:35:29] <skunkworks> he also got http://electronicsam.com/images/emco/terco.JPG
[08:36:01] <skunkworks> oops
[08:42:22] <jthornton> I got a strange error after my last push that I don't understand. http://pastebin.com/gvXXVWcU
[08:45:03] <cradek> error: error in sideband demultiplexer
[08:45:04] <cradek> uhhh
[08:46:00] <jthornton> what the heck is that?
[08:46:04] <cradek> b538aa7 did get pushed
[08:46:06] <cradek> I have no idea, sorry
[08:46:23] <jthornton> ok, if it got pushed I'll ignore the error on this end
[08:46:28] <jthornton> thanks for looking
[08:46:38] <cradek> http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=log;h=refs/heads/v2.5_branch
[08:47:59] <jthornton> I didn't even think of looking on the git log, I focused too much on the error
[08:59:13] <ssi> jepler: that makes sense
[09:38:53] <seb_kuzminsky> argh
[09:39:18] <seb_kuzminsky> the buildbot failure looks like the old linuxcncrsh problem again, but running with cradek
[09:39:40] <seb_kuzminsky> cradek's unbehiddening patch there's new info:
[09:39:48] <seb_kuzminsky> http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/1137/steps/runtests/logs/stdio
[09:39:51] <seb_kuzminsky> search for linuxcncrsh
[09:40:10] <seb_kuzminsky> "Not starting new LinuxCNC"
[09:40:25] <seb_kuzminsky> that's the linuxcnc script not starting linuxcnc because it thinks it's already running
[09:41:48] <jepler> back here at build 1133, the build was killed for "1200 seconds without output"
[09:41:51] <jepler> http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/1133/steps/runtests/logs/stdio
[09:41:54] <jepler> that sure could leave the lock file
[09:42:11] <jepler> .. and that log has interesting information too
[09:42:15] <jepler> it goes off the rails because:
[09:42:15] <jepler> Issuing EMC_TASK_PLAN_EXECUTE -- (+509,+280, +9,m100\032p0\032q0,)
[09:42:15] <jepler> Can't issue MDI command when not homed
[09:42:15] <jepler> emc/task/emctaskmain.cc 2185: error executing command 509:EMC_TASK_PLAN_EXECUTE
[09:42:18] <jepler> emcTaskIssueCommand() returning: -1
[09:42:44] <seb_kuzminsky> i gotta run, but i'll look at this later today
[09:42:50] <jepler> you're a champ.
[09:42:52] <seb_kuzminsky> seems like two problems
[09:43:06] <seb_kuzminsky> i'm a chump for putting this failing test in there in the first place...
[09:43:07] <seb_kuzminsky> laters
[09:43:20] <jepler> so 'sleep 2' isn't necessarily enough to get linuxcnc homed I guess?
[10:06:42] <alex_joni> cradek: http://stackoverflow.com/questions/9592908/error-in-sideband-demultiplexer-with-a-git-post-receive-hook
[10:07:50] <cradek> I kind of figured one of the hooks failed, but I couldn't find anything in my logs about what or why
[10:08:23] <alex_joni> might be the KGB hook?
[10:08:31] <cradek> KGB-linuxcnc: knock knock
[10:08:32] <KGB-linuxcnc> cradek: My master told me to not respond.
[10:08:41] <cradek> well it's alive
[10:08:53] <cradek> it might have been buildbot too
[10:08:53] <alex_joni> if it's a one-off.. forget it :)
[10:08:55] * cradek shrugs
[10:09:11] <cradek> thanks for finding that answer
[10:10:29] <alex_joni> I found a technical explanation too http://git.661346.n2.nabble.com/error-error-in-sideband-demultiplexer-td6473787.html
[10:12:45] <cradek> "the XXXX hook exited with an error or before reading all its stdin"
[10:13:35] <cradek> EVEN if you know it's talking about hooks, it's still a lousy error message that makes you guess what went wrong
[10:13:46] <JT-Shop> I've only seen it the one time
[10:41:12] <kwallace> Is it just me or is searching for information on IC part numbers totally polluted?
[10:45:05] <skunkworks> you have to wade through the crap
[10:45:24] <cradek> yeah, it's not you
[10:46:29] <kwallace> I found it: http://www.pericom.com/products/signal-switch-multiplexers/?part=PI5C16211
[10:48:10] <kwallace> I found this chip on the 6i25 and assume I can use these specs as a guide for the I/O pins?
[10:49:48] <CaptHindsight> for signal characteristics possibly if there are no other components between the package pins and the connectors
[10:51:02] <CaptHindsight> but signal numbering on the Pin Config diagram and what the PCB uses might be completely different
[10:54:58] <kwallace> I'm just trying to get an idea what the 6i25 I/O sink and source currents might be. Crud, this chip is a switch and not a driver, so is the wrong place to look.
[10:55:27] <skunkworks> kwallace, ask peter :)
[10:55:46] <cradek> I'd figure his manuals were good enough to tell you - no?
[10:58:16] <skunkworks> I don't see it in the manual
[10:58:27] <kwallace> The only thing I have pulled from the manual is information on voltage tolerance and pull-ups, which don't shed light on sink current.
[10:59:18] <skunkworks> it should be atleast as good as a printer port sinking :)
[11:03:27] <kwallace> Which usually is 3ma. Until I hear otherwise, I'll have to go with that. Thank you.
[11:16:10] <jepler> I also don't spot a specification of sink current in the 6i25 manual
[11:18:18] <pcw_home> 24 mA sink/source
[11:19:17] <pcw_home> (Max, the output drive is programmable)
[11:19:32] <jepler> pcw_home: thank you
[11:19:35] <jepler> did we overlook it in the manual?
[11:19:43] <jepler> or is it bitfile programmable?
[11:20:02] <pcw_home> Yes its programmable in th ebitfile
[11:20:05] <jepler> gotcha
[11:20:23] <pcw_home> ~4 to 24 mA IICRC
[11:20:58] <pcw_home> default for external I/O pins in our UCF files is 24 mA
[11:22:46] <seb_kuzminsky> pcw_home: speaking of "programmable in the bitfile", we should talk about hostmot2 firmware building at some point
[11:22:51] <pcw_home> NET "IOBITS<0>" LOC = "P132" | IOSTANDARD=LVTTL | SLEW=SLOW | DRIVE=24;
[11:23:27] <seb_kuzminsky> the hm2 buildbot is up and running, it's building the vhdl source in git and producing debs containing bitfiles that i haven't tested yet
[11:23:39] <pcw_home> Thats would be great to get the buildbot synced to the latest
[11:24:05] <kwallace> So, I can count on at least 4ma which is plenty to control optos, LEDs and driver ICs. Thanks Peter.
[11:24:16] <seb_kuzminsky> yeah, agreed!
[11:24:39] <seb_kuzminsky> i'd be happy to help you get set up with git some night (not now, i'm at work)
[11:24:54] <seb_kuzminsky> do you do your development on windows or linux? (or something else?)
[11:25:13] <pcw_home> kwallace all of our standard configs are set for 24 mA on the I/O pins
[11:25:25] <pcw_home> Windows
[11:25:36] <pcw_home> not that it matters much
[11:26:04] <pcw_home> I actually made a batch file to build all the 7I80 varients
[11:26:09] <seb_kuzminsky> it only impacts which git client you use
[11:27:08] <seb_kuzminsky> hey, the git folks are providing .exe files (installers?) directly, i didn't know that! http://git-scm.com/download/win
[11:27:22] <seb_kuzminsky> bbl
[11:27:36] <pcw_home> bye
[11:31:24] <jepler> pcw_home: is current ISE able to take advantage of multiple cores while building a single firmware?
[11:31:59] <jepler> pcw_home: one of the neat things about my linux build scripts is that as long as you have enough RAM you can start 1 firmware build for each core in a multi-core system
[11:32:14] <jepler> .. i am not aware of how to do that with batch files, though it sure could be a hole in my knowledge
[11:41:03] <pcw_home> I think its possible but I did not do it (also not sure it would help much with only4 G of RAM)
[11:41:05] <pcw_home> i just let it run, took a few hours to do ~20 bitfiles
[11:45:50] <jepler> I did this in a 4GB, 4-core machine though that was also with an older version of ise
[11:46:11] <jepler> I assume now that 4GB+ machines are the norm their memory usage has grown accordingly
[11:47:56] <jepler> my memory is that I could build 48 firmwares in something like 80 wall minutes
[11:48:00] <pcw_home> Not sure, the install size is huge now but i dont think they mess with place&route much, its more FPGA size dependent
[11:49:33] <pcw_home> also really depends on how full the FPGA is (80% might be 5 minutes, 95% migh be 40)
[14:37:30] <andypugh> How wedded are we to TOOL_CHANGE_QUILL_UP and TOOL_CHANGE_AT_G30?
[14:39:19] <andypugh> I find myself wondering if tool change position should be a tool database property. And, for that matter, if spindle positioning should be a toolchanger-defined action.
[14:40:26] <cradek> I'd hope any more flexible system would replace those settings (and still be able to do the same things)
[14:40:32] <cradek> but I'm not sure if that's what you are asking
[14:42:16] <skunkworks> the tool table application would look at those ini file configs and set the correct fields for each tool. :)
[14:43:22] <skunkworks> oh - that would not work. G30 is during program run settable. Hmm what would be
[14:43:24] <andypugh> I don't think you caan determine G30 from the INI.
[14:44:14] <skunkworks> would you be able to set the location as vars?
[14:44:29] <andypugh> I guess that TOOLCHANGE_AT_G30 lets you alter the tool change position in the G-code.
[14:44:40] <andypugh> I am not sure I see that as an advantage.
[14:44:51] <cradek> heh
[14:46:18] <cradek> it's nice that once you get your tools and workpiece loaded, you can move the machine to where it looks safe (like the turret can spin without smashing those long drills into the work) but not much farther, and then do g30.1 and it the tool change location is quickly and easily set to there
[14:46:30] <andypugh> I guess I will just leave the code there, it doesn't actually do any harm.
[14:49:24] <andypugh> This piece of wool I am pulling shows no signs of stopping unravelling...
[14:49:48] <cradek> I bet
[14:53:25] <andypugh> I think iocontrol is doomed.
[14:55:54] <cradek> yay
[14:56:49] <cradek> especially on a lathe job, tool change motion can take a big chunk of the time - it's nice to be able to easily change it
[14:57:14] <cradek> you can leave the spindle going too, so you don't have to wait for it to stop and start
[14:59:57] <andypugh> Short term I am thinking in terms of loadable HAL modules that watch the NML messages and act on tool requests. Then manual / random / turret is a matter of which toolchanger module you load.
[15:00:44] <andypugh> (iocontrol is likley to pre-decease NML)
[15:01:37] <skunkworks> is there an easy way to output a pulse evertime the base thread runs? Like I was outputting a step pulse every base period?
[15:01:56] <andypugh> skunkworks: charge pump?
[15:02:06] <cradek> that'd be every other
[15:02:21] <andypugh> (though I think that might toggle it every _other_ base thread.
[15:02:32] <skunkworks> right
[15:02:47] <andypugh> supply and reset?
[15:02:48] <skunkworks> could I setup a stepgen to do it?
[15:03:18] <cradek> I think you'd just put parport.write and parport.reset in your thread and set some pin high
[15:03:33] <cradek> only the parport doublestep hackery will be capable of doing this
[15:03:39] <skunkworks> right
[15:03:52] <skunkworks> *with the stepgen in doublestep
[15:04:04] <jepler> no you would just feed it '1' (from supply or setp)
[15:04:07] <cradek> you don't need or want stepgen as far as I can see
[15:04:13] <cradek> right
[15:04:22] <jepler> (or an existing enable signal if it should be enabled)
[15:04:34] <andypugh> cradek: You need to set it high every base thread, so possibly use a suitable setp-ed and2?
[15:04:52] <cradek> it'll stay high
[15:04:59] <jepler> right, nothing will drive the signal low
[15:05:04] <skunkworks> jepler, what - what?
[15:05:10] <jepler> nothing will drive the hal signal low
[15:05:26] <jepler> but when stepgen is in the reset mode, a consistent high signal will give one pulse every cycle
[15:05:42] <cradek> you mean parport
[15:05:46] <andypugh> Ah, OK, reset is purely at the hardware register level?
[15:05:51] <skunkworks> high signal to what? That is what I am wondering.
[15:05:52] <jepler> right, parport not stepgen
[15:05:57] <skunkworks> oh
[15:05:58] <skunkworks> duh
[15:06:00] <skunkworks> ok
[15:06:04] <cradek> setp parport.xx-out 1
[15:06:13] <jepler> and setp parport.xx-reset 1
[15:06:24] <cradek> addf parport.write; addf parport.reset
[15:06:33] <jepler> er, -out-reset
[15:06:46] <cradek> pseudohal
[15:07:03] <skunkworks> wait - so all ouput pins of the parallel port do that in reset mode?
[15:07:26] <andypugh> Yes, it's a parport thing, not a stepgen thing.
[15:07:33] <skunkworks> oh - it is pin by pin?
[15:07:38] <andypugh> yes
[15:08:03] <skunkworks> cool
[15:09:19] <skunkworks> These emco compact 5 'pc's seem to use the printer port as a normal step/dir interface other than they latch whenever they want the data read.
[15:10:37] <skunkworks> there is some hackery where they cut out the latch ic and jump through. (for mach) but I think I could just set the latch each time
[15:11:16] <jepler> playing with openscad and slic3r targeting linuxcnc gcode (no glue gun hardware to drive yet though). http://emergent.unpythonic.net/files/sandbox/axis-slic3r.png
[15:11:57] <jepler> this file is ~95k lines and loads/animates fine. of course, I have nvidia proprietary opengl drivers installed..
[15:12:05] <skunkworks> wow - that is pretty
[15:13:05] <skunkworks> *each base sycle.
[15:13:08] <skunkworks> base
[15:13:10] <jepler> it is using the alpha blended gcode option, which lets you make some sense of very tight gcodes like that
[15:13:12] <skunkworks> heh
[15:13:15] <skunkworks> cycle
[15:13:16] <jepler> oh you mean your scope is pretty?
[15:13:35] <skunkworks> no - your screenshot.
[15:16:33] <andypugh> jepler: That looks like part of a Rostock. I suspect you have a bootstrap / catch-22 / chicken and egg problem.
[15:18:44] <jepler> andypugh: that's why you start by spending like a thousand bucks..
[15:18:47] <jepler> (quite right)
[15:30:10] <jepler> the only delta-type extruder I've found where you just by all the pieces from one website is the "rostock max", but most of the reviews of it are not thrilled---at least in the original version, the extruder was not very good, particularly at retracts
[15:30:41] <jepler> the other thing is that the arms are apparently fragile, so many people replace the mounts with magnetic mounts
[15:31:22] <jepler> .. the parts shown are part of a magnetic mount that would use steel bals on the ends of rods and washer/ring-shaped magnets pressed into the cartridge and the platform
[15:31:43] <jepler> (which is not quite the same as any of the other magnetic redesigns I've found)
[15:32:23] <jepler> but .. still not sure I want to spend a thousand bucks on a 3d printer right now
[15:32:35] <jepler> delta-types are on my mind because I'd eventually convert it to linuxcnc so I can play with nontrivkins
[15:32:52] <seb_kuzminsky> jepler: that's very cool
[15:33:35] <seb_kuzminsky> are you runnign slic3r on linux? i heard it sucks :-/
[15:33:47] <jepler> I started with slic3r because that's what charles used
[15:33:58] <seb_kuzminsky> it's what everyone uses, apparently
[15:34:03] <jepler> I don't have any comparative experience yet
[15:34:19] <jepler> last time I played around I tried a different one and it had an even more bewildering array of configuration options
[15:34:31] <seb_kuzminsky> there's been work in freecad lately that may be applicable - section views through your solid
[15:34:41] <jepler> interesting
[15:34:55] <seb_kuzminsky> we'll see where it goes
[15:35:18] <seb_kuzminsky> a bunch of folks at the boulder hackspace are all fired up to convert our 3d printers to linuxcnc now :-)
[15:53:13] <jepler> do you have enough experience with stl -> gcode software to suggest what I should look at after slic3r?
[15:53:56] <jepler> slic3r is made of perl !?
[15:56:15] <seb_kuzminsky> only for subtractive machining. I've had success with pycam for stl -> gcode, but i dont think it does additive fabrication
[15:57:03] <seb_kuzminsky> lol, the #sparkfun topic consists of this link: http://i.qkme.me/3qt516.jpg
[16:17:32] <skunkworks> yeck. Maybe it won't be that easy. http://www.nxp.com/documents/data_sheet/74HC_HCT374_CNV.pdf
[16:19:21] <skunkworks> there has to be a setup and hold time before the clock. Hmm - we are talking ns here. I wonder if it is an issue.
[16:20:02] <skunkworks> I could suppose set the printer port pins individually. instead of -all
[16:20:26] <skunkworks> maybe
[16:21:30] <skunkworks> or I could just bypass the chip.. but it would be cool to have a plug and play solution with linuxcnc.
[16:21:51] <skunkworks> this is the only reference I have http://www.maxton.com/ebay/emco/EMCO%20Compact%205PC%20Conversion%20to%20Mach3.pdf
[16:22:02] <skunkworks> (that article is a bit scary_
[16:24:22] <skunkworks> at plug and play seems doable..
[16:41:20] <andypugh> FWIW slicing an STL is 3 lines of codein Octave
[16:56:40] <skunkworks> heh I can't write each pin individually... the write function runs once per base period duh
[16:57:28] <andypugh> It doesn't have to..
[16:58:07] <andypugh> I ahve never tried this, but there is a fair chance you can addf it twice.
[16:58:28] <skunkworks> heh - the question is - can I set the clock and input at the same time.
[16:58:33] <andypugh> But that may be jumping too soon into implementation.
[16:58:43] <skunkworks> I resemble that remark
[16:59:43] <andypugh> I think you might need to look at the "reset" function and make something that does something similar when you want to.
[17:00:07] <andypugh> A HAL component that toggles one parport pin is pretty trivial.
[17:01:02] <andypugh> component skunk "shortest comp evah!"
[17:01:04] <andypugh> ;;
[17:01:15] <jepler> error: no license specified
[17:01:20] <andypugh> outb(0,0x378)
[17:01:21] <jepler> error: must have at least one pin or parameter or something
[17:02:16] <andypugh> jepler: You removed the requirement to have a function, do the same for pins. But the license is a good call.
[17:02:58] <jepler> skunkworks: use a negative-going pulse to get your setup and hold
[17:03:07] <jepler> that involves also setting xx-out-invert
[17:03:39] <jepler> then you get your setup and hold requirements of the rising edge of the CP pin of 74374 because it happens a configurable time (e.g., min 2000ns) after the data is stable
[17:04:00] <skunkworks> damn
[17:04:11] <skunkworks> that is elegant...
[17:04:18] <jepler> I hope what I said is accurate too
[17:04:52] <skunkworks> heh
[17:05:57] <skunkworks> hmm - I need to think about this. time for a nap
[17:07:23] <skunkworks> I could still use the stepgen in reset mode - just set the reset mode for the stepgen to be longer than the clock pin I am using. (am I understanding it right?)
[17:07:40] <jepler> right, this is for using the reset mode
[17:09:04] <skunkworks> wow - that might work
[17:09:05] <skunkworks> :)
[17:09:24] <skunkworks> jepler: thank you
[17:09:32] <jepler> welcome
[17:09:54] <andypugh> jthornton: http://youtu.be/FVB_rxerfEs
[17:38:59] <skunkworks> how does the reset work with 2 different .reset times? oh - I suppose .reset function just waits until the longest time elapses? reseting the different set of pins along the way?
[17:40:35] <andypugh> it might run twice, if there are two of them. What a complex concept.
[17:41:33] <andypugh> On entry the reset function first checks that the time hasn't already elapsed, and if it has, it exits imediately.
[17:42:20] <andypugh> Otherwise it waits. While it is waiting the entire computer stops, as I understand it. You probably want to avoid long reset times.
[17:47:53] <jepler> skunkworks: I thought there was a single .reset time for all pins
[17:49:30] <andypugh> I am too lazy to check the code, but it might be one reset time for each reset instance?
[17:50:30] <andypugh> (That could only work if the rest instances share a mask). So perhaps it is explicitly singleton. At the moment. :-)
[18:09:12] <andypugh> seb_kuzminsky: For 2.6, how about setting it up to email me any time someone uses G10 L1, L10 or L11 in actual G-code outside MDI or a probe?
[18:10:39] <andypugh> Because that is a nasty corner-case in the distinction between readahead state and machine state.
[18:11:12] <mhaberler> I had been discussing this with cradek a loong time ago; cradek: around?
[18:12:24] <skunkworks> jepler: then my question is how does reset reset pins when they have different reset times?
[18:12:43] <mhaberler> actually the hairy usage condition can be narrowed down a bit: if a 'G10 xxx' is used and the interp is _not_ in a synced state
[18:13:02] <andypugh> It makes life easier if any G10 synchs the queue. I reckon nobody would even notice.
[18:13:10] <mhaberler> nb: post-probe it's in a synced state
[18:13:17] <mhaberler> that's an interesting idea
[18:13:51] <mhaberler> maybe this could in fact solve the issue
[18:14:12] <andypugh> I have used LinuxCNC for years and never explictly used a G10
[18:14:59] <andypugh> I guess that touch-off has effectively done the same thing, but that's not coordinated.
[18:15:18] <mhaberler> well t/o forces a sync post close/timeout
[18:15:35] <andypugh> You are most unlikely to use any G10 in the middle of a profiling move...
[18:15:42] <mhaberler> so post-probe the interp is synced when the next op begins
[18:17:32] <mhaberler> trying to think through if we have a simple condition which can trap that situation; unfortunately there's no 'synced' property
[18:18:18] <mhaberler> one can address the question from a different angle:
[18:18:42] <mhaberler> is the semantics of g-code program identical if readahead is disabled
[18:18:58] <andypugh> Yes.
[18:19:04] <mhaberler> (ignoring blending for now)
[18:19:17] <andypugh> But the performance might reduce.
[18:19:23] <mhaberler> right
[18:20:06] <mhaberler> if that were the case, then a user would be free to sprinkle queuebuster ops into the program and still get the same result (except blending and maybe ncd)
[18:20:21] <andypugh> So, who expects velocity to be constant through a tool or offset change? I would guess at "nobody"
[18:20:56] <zultron> mhaberler, still on US time, I see?
[18:20:59] <mhaberler> yes
[18:21:03] <mhaberler> badly so ;)
[18:21:15] <mhaberler> andy: did you see this one: http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=blob;f=configs/sim/remap/stop-lookahead/README;h=436e134403b699c0ba18e392c721e1bd15d14d1c;hb=d2f30b299c61986fa5ba398a478b78a778872cf3 ?
[18:21:33] <mhaberler> this is essentially a bust-queue-on-demand code
[18:22:05] <mhaberler> (it works wonders when reading an arbitrary hal pin value ;)
[18:22:30] <andypugh> I rather suspect that as long as we support infinite lookahead through G1, G2, G3 and S and stop dead on any other G-code all the users would be happy.
[18:23:12] <mhaberler> do we have any other dead bodies of that sort other than G10?
[18:23:15] <andypugh> No, I hdn't seen that, I don't think
[18:24:54] <andypugh> Not that I have spotted so far, but have only even looked at the userpace stuff for a few months. Everything I have done up to now is nice clean, linear, easy, realtime kernel code.
[18:24:58] <mhaberler> if we can elevate G10 to mean G10, followed by such a G103, this would take out several moving parts
[18:25:34] <mhaberler> what is the line of thought from 'nice and clean' to 'kernel' ;-?
[18:26:06] <andypugh> I think it is easier than that, move G10 to join the other must-synch codes in the BigSwitch?
[18:26:17] <mhaberler> right
[18:26:22] <skunkworks> jepler: if it doesn't work with 2 different reset times - I could just use the reset for the clock(inverted) and run the stepgen in non-reset - normal mode. (this is only 2000ish steps per inch so slow)
[18:26:24] <mhaberler> not much to it
[18:26:30] <mhaberler> no, even easier
[18:26:47] <mhaberler> interp returns interp_execute_finish after a g10, not an interp_ok
[18:26:53] <mhaberler> task handles the rest
[18:27:07] <andypugh> kernel code is nice an clean. Limited, awkward, but you know where you are.
[18:27:57] <andypugh> Ah, yes. <crosses problem off list>
[18:28:48] <mhaberler> I think g92 needs consideration too
[18:29:10] <mhaberler> in particular g92.1,2,3
[18:29:52] <andypugh> Again, I doubt anyone would moan if it broke constant velocity. And redahead is all about constant velocity.
[18:30:52] <mhaberler> that I dont understand, what breaks cv?
[18:31:44] <andypugh> I find it hard to imagine that even a Babbage Engine couldn't keep up with a milling machine. Considering that the workpiece has metal where the Babbage Engine has air in the cams.
[18:32:54] <andypugh> My point is that if the tool point motion stutters due to lack of readehead through a G92, nobody would be surprised.
[18:33:17] <mhaberler> I guess yes
[18:33:31] <andypugh> Whereas they do complain if it stutters between G1 and G2.
[18:34:23] <andypugh> (and, they have, and in some cases with good cause, and some cases unfairly.
[18:35:52] <andypugh> G1 to G2 non-tangetially probably should stutter, and likewise if the R is small. I am not clear which of those conditions was true in Steve Blackmore's code, or neither.
[18:37:09] <mhaberler> does peter jensen hang out here? Dan Falck just pointed me to this: http://nraynaud.github.io/webgcode/
[18:37:54] <mhaberler> andy - I think until proven wrong we could just as well assume G10 and g92.x can be made queuebusters without ill effect
[18:38:14] <mhaberler> we need to get Chris to think this one through, too
[18:39:43] <mhaberler> that would simplify farming out the toolinfo handling into a server big time
[18:40:56] <mhaberler> it would mean that the toolstore's view of offsets and other tool properties have no readahead aspect to it, aaah
[18:41:13] <andypugh> Interesting tool. Any idea _which_ motion controller that is?
[18:41:45] <andypugh> mhaberler: Yes, you spotted why I am attracted to the idea.
[18:41:53] <mhaberler> no, no time to read it yet
[18:42:25] <mhaberler> actually that's the issue which is the singlemost bugging on in the whole affair
[18:42:53] <mhaberler> maybe we should formulate this question to the devlist
[18:44:02] <mhaberler> and debugging too - you could rely on the toolstore reflecting what will be applied
[18:45:51] <mhaberler> (maybe we should just change the interp to sync at g10,g92.x and see if we get a bugtracker entry ;)
[18:46:01] <andypugh> Yes, if you specify that "there can be only one worldview" and that anything that breaks that (other than actual tool-point position) is a "queuebuster" then what is the penalty. I suspect that that in practice there is no penalty.
[18:46:11] <mhaberler> 'an empiricial study'
[18:46:36] <mhaberler> ah, thats an interesting angle
[18:46:50] <mhaberler> narrow down the concept of readahead state instead
[18:47:03] <mhaberler> we have tooltip, modal state, settings
[18:47:07] <mhaberler> anything else?
[18:49:12] <andypugh> Not yet, I am thinking on my feet here.
[18:50:02] <mhaberler> that blob of state in _setup is frightening.. need to go through that line by line really
[18:53:02] <mhaberler> I think we might need a more formal definition what readahead state is
[18:53:46] <andypugh> It is frightening from a conventional software design POV. I have not yet convinced myself it is conceptually wrong for a machine controller.
[18:54:19] <mhaberler> attempt#1: all aspects of interpreter state which can affect machine state and may be out phase with the worldview by more than one command
[18:55:06] <andypugh> more than one NML message?
[18:55:29] <mhaberler> hm, canon command maybe
[18:56:53] <mhaberler> attempt#2: all state in interp which may be changed without breaking position predicition
[18:57:35] <mhaberler> I think that is the more relevant view
[18:58:05] <mhaberler> this suggests we look through all the state which gets set in a sync() operation - that is the ra state
[18:58:38] <mhaberler> by definition, any state that doesnt get changed in sync() cant break ra
[18:59:06] <mhaberler> otherwise it wouldnt be synced to start with..
[18:59:18] <mhaberler> so.. Interp::sync()...
[18:59:33] <andypugh> I think that is right, but need to check
[19:01:05] <mhaberler> Interp::init() just sets the starting condition
[19:01:42] <mhaberler> so: here http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=blob;f=src/emc/rs274ngc/rs274ngc_pre.cc;h=9137a96af1459e546af5ecd8babf1a777ae182ad;hb=d2f30b299c61986fa5ba398a478b78a778872cf3#l1883
[19:02:38] <andypugh> Hmm. Is that generic?
[19:03:05] <mhaberler> as opposed to what?
[19:03:59] <andypugh> (never sure in git.mah. Actually I am rarely sure in git.linuxcnc.org. How the heck do you work out which branch a commit exists in?)
[19:04:19] <mhaberler> I'm looking at master
[19:04:24] <mhaberler> not sure about the answer
[19:05:44] <mhaberler> interestingly offsets arent synced; this is because the interp really doesnt know lots about offsets
[19:06:36] <andypugh> To digress, the latter point mattered to me earlier today. A user on the forum wanted the pretty new foamcutter preview. I have no idea how to find out (from gitweb) which branches that exists on. For that matter I don't know how to do it on my own git clone either.
[19:06:45] <jepler> andypugh: if this is empty then commit d2f30b2 is on master branch: git rev-list origin/master..d2f30b299c61986fa5ba398a478b78a778872cf3
[19:07:13] <mhaberler> recording in cheatsheet...
[19:08:20] <andypugh> jepler: OK, so now, from a work PC, at lunchtime, on Windows, where buildbot is considered a malware server?
[19:08:33] <jepler> andypugh: using gitweb probably not possible
[19:08:47] <jepler> put git on your android smartphone instead
[19:09:03] <andypugh> That seems likely, and a _real_ oversight.
[19:09:41] <jepler> this will tell you *a* branch which contains the commit, but not necessarily a helpful one: $ git describe --all --contains d2f30b29
[19:09:44] <jepler> remotes/mah/master
[19:09:53] <andypugh> Surely knowing which branch a commit was pushed to is pretty dundamental?
[19:10:31] <jepler> I have to admit I'm somewhat surprised there's not a simpler incantation
[19:10:39] <andypugh> (I reserve the right to choose the definition of the new word "dundamental"
[19:10:44] <mhaberler> the tree of commits and the branch names seem to be disjoint concepts
[19:10:55] <mhaberler> branch name just points to a commit
[19:11:39] <mhaberler> so it doesnt tell anything about what else is in the forest except all the way back to the root
[19:12:23] <jepler> anyway, gitweb only exists to check the "has a web interface" item off somebody's imaginary list of requirements; it is typically the worst tool for serious investigation of the project's history.
[19:12:25] <mhaberler> returning to interp: I think we might have to look at canon a bit and how it handles offsets
[19:12:54] <andypugh> It's a real bother when trying to do support. "I know there is this new feature to solve your problem, I can find the commit, but I have _no_ idea which version you need to get it"
[19:13:52] <jepler> if you think it is in a released version, $ git describe --contains dcc5a94e64d03a754acc3cb2451e97ba58d85ee6
[19:13:55] <jepler> v2.5.1~2
[19:14:05] <jepler> this says "it's two commits before version 2.5.1, so it is in version 2.5.1."
[19:14:30] <andypugh> mhaberler: Yes, canon is still terra-ingcognita. I am slowly pulling the thread of wool and seeing what unravells
[19:14:54] <jepler> if it's not in a tag then it will typically tell you 'fatal: cannot describe...' though it might also point you at a non-version tag
[19:14:56] <Tom_itx> a tangled ball of yarn?
[19:15:02] <jepler> slightly improved version: git describe --match='v2*' --contains dcc5a94e64d03a754acc3cb2451e97ba58d85ee6
[19:15:09] <jepler> should only match v2.x tags
[19:15:28] <mhaberler> 'released version' meaning 'has tag'?
[19:16:21] <jepler> ah and here's one that will tell you *all* the remote branches that contain a commit: git branch -r --contains dcc5a94e64d03a754acc3cb2451e97ba58d85ee6
[19:16:24] <jepler> list can be long
[19:17:37] <andypugh> jepler: Again, thanks, and good info, but not (as far as I can tell) useful from the web interface. Typically I end up looking what code got changed, then looking at the tree. Sadly I find myself bothering less and less frequently.
[19:19:21] <jepler> nope, still not relevant to the web interface.
[19:20:01] <jepler> anyway I'll stop spouting off about git commandline stuff and let you guys get back to it
[19:20:07] <jepler> to interp
[19:20:23] <mhaberler> not sure I actually prefer that
[19:20:32] <andypugh> You could usefullly opinionate?
[19:22:09] <jepler> I think you guys are both far enough into the guts and bolts that you don't need opinions from someone who hasn't been in that code lately
[19:22:13] <jepler> hahah guts and bolts
[19:22:28] <andypugh> Sounds right to me
[19:23:19] <andypugh> Who was last in there? It's looking like the Code that OO forgot.
[19:23:57] <mhaberler> ok, so g5x and g92 values live in emccanon.cc, plus rotation. arg.
[19:25:17] <andypugh> G5x is currently ouside the scope of toolstore (but looks like a really natural fit)
[19:25:31] <mhaberler> there are canon cmds to pass current g5x and g92 downstream,queued as soon as set
[19:26:03] <mhaberler> well it's really blunder prevention, so we dont overlook something and create a gaffe
[19:26:50] <mhaberler> and if offsets are to be persistent.. canon might need to talk to the toolstore too
[19:29:24] <mhaberler> the offset values might be pulled back into interp for writing to the .var file though
[19:29:48] <mhaberler> there's nothing like a decent set of layering violations to confuse readers ;)
[19:34:14] <andypugh> Yeah. How about we start from scratch? ;-)
[19:34:48] <mhaberler> well offsets are some veritable mess in terms of layer jumping
[19:34:51] <andypugh> Bedtime.
[19:35:01] <mhaberler> I see. Chicken!
[19:35:32] <mhaberler> there you have it: cleanup job ahead, bang, gone they are.
[19:38:32] <mhaberler> ok, so since andy faded.. jepler: what was that branch again which you referred to (rtapi/hal exception handling)?
[19:41:06] <mhaberler> jepler/rtos-master-v0-linux_rt ?
[19:42:31] <jepler> mhaberler: yes I think so
[19:42:44] <mhaberler> ah
[19:43:10] <jepler> most of that is not suitable for merging
[19:43:48] <jepler> but a few may be
[19:43:58] <jepler> or cherry-picking more likely
[19:44:27] <jepler> d5096c27619758f8ba510802938b3a48f9894eca 72e6856c6884b9c8761d24bb5f8e77fbb0a3ee76 274f474d6f4f465e45c9fb180f72544c4cb325cc I think are good and right and don't break anything
[19:44:50] <jepler> the rtapi_get_nominal_time stuff may or may not be a good idea but I know it's broken for every rtos but rt_preempt user
[19:45:09] <jepler> I was unable to measure whether 0bf2e5b64e5b755b9c6ec9979ff86511c5d0ebef actually made a performance difference
[19:45:28] <jepler> and 87c2a6f0d8165ded67ef995ec562f4f9f044d1d1 is a right change too, as std::map is used by that header without explicitly including <map>
[19:46:13] <mhaberler> right
[19:46:33] <jepler> it didn't fix the issue I was actually thinking about, which was a hardy compile error related to that header
[19:46:40] <jepler> I think hardy, one of the old systems anyway
[19:47:01] <mhaberler> rtapi_get_nominal_time etc looks like an alternate to passing actual time in the thread function params as well?
[19:47:36] <jepler> with these two APIs we don't have to change the parameter list of the realtime functions; they can call whichever function gives them the information they want
[19:47:44] <jepler> but I haven't thought too hard about the overhead of this
[19:48:00] <jepler> two more function calls are more expensive than two more function parameters
[19:48:24] <jepler> but will enough functions consult the information that it's a win overall? no idea at all.
[19:48:32] <mhaberler> I understand reading the TSC causes a pipeline stall, not sure what this means
[19:49:19] <jepler> these all operate in nsec, so it's doing a clock_gettime syscall in the userspace cases (for the _actual variant)
[19:49:32] <mhaberler> uh
[19:49:48] <jepler> well I just read it again
[19:50:10] <jepler> it's using extra_task_data, calling clock_gettime just once per thread invocation, not once per function call
[19:50:46] <jepler> using TSCs is a bad idea but we were forced into it by a version of rtai that had a bad performance hit from whatever API was behind rtapi_get_time on rtai kernelspace
[19:51:07] <jepler> but yes there are clock_gettime calls at every thread invocation in rt_preempt
[19:51:48] <mhaberler> and making that an extra param might increase that to one per thread function
[19:52:39] <jepler> I'm curious about that actually
[19:53:07] <jepler> it seems like what you sometimes want to know is when data was read, and sometimes you want to know the best estimate of when it was written
[19:53:31] <jepler> you can know stuff instead like what time your code is actually running, or when the start of the thread invocation was
[19:53:52] <jepler> but sometimes none of those things is the actual question that would let you get better performance e.g. at closing the servo loop
[19:54:04] <jepler> (heck you probably need to know read time and expected write time both for that)
[19:55:56] <mhaberler> looking at thread_task: isnt the values from rtapi_get_clocks() what we'd want to know in the thread funct?
[19:57:39] <jepler> I think rtapi_get_time is more convenient, because you know its units (ns)
[19:57:53] <mhaberler> except that rtapi_get_clocks() is called post the threadfunct, with only the dubious value of determining runtime and maxtime?
[19:58:04] <jepler> rtapi_get_clocks is in TSCs and may have no fixed unit (CPUs with frequency scaling and non-constant tsc as one example)
[19:58:18] <jepler> (note: in our rtai kernels we disable CPU frequency scaling)
[19:58:24] <mhaberler> right.. I wonder if any code actually uses runtime and maxtime
[19:58:34] <jepler> halcmd show thread lets the user see htem
[19:58:54] <jepler> and sometimes that's useful for debugging, assuming you think you can convert it to ns
[19:58:55] <mhaberler> right, but thats display output only
[19:59:26] <jepler> rtai was the tail wagging the dog on this one. I can't think of one place we really want TSCs, but we use them because (probably either breezy or dapper vintage) of an rtai problem
[20:00:12] <mhaberler> looks like runtime/maxtime arent used in controlling flow at all
[20:00:16] <jepler> hal_parport's use is simplified by use of rtapi_get_time .. ditto uparport
[20:00:26] <jepler> and then there are the uses in hal_lib you already are looking at
[20:03:14] <jepler> oh and the one in motion/control.c which should be junked
[20:03:42] <mhaberler> standing back a bit: what would be useful is actual invocation period besides assumed period in ns; so is the question: how do we get at current time in ns without much overhead?
[20:04:44] <jepler> oh incidentally I think I alluded to this patch on irc but haven't pushed it anywhere: http://emergent.unpythonic.net/files/sandbox/0001-hack-minflt-majflt-ivcsw-pins-from-threads-component.patch
[20:04:49] <mhaberler> I am a bit confused in this clocks vs time land, and period vs abs time
[20:05:36] <jepler> clocks is a bad idea, simply pretend it does not exist
[20:05:51] <jepler> ignore the fact that we do use it despite that
[20:05:58] <mhaberler> ivcsw .. involuntary context switches?
[20:06:10] <jepler> yes as far as I understand it
[20:06:17] <jepler> that's something else that would be a canary for losing realtime
[20:06:36] <jepler> though not impossible if e.g., the fast thread interrupts the slow one
[20:07:21] <mhaberler> do we have a good definition for 'losing realtime' ?
[20:07:35] <jepler> anyway that series about nominal and actual time was about trying to make latency-test results mean the same thing as cyclictest results
[20:07:37] <mhaberler> the xenomai SIGXCPU signal indicating domain change definitely is
[20:08:55] <jepler> in rtai, rt_task_wait_period() returns an error from an enum including RTE_TMROVRN and RTE_UNBLKD
[20:09:00] <jepler> I would have to refresh myself on what those mean
[20:09:13] <jepler> but the former value is the one which we take to be "Unexpected realtime delay on task %d"
[20:09:20] <jepler> .. which is just a rtapi_print_msg
[20:11:25] <jepler> so in my API-centered mind we need an rtapi API for the number of realtime deadlines we think have been missed. when that number increments, it's bad (maybe estop)
[20:11:39] <jepler> if it's unrecoverable (xenomai userspace) then it probably increases forever from that moment on
[20:12:22] <jepler> how you get from API result to estop is having a HAL component that exists just to consult the API and set a pin based on the API's return value .. heartbeat or whatever you like, then it's in hal wiring what it does
[20:12:25] <mhaberler> right, I was thinking about a hard condition to cause an estop
[20:13:09] <mhaberler> I wish that could be done without exposing the thread flavor to hal configs and make them depend on it
[20:13:17] <jepler> in userspace I assume you can figure out for yourself if you missed a deadline by looking at your nominal time, your actual time, and your period..
[20:13:27] <jepler> if nominal > actual + period clearly you missed a deadline
[20:14:10] <jepler> but whatever it is, it simply becomes a requirement for the implementation of rtapi (and an rtapi hook in the current parlance if I am not out of date already)
[20:14:32] <mhaberler> zultron is Captain Hook
[20:15:26] <jepler> hah
[20:17:09] <mhaberler> http://i.dailymail.co.uk/i/pix/2012/10/12/article-2216530-023F6EB9000004B0-499_634x541.jpg
[20:17:58] <jepler> I thought I'd met him in wichita but now I am no longer so sure
[20:20:43] <mhaberler> oh, speaking of which.. Mursi was just removed by the army in egypt
[20:21:05] <Tom_itx> was he the one sitting across from you at the desk by the front mhaberler?
[20:21:31] <jepler> bbl.
[20:21:36] <mhaberler> John Morris? the tallest of all the guys
[20:21:59] <Tom_itx> i'm not so good with remembering names
[20:22:10] <jepler> he was set up over by charles on a card table, wasn't he?
[20:22:18] * jepler tries to remember
[20:22:24] <jepler> anyway, bbl. life is calling me.
[20:22:26] <mhaberler> right
[20:22:30] <Tom_itx> someone should edit some pics and add in names
[20:22:42] <Tom_itx> i've seen 2 sets posted
[20:23:06] <jepler> mhaberler: I hope some of that was helpful to you, if only the sad history lesson of why we have rtapi_get_clocks at all
[20:23:18] <mhaberler> definitely
[20:23:30] <mhaberler> yes, that one I was unclear why it existed at all
[20:42:44] <skunkworks> jepler: I looked at hal_parport.c and my very bad programming reading skills tells me that I don't know what I am looking at. reset_port seems to only wait for deadline which I don't understand. (seems like it only waits for one time)
[20:48:18] <jepler> skunkworks: that's right
[20:48:31] <jepler> skunkworks: andypugh said he thought there might be more than one but he was mistaken
[20:48:54] <jepler> but it should still be fine for non-doublestep setups with this latching pin
[20:49:51] <skunkworks> what does it go by? thi longest pin?
[20:50:07] <skunkworks> the longest reset time? Shortes?
[20:50:12] <jepler> there is only one reset time
[20:50:19] <skunkworks> oh
[20:50:28] <jepler> the thing that is at the pin level is whether it is a resetting pin
[20:50:35] <jepler> but they all get the same timeout
[20:50:38] <skunkworks> I thought you could set the reset time for each pin
[20:50:43] <skunkworks> ah
[20:55:27] <skunkworks> at the most I need 4000 steps per inch at 30 ipm. so pretty low power
[21:03:33] <jepler> so a 20kHz base thread without doublestep will be fine
[21:03:38] <skunkworks> sure
[21:07:12] <skunkworks> more than enough. If I am remembering my math right - 10000hz/4000steps/inch= 2.5 in/sec or 150ipm.
[21:07:32] <skunkworks> (at a20khz base thread)
[21:15:03] <jepler> the dangers of seeing what's on an old linux install:
[21:15:04] <jepler> # On branch v2_3_branch
[21:15:04] <jepler> # Your branch is ahead of 'origin/v2_3_branch' by 2 commits.
[21:17:25] <jepler> there's even a directory called "emc2.cvs"
[21:20:39] <jepler> jepler@azazel:~/emc2.cvs$ cvs diff
[21:20:40] <jepler> rsh: cvs.linuxcnc.org: Name or service not known
[21:20:40] <jepler> cvs [diff aborted]: end of file from server (consult above messages if any)
[21:20:44] <jepler> well I hope there were no changes in there :-P
[21:33:26] <jepler> it also turns out there's a breezy (5.10) install on this disk
[21:33:34] <jepler> I think I won't check whether it has any unpushed changes
[21:36:21] <jepler> there was one mildly interesting thing in the hardy install: I wrote a hardware RNG (based on the xor of a large number of free-running oscillators iirc) in the hostmot2 architecture; the driver was hiding in one of those old linuxcnc directories
[21:37:33] <jepler> also iirc it did something like 40MB/s of diehard-quality output, limited by the inl() based PCI interface and/or the PLX bridge chip
[21:37:56] <skunkworks> heh
[21:38:58] <skunkworks> what did you want to use the random numbers for?
[21:39:30] <jepler> usually I transmit them to the NSA
[21:39:54] <jepler> physical / "true" random number generators have been an interest of mine without a real purpose
[21:48:53] <skunkworks> understood