Back
[08:20:09] <skunkworks> zlog
[08:20:44] <skunkworks> Hmm - me typing zlog creates the log.. If a tree falls in the forest....
[08:50:30] <JT-Shop> skunkworks: I'm working on a different format for the logs
http://gnipsel.com/logs/%23linuxcnc/index.html
[09:05:00] <skunkworks> cool!
[11:03:52] <terkaa> hi
[14:16:28] <terkaa> Hmmm... this looks cool
[14:16:30] <terkaa> https://www.youtube.com/watch?v=fT1gLX-XbGQ
[14:42:58] <jepler> hm as fast as that arm seems to move I guess that's a sped up video
[14:44:00] <jepler> given that you need multiple mountings anyway, I wonder if it's actually a time saver to mount that adapter
[14:44:15] <jepler> might also have limitations of Z working distance that it helps with
[14:45:31] <skunkworks> the fixture plate uner is impressive.. Look at all the holes!
[14:47:38] <cradek> these bed mills don't have knees, so you're hard pressed to drill into the edge of something big
[14:47:57] <bpuk> if you don't have the clearance height you kind have to do it that way
[14:48:01] <cradek> but doesn't everyone have a 6' tall drill press?
[14:48:15] <skunkworks> yes?!
[14:48:22] <bpuk> that said, I've used 90 degree adaptors (on MDF). They're handy, but rigid isn't the term I'd use
[14:49:10] <skunkworks> or a horizontal mill that you can just hang stuff off the table...
[14:49:27] <bpuk> that tooling plate does look nice though
[14:49:55] <bpuk> and nice demo of using pins to locate the part
[14:51:48] <bpuk> aaand I've just looked at the price of that plate
[14:58:42] <terkaa> That can be used with ATC
[14:59:26] <terkaa> Also it might not be useful for parts that small but it is good for big parts
[15:01:57] <terkaa> Like here
[15:02:00] <terkaa> https://www.youtube.com/watch?v=T-xy9Fnrmlc
[15:03:14] <terkaa> And these can also be rigid
https://www.youtube.com/watch?v=83h0WNy6pMA
[15:03:22] <terkaa> But very expensive
[15:03:58] <terkaa> New ones from 3000 up
[15:04:06] <bpuk> The ones I used were on a C axis around the spindle, so you could drill/mill all 4 sides of the part
[15:04:27] <terkaa> bpuk: Those were built in=
[15:04:29] <terkaa> ?
[15:05:08] <bpuk> C axis built into the machine, pin in the angle head goes into the c-axis, can turn to any angle
[15:05:56] <terkaa> Oh ok. That would be really good
[15:06:22] <terkaa> This one is also good:
https://www.youtube.com/watch?v=cKoTfRxAD78&t=259s
[15:06:28] <bpuk> but you're still sticking the tool another 6"-18" out from the spindle
[15:07:12] <terkaa> bpuk: Yes but on these bigger machines it has to.
[15:08:17] <bpuk> https://www.youtube.com/watch?v=gzyvsEVZkq8
[15:08:59] <terkaa> Or our machine wont have any kind of "reach" with angle head:
https://www.youtube.com/watch?v=U7TwyWRrVas
[15:09:38] <bpuk> heh, with a 4" quill travel on my home mill - I think it's safe to say I'm not going to be using one soon
[15:11:10] <bpuk> yup, for a horizontal you'd want stickout
[15:11:15] <terkaa> Yep these wont fit on that one.
[15:11:50] <terkaa> Yes we need that especially because we do not have "zoom boom" on this one
[15:12:57] <terkaa> I have been considering this one:
http://www.ebay.com/itm/222298625473?ul_noapp=true
[15:13:26] <bpuk> I'm trying to get a sense of scale from that video - but I suspect I could fit my BP onto the table of your miller
[15:14:22] <terkaa> It has 2500X1250mm XY
[15:14:48] <bpuk> yeah, my mill would fit on the table, you'd probably get the surface grinder on at the same time
[15:15:39] <terkaa> Yes we need this one for some operator cabin base plates milling
[15:16:00] <terkaa> Those plates are used in underground mining equipment
[15:17:30] <terkaa> But to get to point. I have never used this kind of angle heads. If I can get hold on one, how do I program it?
[15:18:03] <bpuk> do you use CAM?
[15:18:16] <bpuk> if not, carefully
[15:18:43] <terkaa> Yes. But I still need to know it in G-code level
[15:18:58] <terkaa> Basically Y-axis becomes Z
[15:19:05] <terkaa> and Z-becomes Y
[15:20:07] <terkaa> Do we need to change to XZ-plane?
[15:20:34] <bpuk> that's one way, the other way is to consider it a rotation through 90 degrees in the A axis.
[15:21:34] <terkaa> Ok, which one would be simpler, regarding using correct tool length offset? (in this case Y-axis movement)
[15:24:21] <terkaa> I believe application will be drilling, or simple straight milling. Not contours
[15:25:01] <bpuk> if it's fairly simple (drillling/slotting) I'd probably do it by hand. Wondering about flipping the axes, so that you'd program it as a vertical
[15:27:11] <terkaa> Would it be G18 with ie G55 coordinates
[15:27:46] <terkaa> Would tool lenght offset then work with G0 G43 Z10 Hx
[15:30:26] <bpuk> really not sure without testing
[15:31:22] <terkaa> Ok I will test if we find used angle heads
[15:33:30] <bpuk> should be able to test without an angle head - weld two bars together at 90 degrees, stick them in a toolholder, and don't start the spindle
[15:33:56] <terkaa> Hmmm... that is true
[15:33:57] <bpuk> (or cable tie a sharpie to a tool at 90 degrees)
[15:34:23] <terkaa> we have some scrap tools that can be welded
[15:36:42] <terkaa> I can try that tomorrow to see if it is that simple to program
[15:42:54] <bpuk> I'm building up a certain amount of amusement from reading the comments in rs274ngc core
[15:43:23] <bpuk> 'This version does not use any additional memory as it runs. No memory is allocated by the source code'.... #include <set>
[15:43:46] <cradek> bet there are lots of funny stories in there
[15:44:19] <bpuk> 'seems to work ok! FIXME mah is this needed?'
[15:44:39] <bpuk> '// paranoia.'
[15:45:32] <bpuk> all very reassuring comments during a complex set of control flow :D
[15:47:39] <bpuk> out of curiosity - who wrote the o-word code? I know mah did the remap
[15:47:59] <cradek> ken lerman did most of it
[15:48:33] <cradek> I think that was when the interp first malloced
[15:48:59] <bpuk> guessing no longer involved?
[15:49:43] <cradek> ?
[15:50:06] <bpuk> Sorry, I'm guessing Ken Lerman isn't actively involved in linuxcnc these days?
[15:50:30] <cradek> he posts on the lists sometimes
[15:52:21] <bpuk> ok, so if I really can't figure out the control flow he might be able to help
[15:52:39] <cradek> possibly!
[15:52:43] <bpuk> good to know - I'm using A2 paper to graph the basics out - and I'm on my third sheet :D
[15:53:08] <cradek> yikes
[15:54:51] <bpuk> hmm... does git go back to before remap was implemented?
[15:55:24] <cradek> pretty sure
[15:55:31] <cradek> I think everything mah did was way post-git
[15:55:55] <bpuk> that might make it easier - if I can at least split the python stuff out it'll simplify this a lot
[15:55:56] <cradek> O-words are probably pre-git (we used cvs) but all that history was imported into git
[15:56:28] <cradek> I don't think anyone understands remap :-/
[15:56:34] <cradek> you will be our expert!
[15:56:45] <bpuk> I'm hoping to not touch it at all
[15:57:28] <cradek> it ain't just you
[15:57:35] <cradek> :-)
[15:57:41] <bpuk> whoo! branch v2_0_branch does not have the word 'python' in rs274_ngc_pre.cc
[15:57:43] <bpuk> hehe
[15:58:10] <bpuk> interestingly there is a comment in the header - 'This version of the interpreter not saving input lines. A list of all lines will be needed in future versions to implement loops, and probably for other purposes.'
[15:58:32] <cradek> huh
[15:58:56] <cradek> you can sometimes see the future, but usually not perfectly clearly...
[15:59:02] <bpuk> yup, and yet... loops, and other purposes were implemented without saving input lines ;)
[15:59:21] <mozmck> If you're fixing stuff in o-words, make it so "if" statements don't need another O words ;-)
[15:59:40] <bpuk> oh, I'm fixing nothing! it's terrifying in here
[16:00:08] <jepler> (out of all O-words only "sub" should actually need an ID attached)
[16:00:44] <jepler> I think the interpreter was never not terrible, but it's the interpreter we have
[16:00:45] <bpuk> mozmck - if you want me to take a look I'll need at least two g-code files before I'll even consider diving into this pit of nightmares
[16:01:08] <mozmck> bpuk: I was mostly kidding - I bet it's not a trivial fix.
[16:01:10] <bpuk> I'd need one which works using the current syntax, and one that shows how you expect it should work
[16:01:23] <bpuk> probably not, but while I'm digging *shrug*
[16:01:28] <cradek> noooo
[16:01:54] <cradek> we don't want to break all existing gcode programs, and we don't want to support two dialects
[16:02:10] <cradek> it's too late
[16:02:32] <bpuk> which is why we don't have the interpreter we deserve, but instead the interpreter we have
[16:03:11] <bpuk> cradek: which is the exact reason I don't want to push G71 to emc-users until the syntax is locked in
[16:03:39] <cradek> I think you're being smart
[16:03:57] <mozmck> Yeah, so right now you have to have a unique o## for an if statement: o11 if ... o11 endif
[16:05:04] <mozmck> It would be great if the requirement for the unique o## was removed for if statements (and anything else except the "sub" as jepler said).
[16:05:23] <bpuk> but it would throw up the dialect issue
[16:05:41] <mozmck> Yeah - not sure why that would be a problem though.
[16:05:59] <cradek> maybe there's an implementation that would allow o if ... with no number after the o
[16:06:05] <cradek> would have to think it through
[16:06:20] <bpuk> breaking old gcode
[16:06:21] <cradek> o endif would hook back to the latest (unnumbered?) one
[16:06:32] <bpuk> what about nested if's?
[16:06:37] <bpuk> nvm
[16:06:40] <cradek> maybe it's possible to allow but not require the number
[16:07:03] <cradek> bpuk: I don't know. an if stack or something.
[16:07:20] <cradek> bpuk: but roughing! don't get distracted!
[16:07:36] <bpuk> hehe
[16:07:59] <bpuk> I did get distracted at work today - looked at awallins openvoroni
[16:08:19] <bpuk> and went 'this would work perfectly with arbritrary profiles'
[16:11:04] <bpuk> but that's a year or so off
[16:14:57] <bpuk> and more to the point - would that be of interest long term?
[16:16:50] <jepler> OpenVoronoi is under the GPLv3 so unfortunately it can't be incorporated in LinuxCNC, which has some portions (like the interpreter) that are licensed GPLv2 only.
[16:17:27] <bpuk> darn
[16:17:55] <jepler> it's an unfortunate license situation in LinuxCNC that we have to live with.
[16:18:06] <bpuk> would an equivalent implementation be of interest (2.5D CAM with offset profile, trochoidal machining - within the lcnc core)
[16:22:11] <jepler> I don't feel like I know how widely it would be used
[16:22:42] <jepler> if it scratches an itch for you, you should work on it.
[16:23:41] <bpuk> it's more - it affects how I do the profile reading code
[16:24:39] <jepler> you concluded that the type of offsetting done by cutter comp doesn't fit the needs well enough?
[16:25:37] <bpuk> for milling machines - not to the best of my knowledge
[16:25:38] <jepler> (it seems like the type of algorithm you're considering might also replace the current cutter comp algorithm)
[16:26:03] <bpuk> oh no - cutter comp would remain as is - it's toolpath generation
[16:27:09] <jepler> OK, it's clear I've gotten out of my depth on this subject.
[16:27:46] <bpuk> ok - I needed to cut a large pocket at work - we have no CAM software. Writing the toolpath (which is crude) took me about an hour and a half
[16:28:40] <bpuk> the machine control has a G-code to cut an arbritrary pocket, with the profile defined by a subprogram. But it's the stupidist toolpath you could possibly use to make the pocket
[16:29:16] <bpuk> so my brain asked: why can't a sensible toolpath be generated by the control given that program
[16:31:14] <jepler> isn't computing an offset path an important subproblem of this problem?
[16:31:27] <bpuk> the two logical toolpaths (which any CAM package today would generate) would be a centre starting offset toolpath (with or without a finishing pass), or a HSM trochoidal clearing path, followed by a finishing pass)
[16:31:49] <bpuk> yes, it is. but it's not a single offset, it's 'how many passes do we need'
[16:33:13] <bpuk> tbh I'm mostly asking myself 'what features would the perfect machine control have for me'
[16:33:22] <jepler> that's all most of us do
[16:37:07] <bpuk> I think making a cuppa tea should be a feature
[16:46:20] <bpuk> ok. I _think_ I've found the correct entry point
[16:46:31] <bpuk> should G71 be able to be called from within a osub?
[16:47:34] <bpuk> i.e. O100 call -> O100 sub G71 O199 <blah> O0100 endsub
[16:47:56] <jepler> bpuk: seems like that would be desirable
[16:48:58] <jepler> afk
[17:18:40] <pcw_mesa> I guess I need sterner warning about wring wrong bitfiles to our FPGA cards
[17:18:42] <pcw_mesa> (1 5I25 bitfile --> 7I92 and one 7I92 bitfile --> 5i25 in the last 2 months)
[17:20:39] <andypugh> Is it a permanent problem?
[17:20:55] <andypugh> Or is the problem that they were sent out like that?
[17:22:23] <jepler> I think the 7i92 needs JTAG to recover from that, not sure about 5i25
[17:24:41] <pcw_mesa> Yep both need JTAG
[17:25:30] <pcw_mesa> customers not finding the desired bitfile so using one for another card
[17:32:45] <andypugh> Can Mesaflesh be made to refuse?
[17:37:09] <pcw_mesa> it already refuses wrong FPGA type but this is the same FPGA type
[17:37:21] <pcw_mesa> (but different pinout)
[17:38:18] <pcw_mesa> all the current flashable bitfiles have the card name in the file so mesaflash could refuse if the file name is not right
[20:09:42] <jepler> it's too bad we don't know how to peek inside the bitfile and read out the idrom
[20:30:22] <jepler> there's bitgen ... -g userid:<8 hex chars>, which can be seen early in the bitfile in plaintext
[20:30:38] <jepler> ... -g userid:abcdef01 .. gives a bitfile that starts
[20:30:38] <jepler> 0000000 00 09 0f f0 0f f0 0f f0 0f f0 00 00 01 61 00 19 >.............a..<
[20:30:42] <jepler> 0000020 77 6f 72 6b 2e 6e 63 64 3b 55 73 65 72 49 44 3d >work.ncd;UserID=<
[20:30:45] <jepler> 0000040 33 30 35 66 37 38 33 39 00 62 00 0c 36 73 6c 78 >305f7839.b..6slx<
[20:31:09] <jepler> of course if the filename work.ncd can be manipulated too
[20:35:22] <jepler> I don't see it as a bitgen parameter
[20:39:49] <jepler> er of course that wasn't userid:abcdef01
[21:00:38] <Tom_L> anyone besides pcw recovered using jtag yet?
[21:01:24] <Tom_L> i swear i got one here somewhere but i've never used it on these. can't seem to find it atm
[21:04:35] <jepler> I'm pretty sure I've programmed a mesa card by jtag in the distant past. probably a 7i43.
[21:04:43] <jepler> I haven't since then
[21:05:00] <jepler> (I've programmed other xilinx dev boards via jtag though)
[21:05:07] <Tom_L> same
[21:05:10] <jepler> (again it's been years)
[21:05:22] <Tom_L> not quite years for me but a long time
[21:06:38] <jepler> I doubt there's any trick beyond needing to have the jtag hardware and software available
[21:06:59] <jepler> huh I wonder how I have a ~/src/mesa (unversioned, not git) directory here on my laptop
[21:07:04] <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
[21:07:10] <jepler> too bad I just made a bunch of edits there and have no convenient way to track what they were
[21:07:40] <jepler> we'll have to settle for the inconvenient: diffing against the last backup
[21:19:35] <pcw_home> To recover, Its usually easier to JTAG program the FPGA and then use mesaflash to program the flash
[21:19:37] <pcw_home> (and not have to deal with Xilinx's horrible PROM file crap)
[21:20:27] <Tom_L> is the FPGA source in the associated zips?
[21:20:42] <Tom_L> or is that by request only?
[21:20:49] <Tom_L> (i don't currently need any)
[21:22:04] <pcw_home> yeah the zip is pretty current (7I92 updated today)
[21:23:18] <Tom_L> that ordeal prompted me to do the bitfile tutorial
[21:23:42] <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
[21:23:51] <pcw_home> couple of minor fixes recently (new pinout files, DPLL integral term added 7I93,7I96 support)
[21:24:01] <Tom_L> i thought i may need jtag but after the update mesaflash that did the trick
[21:24:02] <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
[21:24:09] <pcw_home> Yeah wish I had started doing that
[21:24:24] <pcw_home> no, its unused
[21:24:54] <jepler> pcw_home: if mesaflash does both then you can switch over to it in time
[21:25:13] <Tom_L> jepler, those rolling their own bitfiles would need to be aware of that
[21:25:43] <pcw_home> its only relatively recently that we've had multiple cards tha use the same flash based FPGA (so are vulnerable to bricking)
[21:25:54] <jepler> hmm I wonder what just went wrong
[21:25:59] <jepler> Erasing sector 0 for boot block
[21:25:59] <jepler> BootBlock installed
[21:25:59] <jepler> Failed to write valid boot sector
[21:26:31] <pcw_home> PCI 64 bit issue?
[21:26:45] <jepler> yeah I bet this mesaflash source tree I started with is old enough to have that problem!
[21:27:33] <pcw_home> if its a 5I25, dont reload/power cycle till you re-program it...
[21:28:24] <jepler> pcw_home: yeah I already reflashed it with a working mesaflash (yay)
[21:29:05] <jepler> "well this isn't how I expected to spend the evening" -- how hobby programming often turns out for me
[21:30:25] <pcw_home> yeah I could use the userid for card name
[21:31:22] <pcw_home> or mesaflash could check the file name and fuss if it does not match the target
[21:31:58] <pcw_home> Ive only had a couple people do this (but 2 in the last 2 months for some reason)
[21:38:24] <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.
[21:40:21] <pcw_home> :-)
[21:47:03] <jepler> Error: wrong bitfile destination card: Detected 5I24, filename is /5i2
[21:47:12] <jepler> well this proves I'm on the right track, just not quite there yet
[21:47:55] <jepler> hmmmm, is there a problem coming up for 5i24 vs 6i24?
[21:48:01] <jepler> or whichever the pci / pci-express pairs are
[21:48:21] <Tom_L> iirc i used 5ixx on 6ixx cards
[21:48:37] <jepler> right, and that should continue to work
[21:49:13] <jepler> I mean, it needs to continue to work
[21:49:39] <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
[21:49:53] <jepler> I guess maybe special cases will be required for a few card IDs
[21:50:23] <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
[21:50:34] <Tom_L> so if it changes somehow that should be edited
[21:52:22] <jepler> Error: wrong bitfile destination card: Detected 5I24, filename is 7i90
[21:53:11] <Tom_L> are you adding an identifier to the .vhd source file for that?
[21:53:16] <jepler> I'm not sure why you would use 6i25 in the first step but I accept your report that it is required
[21:53:21] <jepler> and yes that would break if this change goes into mesaflash
[21:53:51] <jepler> first I'm doing what pcw_home suggested and checking the filename
[21:54:01] <jepler> putting it inside the .bit file structure in some way might happen at a later date though
[21:54:11] <Tom_L> i forget the reasoning on the 6i25 but it had something to do with how mesaflash was at the time
[21:55:21] <jepler> Error: wrong bitfile destination card: Detected 5I24, bitfile ID is 7i90
[21:55:42] <jepler> here's how the message would look when getting the card data out of the bitfile: ^^
[21:56:55] <pcw_home> 6i24 can use 5i24 bitfiles and 6i25 can use 6i24 bitfiles but that the only exception
[21:57:17] <pcw_home> 6i25 can use 5i25 bitfiles I mean
[21:57:35] <Tom_L> could it be somehow encorporated in the .vhd on the line: package PIN_SVST6_6_7I48_72
[21:57:45] <Tom_L> as the identifier
[21:58:15] <Tom_L> ^^ just pulled that one at random
[21:59:54] <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
[22:00:18] <pcw_home> I think the user ID would be good (I think they are all 0xFFFFFFFF now)
[22:01:47] <jepler> pcw_home: yes you get FFFFFFFF if you don't request a different value
[22:02:02] <jepler> another problem is if you like to rename the bitfiles yourself
[22:02:17] <jepler> e.g., you make sure the filename is BLUE_CINCI.BIT or something
[22:02:25] <jepler> because it goes on the Cinci that's painted blue
[22:02:51] <jepler> maybe I only pay attention to filenames that start <digit>[iI]<digit><digit> ?
[22:03:43] <pcw_home> In that case (no card name) a stern warning could be issued
[22:04:45] <pcw_home> I should also put that trick for trying an untested bitfile safely in some of the manuals
[22:06:37] <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
[22:07:21] <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
[22:07:45] <jepler> afk and goodnight
[22:08:15] <pcw_home> thanks, and 'nite