Back
[02:18:35] <jepler> alex_joni: my first thought on skimming through that is that EMC_MAX_DIO and EMCMOT_MAX_DIO should always be the same, so they should come from a common header file.
[02:19:42] <jepler> alex_joni: my second thought is that some user recently said that 4 DIO wasn't enough -- we should increase this or even find a way to make it load-time configurable
[02:21:16] <jepler> if "write analog output" wasn't on my original list of features, it should be ..
[02:22:05] <jepler> looks like you got pretty far already
[02:37:21] <SWPadnos> I'm not sure that EMCMOT_MAX_DIO has to be the same as EMC_MAX_DIO, but it sure needs to be at least as high
[02:38:05] <SWPadnos> it's possible that there could be uses for DIO in emcmot that don't need to be reported to EMC via NML status (though I can't think of any at the moment)
[08:48:06] <alex_joni> jepler: I agree, and I tried (briefly) to do just that, but when I included emcglb.h or config.h from motion (aka RT) it went tits up with the compile, so I dumped it for now
[11:06:20] <alex_joni> that's one of the smaller problems.. when you're around (and care to talk about this), let me know.. I need your input :)
[11:07:40] <fenn> nya
[11:08:21] <alex_joni> nya? is that even a word?
[11:08:33] <fenn> not your average word
[11:08:43] <alex_joni> nya = not your average ?
[11:09:06] <fenn> no its an onomatopoeia
[11:09:53] <fenn> nyaaaaaa
[11:10:03] <lerneaen_hydra> ni!
[11:13:02] <alex_joni> ni pong
[11:16:17] <fenn> lua looks like python with "end" stuck everywhere
[11:49:48] <jepler> :q
[11:49:52] <jepler> oops
[11:54:19] <fenn> alex_joni: here's a case to think about: G64 G1 Y1; if rt_input G1 X1Y2 else G1 X-1 Y2
[11:54:34] <fenn> doesnt it have to start blending before the input?
[11:55:12] <fenn> it cant predict the future, but how do you determine when you need to be able to predict the future?
[11:55:25] <alex_joni> fenn: I don't think it should blend in that case
[11:55:54] <alex_joni> because it could be a G64 G1 Y1 M3; if rt_input G1 X1Y2...
[11:56:09] <alex_joni> and the M3 in there might cause the rt_input to change
[11:56:17] <alex_joni> bbl, lunch
[11:56:45] <alex_joni> jepler: when you get a chance, please read back in #emc
[11:56:53] <jepler> fenn: it must exact-stop at Y1, then read the input, then start again with one of the two motions.
[11:57:07] <jepler> alex_joni: in #emc? what am I looking for in particular?
[11:57:35] <fenn> branching in canon
[11:57:55] <fenn> and splitting interp into g-code specific things and high level functions
[11:57:58] <fenn> that's about it
[11:59:11] <jepler> fenn: lerman's the one who tried to put lipstick on the gcode pig, and for better or worse I think we're stuck with his effort
[11:59:27] <fenn> heh i agree completely
[11:59:34] <fenn> i'd say "worse"
[12:00:26] <fenn> it was a heroic effort
[12:03:08] <jepler> I am told by real machinists that real machinists don't want to learn a programming language .. which seems to mean that whatever language you come up with, it has to be g-code.
[12:04:02] <jepler> but on days when I prefer to blatanly disregard what people who call themselves "real machinists" say they want, I fantasize about throwing out task and replacing it with a thousand lines of python code or so
[12:04:30] <lerneaen_hydra> wouldn't the programming functionality be used for situations where EMC isn't used for driving a mill/lathe/whatever but something more arbitrary?
[12:09:08] <jepler> well that's part of the problem -- I am not sure what the right set of goals is, or what users(s) this change is supposed to benefit
[12:09:25] <jepler> in that case it's probably best that I just don't suggest it for inclusion :-P
[12:20:44] <alex_joni> jepler: well.. we can keep lermen's effort, it's a quite good one so far
[12:20:54] <alex_joni> but I hit some serious limitations with it
[12:21:07] <alex_joni> basicly I can't really add the WAIT() canon call as it is now
[12:21:13] <alex_joni> or I don't see how
[12:22:32] <alex_joni> the problem right now is that branching is done in the interpreter
[12:22:37] <jepler> yes, it has to be
[12:22:45] <jepler> how does "probe" do it?
[12:22:51] <alex_joni> it doesn't
[12:23:03] <alex_joni> probe is just a linear move to a certain point then back to the initial point
[12:23:07] <jepler> it has to block the execution of the following gcode so that the later lines can refer to the coordinates where the probe ended
[12:23:20] <alex_joni> no it doesn't
[12:24:04] <alex_joni> blocking the execution is not a problem
[12:24:08] <jepler> then how does tool length probing (which I've seen run on chris's mill) work?
[12:24:30] <alex_joni> hmm, I need to look at that
[12:25:42] <alex_joni> obviously I have no idea
[12:27:13] <alex_joni> oh, simply.. it's handled in canon
[12:27:35] <alex_joni> the idea is that interp puts all commands in the interp_list
[12:28:09] <alex_joni> * alex_joni reads some more
[12:34:06] <alex_joni> hmm.. this really puzzles me
[12:35:46] <alex_joni> AH-HA
[12:35:52] <alex_joni> return INTERP_EXECUTE_FINISH
[12:36:07] <alex_joni> // inhibit read-ahead until this is done
[12:37:11] <jepler> int Interp::read(const char *command) //!< may be NULL or a string to read
[12:37:21] <jepler> if (_setup.probe_flag == ON) {
[12:37:21] <jepler> CHK((GET_EXTERNAL_QUEUE_EMPTY() == 0),
[12:37:21] <jepler> NCE_QUEUE_IS_NOT_EMPTY_AFTER_PROBING);
[12:37:21] <jepler> set_probe_data(&_setup);
[12:37:30] <jepler> set_probe_data calls stuff like GET_EXTERNAL_POSITION_X()
[12:37:40] <alex_joni> I think the clue in convert_** to return INTERP_EXECUTE_FINISH
[12:37:57] <jepler> so in C/canon you don't get a simple "canon call returns a value or values" structure, it is more complicated
[12:38:38] <alex_joni> don't think so.. it just needs to get called at the appropiate time
[12:40:36] <alex_joni> but .. yes, it needs to be a bit more complicated then what I have
[12:57:56] <fenn> i dont understand any of this interp stuff
[12:58:17] <alex_joni> fenn: :-)
[12:58:36] <alex_joni> it seems to provide a mechanism to stop interpreting untill something finished executing
[12:59:01] <fenn> i remember there are nml commands with wait-states
[12:59:32] <fenn> dunno if that is relevant
[12:59:37] <alex_joni> nope
[13:00:39] <alex_joni> jepler: I'm thinking about having a single canon call for Inputs, WAIT
[13:00:59] <alex_joni> and for some (like read value, it would just set the return-type to immediate)
[13:18:14] <alex_joni> cradek: can you tell me of a int letter available, beside P and E ?
[13:18:34] <alex_joni> L maybe?
[13:22:05] <fenn> Q?
[13:22:28] <alex_joni> that might work
[13:22:52] <fenn> nope
[13:22:58] <alex_joni> M66 P0 E0 L0 Q4.2
[13:23:05] <fenn> Q - feed increment in G83 canned cycle
[13:23:10] <fenn> oh
[13:23:19] <alex_joni> yeah, but for M66 I can use it
[13:23:22] <fenn> ok
[13:23:47] <fenn> what is m66? black magic? :P
[13:23:53] <alex_joni> yeah
[13:24:08] <fenn> http://en.wikipedia.org/wiki/Black_Magic_M-66
[13:24:48] <alex_joni> heh.. how did you know? it fits perfectly :P
[13:24:57] <fenn> i'm a big shirow fan
[13:25:06] <lerneaen_hydra> re custom mcodes,
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?UserDefinedMcodes <-- by external programs does it mean external Gcode files?
[13:25:18] <lerneaen_hydra> or a binary?
[13:25:23] <lerneaen_hydra> or something else?
[13:25:59] <fenn> shell scripts, binaries, etc
[13:26:14] <lerneaen_hydra> oh, ok
[13:26:27] <alex_joni> http://pastebin.ca/662196
[13:26:28] <lerneaen_hydra> is there any simple way to get a code/whatever to run a gcode snippet?
[13:26:44] <alex_joni> gotta run for a while, but I'll continue on this later this evening
[13:26:53] <fenn> lerneaen_hydra: i always wondered that myself
[13:27:06] <alex_joni> sure.. use jdi
[13:27:17] <lerneaen_hydra> jdi?
[13:27:24] <fenn> just do it
[13:27:43] <alex_joni> http://axis.unpy.net/01167419757
[13:27:54] <lerneaen_hydra> as in patch emc?
[13:28:04] <lerneaen_hydra> oh
[13:28:22] <fenn> turn off estop eh
[13:28:53] <fenn> and turn on estop.. even worse!
[13:29:15] <lerneaen_hydra> oh, I was thinking more along the lines of a line in a gcode file that runs a preexisting gocde snippet
[13:29:29] <alex_joni> lerneaen_hydra: you can call a function with o-words
[13:29:42] <lerneaen_hydra> ie a simple code in gcode that does cradek's toolchange function with probe
[13:29:47] <alex_joni> if the function is not defined in your file, it will try to load a file named like that function
[13:29:56] <lerneaen_hydra> oh, it will?
[13:29:56] <lerneaen_hydra> sweet
[13:29:59] <alex_joni> and run the function from that file
[13:30:27] <fenn> from nc_files?
[13:30:27] <alex_joni> later y'all
[13:30:37] <alex_joni> fenn: from your program directory
[13:30:46] <fenn> okie
[13:30:48] <fenn> ciao
[13:31:07] <alex_joni> fenn: from PROGRAM_PREFIX/
[18:27:27] <tfmacz> does anyone have any comments on using a 64-bit amd sempron with emc2 and realtime????
[18:30:18] <SWPadnos> I'm pretty sure both jepler and jmkasunich have done that (may be Athlon 64 instead of Sempron)
[18:30:37] <SWPadnos> I've done some with an Opteron setup as well
[19:00:08] <tfmacz> SWPadnos: I read someting about compiling from CVS
[19:00:42] <tfmacz> SWPadnos: is there a "binary" version available???
[19:01:02] <SWPadnos> well, that's only if you really want the 64-bit kernel. the stock 32-bit kernel runs great on the Sempron
[19:01:49] <SWPadnos> I'm not sure if there's a debian package with a 64-bit RT kernel yet. if so, I'm sure it's still "experimental"
[19:02:13] <tfmacz> I am trying to figure out what would be the advantage of going to the 64 bit operating system???
[19:02:51] <SWPadnos> I'm not sure there are any real advantagesat the moment, and you get some driver / program problems thrown in
[19:02:57] <tfmacz> I have heard lots of packages are not "ported" for 64bit.
[19:03:36] <SWPadnos> it's helpful if you have a PC with more than 3GB of RAM, or if you have software that often works with datasets larger than 4 GB (or does 64-bit math all the time, for that matter)
[19:03:45] <SWPadnos> in most cases, it's not really necessary
[19:04:36] <SWPadnos> eventually, a 64-bit machine may have HAL data types that are 64 bits wide, like doubles instead of floats, but that's just speculation on my aprt at the moment (and wouldn't be likely to happen for a long time for compatibility reasons)
[19:44:28] <tfmacz> SWPadnos: Sorry, got called away, thanks for theinfo, looks like I will stick with the 32 bit
[20:55:20] <alex_joni> hi all
[22:32:12] <jmkasunich__> jmkasunich__ is now known as jmkasunich
[22:51:19] <alex_joni> yay.. it started working :D
[22:52:24] <SWPadnos> yay!
[22:52:26] <SWPadnos> what is it?
[22:52:36] <alex_joni> still the input stuff
[22:52:42] <SWPadnos> cool
[22:53:20] <alex_joni> yeah.. I can now check a digital input from g-code
[22:53:36] <SWPadnos> one thing to think about: do things like a wait request get properly canceled if the controller goes into e-stop/machine off/program stop ... ?
[22:53:36] <alex_joni> the result is in #5398
[22:53:47] <SWPadnos> excellent
[22:54:06] <alex_joni> SWPadnos: that's about it for what I've done
[22:54:11] <SWPadnos> heh
[22:54:16] <alex_joni> but the wait request will probably be handled by motion
[22:54:23] <alex_joni> which sets some result flags
[22:54:41] <alex_joni> * alex_joni has a secret plan to involve jmk in doing that
[22:54:49] <SWPadnos> that's the thing - motion gets canceled, and so should input wait requests - I wasn't sure if that was in the code you had written :)
[22:55:06] <alex_joni> I mostly tweaked the interp
[22:55:12] <alex_joni> and the comm. channels to/from motion
[22:55:41] <alex_joni> M67 P00 - P03 reads motion.digital-input-00 - 03
[22:56:04] <SWPadnos> poo
[22:56:10] <SWPadnos> M67 POO :)
[22:56:22] <alex_joni> M68 is for analog inputs
[22:56:29] <alex_joni> M67 for digital ones
[22:56:35] <alex_joni> and M66 is the wait for input
[22:56:36] <SWPadnos> excellent
[22:56:41] <alex_joni> with lots of params
[22:57:20] <alex_joni> P - input-nr., E - digital/analog, L - type of wait (immediate, rise, fall, high, low), Q - timeout
[22:57:20] <SWPadnos> M66 "wait for analog input 3 to get above 3V P-P, at 60-70 Hz :)
[22:57:41] <alex_joni> something like that
[22:57:51] <alex_joni> ;-)
[22:58:15] <SWPadnos> and there are new NML messages for all these, right?
[22:58:26] <alex_joni> diff coming up
[22:59:48] <alex_joni> http://pastebin.ca/662644
[23:01:15] <alex_joni> actually only one NML message so far
[23:01:19] <alex_joni> 3 CANON calls
[23:01:24] <SWPadnos> ok. np.
[23:01:41] <alex_joni> I mean.. only one NML message for M66, M67 and M68
[23:01:59] <SWPadnos> all this talk of external scripting always brings up issues with networking (sometihng I suspect a lot of the people asking about it don't really think about)
[23:02:00] <alex_joni> it can handle M66, and 67 & 68 are subsets
[23:02:17] <alex_joni> what do you mean?
[23:03:02] <SWPadnos> sorry - first, I link this work with scripting only because scripts need to be able to get some status and branch depending on it, so they're similar
[23:03:32] <alex_joni> I agree
[23:03:40] <alex_joni> and I totally think this was missing and was needed in emc2
[23:03:48] <SWPadnos> people who talk about Mach being programmable with VB aren't thikning about the communication channels that EMC2 has - namely NML, which may be remote from the motion controller (and I/O)
[23:03:52] <SWPadnos> absolutely
[23:04:06] <alex_joni> SWPadnos: yeah, but implemented like this it shouldn't matter
[23:04:15] <SWPadnos> right - that's good :)
[23:04:23] <alex_joni> and it wouldn't have been easier if it was a single machine only
[23:04:29] <SWPadnos> not with EMC ;)
[23:04:38] <alex_joni> the NML part is close to non-existing for me
[23:04:51] <alex_joni> I mean that's one of the things I'm really comfortable with
[23:04:55] <SWPadnos> I imagine making a different front end for EMC - one that's more like the Yaskawa or Parker controller languages
[23:05:20] <SWPadnos> it would basically do its thing, then make canon calls to get stuff done
[23:05:24] <alex_joni> if you can write an interp which calls CANON stuff.. then it should be fairly easy
[23:05:28] <alex_joni> indeed
[23:05:45] <alex_joni> but it would too need to stop interpreting at branchpoints
[23:05:51] <SWPadnos> this can already be done, but some more things are enabled by your IO work, so good work! :)
[23:05:57] <alex_joni> s/would too/too would/
[23:06:12] <alex_joni> I'll try to bring it in shape and checked in tomorrow
[23:06:15] <SWPadnos> sure - and be able to check I/Os, use analog inputs in formulas, etc.
[23:07:12] <alex_joni> check line#33 on that pastebin
[23:07:18] <alex_joni> ;-)
[23:07:32] <SWPadnos> gotta run - time to cook dinner with the wife. see you later, and thanks again for this - it was sorely needed
[23:07:34] <SWPadnos> heh
[23:07:52] <alex_joni> sure thing.. enjoy dinner
[23:08:44] <alex_joni> * alex_joni is off to bed
[23:08:46] <alex_joni> good night all
[23:08:55] <SWPadnos> night