Back
[07:17:20] <micges_work> hello
[07:30:07] <alex_joni> hi
[09:55:04] <micges_work> alex_joni: what dou you think about option to make 'volatile' io pins (motion.digital-out-xx)? (reset to 0 on motion disable, on estop)?
[09:58:39] <alex_joni> that's a complete can of worms :)
[09:59:17] <alex_joni> what could be done - maybe - just thinking out loud now - is:
[09:59:39] <alex_joni> have another pin (maybe RW) motion.digitial-out-xx-initial-state
[10:36:34] <micges_work> and then pin will be set to initial state on disable or estop?
[10:38:01] <micges_work> (hehe, can of worms ;)
[10:55:08] <alex_joni> the second pin can track the pin value
[11:07:48] <micges_work> don't fully understand ;|
[11:24:58] <alex_joni> just a second
[11:25:00] <alex_joni> a bit busy
[11:27:58] <micges_work> ok
[11:30:10] <alex_joni> ok.. now I am
[11:30:25] <alex_joni> there is the pin motion.digital-out-xx
[11:30:33] <alex_joni> which is the output from the motion controller.. right?
[11:30:51] <alex_joni> when estop/motion disable we want it to output a certain value
[11:31:08] <alex_joni> the value can be: 0, whatever was there before, some custom value
[11:50:01] <micges_work> I see, and that certain value is in motion.digitial-out-xx-initial-state
[11:52:08] <micges_work> that makes sense
[12:25:57] <alex_joni> I think if the pin is RW it could be made to track digital-out-xx
[12:26:17] <alex_joni> so if the user does nothing the value it gets reset to at estop/machine off is the same value as before
[12:26:20] <alex_joni> (e.g. no change)
[12:26:41] <alex_joni> but if the users wants, he can connect 0 or whatever value to the pin to reset it to a certain value
[12:27:23] <micges_work> yes true
[12:33:01] <alex_joni> I'm not sure this would work though
[12:33:25] <SWPadnos> if you're actually talking about "when motion is disabled", then you can use the amp-enable out(s) as select inputs to mux2 components
[12:33:41] <SWPadnos> if you're talking about "when motion is stopped", then it needs to be in the motion controller
[12:34:07] <SWPadnos> e.g., when FO or AFO are 0, etc
[12:34:45] <micges_work> SWPadnos: yes but after motion enable (f2) pins values are set to previous value, that is bad
[12:34:51] <micges_work> when using mux
[12:34:58] <SWPadnos> yep, that's true
[12:35:51] <micges_work> I mean I have four pneumatic punchers that are controlled by M64/M65 and they should be disabled on estop
[12:36:00] <micges_work> or external error
[12:36:56] <SWPadnos> default values are a good thing, I don't think anything else related to this goes in the motion controller
[12:38:42] <micges_work> to not make any hard to not forget links in hal to enable this, I think emcmot should reset this on estop
[12:39:04] <SWPadnos> yes, any default values should be output on estop
[12:39:07] <alex_joni> right.. but reset them to the preload values
[12:39:20] <SWPadnos> yes
[12:39:21] <alex_joni> which can be the last values if nothing done by the user
[12:39:32] <alex_joni> or to some custom value, set by setp or whatever
[12:39:38] <SWPadnos> there's still a little bit of a bootstrap issue, but it's probably not going to be a problem in practice
[12:41:57] <SWPadnos> it really screams for "on-pin-change" notifications instead of effectively polling for changes
[12:42:25] <micges_work> if emcmot set default value to be the same as actually value ot moment of M64, then if pin will be connected to some signal then on next cycle that value will be present on default pin
[12:42:59] <SWPadnos> that may be what you need, but it sounds somewhat specific to your situation
[12:43:30] <SWPadnos> if you want to be able to set default values from G-code, you should have an explicit code to do that
[12:43:38] <SWPadnos> otherwise it's all HAL
[12:43:39] <micges_work> that will run as old code if I don't connect any signal to default value
[12:43:53] <SWPadnos> pins can't tell if they're connected to anything
[12:44:07] <SWPadnos> and you can also setp a pin directly, with no signal attached
[12:44:22] <micges_work> no but they value are changed if they are input pins and connected to signal
[12:44:57] <SWPadnos> uh - what if you want a default value, and it's zero (the default for HAL pins)?
[12:45:20] <SWPadnos> you can't tell from the value of a pin whether it's supposed to be valid
[12:45:28] <micges_work> yes
[12:46:09] <micges_work> so maybe M64.1 Pn Qvalue to set default value of P pin to Q value ?
[12:46:36] <SWPadnos> sure, that could work
[12:47:16] <micges_work> SWPadnos: ok thanks
[12:47:25] <SWPadnos> you're welcome
[12:47:35] <SWPadnos> or something. you may want comments from others as well :)
[12:50:26] <micges_work> one small problem is that [RS274NGC]RS274NGC_STARTUP_CODE is one line and all that code must go to program
[12:51:22] <micges_work> but I can handle it ;)
[12:53:33] <SWPadnos> I think it was cradek that pointed out that having "automatically executed code" may be a poor substitute for putting it in the program, where it belongs :)
[12:53:51] <SWPadnos> however, I think that there are good uses for automatic code
[12:55:07] <SWPadnos> a couple of possibilities, which would definitely need comments before doing them, are (a) to make ini sections with startup/shutdown codes, and execute everything in the section
[12:55:30] <SWPadnos> (b) is to allow you to specify a file on the RS274NGC_STARTUP line, instead of a few codes to run
[12:56:20] <SWPadnos> either option is probably controversial, and there are definitely questions about when those codes should be run (every restart, every file load, startup only ...)
[12:56:34] <micges_work> SWPadnos: (b) was my idea two days ago and was rejected
[12:57:47] <micges_work> there are(surely will be) and here is machine that would be fully use that all options
[12:58:48] <micges_work> I have two head welder with 5 pins io for a welder, can't have way to determine init state and such
[12:59:12] <micges_work> state after stop/ before start also
[12:59:38] <micges_work> but yes this is very specific, but will not be in a future
[13:00:02] <SWPadnos> hmmm
[13:01:15] <micges_work> After thinking I will implement M64.1 Pn (set 1 as default) and M65.1 P0 (set 0 as default)
[13:01:30] <micges_work> *M65.1 Pn
[13:04:03] <cradek> surely all the outputs start in some state, and I'm guessing it's zero
[13:04:11] <cradek> if M2 doesn't put them back, that's probably the bug
[13:04:14] <cradek> ... bbl, breakfast
[13:04:52] <micges_work> heh (?)
[13:08:59] <SWPadnos> so M64 sets an output to 1 and M65 sets it to 0?
[13:09:30] <SWPadnos> so here's what I was Hmmm'ing about
[13:10:17] <SWPadnos> there are several times when it might be beneficial to run some codes that the integrator can set up
[13:10:38] <SWPadnos> startup, shutdown, program load, program start, program end ...
[13:11:12] <SWPadnos> there should be an ini file entry for each of the situations we can think of, with g-code or a g-code file name to run in that situation
[13:11:54] <SWPadnos> people who believe that all that stuff should be in the G-code they write can just omit those ini entries, and nothing will be done for them on their machines
[13:12:12] <SWPadnos> people who need it will then have it available
[13:12:44] <micges_work> sry phone
[13:14:33] <micges_work> yes now it's done that way STARTUP_CODE
[13:14:46] <SWPadnos> right. there's only one situation that's implemented :)
[13:23:25] <micges_work> cradek: M2 doesn't reset motion.digital-out-nn, I think that was never intended ;)
[13:31:31] <skunkworks_> logger_dev: bookmark
[13:31:31] <skunkworks_> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-08-28.txt
[13:31:52] <micges_work> SWPadnos: how do you feel about (motion.enable-homing) to not allow homing when command HOME_ALL was issued and external condition to enable homing was not met?
[13:32:56] <SWPadnos> I have no opinion (because I don't know what you're talking about :) )
[13:35:25] <micges_work> I have z axis that is totally in hal (much easier), and xy axes are only allowed for homing if z was homed first, have done it in hal but it's mess (many muxes)
[13:37:52] <SWPadnos> you might be able to use the HOME_SEQUENCE functionality to do that
[13:38:18] <SWPadnos> even if homing is done in HAL, a "done" output can be connected to the Z home switch input
[13:38:51] <SWPadnos> (whatever homing actually means on that machine)
[13:44:10] <micges_work> thanks
[13:52:55] <micges_work> bbl
[17:24:30] <micges> I've done some debbuging of clip9 bug about calling g38 in O<smth> CALL
[17:24:32] <micges> http://www.pastebin.ca/1546011
[17:25:54] <micges> 'STRAIGHT_TRAVERSE: ' debug is from canon call, so all gcodes are executed correctly, but canon don't add last straight line message to the interp_list
[18:26:25] <cradek> do you know what is going wrong at the canon level?
[18:28:02] <micges> still debugging
[18:28:20] <cradek> thanks for looking into it
[18:29:06] <micges> (only clue is that STRAIGHT_TRAVERSE isn't add becouse vel = acc = 0, so some external change occurs of canonEndPoint)
[18:29:11] <micges> no problem
[18:29:20] <cradek> aha big clue
[18:35:34] <CIA-8> EMC: 03micges 07master * ra6d756880a11 10/src/emc/task/emccanon.cc: Always update canonEndPoint through a function canonUpdateEndPoint()
[18:39:25] <cradek> does that fix it for some reason I don't see right away?
[18:39:47] <micges> no it only to easy debug changing
[18:39:51] <micges> for now
[18:48:45] <micges> cradek:
http://www.pastebin.ca/1546120
[18:49:07] <micges> these are two mdi calls of buggy sub
[18:49:23] <micges> see what happens in interp::set_probe_data
[18:50:12] <micges> canonEndPoint is set to location of start of gcode
[18:51:12] <micges> don't know why ;|
[18:51:27] <cradek> what was the url for the gcode again?
[18:51:54] <cradek> found it
[18:52:21] <cradek> no, I guess they don't match
[18:52:28] <cradek> can you paste your test gcode for me?
[18:53:09] <micges> http://www.pastebin.ca/1546125
[18:53:25] <micges> runned from mdi
[18:53:40] <cradek> thanks
[18:56:07] <cradek> sorry, helping someone else at the same time
[19:03:20] <micges> cradek: ok, maybe someone will take a look
[19:09:50] <cradek> I don't understand why lines 3 or 8 issue LINEAR_MOVEs
[19:12:20] <micges> they don't
[19:12:53] <cradek> that must not be what line_number means
[19:13:28] <micges> line_numbers are surely not updated
[19:13:40] <micges> g0 and probe have line=8
[19:14:15] <micges> (g0 and clear probe flag I mean)
[19:20:12] <CIA-8> EMC: 03micges 07task_cleanup * r1162757619f1 10/src/emc/ (nml_intf/canon.hh task/emccanon.cc): Add few more canon local variables to CanonConfig_t struct
[19:21:41] <cradek> is it wrong the first time you call it after running a gcode program, or is it wrong only the first time you call it BEFORE running a gcode program?
[19:23:06] <micges> don't know
[19:24:35] <cradek> I don't understand use_lazy_close but I bet it's related
[19:26:12] <micges> if it is it, that would be fourth bug with O<>CALL
[19:26:39] <micges> I wonder how proper probe position is get into interp...
[19:27:06] <micges> at time of execution there is no way to determine it
[19:27:34] <cradek> see Interp::read
[19:28:15] <cradek> motion captures position on the servo cycle when it sees the probe trigger, and saves it for the interpreter to read later, after the motion ends
[19:29:19] <micges> mhm
[19:31:36] <micges> but in debug log I see that probe data is updated right after G38 is processed in canon..
[19:32:06] <alex_joni> micges: right
[19:32:19] <alex_joni> because it has a special postcondition in the interp
[19:32:23] <cradek> I think as soon as the next line is read that behavior gets triggered
[19:32:32] <alex_joni> and interp stops doing anything else before the result is done
[19:32:59] <cradek> alex knows more than me
[19:33:10] <alex_joni> used to
[19:35:50] <micges> so In this case that special case doesn't work
[19:36:21] <micges> http://www.pastebin.ca/1546177
[19:36:47] <micges> interp paused correclty while probe but data was already updated sooner
[19:37:15] <micges> maybe that's bug here
[19:37:42] <micges> I mean lazy_close case
[19:39:41] <micges> (maybe I'm baffle)
[20:54:03] <micges> good night
[21:21:23] <mshaver> Is there a way (NML message, etc.) for a program running while emc2 is also running to find out emc2's version
[21:42:33] <cradek> nope
[21:53:45] <mshaver> OK!
[22:06:52] <cradek> mshaver: when I start emc2/AXIS, the offsets are in effect and show up right
[22:07:18] <cradek> machine vs relative on the menu also works
[22:09:06] <mshaver> cradek: hmm, I'll try to make it happen with a sample config then, or if not, try to figure out why it happens.
[22:14:05] <cradek> well, I tried trunk, should I be trying 2.3?
[22:14:21] <cradek> ideally i'd reread your bug report I bet
[22:16:13] <cradek> building 2.3 to try
[22:16:41] <mshaver> I'm going to reboot my machine to real time mode & try some of the sample configs. I've got 2.3.3.
[22:19:51] <cradek> mshaver: works for me on 2.3 branch as well
[22:20:11] <mshaver> ok, time for me to try it
[22:25:07] <cradek> running sim/axis as-is
[22:25:41] <mshaver> it works fine on sim/axis on my desktop. I'll have to play with a real machine tomorrow to see what's going on. It's very useful to know this isn't in emc, but a peculiarity of my setup.
[22:26:09] <cradek> well it might still be a bug, but one that's triggered by a difference in configuration
[22:26:20] <mshaver> is there a hal value that's displayed, or is it gotten via nml
[22:26:34] <cradek> I don't understand
[22:27:15] <cradek> oh where do offsets come from?
[22:27:39] <cradek> they are by nml. machine / show emc status, "origin"
[22:27:52] <cradek> also "tool_offset"
[22:27:56] <mshaver> eg. does it display axis.0.motor-pos-fb?
[22:28:01] <cradek> no
[22:28:26] <cradek> hal knows nothing about gcode offsets or the like
[22:28:36] <mshaver> get it's something like EMC_GET_X_POSITION?
[22:28:44] <mshaver> or other nml thing
[22:28:55] <cradek> it's by nml, position is in the stat buffer
[22:29:14] <mshaver> is there an nmlterm? or nmlview?
[22:29:17] <cradek> it gets shuffled around through all the layers of crap, including canon like you say
[22:29:36] <cradek> emctop shows directly what's in the stat buffer
[22:29:45] <cradek> some of the debug options enable a printout of the messages
[22:29:54] <mshaver> yep
[22:29:55] <cradek> dinner bell! bbl
[22:30:02] <mshaver> me too!!! thanks!