how are things in the UP?
A bit of snow
Most of it went south of us.
heh - we've just insured a lasting drought by installing gutters :)
Oh that will do it.
last year - snowblower purchase = no snow, so I'm just assuming ...
That is probably pretty accurate.
I raked a huge mountain of leaves last Monday, and there is another small mountain-to-be in the back yard now....
damned oak trees
The wind will blow in circles now.
and of course it rained and drizzeled all weekend
You should be in the path of the snow we had the other day.
here too, until the gutter was installed
cleared right up
we've already had one snow that stuck
only about an inch, lasted a day or two
I've just started playing with halui. Interesting stuff. Easy to cause error messages.
what kind of errors?
I've noticed a couple of people having NMLish errors/warnings when messing with halui
I made a run button.
but you get an error if it is pressed while interp is running.
That sort of thing.
A dedicated operator panel will require CL.
and you don't get a similar error if you press a normal GUI's run button while the interp is running?
For example test for auto mode, interp idle, then allow run.
halui should deal with run modes, if it doesn't there's a bug
Yes you do.
oh, in that case ...
I see the pins. I just need to start a CL and do the logic.
rayh: did you just say that halui's behavior when you press run is exactly the same as say tkemc's?
Yes it seems to be.
well, it may make more sense to decide that emc should do something different when it gets a "run" command while already running
well, if tkemc is looking at the current mode, and deciding not to send a "run" NML when the run button is clicked under some conditions, then I think halui should do the same
That would be a possibility. If MDI run the currently active string.
if manual ...
But all of that can be a CL program.
I'm not sure that's the best solution
is there logic in tkemc/mini/axis today that makes those kinds of decisions?
I don't think any of that "mode" level of logic was ever put into the tickle guis.
the GUI should know when it should do things, not have CL decide what's OK
the "automatic" nature of AXIS is slightly outside the normal operation of the tk GUIs
since it doesn't require you to manually change from AUTO to MDI
when you said " just started playing with halui. Interesting stuff. Easy to cause error messages", I thought you were implying that things that don't cause errors when you do them on a normal GUI were causing errors with halui
No I just never pressed run twice from the mouse.
and you did with a real button? or you ran into switch bounce or something like that?
I just pressed it twice.
The bounce thing seems to be okay although I've not really tried to see a bounce.
I think Ray happened to notice an interesting error using halui - it's not necessarily a halui error
More like a long standing EMC issue.
I guess there's some question as to whether the "machine modes" make much sense nowadays
also confusion between "machine states" and "GUI states" (compounded when there are multiple GUIs)
the world view concept says the GUIs should track the machine state, not have their own
yep, but there's a race condition if it's considered an error for task to get a "start" command wehen it's already running
(assuming I've correctly named task as "emc" in this case ;) )
if a component of emc receives a command that is illegal in the current state, you have a dilemma
well, "run" when already running is arguably not an error
do you ignore it silently, or pop an error message
right - or just allow a run command when already running
s/allow/ignore/ I think?
I'm talking about defining it as not an error, vs. having the something ignore what it thinks is an error
Right. The tk guis do track state rather than some internal thing.
right, but if you have 3 GUIs running, there's a race between one person hitting "run", and having that state propagate to the status struct, and have all GUIs recognize that the machine is running
so two people hitting the button at "the same time" can be a problem
(on separate GUIs)
or even with a single gui, if you hit run, then hit it again before the message telling the GUI that the first command was accepted and the state is now "running" gets back to the GUI
task has to make sure only sensible state transitions happen -- and for the most part it does
When FredP and I talked about these issues, his opinion was that there would be one real GUI
others would display state and such.
but sometimes it issues error messages
I guess he turned out to be wrong ;)
Although that one operator panel could be passed around.
for instance, I think you'll get such an error message when you have the "two runs issued" condition
I wonder if it should silently ignore any message that says "do something that you are already doing"
at least within some time frame (though that can be complex to code, and may appear random to the user)
I bet some things are already handled like that - if you send a MIST_ON message, and mist is already on, does it throw an error message?
Things like multiple presses of "auto" mode does not raise a message.
nevermind the timer thing - it's stupid
Mist does not raise a message.
MIST_ON is defined as not being an error if mist is already on, I Think
I suspect that there are only a few NML messages that do.
SPINDLE_ON is differnt though, I think the RS274 spec says that is an error
So perhaps jmk is right that it should ignore it silently if it's already doing what the second command asks.
No message here with spindle forward multiple times.
hmmm - well, some G-codes are defined as an error of they're already "on" - I thought spindle was one of them
you sending MDI commands, or pushing buttons?
In the interpreter that is probably true.
I was using tkemc buttons and halui buttons.
the discussion going on in #emc makes me wonder
can we make it simpler to run multiple guis?
why shouldn't I be able to open N instances of tkemc on one box, or open tkemc, mini, and axis all at the same time
I've done each of those combinations in order to test the ability of each to track status.
you can load as many as you like with 'loadusr', but you have to take care of stuff like giving the path to emcsh when running tkemc, giving the -ini argument, etc., yourself
the emc script does that for the "primary" GUI I guess...
But recently it has gotten more difficult, hence the hack that jeppler sent me to get the second or third going.
But when we moved to the heavy use of environment variables we created some headaches.
that's what emc-environment is intended to cure
How do you use that script.
run this in your shell: . path/to/scripts/emc-environment
I get a you are supposed to run this command in a script rather than as a stand alone.
then for the rest of that shell session, you can run most all emc stuff without paths or environment variables
(there's probably stuff that doesn't work, but it just indicates items that should be added to emc-environment.in)
The exact wording is, "This script should be loaded in the context of your shell, ... not executed as a separate command.
if you use one emc2 directory all the time, then you can put the ". .../emc-environment" in your ~/.bashrc and it should work for all shells
Right, that's what the "." or "source" command does
This script should be loaded in the context of your shell, by executing
not executed as a separate command.
jmkasunich@ke-main-1006:~/emcdev/emc2head$ . scripts/emc-environment
first line was without the .
last line with, and it worked
if I can improve the wording, please let me know
or just check in the improvement
The command I used from emc2-head is . scripts/scripts/emc-environment
there should only be one scripts/ there, I think ...
two scripts/ ?
it should need only ... what SWPadnos said
then in the same terminal is tried tcl/mini.tcl -ini stepper_inch.ini
and jmk ;)
jmkasunich@ke-main-1006:~/emcdev/emc2head$ . scripts/emc-environment
jmkasunich@ke-main-1006:~/emcdev/emc2head$ type halcmd
halcmd is /home/jmkasunich/emcdev/emc2head/bin/halcmd
thats how I ran it, and the "type halcmd" shows that it is now finding the halcmd in my run-in-place tree
I just checked in a change to emc-environment.in. with it, I can simply type: mini.tcl -ini axis.ini
the path should include /path/to/emc2/tcl, which it doesn't
ok, it probably does now ;)
the existing .tcl script does something very bad if $EMC2_EMCSH is empty: it invokes itself over and over again
I'll get your revision later. Thanks jepler.
see you ray
see you later
hmmm - it may make sense to have some check for an empty EMC2_EMCSH in the tcl files
way ahead of you
as usual :)
Jymmm is now known as Jymmmmm
back home yet?
finally home ;)
glad to hear it
although it was quicker than I expected
have another system to commission by the end of the week though :)
but I shouldn't complain.. when there's lots of work it's quite good
it might snow here tonight but not much -- 1/4 inch, less than 1cm
I had a bit of snow on this trip
but back home it's quite warm
~8-9 C right now (0:34am)
Jymmmmm is now known as Jymmmmmmmm
Jymmmmmmmm is now known as Jymmmmmm
anyways.. nuff for today
good night all