EMC: 03cradek 07master * rbdfe43c501d5 10/src/emc/task/emccanon.cc: fix corner case where naive cam detector skips full circle arcs with i+,j0
jepler: please check this ^
cradek: updated my rip with that fix, works for me -- didn't mean for you to rush to fix -- thanks again
I can't resist a good bug report
i know what you mean
just hope I didn't break any other cases. there are demons near that code.
but it's such a short function ...
DEMONS HIDE WHERE YOU LEAST EXPECT THEM
check under the bed
alex_joni: May I ask what programs are you writing in day jog besides kinematics and such for welding robots?
are you using some programming frameworks?
not in my day job ;)
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
robh: in the user manual?
nm I found it thanks robh
EMC: 03bigjohnt 07master * r798bca812161 10/docs/src/gcode/main.lyx: Fix typo in G10 L20
sorry was eating lunch only saw it as was making camworks post processor thx for fixing
thanks for letting me know, I leave BJT_Shop on most of the time so if it is flashing I know someone pinged me
I'm thinking about breakfast and a bike ride :)
cradek: your change looks fine. if it actually causes some near-degenerate arc to not be split to lines, that's nbd.
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.
jepler: thanks for checking - the fudge number made me nervous that I didn't understand it all
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.
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.
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!
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)
hm, all of G10 L20 assumes you're currently in the system you're changing. I think it's broken otherwise.
cradek: draw out a similar picture ..... Yep, if it isn't done, then that is what I was thinking of...
cradek: I don't see any wrong behaviour of G10 L20 you mentioned
wait, maybe you are right
it does seem to work - I must be thinking about it wrong
cradek: R word isn't allowed in G10 L20 right ?
that makes no sense
so in docs there is wrong description about R wor in G10 L20
[16:39:18] <micges> http://www.linuxcnc.org/docview/devel/html//gcode_main.html#sec:G10-L20
you are right, it should say G10 L20 R is an error
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
I see it
earlier I've checked it without R
yes me too
are you digging this issue?
if I say no, will you fix it? :-)
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?
alex_joni was thinking that his patch for pause caused this and I prooved this
why you asking?
because I don't think it is fixed, and I thought you had figured out a fix
there is some deeply hiden bug in pause/start/resume status reporting by task
when alex fixed pause he noted in comment that he must code this but he didn't know why;)
appart this there is many bugs to fix...
yes I agree, task is a mess
I started rewriting it but did not get too far
I started by removing the interp_list which I think is unneeded and just makes it more complicated
canon will directly call some function that sends command for motion?
yes that's what I changed it to
making the canon and motion interfaces as similar as possible (especially for arcs) would eliminate another source of many errors
can you paste your code?
well it only barely runs - many things do not work - I kind of gave up
let me see if I can find it
I've started moving iotask to motion
yes eliminating iotask is another very good idea
it hardly does anything anymore
and it makes motion during tool change hard or impossible to do right
[17:14:27] <cradek> http://timeguy.com/cradek-files/emc/0001-runs-barely.patch
MDI and running a basic program works
not much else works
on your code there is no problem about serializing command like M66 and such?
those currently stop readahead - they would still need to do that - motion's queue would empty
same for tool change etc
I think currently both motion's queue and interp_list have to empty
again I do not see any advantage to interp_list
I think interpreting the gcode takes very little time
changing the interpreter's results to NML format and then into motion command format is just extra work for no reason
maybe interp_list was importand on Pentium 200 machines
maybe so, but I bet the interpreter was always pretty fast
I really don't understand the existing design or the reasons for it
and another one is that my run from line doesn't work with interp_list.len > 1 ;)
if queueing is disabled everything works fine, even arcs ;)
cradek: nice chatting bbl
if you have a new rfl implementation that gets more stuff right, maybe my patch will help you make something we can integrate
that would make me very happy
jepler: sorry.. no idea about the specifics
I am quite sure SWPadnos was the last one who uploaded the debs
but I bet he didn't store the ftp, user/pass
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
wow, that took a while
G10 L20 is harder than I first thought.
cradek, could the existing design have been more to decouple the systems so things could be easily changed or replaced?
interp_list vs motion like you just mentioned
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
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.
I see. I had wondered about that myself. seems the NML layers would slow things down.
yes that's definitely true. This change won't affect that.
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
this change wouldn't eliminate that very important layer
why are they called canon? and what is meant by canonical I see mentioned often?
in fact that's how AXIS gets its preview: pretends it's a machine and lets the interpreter "move" it
Ok, good. I might need a pick and place format interpreter someday.
"canonical machining functions" are supposed to be a list of the operations that any machine tool can do
once you have that, all the interpreter has to do is tell the machine to do them in the right order
"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. "
of course we've expanded and modified the list a bit
I see. So higher level commands are broken down to STRAIGHT_FEED etc. Where's the expanded list?
yes for instance a G81 drill cycle will issue many FEEDs and TRAVERSEs
probably the only place to see the exact list is in the source, src/emc/task/emccanon.cc
there's stuff for splines, rigid tapping, etc etc.
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.
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
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.
(that would be neat)
so cutter comp should really be in motion?
like I said, good and bad
off to work on my spindle resolver...
I guess I'm asking where it would go if not in the interpreter?
mozmck: cutter comp could be done at canon level, in emccanon.cc
micges1 is now known as micges
is there a reason for G80 Z to be rejected while G80 G00 Z is valid ? G80 should put G00 active
'Z' without a number following is invalid
oh I think I get your question
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
in fact, the docs explicitly say that it is an error to use axis words with G80 unless you also specify another motion code.
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
beat you again
lol now now
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
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
your renishaw u have cradek is yours infared with a pickup modual?
Omm or Omi
older: MP700 I think it's called
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
yea mine is MP700E also
was just wundering if u had started to interface it yet or not
you don't have the receiver head and box?
they quoted me $1582 for OMI last year
plus $119 for the mounting bracket, haha
the other option is MI12 + OMM but that costs even more
i have the pickup OMI, but renishaw make u need the MI12
i mean OMM
all i can see that box does is convert the OMM signals into 24V to interface to the NC
ah then you're fine, hook them up to your own optos or whatever
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
yes it's very important to get those error signals (low bat, no contact)
ill have to see how that OMM outputs i know OMI does it stright out i belive, error low bat etc
which pickup one do you have