Back
[01:25:08] <jmkasunich2> hi jeff
[01:27:15] <jepler_> hi jmkasunich2
[01:27:32] <jepler_> my machine is up and down so I missed anything you said
[01:29:04] <jmkasunich2> I didn't day anything but hi
[01:29:13] <jepler_> ok
[01:29:23] <jmkasunich2> kinda worn out, long day today
[01:29:26] <jepler_> no, I haven't worked anymore on hallelujah
[01:30:07] <jepler_> I thought about the representation of the signal with bends, though
[01:30:24] <jepler_> load, save, and react to changes in the HAL configuration all seem doable
[01:32:55] <cradek> poor jepler
[01:33:15] <jmkasunich2> whats going on?
[01:33:21] <cradek> rain
[01:33:32] <jepler_> jepler_ is now known as jepler
[01:33:43] <jepler> the last few were not rain
[01:33:55] <jepler> first, I was doing some wiring changes
[01:34:04] <jepler> more recently, though, my machine hung
[01:34:23] <jepler> er, most recently
[01:35:51] <jmkasunich2> bummer
[01:35:56] <jmkasunich2> any idea why?
[01:36:58] <jepler> not sure, but it could be because of the power management stuff I am trying to use
[01:37:03] <jepler> (that's the last thing I changed)
[01:37:12] <jepler> boy, with git you can easily follow multiple paths of development:
http://emergent.unpy.net/index.cgi-files/sandbox/git-arrows.png
[01:37:32] <jepler> it's like a subway map or something
[01:37:44] <jepler> "I wish I could get to the Eiffel Tower, but I just don't know how"
[01:38:01] <jmkasunich2> lotta information in there
[01:38:10] <jmkasunich2> now if only it meant something
[01:38:12] <jepler> yeah
[01:38:31] <cradek> sure is colorful
[01:39:43] <cradek> it's amazing they ever release a working kernel
[01:40:06] <cradek> btw 2.0.4 might be coming up
[01:40:11] <jepler> assuming they do
[01:40:16] <jepler> what's in 2.0.4?
[01:40:20] <cradek> ray answered questions about toolchange position but I'm pretty sure it's broken in 2.0.3
[01:40:24] <jepler> oh
[01:40:34] <jepler> "we'd better fix it, after ray as much as promised it worked"?
[01:40:34] <cradek> I fixed it in head some time ago
[01:40:53] <cradek> well it's just a backport of a tested? fix
[01:41:10] <jepler> it works in the sim-axis configuration
[01:41:23] <jepler> including the bits where it waits for the tool-change-done signal or whatever it's called
[01:41:25] <cradek> the only other new thing in the branch is my halmeter change
[01:41:32] <jepler> the significant figures one?
[01:41:35] <jepler> 1e-5 and all that
[01:41:39] <cradek> yeah
[01:42:04] <cradek> seems 2.0 is about "done"
[01:42:12] <jmkasunich2> yeah
[01:44:24] <jepler> we need to decide what, if anything, needs to be done for 2.1.
[01:45:30] <cradek> just like 2.0 I'd like to have 2.1 out a bit before fest
[01:45:34] <jepler> I think there's lots of great stuff in HEAD and I'd like to get more people using it
[01:46:00] <cradek> then after fest we'll have 2.1.[small integer] that's a nice stable release for the rest of the year
[01:46:12] <jmkasunich2> I'd like to extend setp so if there is no matching param it will check for a unconnected signal and set that
[01:46:40] <jepler> that shouldn't be hard to do
[01:46:42] <jmkasunich2> if we later decide to convert params to pins it will make the change smoother, and if not there is no loss
[01:46:55] <jmkasunich2> yeah, I'll do it once I'm home and caught up
[01:46:56] <cradek> I'd like to see the tool table problems fixed
[01:47:12] <jepler> I agree; we should make the sane change to tool tables even if it breaks the spec
[01:47:18] <cradek> that will lead to a string of units problems for a while
[01:47:58] <jmkasunich2> better to have problems going from 2.0 to 2.1 than from 2.1 to 2.2
[01:48:17] <jmkasunich2> (I'm assuming our number of users will grow, so more people would be affected if we do it later)
[01:48:32] <cradek> I just meant that it's a change that shouldn't be done at the last second, because it'll surely not be quite right
[01:49:01] <cradek> has anyone tested backlash comp at all? I'm afraid it's going to cause constraint violations
[01:49:23] <cradek> if so, we have to figure out what to do about that
[01:49:41] <jmkasunich2> I haven't tested it
[01:50:02] <cradek> I should at least scope it
[01:50:08] <jmkasunich2> unless it flat out doesn't work, any violations it causes will be less than the existing code would do
[01:50:39] <cradek> ok
[01:52:49] <cradek> well that's definitely good then
[01:53:12] <cradek> if it's bounded it can be configured to do something sane
[01:55:01] <jepler> jmkasunich2: how do I tell if a pin has writers?
[01:56:16] <jepler> er
[01:56:20] <jepler> whatever the condition is
[01:57:11] <jmkasunich2> just a sec
[02:00:10] <jmkasunich2> if pin->signal == 0, there is no signal connected to the pin, so setp is free to change it
[02:00:45] <jepler> halcmd: setp motion.enable FALSE
[02:00:45] <jepler> Segmentation fault
[02:00:50] <jmkasunich2> the new value can be written to pin->dummysig
[02:00:50] <jepler> clearly I got the first try wrong
[02:01:18] <jmkasunich2> thats a long, you have to cast if the type is something else
[02:02:56] <jmkasunich2> btw, motion.enable is an output isn't it?
[02:03:07] <jmkasunich2> I guess thats something else that should be checked
[02:03:12] <jepler> 04 bit IN TRUE motion.enable
[02:03:28] <jmkasunich2> oh, right
[02:03:46] <jmkasunich2> I was thinking of axis.N.enable, that enables PID and DACs, etc
[02:04:40] <jmkasunich2> if (( pin->dir == HAL_IN ) && ( pin->signal == 0 )) {
[02:05:06] <jmkasunich2> dunno if it should work for HAL_IO pins
[02:05:10] <jmkasunich2> probably should
[02:06:58] <jepler> do I have to use SHMPTR() with dummysig?
[02:07:19] <jmkasunich2> no, its not a pointer
[02:07:46] <jmkasunich2> pin->dummysig = (long)(whatever-the-value-is)
[02:08:25] <jmkasunich2> actually that should be in a switch, on pin->type
[02:08:45] <jmkasunich2> case FLOAT: pin->dummy = (long) some-float-var;
[02:08:49] <jmkasunich2> etc for each type
[02:10:46] <jepler> halcmd: setp hypot.0.out 1
[02:10:46] <jepler> HAL:6: ERROR: pin 'hypot.0.out' is not writable
[02:10:46] <jepler> halcmd: setp hypot.0.in0 1
[02:10:47] <jepler> HAL:7: ERROR: pin 'hypot.0.in0' is connected to a signal
[02:10:47] <jepler> halcmd: setp hypot.0.in2 34
[02:10:48] <jepler> 05 float IN 3.40000e+01 hypot.0.in2
[02:11:47] <jepler> and 'setp' still works for parameters
[02:11:50] <jepler> shall I check it in?
[02:11:56] <jmkasunich2> sure
[02:12:14] <jmkasunich2> how the hell am I ever supposed to do anything if you do it first?
[02:12:21] <jmkasunich2> (and thanks ;-)
[02:12:35] <cradek> I remember you said you'd find that NaN problem for us
[02:12:36] <jepler> you're welcome
[02:12:50] <cradek> I see nobody has jumped in...
[02:13:35] <jmkasunich2> who, me?
[02:13:54] <cradek> yeah you!
[02:15:41] <jmkasunich2> I forgot all about that
[02:16:25] <cradek> it's definitely the forgettable kind of bug
[02:16:48] <jepler> cradek: you're a shell expert. Are there shells that will mangle the "=" in this case described in the docs?
[02:16:51] <jepler> paramname = value
[02:16:53] <jepler> Identical to setp. This alternate form of the command may be
[02:16:56] <jepler> more convenient and readable when used in a file. Do not use
[02:17:00] <jepler> from the command line, since the shell may try to interpret the
[02:17:02] <jepler> '=' sign.
[02:17:15] <cradek> no
[02:19:17] <jmkasunich2> doesn't foo=blat set the shell var foo to be blat?
[02:19:27] <jepler> only at the start of the line, or after 'set'
[02:19:32] <jmkasunich2> ok
[02:19:40] <cradek> % echo a=b
[02:19:40] <cradek> a=b
[02:19:53] <jmkasunich2> I wrote that line, in a "I don't know, so better to be safe" more
[02:19:55] <jmkasunich2> mode
[02:20:01] <jmkasunich2> if its wrong feel free to correct it
[02:20:31] <jmkasunich2> hmm, I just realized something
[02:20:41] <jmkasunich2> setp has tab completion, using parameter names onlly
[02:21:11] <jmkasunich2> NEFS
[02:22:01] <jepler> NEFS?
[02:22:16] <jmkasunich2> nuttin's ever fscking simple
[02:22:20] <jepler> oh
[02:29:30] <cradek> that was fast
[02:31:56] <jmkasunich2> very
[11:52:11] <SWPadnos> hi Ray
[11:58:57] <rayh> Hey you still up or up early?
[11:59:27] <skunkworks> who?
[11:59:37] <rayh> both
[11:59:52] <skunkworks> :)
[11:59:57] <rayh> Morning skunkworks
[12:00:03] <skunkworks> logger_devel: bookmark
[12:00:03] <skunkworks> See
http://81.196.65.201/irc/irc.freenode.net:6667/emcdevel/2006-09-22#T12-00-03
[12:00:16] <skunkworks> morning. - its friday
[12:00:44] <skunkworks> steve only sleeps when he has a cold
[12:01:18] <SWPadnos> up early - I guess I got used to it from the coughing/hacking/wheezing days
[12:01:23] <SWPadnos> (and maybe Poland)
[12:02:38] <skunkworks> my wife was sleeping perpendicular to the bed - very uncomfortable.
[12:03:00] <SWPadnos> standing up? ;)
[12:03:19] <skunkworks> I was wondering if I sould rule out that "perpendicular"
[12:03:25] <skunkworks> should
[12:03:38] <SWPadnos> do you know the Phish song "Lengthwise"?
[12:03:48] <rayh> you might be able to describe that direction using gcode.
[12:04:21] <SWPadnos> the song has one line, repeated several times (along with the sounds of a person snoring and smacking their lips):
[12:04:24] <skunkworks> No - I know of phish - but could not tell you what they sing
[12:04:40] <SWPadnos> "When you're there, I sleep lengthwise, and when you're gone I sleep diagonally in the bed"
[12:05:17] <skunkworks> she is normally a diagonal sleeper - she just went too far ;)
[12:05:43] <SWPadnos> heh
[12:05:48] <skunkworks> rayh: I describe a lot of things in my head on how it would be programmed in gcode.
[12:06:03] <skunkworks> or how I would program it in gcode
[12:06:24] <SWPadnos> out of curiosity, have either of you heard of a G11 or G12 code?
[12:07:02] <rayh> z0 would start the path
[12:07:09] <SWPadnos> zzzzz0
[12:07:47] <rayh> * rayh can't remember where he put his machine programming manuals.
[12:08:22] <SWPadnos> I didn't see it in the rs274 sopec, but Mach uses it for some sort of circular path (don't remember the difference from g2/g3)
[12:08:29] <skunkworks> we have a fanuc laser that had a custom g-code written in g11. So I wonder if it is some really old code that isn't used anymore.
[12:08:31] <SWPadnos> s/sopec/spec/
[12:09:10] <skunkworks> (it allows us to use a different feed rate for x/y by adjusting a knob
[12:09:12] <skunkworks> )
[12:12:02] <skunkworks> G11 Chamfering
[12:12:05] <skunkworks> ?
[12:12:25] <skunkworks> G12 Rounding
[12:12:41] <skunkworks> http://geocities.com/phamvangiang/Machinist/gcode.htm
[12:13:46] <rayh> g11 g12 lazy coding...IMO
[12:14:26] <skunkworks> G11 Linear Interpolation 0.1X
[12:14:42] <skunkworks> G12 Linear Interpolation 0.01X
[12:15:20] <SWPadnos> oops - that was G12 and G13 for Mach - circular pockets
[12:15:40] <SWPadnos> though it's not really a pocket
[12:15:54] <SWPadnos> takes one I word (radius)
[12:16:09] <SWPadnos> it moves from the current point out by I, in a circle of radius I, then back to center
[12:16:35] <skunkworks> hmmm - I know our K&T has a way to do a /10 feedrated. I wonder if that is what that is.
[12:16:37] <SWPadnos> "the effect is undefined if the current plane is not XY" :)
[12:16:47] <skunkworks> yeck
[12:17:42] <SWPadnos> the only reason I noticed it at all is because there's a small but sumulative error using mach and the G-Rex, and the original tester noticed it on G12 and G13 moves
[12:17:53] <SWPadnos> s/sumulative/cumulative/
[12:18:09] <SWPadnos> though sumulative should also work, since it is summed ;)
[12:18:12] <rayh> I wonder how it works with radius offsets?
[12:18:32] <SWPadnos> I'm sorry - were you implying that Mach has tool offsets?
[12:18:40] <SWPadnos> and/or cutter comp?
[12:18:57] <skunkworks> be nice. :)
[12:19:07] <SWPadnos> let me check that again :)
[12:19:37] <SWPadnos> oh look - the exact same diagrams as in the RS274 manual
[12:20:01] <rayh> probably stolen by both from TomK's original
[12:23:39] <SWPadnos> could be
[12:25:50] <rayh> It was a very early copy of Tom's 6 axis code that I sent Art.
[12:29:01] <rayh> Thought for the day -- quoted from a Haascnc site.
[12:29:05] <rayh> n addition to HSM, HD/ENET and VQC, the wide range of Haas software options includes memory upgrades to 16 MB, additional user-definable M functions, coordinate rotation and scaling, user-definable macros, spindle orientation and more.
[12:31:05] <SWPadnos> 16MB - wow!
[12:32:01] <SWPadnos> how do they cram it all in there?
[12:32:06] <rayh> awesome, eh.
[12:33:49] <jepler> the cvs server is available again.
[12:34:13] <SWPadnos> cool
[12:35:48] <rayh> BTW -- for the folk who spoke about ray's tool change post.
[12:36:12] <rayh> I did test those INI variables with head before posting.
[12:37:05] <SWPadnos> I thought he ws wondering how to make it so that emc would wait for him to manually change the tool, then continue (some solution with VCP or something)
[12:39:47] <rayh> That would work.
[12:40:13] <rayh> as long as the loopback is broken.
[12:40:24] <SWPadnos> loop through VCP
[12:40:38] <rayh> Sure or a hard switch.
[12:40:41] <SWPadnos> an LED turns on, indicating that you should change the tool
[12:40:52] <SWPadnos> then you press a button to say you've done it
[12:41:40] <SWPadnos> that was one of the things I mentioned would be nice at Fest last year (though I didn't conceive of halvcp as a solution)
[12:44:01] <rayh> I tend to use the comment message to tell me which tool to change to.
[12:45:04] <SWPadnos> when I build up a machine for emc again, I'll make a VCP "manual toolchange" panel
[12:45:34] <SWPadnos> unless someone beats me to it
[12:45:51] <SWPadnos> does anyone know if you can have multiple VCP windows simultaneously?
[12:48:07] <rayh> You can run multiple halcmds.
[12:48:19] <SWPadnos> heh - thanks, but that doesn't help :)
[12:48:30] <rayh> So you can put a button in tickle that toggles that pin.
[12:48:45] <rayh> or python
[12:48:49] <SWPadnos> sure
[12:49:32] <SWPadnos> an interesting addition to VCP would be a "popup" type, which pops up a dialog when a pin hits some state
[12:50:24] <SWPadnos> you could use it for warnings also - like low coolant (when a float pin goes below some preset value)
[12:50:55] <rayh> building a machine interface are we?
[12:51:18] <SWPadnos> well, thinking of ways for people to build their interfaces :)
[12:51:27] <rayh> That is one nice thing about open source.
[12:51:44] <SWPadnos> yes indeedy
[12:54:53] <SWPadnos> on another note, I think I found an open-source digital camera design that I'll be able to use for two projects I have in the works
[12:55:10] <SWPadnos> it would also be usable for machine-related tasks, such as measurement and tool alignment
[12:55:18] <rayh> really.
[12:55:22] <SWPadnos> and it's freaking cool!
[12:55:51] <rayh> what kind of accuracy are you imagining.
[12:56:25] <SWPadnos> well, they have 1.3-3 MP sensors, they're working on a 5MP, and there's an 8MP in the same series (which I may design the head board for)
[12:57:14] <rayh> Calibration then would be the trick.
[12:57:19] <SWPadnos> I'm not sure exactly what accuracy/resolution/precision I could get - I haven't run the numbers yet
[12:57:53] <SWPadnos> the nice thing is that the camera has a big FPGA (1M gate), and an embedded Linux computer, and is connected via ethernet
[12:58:03] <SWPadnos> and costs ~$800
[12:58:13] <SWPadnos> (700 if you contribute to the GPL code
[12:58:15] <SWPadnos> )
[12:58:36] <rayh> Commercial tool measuring stands cost more than that.
[12:58:50] <SWPadnos> the website is
http://www.elphel.com, software at their SourceForge page:
https://sourceforge.net/projects/elphel
[12:59:36] <jepler> SWPadnos: there's already hal_manualtoolchange which is written in Python
[12:59:48] <SWPadnos> ok. that would be easier for me ;)
[12:59:48] <jepler> run the sim/axis.ini configuration and enter T1M6
[13:00:18] <rayh> I presume boundary detection of a tool tip or side would be several pixels wide.
[13:00:31] <SWPadnos> probably
[13:00:48] <skunkworks> jepler: good to see the rain stopped :)
[13:00:59] <jepler> skunkworks: don't celebrate yet
[13:01:20] <jepler> the overnight problem was because a machine crashed
[13:02:01] <SWPadnos> the 5MP sensor is 2592x1944, so the FOV would have to be no more than ~2.5x1.8 for 0.001 resolution
[13:02:21] <SWPadnos> though you could have variable resolution with a zoom lens
[13:04:36] <skunkworks> we have an "accugauge" machine that does edge recognition for dimensioning parts.
[13:32:18] <cradek> rayh: I fixed toolchange position in head, but I checked yesterday and found it's not in the 2.0 branch
[13:32:53] <cradek> and that CLEAR position doesn't do anything in head, mostly because I couldn't find documentation that said what it should do
[13:33:09] <jepler> haha "do-do list"
[13:34:13] <cradek> yes that's very funny
[13:34:23] <cradek> I didn't notice it until he sent the correction
[13:38:41] <jepler> me either
[13:51:47] <jepler> in the 'comp' grammar it is possible to give a parameter a documentation string and a default value. which order makes more sense?
[13:51:51] <jepler> param hyst float rw = .001 "Hysteresis of the comparator";
[13:51:53] <jepler> param hyst float rw "Hysteresis of the comparator" = .001;
[13:52:08] <jepler> for functions and pins there's nothing that comes after the documentation string
[13:52:21] <SWPadnos> I'd leave comments at the end
[13:53:37] <SWPadnos> hmmm - maybe reordering the keywords would make more sense as well: param float rw hyst=0.01 "Hysteresis of the comparator";
[14:11:03] <jepler> I'm not sure what order is best
[14:15:25] <jepler> having 'name=default-value' right next to each other seems very good
[14:15:33] <SWPadnos> yep
[14:15:53] <rayh> I guess I don't understand what you fixed. The head I used was older than yesterday.
[14:16:01] <SWPadnos> and dependong on how you parse it, having the type before the default value makes some sense
[14:16:12] <SWPadnos> depending
[14:16:50] <cradek> rayh: I fixed it long ago
[14:17:22] <cradek> rayh: in 2.0.3 I suspect you'll get following errors if you have a toolchange location in the ini
[14:17:33] <cradek> (if it works at all)
[14:23:11] <rayh> Seems to work here.
[14:23:48] <rayh> TOOL_CHANGE_POSITION = 0 0 1
[14:23:52] <cradek> hmmm
[14:23:59] <rayh> In the [EMCIO] section
[14:24:19] <rayh> MDI g0 x1 y2 z3
[14:24:23] <rayh> t1 m6
[14:24:30] <rayh> moves it to 0 0 1
[14:24:45] <rayh> with stepper inch.
[14:25:12] <cradek> I get odd errors after that though
[14:25:31] <rayh> What kinds of errors are you seeing and how?
[14:25:34] <cradek> emc/task/iotaskintf.cc 162: Command to IO level (EMC_LUBE_OFF:+1505,+12, +0,) timed out waiting for last command done.
[14:25:57] <cradek> that's not what I expected at all...
[14:26:43] <rayh> nothing here.
[14:26:53] <rayh> last error was a z-2 command.
[14:27:04] <rayh> we have to fix those damnable soft limits.
[14:27:55] <rayh> tkemc help says it's 2.03
[14:28:06] <cradek> after the tool change can you mdi and move?
[14:28:11] <cradek> mine is just stuck
[14:28:23] <rayh> Yes.
[14:28:41] <rayh> But then the stepper_inch has tool change loopback.
[14:29:00] <jepler> what does soft limits have to do with it?
[14:29:01] <cradek> linkpp iocontrol.0.tool-prepare iocontrol.0.tool-prepared
[14:29:01] <cradek> linkpp iocontrol.0.tool-change iocontrol.0.tool-changed
[14:29:54] <rayh> Oh I just commanded a z neg move and saw the error in dmesg.
[14:30:20] <rayh> spindle toward work is usually a negitive move.
[14:30:31] <rayh> but the soft limits are set the other way.
[14:36:30] <cradek> ok I found the bug I'm looking for
[14:36:39] <cradek> it's hidden because TRAJ limits are set the same as AXIS limits in this configuration
[14:36:54] <cradek> if you run stepper_xyza for instance, you'll see it
[14:37:16] <cradek> you can trigger it with: g0z-1x0y-2 / g0z1x2y0 / t1m6
[14:37:21] <rayh> Ah okay.
[14:37:58] <cradek> it's frustrating when you know a bug is there but can't trigger it
[14:38:10] <rayh> You bet.
[14:38:12] <cradek> or just increase the traj limits, which is what I did
[14:38:40] <cradek> I multiplied acc and vel by sqrt(3) which is a more reasonable setup anyway
[14:38:54] <rayh> Perhaps a note regarding this in the wiki tool change stuff.
[14:39:28] <cradek> well I intend to fix it in 2.0.4, since it's just a simple bug (and the fix is tested)
[14:40:12] <cradek> and we accidentally found a workaround that's ok for 3 axis machines (set traj limits to match axis limits)
[14:40:56] <cradek> in fact I'll go put that fix in the branch now
[14:42:07] <cradek> rayh: do you know how TOOL_CHANGE_POSITION and TOOL_HOLDER_CLEAR are supposed to interact?
[14:43:20] <rayh> moves to change, waits for IO sig, moves to clear, waits, moves to change, waits, then goes on.
[14:43:49] <rayh> The last time I set this up it was with tkio
[14:44:33] <rayh> so I'm not certain what the endpoint of the wait is.
[14:45:12] <cradek> what do the two positions mean physically on the machine? does something like the mazak want this behavior?
[14:45:28] <cradek> I know the mazak has to move Z up
[14:45:52] <rayh> Oh. The tool change position is a mazak sort of thing.
[14:46:54] <rayh> the clear position is intended for a system that puts the tool in a pocket and releases it, moves z up to clear the holder, rotates the carousel, returns the spindle over the new tool holder, and then goes to work.
[14:47:30] <rayh> that was not real clear.
[14:47:43] <cradek> oh I think I see, the carousel is inside the XYZ work envelope somewhere
[14:47:55] <rayh> yes
[14:47:59] <cradek> and the spindle itself pokes the tool into it
[14:48:18] <rayh> rather than having an arm that moves tools into and out of the spindle.
[14:48:22] <cradek> got it
[14:48:51] <rayh> I am seeing a difference in auto mode between head and 2.03
[14:48:54] <cradek> not sure how we'd do that with emc2, since CL can't command motion
[14:49:15] <rayh> The motion is commanded by task and the canons.
[14:49:33] <rayh> and there is a task interaction between motion and IO here.
[14:49:42] <cradek> right but how to coordinate that with the IO (CL) is the problem
[14:50:09] <cradek> I don't think we have any way to do that in emc2 right now
[14:51:22] <rayh> at least there was such a thing.
[14:51:35] <SWPadnos> this is similar to the motion issues with EDM and welding/weaving
[14:51:56] <cradek> seems like supporting an arbitrary toolchanger is very hard
[14:52:29] <cradek> imagine tools that sit in a rack on the table that the spindle 'grabs'
[14:52:42] <SWPadnos> though those want to modify movement output from motion, whereas a toolchanger only works while motion is effectively stopped
[14:52:45] <cradek> not just IO coordinated motion, but motion based on the tool number
[14:53:31] <cradek> can of worms!
[14:53:55] <SWPadnos> yep
[14:54:15] <SWPadnos> I have an overactive can opener ;)
[14:55:07] <rayh> I disagree
[14:55:39] <rayh> There may well be better ways to handle the motion and IO issue but I have used this combination to change tools
[14:56:09] <rayh> I see that the IO okay message is broken and it stalls out between the tool change and holder clear messages.
[14:56:58] <rayh> But that did work with bridgeportio, minimillio, and tkio.
[14:57:20] <rayh> So we would need to find the task complete stuff in these and add it to iocontrol
[14:58:05] <cradek> in a setup like you described do you have to approach the carousel (TOOL_CHANGE_POSITION) from a certain direction? seems like you might have to, to get the holder into the clamp properly
[14:58:22] <rayh> sure
[14:58:48] <cradek> did the user just have to program a certain move before the M6 then?
[14:59:24] <rayh> I've seen a lot of broken tool clamps because some part of the system or other got tired of doing it's part properly.
[14:59:29] <rayh> Yes.
[14:59:36] <cradek> ouch
[15:00:14] <rayh> I used g28 or some such
[15:00:14] <cradek> in this case that could be the "user" part of the system
[15:00:26] <rayh> absolutely
[15:00:28] <cradek> yeah that's a good use for g28
[15:01:05] <cradek> I would like to see enough configurability that we could do these kinds of moves automatically at M6 time
[15:01:30] <rayh> Sure that would be a part of what I consider configurable machine logic.
[15:01:55] <rayh> At the time FredP and I implemented this tool change stuff, what we have is the best we could do.
[15:02:36] <rayh> If we have configurable preconditions to each canonical command we could set up any pattern we needed for most any machine.
[15:02:40] <cradek> sure, I'm not saying it's bad, but it's written for a certain kind of machine (in C) and we're trying to avoid dependence on that today
[15:03:05] <rayh> IMO this is NOT a HAL issue.
[15:03:13] <cradek> but this is a new kind of configurability that has sequences of motion interspersed with IO tests
[15:03:33] <rayh> Not new, maybe new to EMC2
[15:03:50] <cradek> right, new to emc2 is what I mean
[15:04:10] <rayh> But most of the old task planner was ported.
[15:04:45] <cradek> well we could still hardcode (in task, in C) moves for a certain machine
[15:05:02] <cradek> but it seems like that's not the right solution
[15:05:30] <rayh> IMO again. We should take a serious look at both my task stuff and Rumley's work on the emc interpreter.
[15:06:05] <rayh> I believe this coordination must happen at a level far above hardware and hardware abstraction.
[15:06:42] <cradek> yeah I don't think motion belongs in HAL
[15:06:56] <rayh> SWPadnos, had some interesting ideas about a modular task planner.
[15:07:03] <cradek> the things that say "ok go on to the next thing" of course will come THROUGH it but that's all
[15:07:08] <rayh> Almost like kernel modules.
[15:07:22] <rayh> Exactly.
[15:07:44] <SWPadnos> do you mean splitting the motion controller up into more than kinematics and "everything else"?
[15:07:55] <cradek> brb
[15:08:19] <rayh> If I remember my drawing of task,
[15:08:56] <rayh> You had the idea that various combined motion/IO tasks could be plugged in
[15:09:25] <rayh> so that the motion canon and it's related io canon commands could be interleaved in various ways.
[15:09:25] <SWPadnos> yep - are we talking about the "stack of cards" stuff?
[15:09:32] <rayh> exactly.
[15:09:35] <SWPadnos> ok
[15:10:04] <SWPadnos> I'm thinking about it from a programming standpoint right now
[15:10:25] <rayh> c programming or g?
[15:10:27] <SWPadnos> there are certain things that have to be true, regardless of what generates motion
[15:10:30] <SWPadnos> like machine limits
[15:10:33] <SWPadnos> C
[15:10:37] <rayh> k
[15:11:38] <SWPadnos> so splitting out the TRAJ limiter makes sense, so that once could plop an EDM controller module between motion and PID
[15:11:53] <SWPadnos> motion -> EDM controls -> TRAJ limiter -> PID
[15:12:18] <SWPadnos> motion also wants to know about limits though, so it doesn't ask for anything it knows is impossible
[15:13:12] <rayh> Isn't motion planning at one level always a task thing?
[15:13:38] <rayh> Even the interpreter gets involved by sending out of bounds messages and stopping.
[15:13:52] <SWPadnos> it's always done by motion, unless you're doing a toolchange ;)
[15:14:11] <SWPadnos> sure - the same data is needed in multiple locations
[15:14:13] <rayh> There is a motion card stack here.
[15:14:35] <rayh> That exists outside the rt
[15:14:54] <rayh> Or am I obsolete and need to look for some other project.
[15:14:57] <SWPadnos> yeah - I think we were talking about inserting the "other functions" between interp/canon and motion
[15:15:16] <SWPadnos> heh - I don't think you're obsolete
[15:15:56] <rayh> you're being kind. Thanks
[15:16:09] <SWPadnos> yeah, I left out the "yet" ;)
[15:16:19] <rayh> I was thinking maybe I should volunteer for "pysol"
[15:16:26] <SWPadnos> heh
[15:16:34] <SWPadnos> I can test for you
[15:16:42] <rayh> there you go.
[15:17:10] <rayh> IMO we should get 2.1 locked into a testing system.
[15:17:37] <SWPadnos> oh yeah - there should be some motion toward a 2.1 release soon, like next month or so
[15:17:46] <SWPadnos> brb - phone
[15:17:50] <rayh> Then move head in the direction of 2.2 with major changes to task so that it is pluggable and configurable like HAL
[15:18:01] <rayh> We should name it TAL
[15:19:37] <rayh> This might even clear up some of the "accretions" in HAL
[15:20:17] <SWPadnos> TAL?
[15:20:28] <SWPadnos> I thought it would be SAL
[15:20:53] <SWPadnos> I can even think of an abstraction for that: "System Abstraction Library"
[15:20:54] <rayh> Task abstraction Layer
[15:21:07] <SWPadnos> err - an acronym expansion ...
[15:21:10] <SWPadnos> ah
[15:23:32] <rayh> phone
[15:34:58] <rayh> back
[15:37:55] <jepler> "pysol"?
[15:38:35] <SWPadnos> python solitaire, I think
[15:39:01] <jepler> that's the pysol I knew about, but mentioning it seemed like a non sequiteur
[15:39:32] <SWPadnos> I think the idea was "something simpler than EMC"
[15:39:37] <jepler> oh oh
[15:39:57] <jepler> rayh: you mean you're going to take the plunge and start learning python?
[15:40:32] <rayh> Um...
[15:41:01] <rayh> I was thinking about testing.
[15:43:03] <rayh> I showed some MS card player how he could win a game of freecell in < 30 seconds.
[15:43:24] <rayh> Didn't convert her though.
[15:44:19] <rayh> So short term, how do we fix the staging of motion and io like the INI tool change vars set it up?
[15:48:13] <jepler> for tool changing motions, are the capabilities of an "O- sub" adequate to the task?
[15:49:09] <jepler> e.g., T1M6 invokes "O10060 call [1]" instead
[15:49:10] <rayh> Sure. They would allow one to write a move here subroutine and then call the tool change.
[15:49:18] <jepler> I think I'm basically suggesting macros
[15:49:23] <rayh> or the other way round.
[15:49:38] <rayh> T1 o10060
[15:49:47] <rayh> and embed the m6 there.
[15:50:31] <rayh> What we don't have with the interpreter and ordinary g or m codes is IO control.
[15:50:42] <cradek> how does this help solve the problem where we need IO that controls motion?
[15:50:51] <cradek> yeah what ray said
[15:51:22] <jepler> in general, or for toolchanges?
[15:51:38] <rayh> In general
[15:51:39] <cradek> well let's talk about toolchanges right now
[15:51:43] <cradek> heh
[15:51:46] <rayh> Okay.
[15:52:30] <jepler> there's already a digital output capacity in gcode .. just add an input capacity
[15:52:35] <jepler> "wait for pin to be asserted"
[15:52:40] <cradek> if we could link a bunch of hal pins with interp variables, and made a gcode for "wait for a variable" ...?
[15:53:07] <rayh> * rayh grits his teeth as we bypass task.
[15:53:28] <jepler> you guys all know I don't know the first thing about these complex real-world machines
[15:53:49] <cradek> rayh: this puts the configurability into the gcode, instead of another programming language/kernel module
[15:54:11] <cradek> (I don't know if that's good or bad but it's an approach to consider)
[15:54:23] <rayh> machine logic doesn't seem to me to be a gcode thing.
[15:54:45] <rayh> That is why I didn't favor letting gcode toggle hal pins.
[15:55:09] <cradek> I think I agree with you
[15:55:14] <rayh> G code is project oriented and should be rather machine independent.
[15:55:30] <cradek> I definitely agree with that
[15:55:32] <rayh> Sure you can't command a fifth axis if you don't have a fifth.
[15:55:52] <cradek> but you could have subroutines ("macros") that are particular to your machine
[15:56:05] <cradek> for instance I think toolchange should always be M6
[15:56:19] <cradek> if that calls o10006 that's fine, but it should be hidden from the gcode programmer
[15:56:20] <rayh> That is a common way control makers get around specific configs.
[15:56:39] <rayh> and many users or shop operators use macros rather than the standard g codes.
[15:57:25] <cradek> I don't agree with making the gcoder use an O code *instead* of M6
[15:57:54] <skunkworks> * skunkworks still likes the story of jmk getting upset over jepler swaping windows on the mazak controller (causing the machine to studder). "This isn't a little machine!" says john
[15:58:08] <rayh> I tried to argue with the first guy that told me he was doing "o" for tool change.
[15:58:10] <cradek> but M6 could call something like an O routine under the covers
[15:58:59] <rayh> To me that is a "convenient" rather than "best practice" way of doing these things.
[15:59:38] <cradek> well it's a hack someone made for a certain purpose
[15:59:55] <rayh> I agree a single hard coded setup is not the way.
[16:00:01] <rayh> You bet.
[16:00:38] <rayh> It reminds me of the wire that the fellow in Belgium ran from his PLC to his keyboard to press the continue key.
[16:00:51] <cradek> but on the other hand, if you have to move for a tool change, I can't think of a better way to specify motion than gcodes
[16:01:19] <cradek> so I think M6 could sure call a macro that's written in gcode (and that has access to IO)
[16:01:22] <rayh> Clever as hell but there ought to be a better way.
[16:01:40] <cradek> yeah no kidding
[16:01:55] <rayh> I'd a whole lot rather see parameters that handle these things.
[16:02:07] <rayh> That is the way that most CNC makers do it now.
[16:02:28] <cradek> would you explain what that means?
[16:02:28] <skunkworks> but emc needs to be flexable.
[16:02:48] <rayh> Then if whatever system a user has doesn't fit, restort to the wire or the o word.
[16:02:56] <cradek> I mean 'parameters'
[16:03:07] <rayh> Sure.
[16:03:31] <rayh> Let me try a really simple example. The operator door switch/solenoid.
[16:04:03] <rayh> Different countries have different safety standards.
[16:04:07] <jepler> I'm not saying all I/O should go through a level of g-code
[16:04:22] <jepler> an extern e-stop, obviously, wouldn't invoke g-code before it would turn off the amps
[16:04:28] <rayh> So a parameter might be eu or usa or jap or cn
[16:05:02] <rayh> each handles the logic between motion and IO in a different way.
[16:05:25] <rayh> The same is true of different tool changer geometries.
[16:05:36] <jepler> if there are a fixed number of things that are possible, and we don't mind implementing them all, then maybe we should do so
[16:05:47] <jepler> but will we be able to anticipate every tool changer we'd like to support?
[16:06:21] <rayh> That is where SWPadnos' idea of the pluggable comes into my thinking.
[16:06:21] <cradek> look out, it's a trap, anyone who says yes is in danger of being asked to write the spec
[16:06:56] <rayh> Tool change is a set of "pins" to which you attach the module that works for your system.
[16:07:13] <cradek> personally I'd hate to see us go back to requiring people write and compile C code
[16:07:30] <rayh> and that module has a set of params for location, path, pattern.
[16:07:53] <rayh> I agree and the only time the compile is necessary is setup and testing of a new module.
[16:09:07] <cradek> I see arbitrary tool changes as a sequence of interspersed motions and IO, where everything has access to the old and new tool numbers etc.
[16:09:50] <rayh> I see that for pick-and-place changers.
[16:10:16] <cradek> by IO I mean anything that can be done with hal/CL
[16:10:17] <rayh> a set of location parameters for each holder.
[16:10:57] <SWPadnos> perhaps a script language, which has full HAL/motion/I/O capabilities, would be a good solution
[16:11:19] <SWPadnos> though it would basically duplicate half of CL, and half of G-code
[16:11:22] <cradek> I agree, and I know a good scripting language for motion control
[16:11:38] <SWPadnos> heh, but it doesn't include IO
[16:12:02] <cradek> well it includes an array of arbitrary numbers
[16:13:30] <cradek> if the tool number is in #999 I can use g0g53x[#999]y0z0 to position the spindle over it in a certain kind of tool changer (where the tools are 1" apart along the X axis)
[16:13:55] <cradek> now imagine a new gcode for "wait for variable to become true/false"
[16:14:10] <cradek> now aren't we about done with your scripting language?
[16:14:26] <rayh> * rayh starts to cry.
[16:14:40] <rayh> don't you hate whiners.
[16:15:00] <cradek> I'd like to understand your objections better
[16:16:24] <rayh> IMO t2 m6 ought to be all one needs to do to program a tool change.
[16:16:33] <cradek> *I agree*
[16:16:50] <cradek> m6 would call a macro that's NOT in the gcode program
[16:17:05] <cradek> that macro would have access to the T number and also the IO in HAL
[16:17:35] <cradek> it might do what I said above, then exit to return control to the gcode program right after the M6
[16:17:53] <rayh> The issue as I see it is distributed task or single task.
[16:17:56] <cradek> jepler: is this what you were suggesting?
[16:18:04] <rayh> what happens to an abort in the middle of that macro.
[16:18:12] <rayh> or a switch to manual mode.
[16:18:15] <cradek> it stops
[16:18:30] <rayh> These are known to task now and it issues the proper aborts.
[16:18:57] <rayh> and it resets conditions so that the system can recover
[16:19:00] <jepler> cradek: yes
[16:20:00] <rayh> With decentralized io control and decentralized motion control we have more possible conflicts.
[16:20:47] <rayh> It's a bit like the fellow yesterday who posted, "why can I turn on coolant with machine off."
[16:23:46] <jepler> you're saying that at an abort you might want to do additional motion? or that digital outputs might need to be set to a known state?
[16:24:35] <rayh> Right.
[16:24:42] <jepler> both?
[16:25:37] <rayh> There is a provision in usa safety code for controlled motion after abort or estop.
[16:25:47] <cradek> I'm going to make ray cry again but maybe there should be a macro that runs on m2/abort too
[16:26:01] <cradek> so the user can decide if m2 switches to inch mode, or resets g92, or whatever
[16:26:47] <cradek> but that's off the topic of tool changes I guess
[16:26:52] <rayh> I'm of the opinion that we are not really speaking of different abilities, just different ways of approaching them.
[16:27:07] <cradek> I think that's true
[16:27:59] <rayh> And it is very possible that my way of thinking about them has been colored by repair of very old machine tools.
[16:28:54] <cradek> yes I think I see a general abstract problem, and you see particular machines
[16:29:15] <cradek> like when I said 'I see arbitrary tool changes as a sequence of interspersed motions and IO'
[16:29:58] <rayh> Right.
[16:30:55] <cradek> going to break for lunch, bbl
[16:31:48] <rayh> catch you later. gotta run. Thanks
[18:00:23] <alex_joni> hi all
[18:48:06] <LoRez> [Global Notice] Hi all. Some of you may not have heard the news that Rob Levin, known to most as Freenode's head of staff lilo, passed away on the 16th following a car accident on the 12th. Condolences can still be sent to condolences@freenode.net, and will be passed along to his family.
