Back
[00:45:47] <yadok> Hi, if I could ask a somewhat basic question. I currently have a 1988~ cnc knee mill with a dynapath delta 20 controller, it has quadrature encoders and velocity mode servo drives. Would I be correct that the only real hardware I'd need to setup linuxcnc on this would be something like the 6i25/7i77 pair and a decent pc?
[01:08:52] <KimK> yadok: Still there?
[01:17:39] <yadok> Yep
[01:18:07] <KimK> Great, I took a chance. Looking...
[01:24:40] <yadok> A chance?
[01:25:03] <KimK> It looks like that should work fine. And I see that plug-and-go kits are offered with those components, so, great!
[01:26:09] <yadok> Excellent, it looked like that should do I just wasn't sure.
[01:26:22] <KimK> A chance that after taking the time to look it up I wouldn't get "yadok has left the building..."
[01:26:51] <yadok> Oh yeah, I do try to hang around after asking a question.
[01:27:29] <KimK> I used to retrofit with Dynapaths, that should be an easy job if you plan to reuse the old connectors, which I imagine you will.
[01:27:51] <yadok> I would like to be able to switch back if I need to for some reason, so that would be ideal.
[01:28:47] <yadok> I'm working on fitting a spindle encoder at the moment, the index is a bit of a problem though due to the head being geared. Would you happen to know if linux cnc can do without the index for rigid tapping etc?
[01:34:38] <KimK> I believe it can, but I always prefer (insist upon?) having an index for repeatability. Most of the machines I work on have toolholders, so, repeatable tool change is available. Why lose a feature of that? How are you planning to fit a spindle encoder, a real one, or tooth sensors?
[01:35:12] <KimK> If it's a Bridgeport (R8), then, OK.
[01:35:38] <yadok> I'm planning on using a magnetic rotary encoder chip mounted over a magnet on the center of the backgear shaft.
[01:36:58] <KimK> Nice, so it has two channels? (A & B?) What is the minimum tooth size it can detect?
[01:37:12] <yadok> It's a larger knee mill, but the design is very similar to a bridgeporty
[01:37:26] <yadok> bridgeport*
[01:37:57] <KimK> What toolholder does it use? R8, like a Bridgeport?
[01:38:50] <yadok> It has quadrature output, and 12bit accuracy. So maximum 4096 positions total. It's an NT40 taper.
[01:39:10] <yadok> No toolchanger on this though.
[01:39:56] <yadok> I'd like an index, I'm just not sure where to put it.
[01:39:58] <KimK> Oh, that's nice, do you have a part number? But you have to have "face access" and a magnet glued on, is that it?
[01:40:32] <yadok> It's an Austrainmicrosystems AS5045b
[01:41:03] <yadok> It's meant to be mounted with the magnet on the end of a shaft and the chip just over it
[01:41:46] <yadok> So I was going to put a magnet in the end of a longer nut and replace the one holding the top cog/pulley on the backgear
[01:43:08] <yadok> Then just run a piece of steel through over that and below the main drive belt and mount the chip to it.
[01:45:01] <KimK> Thanks, I'll look into it. Minor caution since it seems like a smart device, if it's like the CUI capacitive encoders, there may be a built-in PID (or similar) loop, which interacts with and slightly perturbs your desired PID loop. I don't care for how the CUI's work in a motion loop, but many people use them and find the performance OK. Just so you know going in.
[01:46:36] <yadok> I'm not familiar with them. I do believe the AB output is software generated inside the chip, but I was thinking since it's rated for 30k+ rpm I wouldn't be pushing it with my 3k spindle.
[01:47:34] <archivist> it is the interpolation and delay that may affect you
[01:48:10] <yadok> Iirc the datasheet mentioned something like a 192us fixed delay
[01:48:58] <archivist> so with a reversal that would entail a known error to a tap position
[01:49:26] <KimK> Your machine (since it probably had classic optical encoders already) would be a good test bed to put one of these on and try tuning both ways. If you do, please write up something and let us know, would you?
[01:50:09] <yadok> Sure, but it hasn't got anything in the way of a spindle encoder at the moment so this will be all I have.
[01:50:50] <KimK> Oh, sorry, yes, spindle. I was thinking axes.
[01:51:20] <yadok> Yeah it's got heidenheim (sp?) encoders on the servos
[01:51:32] <yadok> They will stay as long as they can.
[01:52:11] <yadok> So if my math is right, that error should be up to 4 degrees at 3500rpm, not that I'd probably tap at that speed.
[01:52:28] <KimK> Your other alternative would be that very popular allegro part which many have used for gear teeth detector. You need three, and the minimum spacing is 2.5mm tooth, 2.5mm gap.
[01:52:47] <yadok> They would be a form of inductive sensor?
[01:53:27] <KimK> yes, I think magneto-inductive with a built-in magnet, if I remember right.
[01:55:34] <yadok> I might see how I go with this one, should be an easy install at least.
[01:56:05] <yadok> The allegro setup would still be missing an index wouldn't it?
[01:56:16] <yadok> Since the gear is at a ratio to the spindle.
[01:57:19] <archivist> if tapping is like screw cutting on a lathe, it waits for the index before it starts
[01:57:43] <KimK> Jon has the data sheet, and an article. Many have used them. It doesn't look as good as a real encoder, since you get, say, 67 teeth(?) x4 so 268 counts/rev, not a very impressive encoder, but they seem to work reliably. Yes, most people fake an index by drilling a small shallow hole on a smooth part of the gear or ring.
[01:58:28] <yadok> Ok, well this chip will output an index per rotation, it just wouldn't be true to the spindle, perhaps that doesn't matter?
[01:59:35] <yadok> The only time I can think that rotation would be really important is if I wanted to do something like peck tap?
[02:00:43] <KimK> If it's repeatable after one rotation, it should be OK. Will the simulated index be repeatable? I don't know. I hope you'll tell us if you test it, either on the mailing list or the wiki. Who knows, you might end up as a featured project!
[02:01:33] <yadok> It should be fairly repeatable to the backgear shaft at least, the spindle will be a bit out of phase though.
[02:02:43] <yadok> I'll post something up after I try it, I'll be awhile before I get linuxcnc going though I suspect.
[02:03:51] <KimK> Here's Jon's article:
http://pico-systems.com/bridge_spindle.html
[02:04:58] <KimK> Copied by many, works reliably, if at moderate resolution. And it has the "advantage" of being a dumb encoder, so no PID meddling.
[02:05:03] <yadok> Does the odd cadence bother linuxcnc if you have the second sensor not exactly between teeth?
[02:06:10] <KimK> Usually people find a way to make one encoder (or both!) movable for quadrature adjusting. But if you can't, it'll just be a little odd.
[02:06:23] <yadok> Ah ok, that'd work
[02:07:13] <archivist> I milled a dick ready for my mill
[02:07:17] <archivist> disk
[02:07:22] <yadok> lol
[02:09:01] <KimK> (Ha, no comment!) If it's an encoder setup that you have to, say, epoxy together and then lower down into the darkness ;) maybe you could get a similar-sized gear from a junkyard or a transmission shop and get your epoxy right?
[02:09:07] <archivist> this is on the lathe, so made a larger version for the mill
http://www.collection.archivist.info/archive/DJCPD/PD/2013/2013_08_04_starturn_encoder/IMG_1631.JPG
[02:09:49] <yadok> That's a nice looking wheel
[02:11:27] <yadok> If I'm lucky, mine should just be a matter of getting a nut off in there and putting another one, then running a mounting bar through for the chip. That way I should be able to get the magnet concentric to the nut first, so that's my hope.
[02:13:44] <archivist> one slot deeper for index
[02:13:54] <KimK> Nice job, archivist!
[02:14:13] <archivist> that was original, I did not make that
[02:14:35] <KimK> Well, still. Is that a desktop lathe?
[02:15:14] <archivist> yes, denford starturn
[02:16:35] <KimK> We're (very slowly) working on a South Bend benchtop, I don't recall the model right now. More news later, as they say.
[02:17:05] <yadok> That sounds interesting.
[02:17:09] <KimK> Maybe a 4" x 10"? Or something like that.
[02:17:52] <archivist> I have a southbend for manual work
[02:17:56] <KimK> 3/4 HP DC motor, plus steppers. And an 8-position turret.
[02:21:49] <KimK> Nice chatting with you gents, but it's late here. yadok, let us know what you end up with. Come back with questions anytime, but perhaps on #linuxcnc instead next time though, OK? Good luck with your project. Goodnight.
[02:22:09] <yadok> Thanks for the help
[02:22:14] <KimK> You bet
[02:22:24] <yadok> Oops, this isn't the main linuxcnc irc huh
[02:22:48] <yadok> I'll check that one next time...
[02:23:03] <KimK> Well, this channel is supposed to be for linuxcnc software development. But traffic is light right now, so, nevermind.
[02:23:42] <yadok> Sorry about that.
[02:23:58] <KimK> No problem. Goodnight again gents.
[02:24:02] <yadok> Cya
[14:06:38] <jepler> intertesting kinematics design:
http://www.thingiverse.com/thing:1903757
[14:07:49] <skunkworks> wow
[14:08:04] <skunkworks> took a second to figure out how it moved...
[14:10:35] <cradek> https://www.youtube.com/watch?v=PhZ_XG8c4iM
[14:10:39] <cradek> the joints are cartesian!
[14:12:31] <jepler> cradek: wait what
[14:12:36] <jepler> I see that now
[14:14:17] <bpuk_> https://www.youtube.com/watch?v=aRaI0pesDN0
[14:19:12] <cradek> sure but I want to see it draw a square.
[14:21:26] <cradek> this one I don't see any advantage
[14:21:42] <andypugh> Not sure I see the point. It still need slides, so it isn’t like the attraction is that you can print all the parts.
[14:22:11] <cradek> yeah, it has all the slides plus a lot more moving parts
[14:22:40] <cradek> some new singularities when you get too close to the edge (elbow closes up all the way) and the arm gets floppy
[14:23:09] <jepler> it minimizes the stuff that moves just like a delta, but gives you (essentially) cartesian kinematics
[14:23:31] <jepler> the motors and the home switches and the work, none of them move
[14:23:34] <cradek> oh you mean like how you don't have to move any motor
[14:23:39] <cradek> hmm
[14:23:40] <jepler> right
[14:23:58] <cradek> corexy also has that?
[14:23:59] <jepler> for 3d printing minimizing the moving weight seems to consistently be a big consideration
[14:24:07] <cradek> yeah
[14:24:16] <cradek> corexy is barely noncartesian
[14:24:21] <jepler> > CoreXY's (mostly) parallel kinematics mean that the motors, typically the largest source of inertia on a DIY-grade stage, are stationary. This permits rapid accelerations
[14:24:26] <jepler> they name the same advantage
[14:25:54] <andypugh> Ultimaker is faiirly good that way.
http://icdn5.digitaltrends.com/image/ultimaker-2-axis-1500x1000.jpg
[14:25:58] <jepler> on the surface corexy seems to need a lot more belt length and you couldn't do it with screws even if you wanted
[14:27:20] <andypugh> I just noticed, Ultimaker uses the same shafts as guides and to syncrnose each side.
[14:27:48] <jepler> yeah
[14:28:43] <jepler> you have to move the work up and down, but that is not an acceleration or velocity critical operation in 3d printing so it doesn't matter much
[14:31:21] <jepler> hmm I think you're nearly onto something with your typo there: synchronose
[14:32:11] <jepler> anyway you could do 3 more linear slides in your tripteron and now you've got a tri-gantry
[15:04:35] <skunkworks> https://youtu.be/gVlqjA1EKE4?list=PLuCEOfGDb3iSJsg30i21TNgyoDJuFS-WT
[15:26:16] <jepler> yes I need to build a creepy eye robot
[15:26:23] <jepler> that can double as a cat-annoying laser toy
[15:26:38] <jepler> hmmm 5 axis laser cutter
[16:21:37] <cradek> with that device it's *so* easy to make linkages like that
[16:21:45] <cradek> they're plastic when you're done, but still
[16:58:10] <andypugh> So, R-format arcs are always the shortest one possible?
[16:59:18] <andypugh> I thought my G71 code was messed up, it didn’t match the drawing. Then I drew what the code said that I had…
[17:04:00] <bpuk_> from memory uses the shorter for +R, longer for -R
[17:06:06] <andypugh> Hmm, makes sense.
[17:06:12] <andypugh> (some sense)
[17:13:07] <bpuk_> also arcs using R are evil
[17:13:53] <cradek> yes you can get the big arc with -R
[17:14:46] <cradek> http://linuxcnc.org/docs/html/gcode/g-code.html#_radius_format_arcs
[17:15:02] <cradek> the docs do a good job of explaining when it's a good or bad idea to use R format
[17:18:46] <andypugh> I don’t think R-arcs are particularly evil in typical lathe-code
[17:19:19] <bpuk_> no - they are in mill code though. Mostly a preference, I _know_ which way the arc is going with IJK
[17:19:19] <cradek> no, they're super useful
[17:19:46] <cradek> on a lathe usually you're programming a quadrant with known radius
[17:32:03] <bpuk_> I got to play with a new roughing cutter today. 5083, 16mm deep, 5mm wide. 1400mm/min
[17:32:18] <bpuk_> I may have been a little bit nervous on first cut
[17:33:19] <bpuk_> next (non code) project! air blast and mister
[17:40:40] <cradek> I think the 3/4 aluminum rougher is my favorite cutting tool
[17:41:11] <cradek> with flood, you can cut about as fast as you want with it
[17:41:49] <bpuk_> I was having clogging problems with flood - even at full pressure I couldn't get the chips out fast enough
[17:41:59] <cradek> spin it faster!
[17:42:02] <bpuk_> ended up holding an airgun next to the coolant lines
[17:42:05] <cradek> turn it up to 11
[17:42:07] <bpuk_> I can only spin to 4k :(
[17:42:36] <cradek> can you run a bigger diameter then?
[17:43:10] <bpuk_> not ideal for the part - 16mm is as big as I can go without losing features
[17:43:59] <bpuk_> also - I kind of had to get the parts out today - hence using the airline ;)
[17:44:09] <cradek> heh
[17:44:14] <bpuk_> for next time I'll look at a bigger cutter
[17:45:27] <bpuk_> 20mm (3/4) is as big as I can go in collet
[17:45:54] <bpuk_> and to get the recommended surface speed on that I'd still need 6k
[17:45:59] <bpuk_> ... 7.5k
[17:46:02] <cradek> don't remember if my rougher is 3 flute or 4 flute
[17:46:42] <bpuk_> that said, I don't really touch aluminium at work - it was a batch of prototypes that'll be cast in brass eventually
[17:46:44] <cradek> it throws the chips about 2 feet, like a firehose
[17:47:15] <bpuk_> on the profile pass, yup, on the pocket pass they were getting trapped
[17:47:56] <bpuk_> might be worth trying a trochoidal? the constant angle change may spread them a bit more?
[17:48:39] <cradek> I don't know anything about that advanced tooling stuff
[17:48:56] <bpuk_> sorry, toolpath - not cutter
[17:49:12] <cradek> I don't know anything about that advanced toolpath stuff
[17:49:15] <cradek> haha
[17:49:17] <bpuk_> hehe
[17:49:55] <bpuk_> light cuts, crazy high speed, keep the tool at a constant angle of attack
[17:49:59] <bpuk_> that's more or less it
[17:51:36] <bpuk_> as a test, I'm getting an approx 7100 mm/min for a 16mm deep cut, 1mm width, 4k rpm. Don't think the haas will move that fast
[17:53:01] <bpuk_> one day I'll get time to test
[17:59:56] <andypugh> It is quite hard to twll when you have finished when stepping round an arbitray arc, isn’t it?
[18:01:03] <andypugh> I have an anticlockwise arc with a start of +35 and end of _65 degrees, and want the code to visit 0, -90, -180, +90 degrees, then stop.
[18:02:12] <andypugh> 0, 90, -180, -270 is the easy loop, but how to tell that -360 is too far?
[18:05:33] <bpuk_> you've found the arc centrepoint? and know the endpoint?
[18:06:51] <bpuk_> because I think an R type arc is defined by having an equidistant centrepoint - the endpoint (give or take floating point error) tells you when you're there
[18:08:14] <cradek> andypugh: I don't understand even after reading your question 3 times
[18:09:08] <cradek> anticlockwise = positive direction (G3)
[18:09:26] <andypugh> For any arc that passes through a cardinal point I want to split it into smaller arcs at the cardinal points. (This makes the G71 logic easier later)
[18:09:30] <cradek> but you say -90 -180 which is the wrong way
[18:10:02] <cradek> oh you're not talking about the motion
[18:10:40] <andypugh> No, the angles are what arctan2 spits out for the centre-to-start and centre-to-end angles
[18:12:27] <andypugh> It’s just a problem with the circular wrap making it complicated to define the interval.
[18:12:43] <cradek> yeah you've got to normalize it
[18:13:01] <cradek> ideally with the exact same boundary conditions as the rest of the interpreter
[18:13:36] <andypugh> Well, the final version would probably use the exact same code as the rest of the interpreter
[18:13:45] <cradek> because "is it tiny or is it about a full circle" is an eternal problem
[18:16:32] <bpuk_> andy - the original arc is defined in gcode? so you know if it's the short or long arc?
[18:17:03] <cradek> I think you shouldn't think in terms of gcode, you should think in terms of the interp's internal representation
[18:17:46] <cradek> which is: [implicitly current position] center point, new endpoint, turns, [helical/perpendicular endpoint for the 3rd axis]
[18:18:10] <cradek> don't worry about +-R or any other bs, that's already handled
[18:19:09] <cradek> sign of turns tells you which way to go
[18:19:28] <cradek> you'll visit at most 4*turns quadrant points
[18:21:12] <cradek> (does any of this help or am I babbling?)
[18:21:22] <bpuk_> it's useful for me at least :D
[18:21:43] <andypugh> cradek: I am parsing G-code by “hand” to populate a data structure that I think will make the rest of the algorithm easier. I don’t anticipate doing the same in the C++, but I reckon this is quicker than working out the existing code.
[18:22:13] <cradek> andypugh: maybe use sai to parse, and work with the canonical output?
[18:22:39] <andypugh> That’s likely to be the way to do it. I haven’t looked into it yet, though.
[18:23:06] <andypugh> I imagine that sai knows how to find O-word subs too.
[18:23:07] <cradek> because otherwise you start by writing a new incompatible interpreter :-P
[18:23:23] <cradek> well ... it'll unroll them for you I think
[18:23:45] <bpuk_> I'm still trying to work out the o-word logic. it's... fiddly
[18:24:44] <andypugh> Have you tried just passing O <P> CALL to the sai?
[18:25:13] <cradek> um, it doesn't do anything
[18:25:28] <bpuk_> tracing it in code slowly. Working out where I can safely insert code
[18:25:51] <bpuk_> the o-word stuff isn't that bad, until remap gets added in. and then it's...
[18:26:08] <cradek> andypugh: umm it probably starts reading "forward" waiting for o<p> sub?
[18:26:35] <cradek> READ => o<p> call
[18:26:35] <cradek> READ => o<p> sub
[18:26:35] <cradek> READ => g0x1
[18:26:35] <cradek> 7 N..... STRAIGHT_TRAVERSE(1.0000, 0.0000, 0.0000, 0.0000, 0.0000, 0.0000)
[18:26:38] <cradek> yep
[18:26:58] <cradek> so I guess it works right?
[18:27:40] <andypugh> Well <p> was meant to denote the P-word from a G71, but yes that seems to work.
[18:28:14] <andypugh> what command line was that?
[18:28:21] <cradek> rs274
[18:28:24] <cradek> then 1 to start interpreting
[18:28:37] <andypugh> Yes, but did you pass it a file or stdin?
[18:28:45] <cradek> I just typed at the READ prompt
[18:29:00] <cradek> typed those three lines and got that output
[18:30:04] <andypugh> Looks promising.
[18:30:42] <andypugh> (because it also ignores anything until it sees the O100 SUB
[18:31:07] <andypugh> So you could feed it O100 CALL followed by every line in the current file.
[18:31:30] <cradek> it isn't quite right
[18:31:42] <cradek> seems like the "ignored" stuff should have run after I did endsub
[18:31:51] <cradek> I don't think you can have subs with stdin because it's not seekable
[18:32:01] <cradek> but I'm sure it'll work right with a file
[18:32:34] <andypugh> I found it wasn’t very happy with an endsub
[18:35:46] <andypugh> I have a vague recollection that you can import rs274 into Python
[18:38:37] <cradek> yeah somehow - AXIS sure does it
[18:41:19] <andypugh> Does Gremlin use SAI?
[18:46:34] <cradek> sai is the (old name of the) rs274 standalone program - gremlin/AXIS don't use that exactly, but they both link with the interpreter shared library and call functions in it (and it calls back)
[18:47:09] <andypugh> So it’s all using the exact same code?
[18:47:11] <cradek> same as rs274/sai does - it just pretty much has printfs for all the callbacks (where gremlin has opengl calls, etc etc)
[18:47:19] <cradek> yes they all use the same interpreter that task uses
[18:47:29] <cradek> otherwise you're so doomed
[18:47:32] <andypugh> Which does seem like the best plan
[18:47:50] <cradek> the (ahem) AXIS authors weren't quite smart enough to do that at the very first
[18:48:00] <cradek> but they quickly got smarter
[19:00:15] <andypugh> import rs274 // rs274.interpret.gcode.parse(….)
[19:01:26] <andypugh> “TypeError: function takes at least 2 arguments (1 given)”
[19:02:12] <andypugh> Feels close….
[19:19:59] <jepler> https://www.mail-archive.com/emc-developers@lists.sourceforge.net/msg10939.html
[19:20:42] <jepler> note: "master of recent vintage" is 2013, so no doubt that snippet needs TLC again
[19:26:48] <andypugh> jepler: Maybe it is fine, I wasn’t passing it the right things.
[19:27:41] <andypugh> Anyway, time to stop for today.
