Back
[01:25:12] <CIA-82> EMC: 03cradek 07master * rbdfe43c501d5 10/src/emc/task/emccanon.cc: fix corner case where naive cam detector skips full circle arcs with i+,j0
[01:25:41] <cradek> jepler: please check this ^
[01:37:10] <dgarr> cradek: updated my rip with that fix, works for me -- didn't mean for you to rush to fix -- thanks again
[01:37:33] <cradek> I can't resist a good bug report
[01:37:45] <cradek> (sometimes...)
[01:37:53] <dgarr> i know what you mean
[01:38:42] <cradek> just hope I didn't break any other cases. there are demons near that code.
[01:38:57] <SWPadnos> but it's such a short function ...
[01:39:12] <cradek> DEMONS HIDE WHERE YOU LEAST EXPECT THEM
[01:39:30] <SWPadnos> I see
[01:39:33] <SWPadnos> check under the bed
[08:29:43] <micges> cool
[08:34:15] <micges> alex_joni: May I ask what programs are you writing in day jog besides kinematics and such for welding robots?
[08:34:48] <micges> are you using some programming frameworks?
[08:41:59] <alex_joni> not in my day job ;)
[08:45:54] <micges> heh
[09:20:08] <alex_joni> bbl
[11:37:53] <robh> there looks to be a typo on the Gcode reg page for Dev version, for G10 L20, top exsample shows G10 L22 not G10 L20
[12:00:03] <jthornton> robh: in the user manual?
[12:02:02] <jthornton> nm I found it thanks robh
[12:03:23] <CIA-82> EMC: 03bigjohnt 07master * r798bca812161 10/docs/src/gcode/main.lyx: Fix typo in G10 L20
[12:24:13] <robh> sorry was eating lunch only saw it as was making camworks post processor thx for fixing
[12:39:49] <jthornton> thanks for letting me know, I leave BJT_Shop on most of the time so if it is flashing I know someone pinged me
[12:40:35] <jthornton> I'm thinking about breakfast and a bike ride :)
[13:17:32] <jepler> cradek: your change looks fine. if it actually causes some near-degenerate arc to not be split to lines, that's nbd.
[13:18:44] <jepler> alex_joni: can you take care of Eric H. Johnson's new packages? I have no idea what the details of his ftp site are, but I know you've done this in the past.
[14:43:24] <cradek> jepler: thanks for checking - the fudge number made me nervous that I didn't understand it all
[14:44:13] <cradek> jepler: also, AXIS doesn't have that fudge but has a similar routine. strangely, it previewed these arcs correctly. I didn't check whether it was getting -pi and +pi though.
[15:00:50] <Dave911> On Mr. Jeplers website, there is mention that the Eagle schematic software was being used to generate Hal interconnection code. Does anyone know where that software stands? There was a link on Mr. Jeplers website about that but the link is broken.
[15:00:52] <Dave911> Do some of you have a methodology to do complex Hal setups? I'm looking at doing an 8 axis spring winding machine and it may be a fairly complex hal configuration. Any ideas are appreciated! : ) Thanks!
[16:12:45] <cradek> Dave911: I don't know if that was ever completed or successful. But I bet you could draw out a similar picture with a pencil and have it be very useful (and quicker and easier)
[16:19:20] <cradek> hm, all of G10 L20 assumes you're currently in the system you're changing. I think it's broken otherwise.
[16:24:18] <Dave911> cradek: draw out a similar picture ..... Yep, if it isn't done, then that is what I was thinking of...
[16:32:24] <micges> cradek: I don't see any wrong behaviour of G10 L20 you mentioned
[16:36:54] <cradek> wait, maybe you are right
[16:37:09] <cradek> it does seem to work - I must be thinking about it wrong
[16:37:31] <micges> cradek: R word isn't allowed in G10 L20 right ?
[16:37:44] <cradek> right
[16:37:49] <cradek> that makes no sense
[16:38:47] <micges> so in docs there is wrong description about R wor in G10 L20
[16:38:59] <cradek> oh?
[16:39:18] <micges> http://www.linuxcnc.org/docview/devel/html//gcode_main.html#sec:G10-L20
[16:40:00] <cradek> you are right, it should say G10 L20 R is an error
[16:43:17] <cradek> here is how you can see the problem: offset and rotate g54 and g55 differently. switch to g54. use g10 l20 p2 to modify g55. switch to g55 and notice the numbers are not the same as you wrote
[16:47:05] <micges> I see it
[16:47:24] <micges> earlier I've checked it without R
[16:47:45] <cradek> yes me too
[16:50:26] <micges> are you digging this issue?
[16:52:09] <cradek> if I say no, will you fix it? :-)
[16:52:15] <cradek> (yes)
[16:52:51] <micges> hehe
[16:55:40] <cradek> micges: I think I remember you found the cause of the problem where a program will run for 1000 lines and stop, if you start it in single step mode? Do you remember?
[16:57:09] <micges> alex_joni was thinking that his patch for pause caused this and I prooved this
[16:58:00] <micges> why you asking?
[16:58:47] <cradek> because I don't think it is fixed, and I thought you had figured out a fix
[17:00:17] <micges> there is some deeply hiden bug in pause/start/resume status reporting by task
[17:02:10] <micges> when alex fixed pause he noted in comment that he must code this but he didn't know why;)
[17:03:21] <micges> appart this there is many bugs to fix...
[17:06:05] <cradek> yes I agree, task is a mess
[17:06:21] <cradek> I started rewriting it but did not get too far
[17:06:46] <cradek> I started by removing the interp_list which I think is unneeded and just makes it more complicated
[17:08:55] <micges> canon will directly call some function that sends command for motion?
[17:09:14] <cradek> yes that's what I changed it to
[17:09:46] <micges> nice
[17:09:47] <cradek> making the canon and motion interfaces as similar as possible (especially for arcs) would eliminate another source of many errors
[17:10:18] <micges> can you paste your code?
[17:10:49] <cradek> well it only barely runs - many things do not work - I kind of gave up
[17:10:52] <cradek> let me see if I can find it
[17:10:56] <micges> I've started moving iotask to motion
[17:11:18] <cradek> yes eliminating iotask is another very good idea
[17:11:45] <cradek> it hardly does anything anymore
[17:12:01] <cradek> and it makes motion during tool change hard or impossible to do right
[17:12:16] <micges> yes
[17:14:27] <cradek> http://timeguy.com/cradek-files/emc/0001-runs-barely.patch
[17:14:54] <cradek> MDI and running a basic program works
[17:15:05] <cradek> not much else works
[17:16:01] <micges> brb
[17:18:00] <micges> on your code there is no problem about serializing command like M66 and such?
[17:19:01] <cradek> those currently stop readahead - they would still need to do that - motion's queue would empty
[17:19:19] <cradek> same for tool change etc
[17:19:25] <micges> ah ok
[17:19:44] <cradek> I think currently both motion's queue and interp_list have to empty
[17:19:53] <cradek> again I do not see any advantage to interp_list
[17:20:20] <cradek> I think interpreting the gcode takes very little time
[17:20:51] <cradek> changing the interpreter's results to NML format and then into motion command format is just extra work for no reason
[17:21:06] <micges> maybe interp_list was importand on Pentium 200 machines
[17:21:22] <cradek> maybe so, but I bet the interpreter was always pretty fast
[17:22:03] <cradek> I really don't understand the existing design or the reasons for it
[17:22:55] <micges> and another one is that my run from line doesn't work with interp_list.len > 1 ;)
[17:23:27] <micges> if queueing is disabled everything works fine, even arcs ;)
[17:23:57] <micges> cradek: nice chatting bbl
[17:24:03] <cradek> ok
[17:24:32] <cradek> if you have a new rfl implementation that gets more stuff right, maybe my patch will help you make something we can integrate
[17:24:39] <cradek> that would make me very happy
[18:26:20] <alex_joni> jepler: sorry.. no idea about the specifics
[18:26:29] <alex_joni> I am quite sure SWPadnos was the last one who uploaded the debs
[18:26:38] <alex_joni> but I bet he didn't store the ftp, user/pass
[18:43:10] <CIA-82> EMC: 03cradek 07master * r47a99074405d 10/src/emc/rs274ngc/ (interp_convert.cc interp_find.cc rs274ngc_interp.hh): fix using G10 L20 to modify non-current systems
[18:43:15] <cradek> wow, that took a while
[18:43:33] <cradek> G10 L20 is harder than I first thought.
[18:49:39] <mozmck> cradek, could the existing design have been more to decouple the systems so things could be easily changed or replaced?
[18:50:26] <cradek> of task?
[18:51:07] <mozmck> interp_list vs motion like you just mentioned
[18:52:08] <cradek> I understand it was important originally to be able to have different computers doing different parts: one to interpret, one to monitor coolant and spindle, one to run motion ... today those subsystems all talk through layers and layers of NML even though they're always on the same computer
[18:52:26] <mozmck> I don't know much about it at all right now. but I can see that it would be nice if the interpreter could be replaced for some applications.
[18:52:52] <mozmck> I see. I had wondered about that myself. seems the NML layers would slow things down.
[18:52:53] <cradek> yes that's definitely true. This change won't affect that.
[18:53:24] <mozmck> ah, ok.
[18:53:39] <cradek> we could easily plug in a different interpreter. It would use the so-called CANON functions (STRAIGHT_FEED, STRAIGHT_TRAVERSE, ARC_FEED) to control the machine
[18:54:06] <cradek> this change wouldn't eliminate that very important layer
[18:54:14] <mozmck> why are they called canon? and what is meant by canonical I see mentioned often?
[18:54:37] <cradek> in fact that's how AXIS gets its preview: pretends it's a machine and lets the interpreter "move" it
[18:54:52] <mozmck> Ok, good. I might need a pick and place format interpreter someday.
[18:54:54] <mozmck> :)
[18:56:03] <cradek> "canonical machining functions" are supposed to be a list of the operations that any machine tool can do
[18:56:27] <cradek> once you have that, all the interpreter has to do is tell the machine to do them in the right order
[18:57:31] <cradek> "First, all the functionality of common 3-axis to 6-axis machining centers (not turning centers) had to be covered by the functions; for any function a machining center can perform, there has to be a way to tell it to do that function. "
[18:57:38] <cradek> from
http://www.isd.mel.nist.gov/personnel/kramer/pubs/RS274NGC_3.web/RS274NGC_34a.html#1010809
[18:57:51] <cradek> of course we've expanded and modified the list a bit
[18:58:07] <mozmck> I see. So higher level commands are broken down to STRAIGHT_FEED etc. Where's the expanded list?
[18:58:34] <cradek> yes for instance a G81 drill cycle will issue many FEEDs and TRAVERSEs
[18:59:01] <cradek> probably the only place to see the exact list is in the source, src/emc/task/emccanon.cc
[18:59:15] <cradek> there's stuff for splines, rigid tapping, etc etc.
[19:00:11] <mozmck> ok, I've been looking through the code when I have time and am slowly getting a better overall picture I think. don't get enough time though.
[19:00:36] <cradek> an obstacle to replacing the interpreter is that cutter radius compensation is inside the current interp. originally they had a vision of it being past canon, but they did not implement it that way originally, and we have kept the original design:
http://www.isd.mel.nist.gov/personnel/kramer/pubs/RS274NGC_3.web/RS274NGC_34a.html#1000910
[19:01:50] <cradek> that is good and bad. good: AXIS doesn't have to reimplement it to get a matching preview, bad: AXIS can't show you the compensated and uncompensated paths together, no matter how clever it is.
[19:02:07] <cradek> (that would be neat)
[19:02:45] <mozmck> so cutter comp should really be in motion?
[19:02:59] <cradek> like I said, good and bad
[19:03:43] <cradek> off to work on my spindle resolver...
[19:03:44] <mozmck> I guess I'm asking where it would go if not in the interpreter?
[20:55:09] <micges1> mozmck: cutter comp could be done at canon level, in emccanon.cc
[21:00:52] <micges1> micges1 is now known as micges
[23:09:36] <robh> is there a reason for G80 Z to be rejected while G80 G00 Z is valid ? G80 should put G00 active
[23:19:29] <cradek> 'Z' without a number following is invalid
[23:20:00] <cradek> oh I think I get your question
[23:21:23] <cradek> G80 cancels motion mode. Your statement that it makes G00 active is incorrect. You need to specify a new motion mode after the G80. This could be G0, G1, G2, G3, G33, etc
[23:21:46] <cradek> in fact, the docs explicitly say that it is an error to use axis words with G80 unless you also specify another motion code.
[23:21:47] <BJT_Shop> dang your fast I was just going to ask that
[23:21:52] <cradek> http://www.linuxcnc.org/docview/html//gcode_main.html#G80 Cancel Modal Motion
[23:21:53] <BJT_Shop> http://www.linuxcnc.org/docview/html//gcode_main.html#sec:G80:-Cancel-Modal
[23:21:57] <cradek> haha
[23:22:01] <cradek> beat you again
[23:22:36] <BJT_Shop> LOL
[23:29:43] <robh> lol now now
[23:30:24] <robh> yea just on all fanucs (and other controls) G80 Zxx is accepted never new why becasue as u say even in fanuc manual it says as u say
[23:30:59] <robh> no biggie i just forced it to output G00 on end of drill cycles etc any programs i transfer over i will just manualy eddit them lines
[23:31:46] <robh> your renishaw u have cradek is yours infared with a pickup modual?
[23:35:50] <cradek> yes
[23:36:37] <robh> Omm or Omi
[23:36:58] <cradek> older: MP700 I think it's called
[23:37:23] <robh> just i have omm no interface so some time i have to figure all signals out know it can also pickup low bat in probe etc
[23:37:39] <robh> yea mine is MP700E also
[23:38:32] <robh> was just wundering if u had started to interface it yet or not
[23:38:55] <cradek> you don't have the receiver head and box?
[23:39:37] <cradek> they quoted me $1582 for OMI last year
[23:39:58] <cradek> plus $119 for the mounting bracket, haha
[23:40:37] <cradek> the other option is MI12 + OMM but that costs even more
[23:40:43] <robh> i have the pickup OMI, but renishaw make u need the MI12
[23:40:55] <robh> i mean OMM
[23:41:16] <robh> all i can see that box does is convert the OMM signals into 24V to interface to the NC
[23:41:40] <cradek> ah then you're fine, hook them up to your own optos or whatever
[23:43:03] <robh> ill have to play becasue i belive some how MI12 can tell NC when low bat in probe, as well as all the probe touch etc
[23:43:46] <cradek> yes it's very important to get those error signals (low bat, no contact)
[23:44:40] <robh> ill have to see how that OMM outputs i know OMI does it stright out i belive, error low bat etc
[23:44:56] <robh> which pickup one do you have