jepler: took your suggestion and translated my test path to G18. AFU.
as in, the end of SNAFU?
yeah. it's apparent I tested on mill and did lathe as an afterthought
I'm tired of this project now, and it's only 98% done
how is offsetting supposed to work in G18/G19 anyway?
but, probably the number of lines of code that are wrong is very small
G18 is used for lathes
does it still use the radius, or does it use tool length (which I think makes more sense)?
makes no sense on a mill (IMO)
well, you could do pocketing - there would be a fillet at the Z -> X/Y junction
(ie, for doing X or Y slices instead of Z contours)
yeah I suppose with a ball nose mill there's some chance that you might be able to make use of it
some chance, yes
jepler: a long time ago you fixed a problem where make -j would run configure and make at the same time if configure is required. That problem is back again.
cradek: hm foo
by adding default vcp panels full of stuff, cmorley will give users a GUI that looks worse and works less well than AXIS
did I not imply that strongly enough?
I can't fathom why you'd want two DROs on the screen
I can imagine wanting a big-ass one visible when you're across the room
if that's the best we can come up to do with pyvcp as an example, it must mean pyvcp isn't needed by default
and also not having that always obstructing the backplot/preview
isn't the pyvcp stuff only included if you check a checkbox?
(which is close enough to default for those who don't read the manuals, and who want everything)
I don't understand that. I've run a machine a lot, but granted not professionally. I can't see why people think changing XYZ numbers tell you what the machine is doing. an "N" or line number readout, or % of this run done, sure. But XYZ? nope.
well, you have a point
having a well-motivated example would help me feel better about the feature
well lots of people think they want that.
but, I'm with jepler
it can be useful if you're trying to use the machine in a pseudo-manual mode
a "quill up" button is a very useful thing on a vcp panel
ie, as a DRO rather than a CNC position display
so is collet open/close, high/low gear
I can't think of much that will have a wide range of applicability
only a small fraction of people have automatic collets, gears, or drawbars
go to reference point
yes, and likewise, only a small fraction of people need vcp panels
a big (maybe full screen) panel with cycle start, optional stop, and some of the utility items you've mentioned, may be very useful in a shop environment
I don't deny that another gui might be better for some environments
it doesn't prevent people from doing bad things, but it makes it easier to do common things
yes, pyvcp and halui can provide some GUI functionality in some of those cases
oh, of course we have stuff like spindle speed display, load meters, and other things that may be calculated in HAL (and not part of the EMC status struct)
yes feedback spindle speed is useful
SWPadnos: and again applicable to a tiny fraction of stepconf users
nobody who is using stepconf has a "load meter"; that's a servo thing
I probably just don't share this vision of making stepconf do everything.
if it would do everything, then I'm all for it
but since it will only do a subset of some things, I don't think it's a good idea to bloat it out with frivolous stuff
maybe I'll say that in an email (nicely, of course :) )
well "all" you need to make stepconf do everything is have every person add his favorite thing to i
jepler: we could always change ARC_FEED(). nothing stopping us.
oh dear it's "we" and "us" now?
hey like I said, only 2% is left
that's only 1% each
or 1/2% if you can trick jmkasunich and SWPadnos into helping too
I better get started
despite my suggestion about passing the posemath arc structure through the canon call, I'm now only certain that it'll cause more short-term errors than it solves
(that's what we're talking about, right?)
you guys are a hoot
oh hey skunkworks is going to chip in too
right - I am sure I would be able to make a mess of things.
if that's the goal, I bet we could find a lot of people to chip in
make a mesa of things? you mean pcw will help too?
'my' arcs in 'my' machine control program used sin/cos and deg to create them
he hasn't noticed that you need machine/relative in addition to inch/metric to make the display match the internal one
and of course if you use a scale block, it'll be wrong for one of inch/metric ini machines
I start small and work my way up :)
we were just talking about you!
yes I just read that
it came about from this in part I bet http://cnczone.com/forums/showthread.php?t=60199
are you here to help mess up arcs too? we have several volunteers already.
arcs are over-rated - just tell everyone to use short line segments.
What are you doing to arcs? lol
one of the internal representations is kind of bogus, and as a result some code is overly complex, and we are limited to planar arcs
but if we change it, we'll break everything, of course
chester88: I was just trying to compose an e-mail about the example panels -- I think that the examples need to not duplicate functionality that's already in AXIS. No DRO, no "cycle start", no "block delete" -- axis does all those things.
of course all great things break something else
well I common question is the addition of large dro. What do you suggest as an alternative example?
cradek: I thought the lower level arc creation wasn't constricted to planes.
I was thinking of it like this: I know what I want on my machine's panel, and I have that. What would make a great sample panel is probably different - how to pick?
The idea is to show a working example of something - anything so people can see how it was hooked. The large DRO was requested alot so i think that was a good example
chester88: like I said earlier, a panel is most useful for odd extra features on complex machines - people with simple stepper machines (stepconf's target audience) just don't need it
I haven't come up with any examples of things that I think more than a small fractions of users will need -- because I put all the things I think large numbers of users need in AXIS already.
chester88: I think that's why I can't come up with a good idea for what the sample should be.
all the pyvcp panels / ladder are optional no one has to use them
people will always turn on checkboxes that talk about enabling features :-)
I'm not saying that I am categorically against stepconf helping a user add a panel
the examples are NOT default
I want any examples to be good examples
jepler: but that puts you in the unenviable position of recommending good examples
no problem I think I asked of ideas
I really don't see the problem with big dro- or the program control buttons (they are hidden in AXIS)
do you need me to put arrows on a screeshot for you to see where AXIS dro or run button is?
but whatever example you guys want I will include
i did not have run or stop buttons
i had resume pause and step buttons
oh, sorry, it says "pause", "resume", "single block"
the dro is too small IMHO
but to make it begger screws up the drawing screen
the fix for "the dro is too small" is not "one small dro and one big dro"
its a compromise
well I can not turn off AXIS's dro :)
compromise means everyone is unhappy
we need a different GUI for people who want big numbers
actually, there are several already
It is just an option
I agree making it really big screws up the preview screen
that's why I made the "bigger" option, but it's not so big it gets screwy looking
IMHO most people are going to use AXIS because it has the most current features
I also agree with that
I understand that. Thats y a dro on the side works too
maybe we need maintainers for the other guis
Tkemc sounds like it is used fairly often too
that was until a few years ago the most up-to-date gui
so, many people got used to it
ya i'm sure
it has fallen behind because nobody is keeping it updated
but, it sucks for a touch screen
they all suck for touchscreens
not everyone will be happy with any one gui
all the buttons in axis are too small, because they're the right size for mice
the point is you guys dont like the big dro on the side but if some people want it y can't they have it?
we could force everyone to be happy with one GUI by removing all the others
ya that was a complaint i heard thay AXIS use a mouse too much
chester88: we never said people can't have it. we did say it's a bad example.
chester88, they can have it, but as you noticed, it's not a simple change
lol that would work!
since as you noticed, the position displayed by AXIS isn't available outside of AXIS
SWPadnos: the other bad solution is to try to make them all converge until they each satisfy nobody
ooooh, that sounds buzzwordy even
the only things I'm aware of in axis that aren't keyboardable are manipulating the preview plot and scrolling the program text
well that is a black or white argument
SWPadnos: that's what I'm afraid of happening, to be honest
sure, I don't advocate doing that
is it possible to write a python userspace module that has access to AXIS internal variables and sticks them on HAL pins (if one wanted to do that instead of modifying AXIS itself)?
(ie, does python allow for sharing of environment similar to tk?)
SWPadnos: no, your python userspace module would live in a different address space than axis
could AXIS not just export some status pins?
axis already has some hal pins related to jogging
it could, but if your main intent is to duplicate features that AXIS already has, I think you'll find resistance to including those changes
so you will impose your ideas on other people (i don't mean to be impolite just clear)
in areas that I believe are "mine"
by adding some pins allows those who want to to have things different good or bad. kinda the same thing HAL does.
hmmm well that shuts me up :)
chester88: I see two different goals here. one is to get bigger numbers. another is to make sample panels. I think a better way to accomplish goal #1 is to find a good proposal for fitting that onto the AXIS screen in a way that doesn't make it look bad (your words) and also doesn't cause a pain in the neck, like the scaling/offsets that you would have to somehow rebuild in HAL
speaking of which, what's an icon for "optional stop enable" look like?
I can't speak for jepler, but maybe there is a way to get (even) bigger numbers other than putting them in a panel to the right. when you do that, it looks bad (mostly empty) so then you want to fill it up with other stuff (reproducing other controls) and then we have an abomination (just my opinion now).
jepler: hm, good question
(that's at least 85% of the reason that "optional stop" is stuck in a menu, to jump over to another of the items we're debating)
maybe part of it is "M1"
I'm stuck with the pyvcp option that are there for justification. the buttons are there for examples of using halui.
don't get me wrong if I can make it prettier i will!
huh there's tool_optpause.gif
I tried the larger DRO option in axis. It is still not big enough IMHO
I like the "quill up" and "go to reference position" buttons. they give useful functionality that AXIS doesn't have by default
date: 2006/10/29 20:48:02; author: jepler; state: Exp;
optional pause toolbar icon
well so much for 85%
ya they are examples of MDI commands
maybe it would be nice for AXIS to have a toggle between the preview panel and a bigass DRO
actually toggle buttons that change colour/ lable when pressed would be nice
SWPadnos: another tab??
I don't think a tab, but maybe
more like a menu option/button to change modes
3D vs old-style (but nig) :)
when running, the manual tab is entirely greyed out
oh hey Jeff did you write the pyvcp tab code?
how do you use it?
isnan error in emcTrajCircularMove
chester88: I dunno; I may have
John T said you did...
chester88: try this, I dunno if it's right: http://emergent.unpy.net/files/sandbox/tabs.xml
i was reading the source code and cannot figure out how to specify the tab names
it's an old file on my webserver from 2007
I will try that....
jepler, how hard do you suppose it would be to make it possible to put pyvcp panels on the top/bottom/left side of the AXIS display?
(not necessarily at the same time, just an option as to where to put it)
SWPadnos: not sure, I'd have to look
ok - no rush
the reason for my question is that something like a DRO, which is inherently short but wide "looks bad" when on the right side due to all the unused space, so it occurred to me that sometimes a row of buttons or words is a better format than a column
EMC: 03jepler 07TRUNK * 10emc2/share/axis/tcl/axis.tcl: put 'optional pause' on the toolbar
(actually, a DRO is normally a rectangle that is much smaller than the whole AXIS display, but it could be done as a single line with three ordinates instead, on the top or bottom)
SWPadnos: left = not easy (it goes in a widget laid out on a grid, 0-based .. you have to scoot everything over)
ah, so bottom or right are easiest
jepler yes that is the right syntax for tabs - I will relay the info to John T (he is adding to the docs) Thanks.
-f.grid(row=0, column=4, rowspan=6, sticky="nw", padx=4, pady=4)
+f.grid(row=3, column=0, columnspan=6, sticky="nw", padx=4, pady=4)
^^ this switches it to the bottom, between the program text and the status bar
I'll think about whether it's important enough to add an ini setting for that :)
[02:14:44] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/vcp-side.patch
oops I just put tabs in my py file
er, mixed them anyway
ok I was trying to think of an example of wanting AXIS's X Y Z read out (besides just a bigger DRO). On my lathe's operator panel there is a ( PIXIE ) display for position / offset etc (you select with a rotary switch) If I want it to display what AXIS displays it would be nice to have a pin coming from AXIS with this info.
so PYVCP_BOTTOM just needs to be set to anything, and the panel will be on the bottom?
SWPadnos: yes, if it's not empty
I guess technically you could use two vcp panels, one on the right and one on the bottom (without changing the numbers)
row/column in the grid call
it's still row 3 for the bottom, and it's still column 4 for the side
what I'm unsure of is what happens if you call vcpparse stuff twice
yeah, good question
I was forgetting that the two panels would be in the same execution space
would you mind committing that change, or do you not like it? :)
chester88: it's true that displaying the offset currently in effect as a number is something axis doesn't do
I don't see that halui exports this value; it certainly is worth adding to halui
I would also need a way to know it the number is metric or not (to use it on my operator panel)
you mean you need to know the inifile's units?
no would need to know what units the GUI was displaying at this time.
if in AXIS i select metric the the operator panel should display in metric
hold on a sec. there are several things going on here
1) you want a demo for pyvcp, for stepconf
EMC: 03jepler 07TRUNK * 10emc2/share/axis/tcl/axis.tcl: remove debugging statement
2) you want a large DRO for those users who like that idea
3) you want an externally accessible set of position indicators, so you can hook up an external position display (VCP or physical panel)
is that a reasonable summary of the goals?
personally, I think those are separate items, which should not be confused/combined with each other for the purposes of this conversation
regarding #1, I don't know of any really good use of pyvcp for the intended stepconf audience
That is the first problem
I tried to think of some uses, and as it turns out, they're all useful only for machines with feedback and servo machines
the only thing that seems like it could be used is a spindle RPM display
(and associated items, like a pseudo-load meter)
since stepconf supports spindle feedback setup
your intended audience is not what you intended
well, yes and no
well yes :)
hold on - let me finish :)
it would be very nice if someone could use a program like stepconf to configure their basic machine
I can get on board with #3. It's reasonable to want the units displayed in different places on the machine all change together, and having axis export its current "mm/in" selection would let axis be the driver of that. I would accept a patch to add that. Have a look at stuff related to jog.increment in axis.py
regardless of the hardware driver used - so you could select "mesa" or "USC" or "STG" and do some basic configuration to get your machine running
at the moment, you can only set up step/dir machines that use the parallel port
with you SWPadnos
(or multiple ports now, thanks to your effort)
but that's a much more complex program, with many pitfalls
(for instance, PPMC detects hardware at load time - how would
how would "ppmcconf" be told what hardware to expect and where to expect it?
mesa is so configurable, a configurator makes my head hurt :)
much harder program yes. Well mesa it is now lol!
so there's a long way to go to get to a tool that just makes basic machines work for most people
but to get there you have to take some steps
I don't think stepconf should be that program
ok let me tell you the whole deal behind this.
hmmm - if you don't mind, I'd like to say one more thing first ...
I think stepconf is incomplete, even for the intended target audience (leaving aside who the actual audience is :) )
what you have added - ladder / estop config, and a couple of other things, make it more complete
well, estop was one
there are still a couple of things that should be added, like maybe a simple ladder/HAL block for controlling a spindle brake
(I think brake output is one of the pin options)
but once it makes a config that a reasonably intelligent user can tweak for their machine (brake delay time, for instance), I think stepconf is done
and we should then concentrate on making a more complete configurator
without messing up the simplicity of stepconf, which would still be less confusing for a user who just wants steps to come out their parallel port
(OK, I'm done now :) )
since Stepconf is the only way to setup EMC (for step machines) semi automatically everyone uses it
then when they want to do a little more they tinker with it to try to get say ladder or a pyvcp panel
the advanced page was intended to help then see get though things rolling using a fairly general example
sorry i should proof read...
For instance I helped a guy add a pyvcp panel that had a button for tough off.
ok, I understand that intent
y I thought you did :)
it used ladder halui with MDI commands
right - I don't think there's a HAL way of doing touch-off
(other than halui and an MDI command :) )
it took I think a week (this is through email while I was on vacation mind you) just to help him get classicladder to load properly!
now he can click a tab and CL loads and he can figure out how to build a ladder program and since the estop program is in on the wiki is can follow that to see how the whole thing works
people work in steps like that.
eventually they won't nee stepconf at all but I bet they would use it anyways
unless there's a more appropriate alternative
yes I agree!
(no, I'm not suggesting vi :) )
but I would think a new one should follow the same style if possible as people are used to it
but here's the thing - you didn't make the classicladder checkbox put up something that isn't useful - it just gives a blank ladder that can then be edited
for pyvcp, maybe spindle speed or a velocity meter would serve as a "nearly blank" slate to start from
no check the estop program and it loads
ok, that's different
and hooks to HAL
that's a place where there is a need for a function to be completely supported, where it was kind of partially supported before
ie, you could have an estop out, but it didn't necessarily work right for some common stop setups
in fact, I could use that for the G540 config :)
oh i see
well you can edit the ladder program now :)
there's an estop component, but it doesn't seem to do quite the right thing for machines that have an "OK" output that isn't dependent on EMC being ready
not me, I never learned how to use CL :)
(that editor always bugged me, but maybe I should look at it again, now that you upgraded the CL version)
ya actually the program as is has three options all you have to do is more a 'wire'
anyway - back to the argument~Wdiscussion :)
a blank CL makes sense, a CL that does something useful makes sense
anyways the point was to have a fairly common/useful example
ok same deal with pyvcp and halui
in my opinion, it's good because it completes a function that was incomplete before, for a reasonably large class of machines
well, now that you added additional parallel ports, halui can actually be useful
there wasn't much need for it before since the parallel port has such limited I/O
you bet I would like to add function selection to the other ports but I wanted to stop before i got to far
a big DRO as a VCP demo is also OK, but it doesn't need to be perfect if it's only meant to be a starting point for someone to put in whatever it is they really need
in case there was a revolt
what gets lost by adding all this great functionality is the simplicity
this is my machine name. these are the numbers I read out of my manual
this is where stuff connects
well yes and no just don't click the check button!
save / run
having 100 extra checkbuttons is also complex
(I know - it's only 3 :) )
k i was goinf to say that!
note how many people use Macs because they have a simple, uncluttered interface
it's not because they work better or faster or have software you can't get elsewhere, it's because they're less confusing for a lot of people
ok so whats important to understand is i didn't make the dro cause I think I know how to make a better GUI.
It's just what people wanted and so was a good example
hmmm. one sec
just would be WAY better if it switched to metric when AXIS did
what if the user prefers tkEMC?
it has auto, inch, mm, and cm options
which incidentally won't change when you change AXIS, if both happen to be running
(not that that would be a commonn stepconf config, mind you)
then it should export those pins too. Actuall Tkemc is quite far behind AXIS
tkemc has no HAL pins
another thing to note - AXIS won't have any HAL pins if you run it remotely
yes not too many novices could get two interfaces running!
what does it do for it jogging pins when it's remote?
Jeff mentioned the pins
it doesn't export them. it can't
you have to specify an ini or environment option in that case AXIS_NOHAL or some such
so it you use it remotely then you understand you lose some functionality
yeah, sort of
but gain remote ness :)
I guess my point here is that a demo that you expect the user to change doesn't need to be perfect
having a DRO available to HAL is nice, but it shouldn't depend on AXIS
the only other way would be to have AXIS send stutus on say metric display over NML?
so they're separate questions IMP
ya I could live with the non perfect demo.
there is no reason to do that, since displayed units are a display option, not a machine state
the other thing is, what if you want to see position in multiple units at the same time? :)
AXIS does complex stuff to get that display right. if you really must have an external display, you should export the numbers on pins, not a bunch of states
then i could scale relative position to any thing I want
I agree - that eventually what I suggested
actually, the motion controller should export those, or there should be a separate module that any display program (including AXIS, halui, whatever) could connect to to get that "cooked" information
hmmm - maybe not the motion controller, task or something
AXIS export status and XYZ position on pins
ok but I want to know what AXIS is displaying (metric or not ) not what EMC is using
that's what I was talking about
what you need is the current location, in some units
units can be scaled in HAL by using a scale block if necessary
ya HALUI is kind half way there....
but gets no information from the display program of course
could that be done?
and that's the crux of the problem
you would have to use NML commands ?
NML, shared memory, or HAL would seem to be the obvious ways
HAL being one form of shared memory
NML goes over a network right?
or shared memory
no then a remote HUI could still tell me it's displaying metric
this is where my resistance to changing AXIS for the pyvcp sample code comes in - it's not as simple a problem when you consider other valid uses
I agree but If I don't ask the subject doesn't come up. Not to mention I don't get to think of all the problems
it is an interesting idea though, to have display "commands" in NML
this has been very informative
yes I think It would be good
at the moment, any attached displays take their data from the status and error channels, but there's no well defined way for multiple UIs to interact, if that's desired
they only reflect things done in other UIs because the EMC state changes
it sounds like you are trying to put two things that are 180 degrees apart into the same place
hmmm yes you would have to have a way to say i'm AXIS and I'm displaying in metric
maybe only 179 degrees
the original (pre EMC2, pre HAL) architecture of EMC (which is very well thought out IMO) treats each GUI as completely independent
if you want to have two copies of axis and one tkemc, all at the same time, and have one axis displaying mm and the other inches, you could
they were not coupled to each other in any way, they were ONLY coupled to task thru NML
yes i was just trying t find a way connect to a gui and find out some info such as metric display or not
pyvcp is meant to simulate physical indicators and switches, halui is meant to use switches and indicators to control EMC, and neither is meant to talk to another GUI directly
halui is "just another user interface", intended to allow PHYSICAL buttons and displays to interact the way that axis/tkemc/etc allow on-screen ones to work
ya I would want all the GUIs to have to display the same
chester88: I understand what you want
and I'm saying it is 180 degrees away from the NIST philosophy that underlies the emc architecutre
why should independent GUIs have to use the same units?
I never said it shoud
I think it might be desirable sometimes, but I wouldn't want to force it
[22:19:04]<chester88>ya I would want all the GUIs to have to display the same
chester88: 1 minute ago: " I would want all the GUIs to have to display the same"
I'm wondering if ther's an "'nt" missing there
it's like how axis lets a hal component snoop which axis is selected in it: it can lead to better integration between the real panel and axis, according to the integrator's wishes
i'm a bad typer
jepler: the axis hal pins are were the camel's nose under the edge of the tent
now the rest of the camel wants in
and now the camel is spitting at us
I'm not dead on always keeping the original philosophy
well, consider the idea of adding a "display status" NML (or other :) ) channel
with mesasges like "jog axis Y selected"
but if we make such a fundamental change, it shouldn't be by camel nose, or by ad-hoc "somebody wants a bigger DRO, this hack looks like it might work"
or "display units = mm"
this is an amazingly roundabout way to change a font size
well thats why we are talking about it :)
anyone that wants to follow what other UIs do can listen and update as necessary
HAL was certainly never intended to be a way for one GUI to tell another GUI what units are in use
halui isn't supposed to be a "slave" UI to axis either
halui is an INDEPENDENT UI that lets people use physical buttons
how about a independant electrical display?
btw, if you do want a really big DRO, and you are determined to use pyvcp to do it, why not put the neccessary pins for DRO values on halui, and then use a separate pyvcp window to display the numbers?
that wouldn't track display settings in AXIS
(in the jogwheel example it's not even halui, it's talking direct to the motion controller which is probably another violation of nist principles .. but it works smoother)
I consider the jogwheel to be a motion control accessory, not a GUI accessory
the jogwheel interface to motion was designed with physical axis-select buttons next to the wheel in mind
allowing axis's active axis to be the jogwheel active axis was a later change (the camel nose I was talking about)
this is where a "reverse NML channel" could make sense
ie, status coming from the display(s) and going to task/motion/whatever
I wish I was an artist -- I'd draw a picture of me typing on a QWERTY keyboard on the back of a robot, whose arm is reaching out to type on the actual keyboard
I can certainly get behind the idea of GUI <-> GUI communication via NML
al la Robert Tinney and his Byte covers?
one of those GUIs would be halui, and that would be the only UI that would have hal pins
that sounds good
in a way, this is a lot like the joints-axes mess
NIST designed something extremely general and flexible
99.95% of users used trivkins
and mostly implemented it!
people started thinking of joints and axes as the same things, because they only used trivkins
that would allow a remote GUI to have pins (thru HALUI)
and things started to rot
I don't think so
SWPadnos: why not?
oh, unless I'm interpreting that sentence wrong :)
push an axis select button, say "X", on axis
* jepler calls it quits
"selected axis is now X" goes thru NML, all GUIs become aware of it
HALUI would have HAL pins on the EMC machine, and if it's set to track the settings in a remote UI, it would be somewhat equivalent to having HAL pins on the remote UI
halui is included in "all GUIs", and sets the pin
see you jepler
yes that seems best
now here's an interesting question: can there be multiple writers to an NML queue?
I know nutink about NML
I guess there can, since multiple UIs can be run simultaneously
that makes HALUI the only connection between HAL and A GUI the way it should be
halui isn't a connection between hal and a UI, halui IS a UI
k i follow that
ok, so I think the only possible NIST violation here is that commands flow down and status flows up (in the ISD model)
in an ideal world, you could build an EMC machine without a display, and use 7-segment displays and pushbuttons for everything, using halui + hal + i/o pins
Hey thats my Okuma lathe!!
one line of display
we'll never get that ideal I don't think, since one important UI function is selecting the g-code file to run, and that is hard to do with 7-segments and buttons
that's the idea :)
I think halui was made so people could do things with their existing panels
that aren't HAL functions - like cycle start
the alternative (which people have done) is to start soldering wires from your oiltite buttons to the switches on an old keyboard
pendants and hardware panels are the reason for halui
ok, so I think the (more or less) consensus here is that it would be nice to fix the display rpoblem forever by adding a communication channel for UI related status/commands, right?
thats what i was thinking
I think it's less ugly than using hal to talk from one UI to another
I'm not sure it doesn't have its own ugliness that we haven't thought about yet
and then we can theoretically remove HAL pins from AXIS, add some functionality to halui, and do lots of work in the meantime, to make a happy world
well, for people with multiple UIs anyway
thats really the issue here - the old 99% thing - 99% of people are using one UI, and want it to be the "one to bind them" - when they hit X, they want the jogwheel to move X, when they select mm on that GUI, they want the nixie tube DRO to change to mm
the other 1% really do want two independent GUIs, complete with one set to mm and the other displaying inches
that's mostly true
if you are in the "one to bind them" school, it makes perfect sense to simply export the DRO numbers out of axis on hal pins, for the Nixie tubes, or for big pyvcp numbers
yep, but that's ugly IMO
I don't think AXIS should be the center of the universe for that stuff
I prefer the HALUI idea you came up with then people can do what they want
with whatever GUI
since e.g. your halui setup will break if you decide to switch to tkEMC or something else
it sounds like what we are talking about is a central (task? elsewhere) "GUI state" thing, that can be accessed by NML
older GUIs would ignore it (unless somebody gets around to updating them)
newer guis (basically axis and halui) would optionally get and set info there
that way, if you have two instances of axis (maybe on the main PC, and on another computer), you could either have them be independent, or you could make them track each other
that would be perfect - is it possible?
no idea - I don't do NML or GUIs
I just talk a lot
it's potentially a many-to-many channel
I think that should work, but I'm not sure exactly how
what kind of things would be in this GUI state
no, I think NML needs a master / slave setup
how does it work with multiple GUIs? (we know it does work, unless we have horribly rotted something)
since each channel is command / status / error, and the directions for those are explicit
all the GUIs are "masters"
they send commands and receive status and error
so there is one channel per GUI, all connected to task
I think there's one command channel, which all the GUIs connect to, one status channel, and one error channel
so any GUI can send a command, and all see the same status and errors
recall the recent list discussion about emcrsh not getting errors that were taken out of the queue by the local UI
that's also where we ended up with lots of sequencing issues with halui way back when
ok, so we're not really changing the flow of data as much as we are considering a redefinition of where the GUI / control line of demarcation is
since "wait for command complete" translates to something like "wait until the last executed command has the right serial number" or something like that
today, DRO values, display units, active axis, and a number of other things lie on the GUI side of the line
(I don't have a complete understanding or memory of that problem, so take a few grains of salt with this :) )
you and I are taking the conversation in different directions anyway it seems
hmmm. yes, I guess there could be a UIController
like iocontrol or motion, uicontrol would exist simply to convert incoming "commands" into changes in status
(I mean like io or motion in the sense that it's a - what :)
you are jumping ahead in to implementation
sort of (implementation)
got excited there hey
when we (or at least I) am just barely getting my head wrapped around the issues
I'm thinking that NML is the "easiest" thing to use, since it's already in use
and that made me think of NML-related issues as well
"thing to use" = implementation. Stop! ISSUE: DRO, display units, active axis, etc are currently defined on a PER GUI basis
that was a deliberate design decision
ok, continuation: some users would like those settings to track across multiple UIs
now we are talking about (never mind how) making those things be a single global status
no, that's implementation as well
"track across multiple UIs" = "global" (not in the programming sense, but in the "multiple DROs can issue commands to change the display units, and all DROs use the result of the most recent command
single global status is differnet from globally accessible changes
lets be perverse: assume 4 GUIs, call them A, B, C, and D. They may be multiple instances of the same program, like axis, or they may be a mix of axis, tkemc, halui, and another axis, or whatever
we are thinking that an integrator should be able to track some information from any/all GUI using hal
and should be able to tell any all gui some info from HAL
not susing HAL, this isn't hardware related
k well it has to go to hal a some point is what i mean
using some means of communicating with a central repository of display data or settings
I don't follow
that's only necessary for the HAL user interface to work
still being perverse, assume that the user/integrator wants A, and C to change display units together, and B and D to change their units together, but independently from A and C
(so it would happen, but it isn't necessary)
ok, the perverse case is too perverse ;)
no, it isn't
simple things should be simple, complex (perverse) things should be possible
today, A, B, C, and D are completely independent
if we are going to introduce coupling between GUIs, we should do it in a way that lets the integrator decide which UIs are coupled and which are not
so A GUI would have to have a way to be told to track C
and vice versa
all that tells me is that the cimmunication method has to allow for multiple independent channels
if I'm sitting at A and hit mm, I want C's display to change
if I get up, walk over to C, and hit inches, I want A's display to change
so you need a slave component that keeps track of where everyone is and all the GUI poll it?
if I was happy with just coupling A to C, and having B and D both independent, that could be done with a central state - A and C would both read that state (so they display the same) and write it (so commands issued at either would affect both)
when I get perverse and say that I want B and D to track each other, and A and C track each other, the single central state idea collapses
who knows, maybe that case is too perverse
but if you have a central way to know what status on all the GUI and each GUI polls it to see where it's sister is at- does that work?
only if every GUI can talk to all other siblings
I am equally perverse, but I want 37 UIs to all track each other
so every UI needs to be able to talk to at least 36 others for me :)
no the GUI would only talk to the 'central slave' that keeps track of all the GUIs
chester88: thats why I came up with the perverse A=C, B=D, A != B example
a central slave can't do that
sorry, I want 37 UIs that track, and two that don't :)
if the slave has independant info for GUI A B and C and A polls the slave to see where C is and vice vers and B doesn't track anything
chester88: in my perverse example, B wants to track D, A wants to track C
no one slave can achieve that
sorry I don't follow I must be missing something .explain more about your central slave.
I can actually think of a situation where you might want 4 UIs active - on a big lathe with two PC displays, halui for extra buttons, and a remote shop foreman with a display
not my central slave
chester88: you wrote "no the GUI would only talk to the 'central slave' that keeps track of all the GUIs"
there are two basic ways to do this: one is to have a single source of information (position, units, world/joint mode ...)
the other is to have communications channels that carry messages like "changed to mm display"
we already have a single source of MACHINE state information
now we are talking about GUI state information
which almost by definition is local to each instance of each GUI
another issue that we are neglecting - the collection of data that is a GUI state is NOT the same for each GUI
so you can either add a new "static" data source for each possible display configuration (many of them)
tkemc has options (and state) that axis doesn't, and vice-versa
or you can send notes around to change things, and each UI can choose to ignore some or all of the notes
it sounds like we are trying to figure out how to distribute GUI state data between an arbitrary number of arbitrarily incompatible GUIs
it sounds like we are insane
I'm thinking more like a defined set of message "tags" and treat it like HTML - ignore any you don't understand
and optionally ignore others, unless configured not to
but if a single component kept track of the states of all GUIs then anything could ask the component "what state is AXIS 1 in?'
you are discribing one possible approach to attempting the insane task I described
that only works if you want to require that all UIs use the same settings
I'm questioning the sanity of _any_ attempt
which may not bepossible, unless you have a lot of instances of the same UI
chester88: any one "thing" that could keep track of the internal state of tkemc, mini, xemc, axis, halui, and lord knows what else would be a nightmare to write, and even worse to maintain
oh - ok. that central component would have to be able to track an arbitrary number of UIs though, to make me happy :)
someone should be able to add a feature to axis (which might include some internal state) without having to update some other thing
and where do you draw the line
well i guess it depends on how much you want to keep track of too
if you have two instances of axis, and you pan the preview in one of them, do you want the other to pan as well?
I think there's a reasonable subset of UI options that could be useful to ship around between UIs
JMK I don't think so
actually, it may boil down to just DRO related items
chester88: the very fact that you said "I don't think so" instead of "hell no" or "hell yes", points to the problem
I'm not sure what else would be common across UIs, and/or desirable to change automatically
IMO, the answer (re panning) is hell no
but the very fact that we might disagree points out the problem
yeah, or "clear backplot", or changing the window size ...
Well that was my thought
i just didn't say that
your thought was "hell no"?
why didn't you say so then?
I asked the question to point out that some things almost certainly don't want to track
like swp just said - clear backplot, or resizing/moving windows
heh. I thought he just said that his thought was that the problem is that different people might have different thoughts about what's necessary/desirable :)
wow lol gotta read that twice +
though it would be cool for a user to be able to hilight a line in the preview and have it show up on his boss's PC :)
lets back up a bit
this started with the case of ONE instance of ONE GUI
in that case, it is natural to think of that GUI as the "master"
then someone wants to add a DRO
so it is natural to think that the DRO should display exactly what the ONE master GUI displays
if we look only at that problem, then it seems that one master GUI should have hal pins that have the actual DRO numbers
not units, not offsets, not relative/abs or machine/world/part coords, but the actual DRO numbers
then you route those numbers to nixie tubes or pyvcp or whatever
that would be the easiest for a single UI
I don't see how halui would be involved in any way at all
(assuming that the master UI is running on the same PC as HAL)
as soon as you add halui into the mix, you no longer have one master GUI, you now have two equal GUIs
SWPadnos: as it would be in the simple user case
it was involved because at the moment it was the only way to get the info I wanted
chester88: how so? at the moment there is NO way to get the info you want
well not perfectly HALUI has a relative position pin
that's where things went wrong
halui does export position
it is in machine units of course
it just doesn't change units
don't take this wrong, this has been evolving
but what you were proposing earlier was basically: add a pin(s) to Axis with info I don't really want, so I can use that info to manipulate other info from another UI that I don't really want, to make what I do really want
but axis already has what you do really want, the DRO numbers
if you're gonna add pins to axis, add the DRO numbers, don't use halui, don't screw around with scaling, etc in hal
I said that in my email
which one ;-)
put the displayed data on HAL pins
I tend to agree. Actually if AXIS had a pin such as:
then I could do the conversion with a scale component
Or if AXIS had a pin that had X Y Z etc 'displayed value'
then I could use that directly (even better)
those lines are from the email
you put the icky solution first, and the right one later
almost as an aside
yep a wrote as i thought of it
next email: In this case I want a way to display what AXIS displays in X Y Z
I don't care if HALUI gives me this info or AXIS or any other way.
Whatever makes the most sense.
3 hours later, we are saying the same thing
it's kind of an abomination for a UI to export HAL pins (other than halui, which exists explicitly as an interface from physical hardware to EMC control functions)
SWPadnos: yes, 2 hours ago I agreed with that
I think that's why I responded negatively to either suggestion
but what we were migrating too was more of an abomination IMO
it's an abomination, but it is easy :)
well, I don't think so
using a remote interface is useless for 99.9% of users, but absolutely essential to the other 0.1%
so for most people, NML is an abomination (programming complexity aside)
I think configuring multiple GUIs so that some track others (for some features, but not others), and others are independent, etc, will make configuring hostmot2 seem like childs play
lol you are right!
SWPadnos: remote GUIs are important
well, one implementation that isn't too hard to do is to make a ui thingy that connects to EMC status via NML
and connects to one or more UIs via another NML channel
but is it important that a DRO on the host machine can track a GUI on a remote machine?
it may be
I can't say for sure that it will never be important to anyone
consider a nixie tube display on the machine, which is run from a headless PC and controlled by remote AXIS
this is chester88's scenario
minus the remote axis
I switch the display in AXIS, and I want the tube display to change also
instead of me having to go flip switches to match
no, not necessarily
headless controller in the cabinet and a PC connected via ethernet, but still on a "pendant" by the machine
chester has never talked about headless or remote GUIs, and stepconf doesn't support remote GUI configs
stepconf is only one of the 3 questions being discussed
I think we're agreed that the placeholder/example for stepconf doesn't need to be perfect
understood, but my understanding was that this whole discussion was in the context of making it easy for stepconf class users
well i would like it to be but could live with it not.
no, that was the start, but it's multiple questions
making an easy VCP DRO isn't that useful IMO, but putting something that people understand in the sample that stepconf creates is useful
stepconf was what brought it up but it has morphed
and numbers that change when the machine moves are easy to understand as an example
yes that was the point of the example and it was something that people have asked for.
after just a little discussion, I still don't think pyvcp is all that useful for most stepconf users, and a better example might be spindle speed (since stepconf can set up spindle feedback)
but that's another discussion
there is a spindle speed example
oh, then use that! :)
i have both
both options in there
yes, got it
if you really want to do people a service, then you should take advantge of the fact that you have two pyvcp examples
make the DRO one use a separate pyvcp window, instead of tacking one onto the side of Axis
I have not heard anyone ask for a vcp panel dro. I *have* heard them ask for a larger DRO.
DRO displays tend to be wide and not-too-tall, the panel on the side of Axis is tall and narrow
certainly nobody has asked for two DROs that don't agree on units or offsets sometimes
and you or jepler (or both) gave them a larger DRO
there was a separate DRO made, but it still wouldn't track AXIS' display settings
but people try to help, and the hammer they know is vcp, and so this is a nail
and someone(s) said "still not big enough, give me MORE!!!"
back to what I said two hours ago: this is a crazy roundabout way to get a larger font
is the DRO the only thing that would be useful for UIs to talk to each other about?
the only reason I'm not calling it totally stupid is that in theory the hal approach could be used to drive 7-segment displays (or nixies ;-) on the actual machine
SWPadnos: that depends
the nixies should have a little silver units toggle switch next to them
yeah, that's why I'm asking :)
if you have two GUIs on the same machine, for a single user (as opposed to one in the bosses office), then it might get annoying if you set units, relative/abs, etc on one, then have to screw around making the other match
cradek: IOW, halui should have DRO outputs, and a units input, all pins
and forget about it tracking the Axis DRO
sure, that's how halui works
does it already have DRO outputs and units inputs? I think it only outputs machine units
I want to have a chicken-head knob that switches the nixies between X,Z,N,F,S,T
AXIS doesn't/can't have that
N F T - don't know those
halui doesn't either, but can
it's just inappropriate to dump the guis together and stir. they can be different.
oh, I know N and F
oh, and T
I think it's a misconception to think that letting UIs talk to each other somehow makes them the same thing
there is one use case, unrelated to hal or nixies, where tracking might be a nice feature
two instances of the SAME gui might benefit from tracking
if you have a screen at the tailstock and and another at the headstock end for example
SWPadnos: I guess you may be right
it's remotely possible (but only remotely :) )
but if you limit it to instances of the same GUI (no tkemc tracking axis), then it can be done as a feature of _that_ GUI
the HTML model makes a lot of sense there
browsers are supposed to ignore tags they don't understand
if jepler/cradek/someone wants to add the ability to open another NML channel (or any other method) between two instances of Axis, and sync those instances they can
and all those changes would be contained within axis
if you have a big vocabulary of UI settings that can be passed around, then UIs that care can act on those they understand, and ignore those they don't
that smells bad to me
they can also ignore ones they understand, or not connect to the message pipe, if you don't want some instance to track any others
hmmm - why does it seem like a bad idea to you?
(if you can identify the problem(s) )
EMC: 03cradek 07TRUNK * 10emc2/src/emc/rs274ngc/interp_convert.cc: only the tip of the iceberg for fixing concave corner lathe arcs, I'm afraid
uh oh :(
the idea of trying to make a vocabulary that is even remotely suitable for two vastly different GUIs makes me shudder
if you wind up with each GUI only understanding its own messages, and ignoring those from other GUIs (except maybe for a very small subset that is truly general to all GUIs), then your cross-gui syncing won't work worth crap anyway
I think there's a small subset of things that might want to be synced across dissimilar UIs
I should just stay out of the gui syncing part of this - not my area of expertise
jog axis (maybe), jog scale (maybe), DRO mode (world/joint, absolute/relative, machine/world, units)
not much else I can think of that isn't already part of emc status
maybe "selsected line"
oh, DTG vs. position
I'm going to change the subject back to big DROs
people whined "I can't read the axis DRO"
cradek/jepler gave them a bigger DRO
people whined "still isn't big enough"
chester88 decided to use pyvcp to give them a really really big DRO
and here we are
the kind of people who are whining are ones who won't want to (or be able to) figure out how to set the chicken headed knob(s) to make their DRO match the Axis DRO (or will manage it, then get all confused when they change something in axis and the big DRO doesn't change)
the axis authors already added hal pins for selected axis, so people with jogwheels don't need chicken headed knobs to set what axis the wheel should move
I see DRO number pins on axis as more of the same - not elegant, but solves one class of problem for one class of user
here's a bigass DRO for people who want it: http://emergent.unpy.net/index.cgi-files/sandbox/dro.py
it could be made to output to HAL pins instead of display the numbers, if you want to make a pyvcp example with it
doesn't it already print big numbers to the screen?
it doesn't solve the problem of not tracking AXIS changes though
no, it doesn't
thats why I said slow down - the comment about HAL pins is a tangent
why would you take a program that prints big numbers to the screen, halify the output, then send it to another program that unhalifies it and prints big numbers to the screen?
I wouldn't - feel free to move on from that :)
feature request for halui - DRO outputs, with display-units and relative-abs and maybe joint-axis select inputs
that also doesn't solve the "tracking Axis changes" problem, but it will give cradek his nixies and chicken headed knobs
in a way that is architecturally sane - halui doing what halui is supposed to do
yep, I agree wholeheartedly
hal pins out of axis telling us what units it is using: ugly ugly
yes, but sadly quickand easy
so easy even I could probably do it (if I can find where the numbers are printed, and it's not in some tcl code)
fwiw, someone isn't automatically a whiner when he unknowingly asks for something that pushes a developer's hot button
hal pins out of Axis telling us what the DRO numbers are: not pretty, but not much worse than hal pins from Axis telling it what axis you have selected for jogging
yeah, that wasn't kind of me
oh, that's the quick and easy one - not what you said before
(I agree better halui dro outputs would be great)
I think I'm coming to the conclusion that inter-UI communication isn't very useful (where cradek has been all along I think :) )
it would be great for a few things related to remote UIs that aren't really remote (ie, connected to headless controllers)
can X be used in a way that lets ONE instance of Axis draw exactly the same stuff on two screens, and accept keypresses and mouse clicks from both screens?
but it's mostly the DRO that benefits
jmkasunich: ubuntu has the remote desktop (vnc) stuff built in
ok, so that would be a way to address Axis at the headstock and another Axis at the tailstock
one guy moving from one to the other probably wants _everything_ to track anyway, to avoid confusion
yes, it's one instance of AXIS, on two displays
which is the other option - put another keyboard, mouse, and a second (cloned) display back there
like from a dual-head card
for headless, would ssh -X work, run Axis itself on the headless unit, and draw on the remote screen? or does that add X bloat to the headless PC?
it should be possible to run X client apps on the headless machine wihtout X installed, but it seems like the easiest way to be sure you have all the correct libraries is to just install X
so yes, it adds some bloat in most cases
disk bloat anyway
memory bloat, some, CPU bloat, hopefully not too much
well, AXIS is running on the headless unit. I don't know where the mesa code would be executing
I'll probably be trying that on that single board system I was talking about last night
that should be server (remote) side
the one I was supposed to spend this evening testing
don't worry - I won't be yakking at you much from Saturday night through Teusday night, so you might actually have some time :)
so there are solutions (of sorts) to the "axis on two screens" problem, and the "headless" problem, and the "nixie DRO with knobs" problem
yep, it's just the synchronization that has no simple solution
the main unsolved problem is "really really big copies of the exact AXIS numbers, without extra knobs"
except to ignore it
I guess "nixie copies of the AXIS numbers, without knobs" is the same problem
that has an easy but icky solution, for non-remote machines
the icky solution even works for remote, as long as the nixies are at the remote location as well
you can run HAL (even non-rt sim hal) on the remote, axis will export its pins, hook them to nixies (or pyvcp) on the remote
maybe. I was wondering how it would work to have HAL on a remote machine and HAL on the controller
neither HAL would know the other existed
like what would go wrong because of the assumption that HAL is HAL
you'd need separate hal files for each machine of course
I know HAL can run independently on different machines (we do it all the time :) )
in fact, I don't know how you'd manage a remote config - you have to start EMC2 on the main first, then start the GUI on the remote and let it connect to the NML on the main?
I'm wondering if there are any assumptions in AXIS or elsewhere that if HAL is present, it's *the* HAL
no, shouldn't :)
but you never know
axis is a component (I think), it doesn't decide to make any connections on its own
therefore it doesn't know or care what is out there
yeah, that should be true
as to your question, I think EMC2 has to be running for any UI to connect to ir
remote or local
the run script uses that order, doesn't it?
I'd have to look, and it is getting too late
time to walk the dog and get some sleep
oh, sleep. novel idea
heh, I thought you were gone already
well, I am - goodnight
k thanks for the talk
[Global Notice] Good Morning all, we'll be restarting two of our servers in about half an hour. niven (v4) and simak (v6) -- affected users are in the region of 2,000. We apologise for the inconvenience. Thank you for using freenode and have a good day!
[Global Notice] Hi again, it's 0903 and all is well. The two servers have been restarted and is linked back to the network. Thank you for your patience and have a nice day.
good morning all
I'm getting and error when trunk compiles "make: *** [checkref_en] Error 1" any clues?
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/gcode/main.lyx: add g7 g8
BigJohnT: I see you figured it out
(at least morning over there)
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/hal/images/ (6 files): add graphics
hi jepler and alex_joni
you mean the g7/8
he meanst the checkref-en error
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/hal/ (basic_hal.lyx pyvcp.lyx): add a few missing pyvcp things
BigJohnT: hm but I still get the checkref error over here
no I still get it too
is that related to the docs?
Anchors used in gcode.html but not defined in gcode_main.html:
ok I know what that is
gcode.html uses exactly 'sub:G7,-G8:-Set' as the name of the reference
I see that what you just added doesn't define exactly that reference
either one can be changed, just so they match
hmmm I didn't do anything in gcode.html
but I'll make it match
I only looked at your commit message, "add g7 g8" and jumped to conclusions
cradek: must have got busy and forgot to finish it
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/html/gcode.html: make g7 g8 reference match main.lyx
* BigJohnT is off to work now
oh I should have said something. I did that to gcode.html - I just guessed what the heading would be, if it is phrased like nearby stuff
BigJohnT: if you're not going to try to write the diameter mode documentation right away, I'll see if I can corner cradek and make him help me write it
I think that next to les newell who actually wrote it, he probably knows the most about it
I have some in there now jepler
I'll get with Les
EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: fix wraparound of active modal code display
what does the new cutter comp remove from the old requirements? entry restrictions?
EMC: 03jepler 07TRUNK * 10emc2/share/axis/tcl/axis.tcl: fix wraparound of active modal code display
EMC: 03jepler 07TRUNK * 10emc2/share/axis/images/ (tool_blockdelete.gif tool_blockdelete.xcf): add "block delete" to toolbar
EMC: 03jepler 07TRUNK * 10emc2/share/axis/tcl/axis.tcl: add "block delete" to toolbar
EMC: 03jepler 07TRUNK * 10emc2/share/axis/tcl/axis.tcl: update copyright years
EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: update copyright years
jepler: can you change those with the program running and get sane results? we talked about needing to stop readahead through certain spots, but I don't know if anyone ever did it
cradek: I dunno -- are you fearing that putting those on the toolbar will make users more likely to do it? (you're probably right)
axis will sure screw things up if you toggle block delete, because it reloads the preview
I'm not sure they were even enabled during run, before
no, the menu items are available
BigJohnT: I've run into some problems with lathe cutter comp. can you hold off for a few days on writing the docs?
jepler: on help->about also year update
ok, I just added a brief entry in the g code list
micges_emc: ah good point
nice gifs you have :)
diameter/radius is done and fine, I just don't want you to waste time on cutter comp docs when I might still be changing it
honestly I think they're terrible images
block_delete change may be allowed during run ?
EMC: 03jepler 07TRUNK * 10emc2/share/axis/tcl/axis.tcl:
EMC: disable 'optional pause' and 'block delete' during program run, since we're not sure whether their effect during a run would match user expectations
EMC: update another copyright date
micges_emc: before now, the menu item was available during a program run, but it doesn't behave like I think a user would want; that's why I've now disabled it
specifically: runnig axis.ngc, turn off "block delete" and start run. Then turn on "block delete". The underline is drawn anyway
I just did it
"optional pause" does seem to work as a user would expect
EMC: 03jepler 07TRUNK * 10emc2/share/axis/tcl/axis.tcl: restore optional pause toggle, it works like a user would expect
EMC: 03jepler 07TRUNK * 10emc2/share/axis/images/axis-lathe.ngc: makes no sense to mill, but it's nice to splash on lathes
EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: load axis-lathe as splash screen; reorganize initial file open code a bit
EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: expand tabs to spaces; no functional change
EMC: 03tissf 07TRUNK * 10emc2/docs/html/gcode_fr.html: french translation update add G7,G8
EMC: 03tissf 07TRUNK * 10emc2/docs/src/gcode/main_fr.lyx: french translation update add G7,G8
EMC: 03tissf 07TRUNK * 10emc2/src/po/ (fr_axis.po fr_rs274_err.po): french translation update add G7,G8
wow, he's the fastest translator in the world
yep, he is fast as fast can be :)
I've added pyvcp puttons to make GOTO ZERO XY and GOTO_ZERO_Z
I can't figure how to make GOTO_Z_MAX pyvcp command
how can I figure z_max in hal ?
use MDI: G0 G53 Z0
that goes to 0, not max (right?)
I assume he means "up"
but sure, use any other number you want
I assume "the opposite end from zero", since GOTO_ZERO_Z is already there :)
I think the only way to get that number in HAL is to have halcmd set a parameter or something
using halcmd setp new_parameter [AXIS_2]MAX_LIMIT
ok and then how to MDI it ?
but hal can't move the machine. if you do that, it's a sure sign that you are taking the wrong approach
yes halui I'm using
I don't think that limits are available to gcode
but it would be nice if they were in the parameter list somewhere
micges_emc: see the halui docs for information about how to use MDI
[15:48:36] <cradek> http://www.linuxcnc.org/docs/devel/html/gui_halui.html#r1_2_11
I want to add GOTO_Z_MAX and the best that MAX will be configurable
sorry, I want to add GOTO_Z_MAX only
cradek: I've readed it few times
what is not clear?
hm, it doesn't say you can have more than one MDI command - it should say that
also, it will change to MDI mode for you (and then back), contrary to what the docs say
It kinda says you can have more than one "and export pins from 00 to the number of MDI_COMMAND's found in the ini"
I think the question here is not "how do I get halui to do an MDI move", it's "how can I get the max limit for an axis, so I can make halui MDI to that point"
BigJohnT: you are right
SWPadnos: this is the question, thanks
so it switches to mdi for the duration of the command...
the max limit for an axis is whatever you say it is
if the axis is 1000mm, and you specify your limits are 0 to 1000, the MDI command will be G0 G53 X1000
* BigJohnT looks for his "heh" key but can't find it
if you want to make a pyvcp panel that can be used on multiple machines, is there a way of axxessing the limits from g-code?
why make it harder?
is there a limit to the number of MDI commands in the INI file?
for each machine, when you set the limits in the ini file, also set the corresponding mdi command
BigJohnT: let me check, I think there is a compiled-in limit
ok, so you agree that there's no way to access machine limits from g-code?
ok thanks cradek
limit is 10
EMC: 03jepler 07TRUNK * 10emc2/scripts/emc-environment.in: improve completion of 'emc' command to expand to ngc files in the second argument
yes it's 10 currently
you can increase it with a recompile of course
SWPadnos: I agree with that
SWPadnos: (also, limits are joints, gcode is axes...)
cradek, ok, then I agree that modifying the pyvcp file is the only way to get the function micges wants :)
SWPadnos: ini file
or the ini file
EMC: 03tissf 07TRUNK * 10emc2/docs/src/gcode/main_fr.lyx: french translation update - M1xx examples
by the way, if anyone is bothered by the limit of 10 mdi pins in halui, this patch lifts that arbitrary limit (unfortunately I ended up changing more stuff than I had hoped when I decided to introduce just a bit of C++): http://emergent.unpy.net/files/sandbox/halui-unlimited-mdi.patch
jepler: is this preffered?
- old_halui_data.machine_on = *(halui_data->machine_on) = 0;
+ old_halui_data.machine_on = 0; *(halui_data->machine_on) = 0;
alex_joni: after changing the type of old_halui_data items to bool, the old formulation a=b=0 gave warnings: emc/usr_intf/halui.cc|1580| warning: suggest parentheses around assignment used as truth value
ah, I see
that's one of the "changing more stuff than I had hoped" things
(there was some other error trying to have a vector<hal_bit_t> and using deque<bool> cleared that up)
what is a deque?
* alex_joni was afraid to ask
cradek: deque<bool> is what you type when you want a vector<bool>
deque is a structure for which inserts and removals at either end are both O(1) operations, unlike the vector where insertions and removals at the front are O(N)
[16:56:22] <BigJohnT> http://en.wikipedia.org/wiki/Deque
but because of a decision in the design of the STL, a vector<bool> can't quite be treated like any other vector<T>
vector<bool> is like FD_SET, a packed form that doesn't waste 7 or 31 bits for every bit actually stored, but unfortunately you can't pass &bitvector[i] to a function that expects a bool*
.. which is what I needed to do
did my explanation bore all of you so much that you just left?
* alex_joni read something funnier in the mean time: http://www.theregister.co.uk/2009/01/15/ubuntu_cant_access_net/
didn't bore me, I almost understood 80% of what you said
"So she dropped out of the college's fall and spring semesters."
BigJohnT: jepler knows we were kidding, it's surely never boring in here
nope, should I send her a pencil and paper?
alex_joni: as a wisconsinite - I am embarrassed
EMC: 03tissf 07TRUNK * 10emc2/docs/src/ (Submakefile docs.xml index.tmpl index_fr.tmpl): french translation update
EMC: 03tissf 07TRUNK * 10emc2/docs/src/lathe/lathe-user_fr.lyx: french translation update
* BigJohnT listens to Autobahn by Kraftwerk
cradek: I was just revising that CoordinateSystems page a bit. Is what I say in section 4 about "insert tool and use tool offset" correct?
the last couple sentences on the page confuse the issue though
hm, should I just delete the "for example" part?
the whole issue is complex. if your tool offsets are right, you can set the work origin using a tool. if your work origin is right, you can set tool offsets by measuring the tool according to the work
I think that what I wanted with those paragraphs was to give an example of when to enter a non-0 number in touch off
I guess I don't know how to explain all of it
maybe describe the use of an edgefinder
"For example, if you are using a .500" diameter edge finder, enter .500/2 or .250"?
jog so the edgefinder touches the left side of the workpiece. touch off, X, -0.1
I guess a .500" edge finder would be pretty big; what's a typical size?
they are .25 radius or .1 radius. the .1 radius is the most common
.2 dia is what I use
next, jog so the edgefinder touches the front of the workpiece. touch off, Y, -0.1
now place the tool above the work and jog up slowly until a 0.5 dowel pin just rolls under the tool. touch off, Z, 0.5
(if you do this as your example, you might teach technique and the use of touch-off both)
or, if someone is familiar with the techniques, they will see how easy touch-off is to use for these common operations
actually you want to jog until the edge finder "breaks" then set your offset
if that makes any sense :/
I've "broken" an edge finder by jogging wrong...
yes that is easy to do
but yeah, I'm assuming knowledge about how to use an edge finder. I don't know if this is the place to describe it.
For example, the following procedure can be used to set the material origin using an .200"-diameter edge finder and a 0.500" dowel pin:
* Jog so that the edgefinder touches the left side of the workpiece. Touch off X to -.1 inches. (this can also be entered as -.2/2)
* Jog so that the edgefinder touches the front side of the workpiece. Touch off Y to -.1 inches.
* Place the tool above the work and jog up slowly until a 0.5 dowel pin just rolls under the tool. touch Z to 0.5.
you would be surprised how many machinist wannabees don't know how to use an edge finder
* skunkworks_ has never had a edgefinder
BigJohnT: I bet it's one of those things that's easy to understand as soon as someone shows you, but you don't just "get it" otherwise
jepler: that looks good to me
"touch Z" -> "touch off Z" for consistency
skunkworks_: you use the round wiggler?
[17:53:59] <jepler> http://www.youtube.com/watch?v=f0od-cp_9dg
f0od reminds me it's lunchtime
I'm to 2:13 and they haven't shown a screenshot yet so maybe this is a good video to link to
I know how they work.. Just never had one.
so far he has not told you what rpm to use
he never did
cradek: you need one of those light-up edge detectors
* BigJohnT wants a 480v 3P edge finder :)
I think the light-up ones probably work less well
they need/assume zero runout, the other styles don't care so much
I like my Starrett mechanical one
It's like a 4 jaw chuck I can get a part to center in a few seconds
lunch for me
* BigJohnT heads out to check the live trap
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/gui/halui.lyx: note max mdi commands loaded from ini
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/drivers/hostmot2.lyx: add note about man pages
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/common/Stepper_Diagnostics.lyx: add a bit more info on rtapi error