Back
[12:00:59] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-eth-multiple a00817f 06linuxcnc 10docs/man/man9/hm2_eth.9 10src/hal/drivers/mesa-hostmot2/hm2_eth.c 10src/hal/drivers/mesa-hostmot2/hm2_eth.h hm2_eth: allow multiple instances (up to 4) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a00817f
[12:00:59] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-eth-multiple 06ca091 06linuxcnc 10(7 files in 2 dirs) hostmot2: support split reads * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=06ca091
[12:00:59] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-eth-multiple c76ecd0 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c hm2_eth: make unrecognized boards work * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c76ecd0
[12:01:02] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-eth-multiple 3f49dd5 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c 10src/hal/drivers/mesa-hostmot2/hm2_spi.c 10src/hal/drivers/mesa-hostmot2/hostmot2-lowlevel.h 10src/hal/drivers/mesa-hostmot2/tram.c hostmot2: don't overload queue_write's length argument * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3f49dd5
[12:01:07] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-eth-multiple 2a83a1b 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c hm2_eth: print board_ip in messges about arp * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2a83a1b
[12:01:10] <jepler> seb_kuzminsky: I believe I've addressed your review notes. ^^^
[12:13:35] <jepler> now switching to my u3 for the next task
[12:37:07] <jepler> first, I have to provoke it to fail for me, and so I have a general idea of the frequency of the failure
[12:38:02] <jepler> the two failures seb noted were 1100 and 1453, so the first guess is once per ~350 runs of the full testsuite
[12:42:45] <jepler> looks like the testsuite takes about 20000 samples with halsampler across all tests
[12:43:01] <jepler> -> 1 failure per 7 million sampler cycles
[12:52:46] <jepler> so maybe my first time around was lucky -- I got it on iteration 311 of running just limit3.0 and threads.0 (in threads.0)
[13:02:39] <jepler> whee, a purpose-built setup hits it 50% of the time in <1 minute
[13:21:34] <jepler> and with a few judicious barrier ops added, 10 40-second tests all passed
[13:27:15] <seb_kuzminsky> jepler: awesome!
[14:47:40] <cradek> ooooh, jepler's the wizard today
[14:47:46] <cradek> we need a wizard hat
[14:57:54] <cradek> http://linuxcnc.org/index.php/english/forum/49-basic-configuration/29420-rigid-tapping-with-a-speed-controlled-spindle?start=10#60742
[14:58:13] <cradek> I guess seeing the obvious bug in a gcode program is as wizardy as I get :-P
[14:58:35] <seb_kuzminsky> http://i0.kym-cdn.com/entries/icons/original/000/001/781/wizard.jpg
[15:02:01] <cradek> I wonder if a piece of aluminum foil would make the crappy rough undersized shanks on these diamond burrs actually clamp in the collet
[15:03:34] <seb_kuzminsky> i've used beer-can sheet-metal for shims before, but never in a spindle collet
[15:03:55] <cradek> sure because that would be nuts
[15:04:10] <cradek> so I'm gonna go try it
[15:04:28] <seb_kuzminsky> awesome
[15:04:37] <seb_kuzminsky> make a movie so we can see when it explodes
[15:09:04] <mozmck> Anyone need an electron microscope?
[15:09:26] <CaptHindsight> mozmck: what yah got?
[15:09:30] <mozmck> http://www.ebay.com/itm//201388723543
[15:09:35] <mozmck> 4 miles down the road from me.
[15:09:52] <CaptHindsight> nice
[15:10:01] <mozmck> I think I need it, but I'm not sure what for yet :)
[15:10:06] <CaptHindsight> was looking at some last week
[15:10:13] <cradek> for magnifying things a lot
[15:10:34] <CaptHindsight> turn it into a dual SEM and FIB machine down to 1nm resolution
[15:10:43] <CaptHindsight> FIB = focused ion beam
[15:19:10] <CaptHindsight> oh it's a TEM not a SEM
[15:19:15] <CaptHindsight> see even smaller stuff
[15:27:59] <Tom_itx> cradek, get some brass shimstock from a hobby store to wrap around the shanks
[15:29:03] <Tom_itx> i keep an envelope of various thickness in my tool box for various things
[15:30:07] <jepler> 200 iterations of the test harness, 400 million halsampler samples, no more bad information read
[15:31:00] <cradek> the aluminum foil really didn't work at all
[15:31:17] <Tom_itx> brass is stiffer
[15:31:47] <cradek> I think I have some, 10 miles from here
[15:31:54] <cradek> could be worse
[15:32:43] <cradek> I have feeler gauge stock too, but I don't know what thicknesses
[15:32:53] <Tom_itx> alternate to aluminum foil would be aluminum duct tape
[15:33:06] <Tom_itx> it's a thin aluminum sheet like foil with adhesive back
[15:33:16] <cradek> I've been considering trying super glue
[15:33:34] <cradek> hmm I should try to measure how much slop there is
[15:33:36] <Tom_itx> thin sandpaper too
[15:33:44] <Tom_itx> like 600 etc
[15:33:54] <Tom_itx> if you can get it wrapped around that little shaft
[15:34:27] <cradek> there's nowhere near that much space
[15:34:28] <Tom_itx> the collet will expand some
[15:35:23] <cradek> it's 1/8 and has hardly any give to it
[15:35:31] <cradek> it's not slotted very deep
[15:36:32] <cradek> about .0025 of wiggle
[15:36:47] <cradek> if I have .001 shim stock it might be perfect
[15:36:54] <Tom_itx> yeah
[15:36:56] <cradek> bbl :-)
[15:37:28] <Tom_itx> i've been known to sacrifice feeler gages in a pinch
[15:37:44] <cradek> yeah I don't know if I have a set with .001
[15:37:56] <cradek> I think the cheap sets just go down to 2
[15:40:07] <Tom_itx> http://www.professormotor.com/product-p/ks258.htm
[15:41:23] <Tom_itx> your local hobby store should carry that K&S stuff
[15:59:44] <JT-Shop> some locktite on the shaft may work
[16:06:53] <KGB-linuxcnc> 03Chris Morley 05stepconf-mach-import 4f57b42 06linuxcnc 10src/emc/usr_intf/stepconf/Submakefile 03src/emc/usr_intf/stepconf/import_mach.py stepconf -add import-mach file * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4f57b42
[16:06:54] <KGB-linuxcnc> 03Chris Morley 05stepconf-mach-import 866cf48 06linuxcnc 10src/emc/usr_intf/stepconf/pages.py 10src/emc/usr_intf/stepconf/start.glade stepconf -add code to utilize mach convert program * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=866cf48
[16:07:33] <JT-Shop> YEA!
[16:08:10] <cmorley> Hey JT-Sop:
[16:08:38] <cmorley> JT-Shop: can you give that branch a once over when you get time?
[16:09:27] <cmorley> It is based off of 2.7 - I will have to check with Seb if that is ok to push - if you are happy with it.
[16:09:31] <jepler> manpage:
http://paste.debian.net/283687/ patches:
http://media.unpythonic.net/emergent-files/sandbox/linuxcnc-barrier.patches.mbox
[16:10:52] <JT-Shop> cmorley, I'll test it out in the morning
[16:10:59] <JT-Shop> thanks for adding that
[16:11:39] <cmorley> ok sounds good. I have tested with one Mach file seems ok, after some tweaks - see commit comment.
[16:11:58] <cmorley> ya no problem thanks for writing it :)
[16:12:16] <cmorley> ttyl
[16:32:27] <cradek> jepler: awesome
[16:32:31] <cradek> cmorley: awesome
[16:32:35] <cradek> JT-Shop: awesome
[16:41:50] <seb_kuzminsky> cmorley: it's very welcome in 2.7
[16:41:56] <seb_kuzminsky> i'll review it tonight
[17:15:01] <jepler> latest from SF confirms that mailing lists are still not restored
[17:15:03] <jepler> > dev services (SCM, uploads, ML's, project web) pending restoral
[17:15:09] <jepler> (which isn't even a word)
[17:16:39] <jepler> but at least it makes the list of stuff to fix
[17:17:35] <cradek> jepler: which version should get barriers?
[17:22:43] <jepler> cradek: certainly nothing before 2.7. I don't care too strongly whether it goes into 2.7 even, since we're not going to promote linuxcnc on arm afaik
[17:25:18] <Tom_itx> isn't that machinekit's thing?
[17:27:30] <jepler> mumble
[17:40:57] <seb_kuzminsky> i agree 2.7 is the earliest that makes sense to add it
[17:41:31] <seb_kuzminsky> i wonder what the impact on i386 and amd64 would be. does gcc emit anything at all for barriers on those architectures?
[17:45:07] <skunkworks> zlog
[17:45:20] <JT-Shop> I love it when people toss out ideas and get good feedback. I never thought of adding the conversion program to stepconf but it makes perfect sense
[17:46:01] <seb_kuzminsky> yeah
[17:46:09] <andypugh> Which program is that?
[17:46:34] <andypugh> Ah, the Mach importer?
[17:46:35] <JT-Shop> mach 3 to stepconf conversion
[17:46:40] <JT-Shop> aye
[17:46:57] <andypugh> Yes. That’s a “doh!” isn’t it?
[17:47:06] <JT-Shop> exactly
[17:47:42] <andypugh> seb_kuzminsky: Do you still think that the toolchanger vismach would be nice in 2.7?
[17:48:08] <seb_kuzminsky> yeah, sounds like fun
[17:48:15] <seb_kuzminsky> does it go with a particular sim config?
[17:48:42] <andypugh> One tricksy thing is that the spindle orient part works a lot better with a change in the orient comp that I only pushed to master
[17:49:01] <andypugh> It’s a complete standalone sim config
[17:49:27] <seb_kuzminsky> ok, having a sim config that shows how to use it is good
[17:49:35] <seb_kuzminsky> what's the orient thing? is it a bugfix or a new feature?
[17:49:54] <andypugh> I will look at putting a latch/oneshot in so that the is-oriented is delayed.
[17:50:02] <andypugh> New pin
[17:50:06] <seb_kuzminsky> hmm
[17:50:43] <seb_kuzminsky> the new pin has a delayed .is-oriented value?
[17:50:49] <seb_kuzminsky> brb
[17:51:20] <andypugh> http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=commit;h=9763aa8efe856da5aef963615c81b4aeb36d6755
[17:52:17] <andypugh> The new pin goes flase when orient-enable is aserted, and only goes true when some orienteering has happened. A simple ‘near” tends to go true immediately and aborts the orient.
[17:53:03] <andypugh> It looks like something that might be fixable by thread order, but doesn’t seem to be, or I didn’t try enough combinations.
[17:57:47] <skunkworks> rob has a fix in his github rempository - I hope to test it soon. (he has been running through is test too)
[17:57:54] <skunkworks> rempository?
[17:58:10] <andypugh> fix for what?
[18:01:39] <skunkworks> there was a acc violation with certain accelleration/arc combination
[18:02:04] <skunkworks> andypugh: the bug you posted on sourceforge from the forum
[18:02:44] <andypugh> Ah, that one.
[18:03:21] <skunkworks> hi fixed it last week but it caused other issues. :)
[18:03:25] <skunkworks> *He
[18:12:36] <jepler> libnml appears to use semaphores to prevent one side writing into an NML message while another side is reading it
[18:12:49] <jepler> accordingly, it does not have the data ordering problems of our other, cruder systems
[18:21:52] <jepler> (os semaphores should incorporate barriers)
[18:24:36] <andypugh> jepler: Was that a comment on my comment, or a standalone comment unrelated to my comment?
[18:34:28] <seb_kuzminsky> jepler: great
[18:34:35] <seb_kuzminsky> skunkworks: great
[18:37:53] <andypugh> seb_kuzminsky: Have you run the vismach/toolchange sim?
[18:38:57] <andypugh> (I can’t actually remember if the version I posted yesterday uses normal orient or modded orient)
[18:38:58] <seb_kuzminsky> andypugh: not yet, i'll try to do it tonight
[18:39:35] <seb_kuzminsky> what's the branch called?
[18:40:40] <andypugh> It uses ordinary orient at the moment. And it isn’t a branch, it is currently a ZIP on the forum.
[18:41:37] <andypugh> http://www.linuxcnc.org/index.php/english/forum/24-hal-components/29153-vmc-related-hal-questions#58732
[18:41:55] <andypugh> (More use to the intended audience than a git branch at the moment)
[18:49:05] <seb_kuzminsky> andypugh: can you push it as a branch please? that way the buildbot will tell us if there are any problems on any platforms (and it's more convenient for me to look at)
[18:50:14] <andypugh> OK, but not now. I am in a hotel room in Spain, and it’s getting late.
[18:50:55] <seb_kuzminsky> ok, when you get a chance
[19:39:57] <cradek> Tom_itx: the .001 brass shim stock worked
[19:40:36] <cradek> wrapped around, it was tight in the collet without drawing it shut, just like a real tool is
[19:43:07] <Tom_itx> nice
[19:43:20] <Tom_itx> just make sure it doesn't overlap or it won't run true
[19:47:41] <jepler> seb_kuzminsky: yes, it emits an "mfence" instruction on x86_64 and i386 with recent -march= selected; and a lock-prefixed memory-accessing NOP for i386 without -march= selected (pre-sse2)
[19:47:59] <jepler> seb_kuzminsky: in a loop whose body is just mfence, it takes ~50 cycles per loop on an intel i7
[19:48:37] <jepler> so the penalty is probably 40-50 cycles per use if my test harness is right
[19:49:14] <jepler> "lock orl $0, (%esp)"
[19:50:57] <jepler> hmmm
[19:51:07] <jepler> the *other* reason the fence is needed is the clever compiler
[19:51:07] <jepler> void f(struct T *t) {
[19:51:07] <jepler> while(t->a == 0) /* NOTHING */;
[19:51:07] <jepler> printf("%d\n", t->b);
[19:51:07] <jepler> }
[19:51:30] <jepler> there's nothing in the abstract machine that allows t->b to change during this function, so there's no reason the read can't be moved above the while-loop
[19:52:51] <jepler> hm my attempted changes to task/motion just totally broke it
[19:53:29] <jepler> usrmotReadEmcmotStatus: COMM_SPLIT_READ_TIMEOUT
[20:00:07] <cradek> the whole serial number system is broken without syncs too, right?
[20:00:47] <cradek> or do we have queues now
[20:02:36] <cradek> tool change handshaking?
[20:05:55] <jepler> cradek: it looks like anything going through libnml is already safe, because they use operating system mutexes.
[20:06:16] <cradek> oh ok
[20:06:51] <jepler> "Primitives such as mutexes and semaphores are provided to synchronize access to resources from parallel threads of execution. These primitives are usually implemented with the memory barriers required to provide the expected memory visibility semantics. In such environments explicit use of memory barriers is not generally necessary." -- wikipedia
[20:07:12] <cradek> ok so it's generally usually ok
[20:07:13] <jepler> I *think* tool-change / tool-changed is OK
[20:07:40] <cradek> I was thinking about how it sets a request number and then a bit to say you should read it
[20:07:55] <jepler> oh, hm.
[20:07:55] <cradek> doesn't iotask twiddle those hal bits directly?
[20:07:57] <jepler> you're right
[20:08:33] <jepler> so the thing I was trying to formulate about index-enable & position-fb would apply here too
[20:09:17] <cradek> I think no, because motion and hal drivers are all realtime
[20:09:19] <jepler> except that in the case of index, the reader and writer are typically both in the same realtime thread, so they don't have a problem
[20:09:27] <cradek> yeah that
[20:09:41] <jepler> software stepgen & encoder need attention where they exchange data from the fast thread to the slow one
[20:09:54] <cradek> er no, they can be in different realtime threads, but that's still ok, because one cpu
[20:10:06] <cradek> ?
[20:10:25] <jepler> if we want to further codify that all the RT stuff runs on one CU
[20:10:25] <cradek> I thought if both reader and writer are realtime it's ok
[20:10:26] <jepler> CPU
[20:10:43] <cradek> above my pay grade
[20:11:14] <jepler> right now we provide rate monotonic scheduling, but we haven't ever formally promised it. RMS implies that all RT threads run on one CPU thread
[20:11:16] <cradek> I think seb is right that probing is a trouble spot
[20:13:15] <cradek> we DO promise it:
http://linuxcnc.org/docs/html/man/man3/hal_create_thread.3hal.html
[20:13:18] <jepler> yeah, same thing with the same "probably usually OK because usually in the same thread"
[20:13:56] <cradek> I think no, because probing communicates with task so the results can make it into the interpreter
[20:14:26] <jepler> It's RT which takes care of all the latching, right?
[20:14:36] <jepler> one patch (not in the series I posted so far) fixes up the shared memory between task and motion
[20:14:51] <jepler> fixing the existing "head == tail" checks to actually work
[20:15:14] <cradek> oh yeah, the latching is surely in motion
[20:21:37] <jepler> seems like with home switches and probe inputs it doesn't matter much; the consequence there is having the position be different by 1 servo cycle
[20:21:48] <jepler> it's not "read as zero", it's "read as stable"
[20:21:53] <jepler> er "read as stale"
[20:23:30] <cradek> but with index, if not for all-one-cpu, you can maybe get the not-yet-reset value
[20:23:38] <cradek> for one servo cycle
[20:24:19] <jepler> right
[20:25:01] <jepler> I am very tempted to say it's broken to update position-fb and index-enable not from the same thread as motion
[20:25:10] <jepler> I mean, it's OK if that's broken
[20:25:58] <cradek> software encoder updates those things in the slow half?
[20:26:15] <jepler> yes, I believe so
[20:27:46] <jepler> how the heck do you get barriers in the right place in a classicladder toolchanger
[20:29:09] <cradek> doesn't ladder read all inputs, then run all the program, then write all outputs? seems like it would be fine.
[20:30:02] <jepler> barriers are required on the reading side, because otherwise reads can occur in a different order than program order implies
[20:30:50] <jepler> so for the same reason that iocontrol needs a barrier between setting the tool number and asserting tool-prepare, ladder needs to (A) read tool number before tool-prepare in program order and (B) have a barrier between them so that program order and actual order are the same
[20:30:51] <cradek> I don't understand
[20:31:04] <cradek> processing
[20:31:38] <jepler> today, who knows if (A) is true anyway
[20:31:53] <jepler> probably bits are read in a fixed order with respect to numbers
[20:32:15] <jepler> while (f == 0);
[20:32:15] <jepler> // Memory fence required here
[20:32:15] <jepler> print x;
[20:32:30] <cradek> ok I'm with you now
[20:32:31] <jepler> same if it's: if(f == 0) print x; which is more like the ladder situation
[20:32:34] <jepler> https://en.wikipedia.org/wiki/Memory_barrier
[20:32:49] <jepler> the load of x from memory could be before the load of f from memory, in this kind of computer
[20:32:55] <cradek> because ladder_rt is hooked to iocontrol
[20:33:25] <jepler> right, via hal
[20:33:29] <cradek> it seems like you can't fix this in the general case of having arbitrary hal programmability
[20:33:33] <jepler> yes
[20:33:45] <cradek> that's ... bad
[20:34:03] <jepler> a bunch of dumb things in shared memory is a great idea if your background is microcontrollers and x86 doesn't dash any of those hopes too hard
[20:34:23] <jepler> except now I'm concerned for all machines about part A of the classicladder toolchainger story
[20:34:28] <jepler> changer
[20:34:43] <cradek> yeah
[20:35:07] <cradek> doesn't even require this arm thing to screw that up
[20:35:10] <jepler> right
[20:38:55] <jepler> hm do we have general "copy input to output" components?
[20:39:06] <jepler> if so you just need to add a "execute a barrier instruction" component
[20:39:48] <jepler> so then you'd put this component in classicladder's thread, copy(tool-prepare); barrier; copy(tool-number) in imperative speak
[20:40:34] <cradek> I'm taking your word for this
[20:41:25] <jepler> ah, actually a better idea
[20:41:40] <jepler> use classicladder to delay the tool-prepare signal by one cycle so that tool-number is stable
[20:42:12] <jepler> .. or, in iocontrol, sleep(any nonzero amount) after setting tool number and before asserting the prepare signal
[20:42:37] <jepler> it's almost like making linuxcnc work on arm is a waste of time
[20:42:48] <jepler> literally, if we insert sleep(1)
[20:45:07] <cradek> I wonder how many wrong tool changes our users will get, with it all as is, before the sun burns out
[20:45:44] <jepler> seems like a lot of toolchanger designs might do OK if they initially get the wrong tool number but it becomes right 1ms later
[20:46:10] <jepler> turn the wrong way for 1ms, or go around an extra time, or suchlike
[20:46:46] <cradek> it sure depends
[20:46:55] <jepler> and just once in a very blue moon
[20:47:39] <jepler> (And I feel one comin' on soon)
[20:47:59] <cradek> stop by and I'll buy you a beer
[20:48:44] <jepler> hm I didn't know it was a cover when Ms. Parton recorded it.
[20:49:41] <cradek> wouldn't surprise me if that was an old song
[20:49:43] <jepler> (in fact the first I recall of the song was when the band I was listening to announced from the stage that their next number was a cover *of* Dolly Parton)
[20:49:46] <jepler> https://en.wikipedia.org/wiki/Once_in_a_Very_Blue_Moon
[20:50:14] <jepler> which gives the songwriting credit to (Patrick Alger, Eugene Levine)
[20:50:26] <cradek> oh maybe I don't know that song
[20:50:40] <cradek> I was thinking of: blue moon, you saw me standing alone, without a something something ...
[20:50:45] <jepler> [Alger] later teamed up with Nanci Griffith and co-wrote Griffith's hit songs "Once In A Very Blue Moon" ( with Eugene Levine) and "Lone Star State of Mind."(with Eugene Levine and Fred Koller)
[20:51:27] <jepler> https://www.youtube.com/watch?v=ykKKCqy3gKM
[20:53:01] <cradek> never heard it before
[20:55:43] <jepler> (she should have changed that stupid lock, and also her address)
[20:56:36] <cradek> ugh, she murders roseville fair because she's so scared someone will say GAYYYYYYY if she sings it right
[20:56:40] <cradek> I hate when people do that
[20:58:36] <Tom_itx> i doubt tool changers react that quick anyway
[20:59:01] <cradek> Tom_itx: but it's easy to imagine a ladder that latches the value
[20:59:02] <Tom_itx> all the ones i've seen were rather slow or did a prefetch
[20:59:57] <cradek> latch the request on a rising edge has got to be a typical ladder behavior
[21:00:14] <Tom_itx> i've not messed with classic ladder yet
[21:01:31] <jepler> cradek: if the choice was to gender-flip it or tell it in the third person, which is the lesser violence to the song? (yes, I know that's a false dichotomy)
[21:03:35] <jepler> cradek: and more importantly, how serious were you with that beer invitation?
[21:03:40] <cradek> the basic flip would be hard, because you'd end up with "gentle flower of a small town boy" "... my joy(?)"
[21:03:46] <cradek> totally serious
[21:04:04] <jepler> I think I'll drop by then
[21:04:15] <cradek> ok, I'll make sure something's cold
[21:04:40] <jepler> OK, how about "I was dressed in blue and I looked so lovely"
[21:05:00] <cradek> bleh
[22:58:44] <seb_kuzminsky> jepler/hm2-eth-multiple (2a83a1) seems fine on my bp, it homed at least, ship it!
