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