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)?
that's a complete can of worms :)
what could be done - maybe - just thinking out loud now - is:
have another pin (maybe RW) motion.digitial-out-xx-initial-state
and then pin will be set to initial state on disable or estop?
(hehe, can of worms ;)
the second pin can track the pin value
don't fully understand ;|
just a second
a bit busy
ok.. now I am
there is the pin motion.digital-out-xx
which is the output from the motion controller.. right?
when estop/motion disable we want it to output a certain value
the value can be: 0, whatever was there before, some custom value
I see, and that certain value is in motion.digitial-out-xx-initial-state
that makes sense
I think if the pin is RW it could be made to track digital-out-xx
so if the user does nothing the value it gets reset to at estop/machine off is the same value as before
(e.g. no change)
but if the users wants, he can connect 0 or whatever value to the pin to reset it to a certain value
I'm not sure this would work though
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
if you're talking about "when motion is stopped", then it needs to be in the motion controller
e.g., when FO or AFO are 0, etc
SWPadnos: yes but after motion enable (f2) pins values are set to previous value, that is bad
when using mux
yep, that's true
I mean I have four pneumatic punchers that are controlled by M64/M65 and they should be disabled on estop
or external error
default values are a good thing, I don't think anything else related to this goes in the motion controller
to not make any hard to not forget links in hal to enable this, I think emcmot should reset this on estop
yes, any default values should be output on estop
right.. but reset them to the preload values
which can be the last values if nothing done by the user
or to some custom value, set by setp or whatever
there's still a little bit of a bootstrap issue, but it's probably not going to be a problem in practice
it really screams for "on-pin-change" notifications instead of effectively polling for changes
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
that may be what you need, but it sounds somewhat specific to your situation
if you want to be able to set default values from G-code, you should have an explicit code to do that
otherwise it's all HAL
that will run as old code if I don't connect any signal to default value
pins can't tell if they're connected to anything
and you can also setp a pin directly, with no signal attached
no but they value are changed if they are input pins and connected to signal
uh - what if you want a default value, and it's zero (the default for HAL pins)?
you can't tell from the value of a pin whether it's supposed to be valid
so maybe M64.1 Pn Qvalue to set default value of P pin to Q value ?
sure, that could work
SWPadnos: ok thanks
or something. you may want comments from others as well :)
one small problem is that [RS274NGC]RS274NGC_STARTUP_CODE is one line and all that code must go to program
but I can handle it ;)
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 :)
however, I think that there are good uses for automatic code
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
(b) is to allow you to specify a file on the RS274NGC_STARTUP line, instead of a few codes to run
either option is probably controversial, and there are definitely questions about when those codes should be run (every restart, every file load, startup only ...)
SWPadnos: (b) was my idea two days ago and was rejected
there are(surely will be) and here is machine that would be fully use that all options
I have two head welder with 5 pins io for a welder, can't have way to determine init state and such
state after stop/ before start also
but yes this is very specific, but will not be in a future
After thinking I will implement M64.1 Pn (set 1 as default) and M65.1 P0 (set 0 as default)
surely all the outputs start in some state, and I'm guessing it's zero
if M2 doesn't put them back, that's probably the bug
... bbl, breakfast
so M64 sets an output to 1 and M65 sets it to 0?
so here's what I was Hmmm'ing about
there are several times when it might be beneficial to run some codes that the integrator can set up
startup, shutdown, program load, program start, program end ...
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
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
people who need it will then have it available
yes now it's done that way STARTUP_CODE
right. there's only one situation that's implemented :)
cradek: M2 doesn't reset motion.digital-out-nn, I think that was never intended ;)
Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-08-28.txt
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?
I have no opinion (because I don't know what you're talking about :) )
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)
you might be able to use the HOME_SEQUENCE functionality to do that
even if homing is done in HAL, a "done" output can be connected to the Z home switch input
(whatever homing actually means on that machine)
I've done some debbuging of clip9 bug about calling g38 in O<smth> CALL
[17:24:32] <micges> http://www.pastebin.ca/1546011
'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
do you know what is going wrong at the canon level?
thanks for looking into it
(only clue is that STRAIGHT_TRAVERSE isn't add becouse vel = acc = 0, so some external change occurs of canonEndPoint)
aha big clue
EMC: 03micges 07master * ra6d756880a11 10/src/emc/task/emccanon.cc: Always update canonEndPoint through a function canonUpdateEndPoint()
does that fix it for some reason I don't see right away?
no it only to easy debug changing
these are two mdi calls of buggy sub
see what happens in interp::set_probe_data
canonEndPoint is set to location of start of gcode
don't know why ;|
what was the url for the gcode again?
no, I guess they don't match
can you paste your test gcode for me?
[18:53:09] <micges> http://www.pastebin.ca/1546125
runned from mdi
sorry, helping someone else at the same time
cradek: ok, maybe someone will take a look
I don't understand why lines 3 or 8 issue LINEAR_MOVEs
that must not be what line_number means
line_numbers are surely not updated
g0 and probe have line=8
(g0 and clear probe flag I mean)
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
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?
I don't understand use_lazy_close but I bet it's related
if it is it, that would be fourth bug with O<>CALL
I wonder how proper probe position is get into interp...
at time of execution there is no way to determine it
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
but in debug log I see that probe data is updated right after G38 is processed in canon..
because it has a special postcondition in the interp
I think as soon as the next line is read that behavior gets triggered
and interp stops doing anything else before the result is done
alex knows more than me
so In this case that special case doesn't work
[19:36:21] <micges> http://www.pastebin.ca/1546177
interp paused correclty while probe but data was already updated sooner
maybe that's bug here
I mean lazy_close case
(maybe I'm baffle)
Is there a way (NML message, etc.) for a program running while emc2 is also running to find out emc2's version
mshaver: when I start emc2/AXIS, the offsets are in effect and show up right
machine vs relative on the menu also works
cradek: hmm, I'll try to make it happen with a sample config then, or if not, try to figure out why it happens.
well, I tried trunk, should I be trying 2.3?
ideally i'd reread your bug report I bet
building 2.3 to try
I'm going to reboot my machine to real time mode & try some of the sample configs. I've got 2.3.3.
mshaver: works for me on 2.3 branch as well
ok, time for me to try it
running sim/axis as-is
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.
well it might still be a bug, but one that's triggered by a difference in configuration
is there a hal value that's displayed, or is it gotten via nml
I don't understand
oh where do offsets come from?
they are by nml. machine / show emc status, "origin"
eg. does it display axis.0.motor-pos-fb?
hal knows nothing about gcode offsets or the like
get it's something like EMC_GET_X_POSITION?
or other nml thing
it's by nml, position is in the stat buffer
is there an nmlterm? or nmlview?
it gets shuffled around through all the layers of crap, including canon like you say
emctop shows directly what's in the stat buffer
some of the debug options enable a printout of the messages
dinner bell! bbl
me too!!! thanks!