Back
[00:13:03] -!- marshmn has quit [Ping timeout: 252 seconds]
[00:16:29] -!- KimK has quit [Ping timeout: 256 seconds]
[00:21:14] -!- zeeshan [zeeshan!~kvirc64@CPE84948c379051-CM84948c379050.cpe.net.cable.rogers.com] has joined #linuxcnc-devel
[00:32:59] -!- andypugh has quit [Quit: andypugh]
[01:01:56] -!- KimK [KimK!~Kim__@ip68-102-85-68.ks.ok.cox.net] has joined #linuxcnc-devel
[01:21:08] -!- BeachBumPete [BeachBumPete!~IceChat9@2601:589:8201:bbc0:143c:f72c:e2f1:8056] has joined #linuxcnc-devel
[01:28:14] -!- BeachBumPete [BeachBumPete!~IceChat9@2601:589:8201:bbc0:143c:f72c:e2f1:8056] has parted #linuxcnc-devel
[01:31:23] -!- kingarmadillo has quit [Ping timeout: 244 seconds]
[01:41:12] <jepler> it's too bad we don't know how to peek inside the bitfile and read out the idrom
[01:49:36] -!- wortley [wortley!~wortley@2602:306:cfd4:2620:221:9bff:fe48:57d1] has joined #linuxcnc-devel
[01:50:18] wortley is now known as yeltrow
[02:01:52] <jepler> there's bitgen ... -g userid:<8 hex chars>, which can be seen early in the bitfile in plaintext
[02:02:08] <jepler> ... -g userid:abcdef01 .. gives a bitfile that starts
[02:02:08] <jepler> 0000000 00 09 0f f0 0f f0 0f f0 0f f0 00 00 01 61 00 19 >.............a..<
[02:02:12] <jepler> 0000020 77 6f 72 6b 2e 6e 63 64 3b 55 73 65 72 49 44 3d >work.ncd;UserID=<
[02:02:15] <jepler> 0000040 33 30 35 66 37 38 33 39 00 62 00 0c 36 73 6c 78 >305f7839.b..6slx<
[02:02:39] <jepler> of course if the filename work.ncd can be manipulated too
[02:06:46] -!- zeeshan has quit [Read error: Connection reset by peer]
[02:06:52] <jepler> I don't see it as a bitgen parameter
[02:11:19] <jepler> er of course that wasn't userid:abcdef01
[02:32:08] <Tom_L> anyone besides pcw recovered using jtag yet?
[02:32:54] <Tom_L> i swear i got one here somewhere but i've never used it on these. can't seem to find it atm
[02:36:05] <jepler> I'm pretty sure I've programmed a mesa card by jtag in the distant past. probably a 7i43.
[02:36:13] <jepler> I haven't since then
[02:36:30] <jepler> (I've programmed other xilinx dev boards via jtag though)
[02:36:37] <Tom_L> same
[02:36:40] <jepler> (again it's been years)
[02:36:52] <Tom_L> not quite years for me but a long time
[02:38:08] <jepler> I doubt there's any trick beyond needing to have the jtag hardware and software available
[02:38:29] <jepler> huh I wonder how I have a ~/src/mesa (unversioned, not git) directory here on my laptop
[02:38:34] <Tom_L> back when i loaded the wrong size chip to one i ordered one for this but i haven't a clue right now where it is hiding
[02:38:40] <jepler> too bad I just made a bunch of edits there and have no convenient way to track what they were
[02:39:10] <jepler> we'll have to settle for the inconvenient: diffing against the last backup
[02:51:05] <pcw_home> To recover, Its usually easier to JTAG program the FPGA and then use mesaflash to program the flash
[02:51:07] <pcw_home> (and not have to deal with Xilinx's horrible PROM file crap)
[02:51:58] <Tom_L> is the FPGA source in the associated zips?
[02:52:12] <Tom_L> or is that by request only?
[02:52:20] <Tom_L> (i don't currently need any)
[02:53:35] <pcw_home> yeah the zip is pretty current (7I92 updated today)
[02:54:48] <Tom_L> that ordeal prompted me to do the bitfile tutorial
[02:55:12] <jepler> pcw_home: what do you think about using -g userid: to encode the board name in the bitfile in a way mesaflash can check it? I'm envisioning checking that first (if it's not 0xffffffff) and then the filename
[02:55:21] <pcw_home> couple of minor fixes recently (new pinout files, DPLL integral term added 7I93,7I96 support)
[02:55:31] <Tom_L> i thought i may need jtag but after the update mesaflash that did the trick
[02:55:32] <jepler> it would be a tiny bit more robust against user meddling but I don't know if you use userid for any other purpose
[02:55:39] <pcw_home> Yeah wish I had started doing that
[02:55:55] <pcw_home> no, its unused
[02:56:24] <jepler> pcw_home: if mesaflash does both then you can switch over to it in time
[02:56:44] <Tom_L> jepler, those rolling their own bitfiles would need to be aware of that
[02:57:13] <pcw_home> its only relatively recently that we've had multiple cards tha use the same flash based FPGA (so are vulnerable to bricking)
[02:57:24] <jepler> hmm I wonder what just went wrong
[02:57:29] <jepler> Erasing sector 0 for boot block
[02:57:29] <jepler> BootBlock installed
[02:57:29] <jepler> Failed to write valid boot sector
[02:58:01] <pcw_home> PCI 64 bit issue?
[02:58:15] <jepler> yeah I bet this mesaflash source tree I started with is old enough to have that problem!
[02:59:03] <pcw_home> if its a 5I25, dont reload/power cycle till you re-program it...
[02:59:55] <jepler> pcw_home: yeah I already reflashed it with a working mesaflash (yay)
[03:00:36] <jepler> "well this isn't how I expected to spend the evening" -- how hobby programming often turns out for me
[03:01:55] <pcw_home> yeah I could use the userid for card name
[03:02:52] <pcw_home> or mesaflash could check the file name and fuss if it does not match the target
[03:03:28] <pcw_home> Ive only had a couple people do this (but 2 in the last 2 months for some reason)
[03:09:54] <jepler> people are getting dumber over time. I'm pretty sure I have a pie chart or maybe it was a venn diagram to prove it.
[03:11:24] -!- bpuk_ [bpuk_!~bpuk@boopotter.plus.com] has joined #linuxcnc-devel
[03:11:34] -!- bpuk has quit [Ping timeout: 250 seconds]
[03:11:51] <pcw_home> :-)
[03:18:33] <jepler> Error: wrong bitfile destination card: Detected 5I24, filename is /5i2
[03:18:42] <jepler> well this proves I'm on the right track, just not quite there yet
[03:19:25] <jepler> hmmmm, is there a problem coming up for 5i24 vs 6i24?
[03:19:31] <jepler> or whichever the pci / pci-express pairs are
[03:19:52] <Tom_L> iirc i used 5ixx on 6ixx cards
[03:20:07] <jepler> right, and that should continue to work
[03:20:43] <jepler> I mean, it needs to continue to work
[03:21:09] <jepler> but if mesaflash starts reading out "6ixx" as the card identity and "5ixx" as the bitfile identity and says it isn't allowed, that's a problem
[03:21:23] <jepler> I guess maybe special cases will be required for a few card IDs
[03:21:53] <Tom_L> prompted me to put this up:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Recover_Corrupt/Blank_EEPROM_5i24%2C6i24%2C7i24%2C_6i25
[03:22:04] <Tom_L> so if it changes somehow that should be edited
[03:23:52] <jepler> Error: wrong bitfile destination card: Detected 5I24, filename is 7i90
[03:24:41] <Tom_L> are you adding an identifier to the .vhd source file for that?
[03:24:46] <jepler> I'm not sure why you would use 6i25 in the first step but I accept your report that it is required
[03:24:51] <jepler> and yes that would break if this change goes into mesaflash
[03:25:21] <jepler> first I'm doing what pcw_home suggested and checking the filename
[03:25:32] <jepler> putting it inside the .bit file structure in some way might happen at a later date though
[03:25:42] <Tom_L> i forget the reasoning on the 6i25 but it had something to do with how mesaflash was at the time
[03:26:51] <jepler> Error: wrong bitfile destination card: Detected 5I24, bitfile ID is 7i90
[03:27:12] <jepler> here's how the message would look when getting the card data out of the bitfile: ^^
[03:28:26] <pcw_home> 6i24 can use 5i24 bitfiles and 6i25 can use 6i24 bitfiles but that the only exception
[03:28:47] <pcw_home> 6i25 can use 5i25 bitfiles I mean
[03:29:05] <Tom_L> could it be somehow encorporated in the .vhd on the line: package PIN_SVST6_6_7I48_72
[03:29:15] <Tom_L> as the identifier
[03:29:46] <Tom_L> ^^ just pulled that one at random
[03:31:24] <Tom_L> could also identify if the io count was correct. maybe moot as the board id would be doing the same thing to a degree
[03:31:48] <pcw_home> I think the user ID would be good (I think they are all 0xFFFFFFFF now)
[03:33:17] <jepler> pcw_home: yes you get FFFFFFFF if you don't request a different value
[03:33:32] <jepler> another problem is if you like to rename the bitfiles yourself
[03:33:48] <jepler> e.g., you make sure the filename is BLUE_CINCI.BIT or something
[03:33:55] <jepler> because it goes on the Cinci that's painted blue
[03:34:21] <jepler> maybe I only pay attention to filenames that start <digit>[iI]<digit><digit> ?
[03:35:13] <pcw_home> In that case (no card name) a stern warning could be issued
[03:36:15] <pcw_home> I should also put that trick for trying an untested bitfile safely in some of the manuals
[03:38:07] <jepler> I pushed my WIP branch to github
https://github.com/micges/mesaflash/compare/master...jepler:master but it's not polished enough to pull-request yet
[03:38:51] <jepler> it does potentially detect the mismatch in the two ways we discussed, but there's no way to override it, and no special handling of the magic 5/6 board types or the recovery mode where you must specify 6i25
[03:39:15] <jepler> afk and goodnight
[03:39:45] <pcw_home> thanks, and 'nite
[03:50:54] -!- yeltrow has quit [Quit: Konversation terminated!]
[05:44:46] -!- kwallace_ofcb [kwallace_ofcb!~kwallace@162.222.30.253] has parted #linuxcnc-devel
[06:08:04] -!- yadok [yadok!~chatzilla@106.177.149.122.sta.dodo.net.au] has joined #linuxcnc-devel
[06:14:15] -!- goatsimul [goatsimul!65648e81@gateway/web/freenode/ip.101.100.142.129] has joined #linuxcnc-devel
[06:17:17] <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?
[06:33:08] -!- kingarmadillo has quit [Ping timeout: 260 seconds]
[06:40:22] <KimK> yadok: Still there?
[06:49:10] <yadok> Yep
[06:49:37] <KimK> Great, I took a chance. Looking...
[06:56:10] <yadok> A chance?
[06:56:33] <KimK> It looks like that should work fine. And I see that plug-and-go kits are offered with those components, so, great!
[06:57:39] <yadok> Excellent, it looked like that should do I just wasn't sure.
[06:57:52] <KimK> A chance that after taking the time to look it up I wouldn't get "yadok has left the building..."
[06:58:21] <yadok> Oh yeah, I do try to hang around after asking a question.
[06:58:59] <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.
[06:59:21] <yadok> I would like to be able to switch back if I need to for some reason, so that would be ideal.
[07:00:17] <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?
[07:06:08] <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?
[07:06:42] <KimK> If it's a Bridgeport (R8), then, OK.
[07:07:08] <yadok> I'm planning on using a magnetic rotary encoder chip mounted over a magnet on the center of the backgear shaft.
[07:08:28] <KimK> Nice, so it has two channels? (A & B?) What is the minimum tooth size it can detect?
[07:08:42] <yadok> It's a larger knee mill, but the design is very similar to a bridgeporty
[07:08:56] <yadok> bridgeport*
[07:09:28] <KimK> What toolholder does it use? R8, like a Bridgeport?
[07:10:20] <yadok> It has quadrature output, and 12bit accuracy. So maximum 4096 positions total. It's an NT40 taper.
[07:10:40] <yadok> No toolchanger on this though.
[07:11:26] <yadok> I'd like an index, I'm just not sure where to put it.
[07:11:28] <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?
[07:12:02] <yadok> It's an Austrainmicrosystems AS5045b
[07:12:33] <yadok> It's meant to be mounted with the magnet on the end of a shaft and the chip just over it
[07:13:16] <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
[07:14:38] <yadok> Then just run a piece of steel through over that and below the main drive belt and mount the chip to it.
[07:16:31] <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.
[07:18:06] <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.
[07:19:04] <archivist> it is the interpolation and delay that may affect you
[07:19:40] <yadok> Iirc the datasheet mentioned something like a 192us fixed delay
[07:20:28] <archivist> so with a reversal that would entail a known error to a tap position
[07:20:56] <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?
[07:21:39] <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.
[07:22:20] <KimK> Oh, sorry, yes, spindle. I was thinking axes.
[07:22:50] <yadok> Yeah it's got heidenheim (sp?) encoders on the servos
[07:23:02] <yadok> They will stay as long as they can.
[07:23:41] <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.
[07:23:58] <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.
[07:24:17] <yadok> They would be a form of inductive sensor?
[07:24:57] <KimK> yes, I think magneto-inductive with a built-in magnet, if I remember right.
[07:27:04] <yadok> I might see how I go with this one, should be an easy install at least.
[07:27:35] <yadok> The allegro setup would still be missing an index wouldn't it?
[07:27:46] <yadok> Since the gear is at a ratio to the spindle.
[07:28:49] <archivist> if tapping is like screw cutting on a lathe, it waits for the index before it starts
[07:29:14] <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.
[07:29:58] <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?
[07:31:05] <yadok> The only time I can think that rotation would be really important is if I wanted to do something like peck tap?
[07:32:13] <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!
[07:33:04] <yadok> It should be fairly repeatable to the backgear shaft at least, the spindle will be a bit out of phase though.
[07:34:13] <yadok> I'll post something up after I try it, I'll be awhile before I get linuxcnc going though I suspect.
[07:35:22] <KimK> Here's Jon's article:
http://pico-systems.com/bridge_spindle.html
[07:36:28] <KimK> Copied by many, works reliably, if at moderate resolution. And it has the "advantage" of being a dumb encoder, so no PID meddling.
[07:36:33] <yadok> Does the odd cadence bother linuxcnc if you have the second sensor not exactly between teeth?
[07:37:35] -!- ve7it has quit [Remote host closed the connection]
[07:37:40] <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.
[07:37:54] <yadok> Ah ok, that'd work
[07:38:42] <archivist> I milled a dick ready for my mill
[07:38:47] <archivist> disk
[07:38:52] <yadok> lol
[07:40:20] -!- goatsimul has quit [Ping timeout: 260 seconds]
[07:40:32] <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?
[07:40:37] <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
[07:41:19] <yadok> That's a nice looking wheel
[07:42:57] <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.
[07:45:14] <archivist> one slot deeper for index
[07:45:24] <KimK> Nice job, archivist!
[07:45:43] <archivist> that was original, I did not make that
[07:46:06] <KimK> Well, still. Is that a desktop lathe?
[07:46:44] <archivist> yes, denford starturn
[07:48:05] <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.
[07:48:35] <yadok> That sounds interesting.
[07:48:39] <KimK> Maybe a 4" x 10"? Or something like that.
[07:49:22] <archivist> I have a southbend for manual work
[07:49:26] <KimK> 3/4 HP DC motor, plus steppers. And an 8-position turret.
[07:53:19] <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.
[07:53:39] <yadok> Thanks for the help
[07:53:45] <KimK> You bet
[07:53:54] <yadok> Oops, this isn't the main linuxcnc irc huh
[07:54:18] <yadok> I'll check that one next time...
[07:54:34] <KimK> Well, this channel is supposed to be for linuxcnc software development. But traffic is light right now, so, nevermind.
[07:55:12] <yadok> Sorry about that.
[07:55:28] <KimK> No problem. Goodnight again gents.
[07:55:32] <yadok> Cya
[08:33:25] -!- kingarmadillo has quit [Ping timeout: 260 seconds]
[09:24:09] -!- yadok has quit [Quit: ChatZilla 0.9.93 [Firefox 50.0/20161104212021]]
[10:34:02] -!- kingarmadillo has quit [Ping timeout: 256 seconds]
[11:15:26] -!- skunkworks_ has quit [Ping timeout: 250 seconds]
[11:28:10] -!- mk0 [mk0!~Orr@fiztech.basnet.by] has joined #linuxcnc-devel
[11:38:20] -!- mk0 has quit [Quit: Leaving]
[13:02:39] -!- skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[14:24:03] -!- sel [sel!~sel@net77-43-27-64.mclink.it] has joined #linuxcnc-devel
[14:24:19] -!- sel has quit [Remote host closed the connection]
[14:52:53] -!- kingarmadillo has quit [Ping timeout: 248 seconds]
[15:50:49] -!- kwallace_ofcb [kwallace_ofcb!~kwallace@162.222.30.253] has joined #linuxcnc-devel
[18:09:00] -!- ve7it [ve7it!~LawrenceG@S010648f8b3c3bc3b.pk.shawcable.net] has joined #linuxcnc-devel
[18:20:24] -!- pcw_home has quit [Ping timeout: 256 seconds]
[18:31:32] -!- pcw_home [pcw_home!~chatzilla@c-50-143-148-115.hsd1.ca.comcast.net] has joined #linuxcnc-devel
[18:45:31] -!- kalxas has quit [Changing host]
[18:45:50] -!- andypugh [andypugh!~andypugh@cpc14-basl11-2-0-cust1010.20-1.cable.virginm.net] has joined #linuxcnc-devel
[19:38:08] <jepler> intertesting kinematics design:
http://www.thingiverse.com/thing:1903757
[19:39:19] <skunkworks> wow
[19:39:34] <skunkworks> took a second to figure out how it moved...
[19:42:04] <cradek> https://www.youtube.com/watch?v=PhZ_XG8c4iM
[19:42:09] <cradek> the joints are cartesian!
[19:44:01] <jepler> cradek: wait what
[19:44:06] <jepler> I see that now
[19:45:47] <bpuk_> https://www.youtube.com/watch?v=aRaI0pesDN0
[19:50:41] <cradek> sure but I want to see it draw a square.
[19:52:55] <cradek> this one I don't see any advantage
[19:53:12] <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.
[19:53:41] <cradek> yeah, it has all the slides plus a lot more moving parts
[19:54:10] <cradek> some new singularities when you get too close to the edge (elbow closes up all the way) and the arm gets floppy
[19:54:39] <jepler> it minimizes the stuff that moves just like a delta, but gives you (essentially) cartesian kinematics
[19:55:01] <jepler> the motors and the home switches and the work, none of them move
[19:55:03] <cradek> oh you mean like how you don't have to move any motor
[19:55:08] <cradek> hmm
[19:55:10] <jepler> right
[19:55:28] <cradek> corexy also has that?
[19:55:29] <jepler> for 3d printing minimizing the moving weight seems to consistently be a big consideration
[19:55:37] <cradek> yeah
[19:55:46] <cradek> corexy is barely noncartesian
[19:55:50] <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
[19:55:55] <jepler> they name the same advantage
[19:56:44] -!- kingarmadillo has quit [Ping timeout: 250 seconds]
[19:57:24] <andypugh> Ultimaker is faiirly good that way.
http://icdn5.digitaltrends.com/image/ultimaker-2-axis-1500x1000.jpg
[19:57:28] <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
[19:58:50] <andypugh> I just noticed, Ultimaker uses the same shafts as guides and to syncrnose each side.
[19:59:17] <jepler> yeah
[20:00:13] <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
[20:02:51] <jepler> hmm I think you're nearly onto something with your typo there: synchronose
[20:03:41] <jepler> anyway you could do 3 more linear slides in your tripteron and now you've got a tri-gantry
[20:16:03] -!- sheppard has quit [Quit: Ex-Chat]
[20:17:16] -!- marshmn has quit [Ping timeout: 250 seconds]
[20:36:05] <skunkworks> https://youtu.be/gVlqjA1EKE4?list=PLuCEOfGDb3iSJsg30i21TNgyoDJuFS-WT
[20:55:21] -!- skunkworks has quit [Read error: Connection reset by peer]
[20:57:46] <jepler> yes I need to build a creepy eye robot
[20:57:52] <jepler> that can double as a cat-annoying laser toy
[20:58:08] <jepler> hmmm 5 axis laser cutter
[21:53:07] <cradek> with that device it's *so* easy to make linkages like that
[21:53:15] <cradek> they're plastic when you're done, but still
[22:29:40] <andypugh> So, R-format arcs are always the shortest one possible?
[22:30:47] <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…
[22:35:30] <bpuk_> from memory uses the shorter for +R, longer for -R
[22:37:35] <andypugh> Hmm, makes sense.
[22:37:41] <andypugh> (some sense)
[22:38:48] -!- kingarmadillo has quit [Ping timeout: 245 seconds]
[22:44:37] <bpuk_> also arcs using R are evil
[22:45:23] <cradek> yes you can get the big arc with -R
[22:46:16] <cradek> http://linuxcnc.org/docs/html/gcode/g-code.html#_radius_format_arcs
[22:46:31] <cradek> the docs do a good job of explaining when it's a good or bad idea to use R format
[22:48:50] -!- BeachBumPete [BeachBumPete!~IceChat9@2601:589:8201:bbc0:143c:f72c:e2f1:8056] has joined #linuxcnc-devel
[22:50:16] <andypugh> I don’t think R-arcs are particularly evil in typical lathe-code
[22:50:31] -!- BeachBumPete [BeachBumPete!~IceChat9@2601:589:8201:bbc0:143c:f72c:e2f1:8056] has parted #linuxcnc-devel
[22:50:48] <bpuk_> no - they are in mill code though. Mostly a preference, I _know_ which way the arc is going with IJK
[22:50:49] <cradek> no, they're super useful
[22:51:16] <cradek> on a lathe usually you're programming a quadrant with known radius
[23:03:33] <bpuk_> I got to play with a new roughing cutter today. 5083, 16mm deep, 5mm wide. 1400mm/min
[23:03:47] <bpuk_> I may have been a little bit nervous on first cut
[23:04:49] <bpuk_> next (non code) project! air blast and mister
[23:12:10] <cradek> I think the 3/4 aluminum rougher is my favorite cutting tool
[23:12:40] <cradek> with flood, you can cut about as fast as you want with it
[23:13:18] <bpuk_> I was having clogging problems with flood - even at full pressure I couldn't get the chips out fast enough
[23:13:29] <cradek> spin it faster!
[23:13:31] <bpuk_> ended up holding an airgun next to the coolant lines
[23:13:35] <cradek> turn it up to 11
[23:13:37] <bpuk_> I can only spin to 4k :(
[23:14:06] <cradek> can you run a bigger diameter then?
[23:14:39] <bpuk_> not ideal for the part - 16mm is as big as I can go without losing features
[23:15:28] <bpuk_> also - I kind of had to get the parts out today - hence using the airline ;)
[23:15:39] <cradek> heh
[23:15:44] <bpuk_> for next time I'll look at a bigger cutter
[23:16:56] <bpuk_> 20mm (3/4) is as big as I can go in collet
[23:17:24] <bpuk_> and to get the recommended surface speed on that I'd still need 6k
[23:17:29] <bpuk_> ... 7.5k
[23:17:31] <cradek> don't remember if my rougher is 3 flute or 4 flute
[23:18:11] <bpuk_> that said, I don't really touch aluminium at work - it was a batch of prototypes that'll be cast in brass eventually
[23:18:14] <cradek> it throws the chips about 2 feet, like a firehose
[23:18:45] <bpuk_> on the profile pass, yup, on the pocket pass they were getting trapped
[23:19:26] <bpuk_> might be worth trying a trochoidal? the constant angle change may spread them a bit more?
[23:20:08] <cradek> I don't know anything about that advanced tooling stuff
[23:20:26] <bpuk_> sorry, toolpath - not cutter
[23:20:42] <cradek> I don't know anything about that advanced toolpath stuff
[23:20:45] <cradek> haha
[23:20:47] <bpuk_> hehe
[23:21:25] <bpuk_> light cuts, crazy high speed, keep the tool at a constant angle of attack
[23:21:29] <bpuk_> that's more or less it
[23:23:06] <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
[23:24:31] <bpuk_> one day I'll get time to test
[23:31:25] <andypugh> It is quite hard to twll when you have finished when stepping round an arbitray arc, isn’t it?
[23:32:32] <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.
[23:33:42] <andypugh> 0, 90, -180, -270 is the easy loop, but how to tell that -360 is too far?
[23:37:03] <bpuk_> you've found the arc centrepoint? and know the endpoint?
[23:38:20] <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
[23:39:44] <cradek> andypugh: I don't understand even after reading your question 3 times
[23:40:38] <cradek> anticlockwise = positive direction (G3)
[23:40:56] <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)
[23:41:00] <cradek> but you say -90 -180 which is the wrong way
[23:41:32] <cradek> oh you're not talking about the motion
[23:42:10] <andypugh> No, the angles are what arctan2 spits out for the centre-to-start and centre-to-end angles
[23:43:57] <andypugh> It’s just a problem with the circular wrap making it complicated to define the interval.
[23:44:12] <cradek> yeah you've got to normalize it
[23:44:31] <cradek> ideally with the exact same boundary conditions as the rest of the interpreter
[23:45:06] <andypugh> Well, the final version would probably use the exact same code as the rest of the interpreter
[23:45:15] <cradek> because "is it tiny or is it about a full circle" is an eternal problem
[23:48:01] <bpuk_> andy - the original arc is defined in gcode? so you know if it's the short or long arc?
[23:48:33] <cradek> I think you shouldn't think in terms of gcode, you should think in terms of the interp's internal representation
[23:49:16] <cradek> which is: [implicitly current position] center point, new endpoint, turns, [helical/perpendicular endpoint for the 3rd axis]
[23:49:40] <cradek> don't worry about +-R or any other bs, that's already handled
[23:50:38] <cradek> sign of turns tells you which way to go
[23:50:58] <cradek> you'll visit at most 4*turns quadrant points
[23:51:31] -!- racicot has quit [Changing host]
[23:52:42] <cradek> (does any of this help or am I babbling?)
[23:52:51] <bpuk_> it's useful for me at least :D
[23:53:13] <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.
[23:53:43] <cradek> andypugh: maybe use sai to parse, and work with the canonical output?
[23:54:08] <andypugh> That’s likely to be the way to do it. I haven’t looked into it yet, though.
[23:54:36] <andypugh> I imagine that sai knows how to find O-word subs too.
[23:54:36] <cradek> because otherwise you start by writing a new incompatible interpreter :-P
[23:54:53] <cradek> well ... it'll unroll them for you I think
[23:55:15] <bpuk_> I'm still trying to work out the o-word logic. it's... fiddly
[23:56:13] <andypugh> Have you tried just passing O <P> CALL to the sai?
[23:56:43] <cradek> um, it doesn't do anything
[23:56:57] <bpuk_> tracing it in code slowly. Working out where I can safely insert code
[23:57:20] <bpuk_> the o-word stuff isn't that bad, until remap gets added in. and then it's...
[23:57:37] <cradek> andypugh: umm it probably starts reading "forward" waiting for o<p> sub?
[23:58:05] <cradek> READ => o<p> call
[23:58:05] <cradek> READ => o<p> sub
[23:58:05] <cradek> READ => g0x1
[23:58:05] <cradek> 7 N..... STRAIGHT_TRAVERSE(1.0000, 0.0000, 0.0000, 0.0000, 0.0000, 0.0000)
[23:58:08] <cradek> yep
[23:58:28] <cradek> so I guess it works right?
[23:59:10] <andypugh> Well <p> was meant to denote the P-word from a G71, but yes that seems to work.
[23:59:44] <andypugh> what command line was that?
[23:59:51] <cradek> rs274
[23:59:54] <cradek> then 1 to start interpreting
