Back
[07:53:27] <pcw_home> Is HALscope in master broken?
[07:54:01] <pcw_home> rtapi_shmem_new failed due to shmget(key=0x130cf406): Permission denied
[07:54:02] <pcw_home> SCOPE: ERROR: failed to get shared memory (key=0x130cf406, size=264)
[10:00:07] <jepler> pcw_home: working here, recent master, uspace preempt-rt.
[10:01:55] <jepler> EPERM The SHM_HUGETLB flag was specified, but the caller was not priv‐
[10:01:58] <jepler> ileged (did not have the CAP_IPC_LOCK capability).
[10:02:16] <pcw_home> strange: here master fails to launch halscope, but 2.7 works
[10:02:35] <jepler> pcw_home: uspace preempt-rt?
[10:02:42] <pcw_home> also uspace , preepmt-rt
[10:05:35] <jepler> pcw_home: both 2.7 and master are working here
[10:05:49] <jepler> I do have a higher minimum locked memory configured, I've lost track of whether that's needed these days or not
[10:05:52] <jepler> $ cat /etc/security/limits.d/linuxcnc.conf
[10:05:54] <jepler> * - memlock 20480
[10:05:57] <jepler> (reboot or log out to take effect)
[10:05:58] <pcw_home> Its entirely possible I've busted something
[10:11:52] <pcw_home> * soft memlock 30000000
[10:11:54] <pcw_home> * hard memlock 30000000
[10:21:19] <pcw_home> I wonder is this is just a strange artifact of JA vs pre JA and some halscope default file with non existent pins
[10:21:36] <jepler> you could remove your autosave.halscope but I don't think that's it
[10:21:44] <jepler> it hasn't even thought about what pins to sample by the time it's mapping the shm
[10:24:22] <pcw_home> yeah moved default.halscope and autosave.halscope and it made no difference
[10:28:43] <archivist> did you leave that mem buster in the hal file <pcw_mesa> I can load 366 before it runs out of mem
[10:38:43] <jepler> if you ever $ ipcs | grep 130cf406
[10:38:46] <jepler> errr
[10:38:55] <jepler> what's that show ^^^^
[10:39:06] <jepler> here with halscope loaded it says
[10:39:06] <jepler> 0x130cf406 21331991 jepler 600 128272 2 locked
[10:39:21] <jepler> I'm particularly interested in the 3rd and 4th columns
[10:39:47] <jepler> if it's not owned by "you" or not mode 600 that could be a cause of this problem
[10:40:58] <jepler> or point in an interesting direction anyway
[10:42:46] <pcw_home> archivist no that was just done with halcmd
[11:00:03] <pcw_home> 2.7:
[11:00:05] <pcw_home> 0x130cf406 57835671 pcw 600 128264 2 locked
[11:00:06] <pcw_home> 2.8
[11:00:08] <pcw_home> not there
[11:10:36] <jepler> weird. I wish I could reproduce it here.
[11:10:48] <jepler> is this one of your mint18 machines?
[11:13:06] <pcw_home> This is ubuntu 14.04
[11:14:21] <pcw_home> But its definitely something new, wonder if a ubuntu update broke it
[11:15:04] <pcw_home> I'll have to try on the Mint systems but I'll bet they work
[11:16:02] <jepler> The last time I was messing with how uspace does privileged operations was October 17 and that did touch how it locks memory for "loadusr" programs like halscope
[11:22:28] <jepler> you could go back to before that change by checking out re f269495a90db4d03c4872795c9d2c9092d066c9bf
[11:22:38] <jepler> it would be a good data point to have
[11:24:07] <pcw_home> OK i just did by date before Oct 10
[11:24:15] <jepler> that is, ref 269495a90db4d03c4872795c9d2c9092d066c9bf
[11:25:43] <jepler> the start of that string of commits was on Oct 8, "uspace: revamp privilege handling to not setfsuid" 3d4fc3bf44199886bec6391e802738eb4a01304a
[11:32:35] <jepler> I tried linuxmint18 just in case that would turn up a problem that's not happening on jessie, but it worked for me there too
[11:33:38] <jepler> but I still haven't reproduced a problem with halscope
[11:36:57] <pcw_home> I think its something messed up with shared mem on my machine
[11:36:59] <pcw_home> ref 269495a90db4d03c4872795c9d2c9092d066c9bf wont even launch:
[11:37:00] <pcw_home> rtapi_shmem_new failed due to shmget(key=0x00000064): Invalid argument
[11:37:01] <pcw_home> MOTION: rtapi_shmem_new failed, returned -22
[11:38:03] <jepler> let me build at that ref just to double check
[11:39:11] <jepler> yeah that specific ref also works for me
[12:10:48] <pcw_home> sorry, looks like it was just exhausted shared memory, all works after rebooting
[12:50:37] <pcw_home> oops nope broken again, worked one time
[12:59:29] <terkaa> evening
[13:44:33] <andypugh> bpuk: With my plane-agnostic approach to G71 we get G72 for free. But with a surprising quirk.
[13:45:30] <andypugh> https://ibin.co/33LBkhbVr5qT.png
[13:46:33] <andypugh> Something mysteriously changes about the line-arc intersection calculation.
[14:00:54] <andypugh> For comparison, the same code with G71 works properly.
[14:00:55] <andypugh> https://ibin.co/33LGKowitRtn.png
[14:02:53] <andypugh> And the code,
http://codepad.org/saZo8Fip
[14:02:55] <mozmck> looks like the arcs are flipped
[14:03:53] <andypugh> Indeed. I guess that might be expected.
[14:04:12] <andypugh> G72 is just G71 with X and Z flipped.
[14:05:22] <andypugh> (the code is written in x and y, and then different machine axes are assigned to x and y depending on current plane, with a dfferent allocation for G72)
[14:06:27] <andypugh> For fun, that code can rough UV, WU and VW planes, but then LinuxCNC can’t finish them :-)
[14:10:31] <bpuk> heh. looks like you've got it working nicely in remap. that's working with osubs?
[14:10:54] <andypugh> Sort-of working with O-subs
[14:11:43] <andypugh> So, I put in a flip for G72, and that works (delibrately pathalogical profile)
https://ibin.co/33LJchPEFo1g.png
[14:12:23] <bpuk> interesting - so it will accept non monotonic profiles, and only cut the 'safe' bits
[14:12:33] <andypugh> Yes.
[14:12:46] <andypugh> I don’t know whether that is good or bad
[14:12:55] <bpuk> how does that last example look as G71?
[14:13:41] <bpuk> (I'm also not convinced you've got the same treatment of I, K, J, L) from the pictures
[14:13:45] <bpuk> but it looks good!
[14:14:39] <andypugh> https://ibin.co/33LKcCpxnNw9.png
[14:14:58] <andypugh> No consideration of IJK at all yet.
[14:15:14] <bpuk> so it's partway to type2 as is
[14:15:19] <bpuk> ah, fair enough
[14:16:07] <andypugh> I can’t decide whether IK / JL are just a shift of profile or a change in arc radius with the centre in the same place
[14:16:43] <bpuk> traditionally shift of profile
[14:17:21] <andypugh> The good reason to do it in the C++ is that the arcs are calculated in the same code as all other arcs. In fact I probable spent longer on re-coding arcs than anything else.
[14:18:09] <andypugh> Going back to your question, it does use the O-sub way, but basically just searches the G-code file with a regex to find the G-code lines.
[14:19:24] <bpuk> so it wouldn't - for example - find an osub in a different file
[14:19:50] <andypugh> No.
[14:20:17] <bpuk> working through the daft questions - have you had to patch the C++ code for arcs to get it working to this stage?
[14:20:23] <andypugh> I wasn’t actually trying to solve that part of the problem. I would imagine that to be very difficult from inside a remap.
[14:20:48] <bpuk> or have you reimplemented the arc code in the python remap (I'm skimming the code as I'm typing)
[14:20:58] <andypugh> I haven’t touched any C++ code at all.
[14:21:26] <andypugh> Yes, a reimplemented arcs in Python (and added cardinal points)
[14:22:21] <bpuk> and as you've mentioned - getting the cardinal points in the C++ code would be really handy for other things too
[14:22:32] <andypugh> I don’t expect any of this code to be used, just perhaps some of the ideas.
[14:24:25] <bpuk> it looks pretty close to be honest
[14:24:47] <bpuk> have you had many thoughts on anti-gouging - I can see some of those examples gouging with certain tool shapes
[14:27:18] <andypugh> bpuk: I think gouging on arcs can be detected by looking at the tangent at the intersection and seeing if it is inside the tool angle.
[14:27:36] <bpuk> Completely random aside: has anyone done a pressbrake conversion to linuxcnc - theres a small one on ebay at the minute that I'm really tempted by
[14:27:55] <andypugh> I think it has been done, yes.
[14:28:15] <andypugh> Shouldn’t be hard
[14:29:13] <bpuk> I was thinking it was more or less a pure hal with tiny custom UI for the front end
[14:29:56] <andypugh> I think so, yes.
[14:30:18] <andypugh> I did a pure-table based UI recently, can’t remember why.
[14:30:25] <andypugh> Let me find the link
[14:31:06] <bpuk> I'm mostly asking myself: a) will this fit in the garage and b) Will I actually use this enough
[14:31:37] <bpuk> but it's at a low enough price that I'm really tempted
[14:31:58] <andypugh> bpuk:
https://forum.linuxcnc.org/38-general-linuxcnc-questions/31804-cnc-tube-bender-based-on-linuxcnc-ideas?start=10#82686
[14:33:19] <bpuk> yup - that would be pretty much exactly what I had in mind
[14:33:50] <andypugh> Well, you are obvioulsy welcome to take that and make it actually move metal.
[14:33:55] <bpuk> set up the backstop positions and press depths. Each time you press start (mechanical button) do the bend, retract, move to the next bend
[14:34:53] <andypugh> looking at the Promicam?
[14:35:00] <bpuk> yes
[14:35:24] <andypugh> Just down the road from me.
[14:35:46] <bpuk> wait, there are two at similar prices
[14:35:50] <bpuk> http://www.ebay.co.uk/itm/PROMECAM-25-12-25-TON-CNC-press-brake-/272461526479?hash=item3f6ff8f5cf:g:l5wAAOSwal5YIbLU
[14:36:02] <bpuk> was the one I'd spotted
[14:36:21] <andypugh> Right, the other one is the one I found.
[14:36:33] <bpuk> which is a much bigger unit
[14:39:09] <skunkworks> andypugh,
https://ibin.co/33LJchPEFo1g.png
[14:39:31] <skunkworks> am I seeing the rapid cutting into the part?
[14:40:18] <andypugh> Yes :-)
[14:41:20] <andypugh> Even the hypothetical zero-angle tool would gouge that shape.
[14:41:41] <andypugh> Could set R to zero to not do that.
[14:42:20] <skunkworks> ah - cool
[14:42:38] <bpuk> ideally it'd avoid the backgouge, and you'd finish with a different tool - but it is an evil shape
[14:43:31] <andypugh> It’s _your_ evel shape, largely. Just the G71test1 file with negative radius numbers.
[14:43:38] <bpuk> :D
[14:47:03] <bpuk> *blink* Interp::findFile is recursive!
[14:47:51] <bpuk> and apparently isn't called anywhere from within rs274
[14:53:02] <andypugh> Recursion is a fairly common way to search a directory tree. I have even done it myself a few times, and I am not a real programmer.
[14:53:43] <bpuk> yup - I was mostly trying to find where it was called from
[14:56:15] <andypugh> bpuk: Talking of “Real Programmers”, have you seen this?
http://www.pbm.com/~lindahl/mel.html
[15:00:01] <bpuk> Nope, hadn't seen that one
[15:03:40] <bpuk> I've figured out where I can put the entrypoint in the o-word code - but it wont work if the G71 is inside an O-Sub
[15:03:53] <bpuk> if that's going to be required, I'll have to dig some more
[15:05:00] <andypugh> I can imagine that that might be required.
[15:05:44] <andypugh> Maybe it would be easier to create a new O-word? O100 BLOCK / ENDBLOCK maybe?
[15:06:09] <andypugh> (I haven’t really thought that through)
[15:06:35] <bpuk> I had thought of creating a seperate profile block
[15:06:46] <bpuk> P100 begin..... P100 end
[15:07:40] <bpuk> doing it as block/endblock could work...
[15:29:35] <bpuk> hmm
[15:30:31] <bpuk> how to describe this. within a osub that is valid for G71/G70/G72. Do any of the other osub routines need to work? (i.e. should you be able to do a while loop within a G71 command)
[15:34:08] <andypugh> Absolutely not
[15:34:22] <andypugh> (well, if sticking to the standards)
[15:34:47] <andypugh> The stuff I have read is pretty explicit that only G0, G1, G2 and G3 are allowed in the block
[15:35:41] <bpuk> mmhmm - can we think of a use case where being able to use osub blocks would be useful?
[15:36:01] <bpuk> because if not - then doing o100 block ... o100 endblock doesn't look too bad
[16:34:12] <andypugh> Has it really been that long, or is there an offset in the timestamps?
[16:34:27] <andypugh> Anyway…
[16:35:05] <andypugh> Is the question whether you need to be able to call the G71 O-sub in the normal way, rather than with G71, G72 or G70?
[16:35:49] <andypugh> Or whether there is a situation where you would want to be able to have O-words in the G71/72 block ?
[16:37:50] <bpuk> both
[16:38:02] <bpuk> I was thinking the latter, but the former is important too
[16:38:27] <andypugh> The first is an interesting question.
[16:38:58] <andypugh> It seems that the first line of a G71 block defines the feed line for the rest of the profile.
[16:39:12] <bpuk> my gut call is don't allow it to be called using oN call
[16:39:39] <bpuk> since once G70 is defined - that pretty much calls it
[16:39:42] <andypugh> Which means that G71/G72 ignores the first line, as it is not a motion line, and so calling the sub would lead to unexpected results.
[16:40:00] <andypugh> Now, personally, I hate that.
[16:40:36] <andypugh> I think that the feed-peath should be defined by XZ (Y, U, V, W) wordsin the actual G71 line
[16:41:13] <andypugh> So this is a question of standards-compliance or doing it our way.
[16:41:15] <bpuk> Hmm. two ways to approach this OTT. Conventional way is to use the current xy location as the position to close the loop from, leave the loop open. The other approach is to define a closed loop in the profile, and use the start point to determine the quadrant only
[16:41:26] <andypugh> The standards smell of a terrible lash-up
[16:41:37] <bpuk> tbh, at this point I think we're doing this our way - it's a case of making it sensible
[16:42:17] <bpuk> and I can see exactly how the standards ended up where they are based on the memory constraints at the time.
[16:43:05] <bpuk> and I can see at least a few attempts (look at the Haas G150 mill code) where manufacturers have tried to update the standards to something closer to what we're looking at
[16:44:03] <bpuk> oh - and if you can think of an easy way to explain the difference between 'thickness' and 'overthickness' let me know - I've got about 10 lines of comments trying to describe it :D
[16:44:17] <andypugh> I think that, with the tool at the start point, it should be the case that calling the sub as a sub or calling it with G70 should have exactly the same effect.
[16:45:02] <andypugh> Yes, I remain baffled by the distinction between I and U etc
[16:46:22] <bpuk> OK. Proposal. G71/G72 take the feedrate defined in the G71/G72 line. Any feedrates/speeds defined in the o profile are recorded, but ignored. G70 runs through the sub obeying any feedrates/speeds as required. oN call results in an error
[16:50:17] <bpuk> comments, disagreement, etc?
[16:51:33] <andypugh> And feed rates defined in the O-block are probably cause to raise an error
[16:52:06] <andypugh> Hmm, or maybe not, if we want it to be valid to call the sub normally.
[16:52:29] <andypugh> I think you are a few thoughts ahead of me.
[16:53:00] <andypugh> So, why record, rather than just ignore, F-words in the block?
[16:53:12] <bpuk> I'm thinking disallow calling the block, but use them if G70 is called
[16:55:59] <andypugh> I think we need more opinions. Ask the mailing list. The US are all comatose through turkey overdose
[16:56:30] <bpuk> pfft. If they're turkey'd out we'll have to decide without them ;)
[16:56:47] <bpuk> kidding aside. I think I can implement the proposal as described without much effort
[16:57:03] <bpuk> so it might be easier to throw it in, and then I've got code confirming it works or doesn't
[17:06:14] <andypugh> bpuk: I compiled my own thread table years (err, 24 years) ago:
http://www.bodgesoc.org/thread_dia_pitch.html
[17:06:59] <bpuk> bookmarked
[17:07:15] <bpuk> I normally check zeus, then g-wizard, then google
[17:07:29] <bpuk> I think you're going to slot in after zeus ;)
[17:07:52] <andypugh> There are some more I need to add. It is missing metric below M3, which seems like a real miss.
[17:08:26] <andypugh> Mine was made specifically for identifying a thread from measurements.
[17:09:44] <andypugh> I did make a version that had the _actual_ OD after flatting/rounding as the master column. (so, you measure a thread, and that’s the number to look up) but seem to have lost it.
[17:10:38] <bpuk> heh. the industry I work in _loves_ making new threads. I tend to have to define threads as '3/8" OD 0.75mm pitch. Minor/Major X/Y'
[17:12:59] <bpuk> or in one particular case (I'm making up the numbers, would have to pull the drawing) - '19.072 OD. Major 19.54, Minor Y. 0.9748 pitch. Thread angle 57 deg'
[17:13:24] <andypugh> That’s a bit special.
[17:13:55] <andypugh> I have a tap here: M14.05 x 0.5
[17:14:21] <bpuk> yeah, I've got stuff like that - that's not so scary
[17:14:37] <bpuk> it's when the thread required the top of the thread to be cut off
[17:14:41] <bpuk> at a random angle.
[17:14:45] <andypugh> Presumably that was for a plated hole
[17:14:52] <bpuk> makes sense
[17:15:15] <bpuk> I picked up a thread gage (part of a job lot) for M50x0.5 a while back
[17:15:32] <andypugh> 57 degrees thread angle is just wrong. Threads should only ever be 55 degrees.
[17:15:59] <bpuk> yup. I'll accept the 60 degrees if I have to. but anything other than those....
[17:18:15] <andypugh> 47.5?
[17:18:45] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15screwtop opened pull request #214: Screwtop/docs/inifile vars (06master...06screwtop/docs/inifile-vars) 02
https://github.com/LinuxCNC/linuxcnc/pull/214
[17:18:50] <andypugh> I have made quite a lot of 47.5 degree threads
[17:19:29] <bpuk> hmm. that one isn't ringing a ball
[17:19:31] <bpuk> *bell
[17:19:41] <bpuk> 45 deg 30 min I know
[17:20:31] <bpuk> 29 for acme, 30 for trap, 45 for buttress, 80 for (ugh) Pg. I stick with the main two as far as possible
[17:21:24] <bpuk> odd. google tells me BA is 47.5
[17:21:33] <bpuk> other sources tell me BA is 45 30
[17:30:12] <bpuk> other sources are a) wrong b) have a request from bodgesoc to add BA c) major typo ;)
[17:31:55] <andypugh> BA is an appealing thread. The dimensions are all based on a simple formula.
[17:33:03] <bpuk> it just confused me
[17:33:17] <bpuk> *confuses - being a metric thread, with imperial measurements
[17:34:10] <bpuk> I probably cut about 40% metric, 20% BSP, 20% whitworth. The rest are a bit random
[17:35:43] <andypugh> Nice thing about a CNC lathe is that you can make any thread you want.
[17:36:57] <bpuk> oh yes
[17:37:10] <bpuk> going from the converted denford to a TL-1 was like...
[17:37:24] <andypugh> The only odd one I have done (other than the antique fine threads on my Rivett lathe) was for a one-off joint that I think was 14.75 x 0.9 (metric) because that put the thread to inner to outer equal, and it was a one-time assembly.
[17:37:50] <bpuk> don't get me wrong. the denford was OK - but it was slow, fiddly, not particularly accurate, very prone to binding
[17:39:37] <andypugh> I am from Brighouse. I feel an affinity to Denford, but I am not sure I want one
[17:39:49] <bpuk> hehe
[17:40:08] <bpuk> if you ever decide you want one, you can have mine ;) I'll pull the aloris toolholder first
[17:40:21] <bpuk> (it's got a front turret and a rear aloris)
[17:40:30] <andypugh> But they still exist, unlike 98% of the companies at www.lathes.co.uk
[17:40:31] <bpuk> (the front turret... is not stiff)
[17:42:00] <bpuk> I've looked at replacing the turret a couple of times, but ultimately - it's a trainer lathe - it's not intended for the use I need
[17:43:31] <bpuk> next project on the lathe list is an iso30 spindle - at which point I'll probably be asking for your help on the gripper
[17:45:09] <bpuk> don't want to do a ball type - and I know you've done gripper type
[17:46:04] <andypugh> I have, though that was a few years ago and now grippers are not super expensive on eBay and even Amazon.
[17:47:05] <bpuk> wheres the fun in that?
[17:47:29] <bpuk> and I'm aiming for 24k - so I'm probably going to have to be a bit careful with the gripper
[17:47:36] <bpuk> I know it's low mass
[17:52:51] <andypugh> The way I made my gripper was to hold 4 squares of steel in the 4-jaw chuck and bore out the inner profile. I also did things I am now vague about with registers and pressed-on sleeves to make it all work, but the basic idea is to _start_ with 4 separate bits of metal.
[17:54:34] <bpuk> 4-jaw. that could be a problem
[17:54:43] <bpuk> ok, need to find a work project that needs a 4-jaw
[17:55:23] <andypugh> square collet?
[17:55:38] <bpuk> 3 jaw only on that lathe
[17:55:47] <bpuk> could mill soft jaws
[17:55:52] <andypugh> 3-leaf gripper made of hex bar?
[17:56:05] <bpuk> ugh - I'll just get work to buy a 4-jaw
[17:56:22] <bpuk> they were complaining we were going to have to pay too much corporation tax
[17:57:02] <bpuk> I told them that wouldn't be a problem if they gave me a budget
[17:57:06] <andypugh> Every lathe needs a 4-jaw, otherwise you can’t ever re-work things true
[17:57:25] <bpuk> re-work? it's a production machine. it's right first time, or the part is scrap
[17:58:06] <andypugh> You never turn the part round to machine the other end?
[17:58:41] <bpuk> yup, onto a soft-jaw jig
[17:59:08] <andypugh> (I am grinning about the face-driver I scored on eBay the other week that was adverised as a “cutter:
[17:59:14] <bpuk> face-driver?
[17:59:31] <bpuk> nvm :D
[17:59:46] <bpuk> 'cutter' hehe
[18:00:16] <andypugh> https://www.youtube.com/watch?v=UriWQVTSXQo
[18:01:28] <bpuk> pretty much like a centre for a woodlathe - I knew the concept, not the name. soon as I saw a picture I went 'oh, those'
[18:01:44] <bpuk> and they're being a bit gentle with the mazak
[18:01:57] <andypugh> You think?
[18:02:19] <andypugh> You do have to be a _bit_ gentle with a face driver.
[18:02:39] <andypugh> I am actally amazed how not-gentle they are being.
[18:02:41] <bpuk> unless they're turning tool steel, it seems really gentle
[18:03:06] <andypugh> The swarf is reallly rather balistic
[18:03:07] <bpuk> hmm. they don't mention material
[18:04:17] <andypugh> (see how I put in an extra “l’ in reallly for balistic to borrow?
[18:04:44] <bpuk> heh
[18:05:19] <bpuk> just noticed the sparks on the second watch through - guessing it's a work hardening material
[18:07:46] <andypugh> I got to that video originally from the web-site of a face-driver maker who showed it as an example that you can take proper cuts with a face driver.
[18:08:28] <bpuk> KNUX, looks like about 6mm cut on the first pass. depending on the material it could be beastly, or light
[18:08:36] <andypugh> Did you watch to the end? The part is bigger than I thought, or the operator has small hands
[18:08:45] <bpuk> from the sparks, I'm guessing beastly
[18:09:01] <bpuk> yeah, it's a bigger part than i thought at first
[18:13:22] <bpuk> next OT question: Spindle material - I've been thinking EN24. Not convinced it's the best choice
[18:13:54] <bpuk> AISI 4340 is available locally
[18:14:31] <andypugh> You could use 817M40 :-)
[18:15:39] <andypugh> EN24 nitrides well, if that is impotant.
[18:16:12] <bpuk> I've got CBN tips - would rather have a deeper hardness
[18:16:41] <bpuk> since I'll be rough turning, stress relief, pre-finish, harden, finish turn, finish grind
[18:17:10] <andypugh> If you don’t intend to heat treat at all then EN24 is great. If you don’t intend to post-treat grind or machine, then the same is true.
[18:17:12] <bpuk> not come across 817M40T - looks fairly similar to 4340 - but with slightly more chromium
[18:17:56] <andypugh> 817M40 is the modern name for EN24. Sorry, it was a metallurgist joke :-)
[18:18:16] <bpuk> oh :D haha
[18:18:29] <bpuk> straight over my head ;)
[18:19:24] <andypugh> Do you know what properties you need? EN8 might be good enough with heat-treat and grinding.
[18:19:25] <bpuk> way I see it is - I'm spending a grand ish on bearings. the cost of material is pretty minor in comparison
[18:19:56] <bpuk> I really don't want to touch EN8. it's a pig to machine. EN24 is at least free-machining
[18:20:33] <andypugh> I have not found EN8 to be at all hard to machine, or even hob.
[18:21:01] <bpuk> really? I find it fine on the mill, and a nightmare on the lathe
[18:21:13] <bpuk> whatever I do it's covered in chatter marks
[18:22:00] <bpuk> I'd rather machine 303 than EN8
[18:22:11] <andypugh> One of us didn’t have EN8 then. These were EN8
https://goo.gl/photos/e7EGPkuHpN4ovyCP7
[18:22:48] <bpuk> hob finsih looks good, some scouring on the OD. Very Very good for EN8
[18:23:14] <andypugh> And made on the cheap Chinese lathe too
[18:23:30] <bpuk> I had more luck with EN8 on the Ward than I did on the Haas
[18:23:48] <bpuk> but that was all box work - the support always helps
[18:24:00] <andypugh> Not tried EN8 on the Holbrook yet.
[18:24:59] <andypugh> Out of interest, how would you have made those dog-ramps?
[18:25:31] <andypugh> (took me a while to figure out a way)
[18:26:56] <bpuk> mill, 2-3 ops. cut blanks on the saw, rear face and bore, flip - centre on a pin with ID clamps. mill outside, face, mill dogs. 4th axis, mill outside slots
[18:27:30] <bpuk> alternative, rear face and bore, 4th axis, mill dogs, OD, slots
[18:28:05] <bpuk> oh, as another aside - if you know anyone who is looking for machines in the UK, we've got to get rid of 4 machines by middle of next year. Bridgeport manual, ward 3DS (I think), colchester master (needs major rework), haas TM1-P (hoping I can talk them out of selling)
[18:29:06] <bpuk> looking again, the dog-ramps could be threaded ID. if you can underside pin them it's no problem, if not... ugh, grub screws?
[18:29:42] <andypugh> The question was more about just the ramps
[18:30:18] <bpuk> either tiny tiny ballnose and a few hours, or 4th axis and a series of smaller cutters
[18:31:12] <bpuk> 4th axis: rag it out with the 16mm, get it mostly clear with an 8mm. then drop to a 3mm (or lower). I assume they're not tapered in 2 directions (a, X)
[18:31:13] <andypugh> There is an acute angle between the ramp and the drive face
[18:31:47] <bpuk> third option. Rig the indexer up to the shaper
[18:32:13] <bpuk> I'm guessing you did them on the lathe?
[18:32:14] <andypugh> Shaper might be how they were made in 1921
[18:32:29] <andypugh> CNC horixontal milling.
[18:32:56] <bpuk> how did you get the final angle - smallest permissable cutter?
[18:33:23] <andypugh> https://goo.gl/photos/e7EGPkuHpN4ovyCP7
[18:33:59] <bpuk> (have to admit, whenever you do a new blog post I'm all 'ooh shiny' - since you seem to find interesting solutions to any problem)
[18:34:21] <Tom_L> andypugh is that what you're making now?
[18:34:40] <bpuk> ok, some threaded ID, some not.
[18:34:47] <andypugh> I admit they are not actually perfect geometry, but they were better than any original parts that anyone had :-)
[18:35:13] <bpuk> can I take back all those 'how would I have made' comments
[18:35:20] <bpuk> I'd have EDM'd them :D
[18:35:58] <bpuk> OD on the wire, fancy bits on the friend's plunge
[18:37:09] <bpuk> (last mould off the plunge I didn't have to polish - that machine is freakishly good)
[18:37:20] <andypugh> I think wire would have been perfect fot the face-ratchet actually.
[18:37:49] <andypugh> (4th-axis wire)
[18:39:18] <bpuk> yeah - short of going crazy with a 5 axis it's probably as good as you're going to get
[18:40:08] <bpuk> (the 5-axis plunge edm is what the third ISO30 spindle is intended for. I don't need to splurge on bearings for that one)
[18:41:56] <andypugh> I disagree, wire will make the perfect geometry (with infinitely thin wire) whereas 5-axis can’t.
[18:42:59] <bpuk> wire is never infinitely thin though - with the wire and the gap distance it's a long way off thin
[18:44:24] <bpuk> you can get close - but that final corner is going to have a noticable rad
[18:45:13] <bpuk> you'll get closer with a HSS shaper tool for the final corner - the rest of the shape will be better on a EMD
[18:45:16] <bpuk> *EDM
[19:06:24] <bpuk> Crazy question time.
[19:06:50] <bpuk> The comments refer to the original programmers subjective intent to store the program in memory
[19:07:15] <bpuk> is there a reason (beyond the obvious rewrite of the entire interpreter) that we don't?
[20:41:53] <jepler> bpuk: there are no-longer-true considerations like wanting the *whole system* to be allocation free after startup. there are possible considerations, like whether keeping the whole program in memory is too resource intensive for constrained systems with big part programs (think lowst-end ARM Linux trying to run the biggest 3d printer program .. it may run to dozens of megabytes, and there are still
[20:41:59] <jepler> platforms with <1GB total RAM. and yeah, there's the perceived difficulty of such a change
[20:42:02] <jepler> vs not knowing for sure what the payoff would be
[20:42:53] <jepler> of course other approaches might be viable like mmap()ping the whole program and keeping a much smaller table that lets you efficiently find any line you might need to refer to (like, the byte offset of each O-sub start)
[20:43:48] <jepler> the interpreter is really an unloved part of linuxcnc, but then all the parts feel that way at one time or another
[21:23:08] <skunkworks> zlog
[21:39:40] <skunkworks> what was the bdi based on?
[21:55:20] <jepler> skunkworks: iirc one was based on a redhat and bdi-live was based on debian/knoppix.
[21:55:33] <jepler> (if so it was redhat pre-fedora)
[21:56:38] <jepler> > Versions 1.0 to 2.18 (Redhat) were issued from introduction until January 1, 2005
http://sherline.com/updates-to-emc/
[22:03:54] <skunkworks> jepler, cool - thanks
