Back
[04:18:56] <SWPadnos> maybe the home icon should be a little house
[04:46:19] <cradek> I can't tell if you're serious or kidding
[04:49:33] <SWPadnos> yes - both
[04:49:44] <cradek> xor?
[04:49:57] <SWPadnos> but the house icon would be more accurate for showing that the machine is in home position
[04:50:19] <SWPadnos> well - several people have asked what the target means. it's not obvious that it means "homed"
[04:50:43] <cradek> but ... it comes on when you home
[04:50:49] <SWPadnos> heh
[04:50:56] <SWPadnos> well, there is that :)
[04:51:09] <cradek> well I'm actually serious, it seems very discoverable, even if it's a total nonsense symbol (which I don't think it is)
[04:51:29] <SWPadnos> does it turn off if you hit home again?
[04:51:31] <cradek> a house would be a pun, which would bother me I think
[04:51:41] <SWPadnos> (until homing is finished)
[04:51:53] <cradek> if you have homing motion, yes it turns off until home is reestablished
[04:51:57] <SWPadnos> ok
[04:52:35] <SWPadnos> if you aren't looking at the display when homing (like - looking at the machine, with a hand over the esc key), then you may not notice that it's a result of homing
[04:52:44] <cradek> the only other precedent we have in other guis is the different colors for the numbers
[04:52:45] <SWPadnos> and it never turns off (unless you home again)
[04:52:48] <SWPadnos> yep
[04:53:09] <cradek> I think that's equally discoverable, but probably not as clear
[04:53:17] <SWPadnos> not a problem, but I think K'zan isn't the first person to wonder what the target is
[04:53:20] <cradek> (and useless for 10% of men)
[04:53:25] <SWPadnos> heh
[13:57:50] <rayh> This is a very late reply but IMO we are a machine control and machine control is in essence different from other software and we ought to make certain that folk do not overlay their understand of "office" widgets with machine control actions.
[14:02:24] <alex_joni> http://www.lenauschule.de/img/url.gif <- home?
[14:11:31] <skunkworks> I think most people call it the emc2 livecd
[14:11:40] <skunkworks> now-en-days
[14:39:50] <SWPadnos> hmmm
[14:40:27] <rayh> hmmm?
[14:40:40] <SWPadnos> looking at Ray's email, it dawned on me that we have no way of making core_stepper.hal automatically load the correct number of stepgens
[14:41:02] <rayh> Yep. Saw that also.
[14:41:07] <SWPadnos> when you didn't need to specify step_type, you could use loadrt stepgen num_chan=[TRAJ]AXES
[14:41:11] <rayh> but a bit late.
[14:41:14] <SWPadnos> heh
[14:41:38] <SWPadnos> no, I mean that there's no way to make it automatic, not that you forgot to put it in
[14:41:43] <rayh> Should have used the mesa examlpe throughout
[14:42:04] <SWPadnos> true - he'd already have the DACs anyway
[14:42:15] <SWPadnos> incidentally, that brings up another HAL issue
[14:42:30] <rayh> You might have guessed that I'm riding one of my favorite horses this morning. I named him "edgy."
[14:42:31] <SWPadnos> there's no way to tell a driver what it should find
[14:42:35] <SWPadnos> heh
[14:42:49] <rayh> driver?
[14:42:54] <SWPadnos> so I can't say "there should be two mesa cards, don't load if you find 0, 1, or >2 cards"
[14:43:07] <rayh> Oh. Sure
[15:00:03] <SWPadnos> heh - there's the problem with autodetection
[15:12:08] <alex_joni> http://dsplabs.cs.utt.ro/~juve/emc/cd-cover/
[15:13:26] <rayh> Nice
[15:23:02] <alex_joni> see you guys later
[17:08:21] <jepler> whee -- I finally hooked pluto-step up to zenbot. it works quite nicely.
[17:09:50] <rayh> Yea. Another success.
[17:13:35] <jepler> of course I'm not cutting anything, so for all I know it could be way off the path
[17:13:46] <jepler> but G28 goes back to the reference location after running some gcode, so I'm optimistic
[17:14:27] <jepler> about 38k steps per second (1.2 in/min, SCALE 32000)
[17:15:49] <jepler> I'm using a 2kHz servo cycle
[17:17:05] <rayh> I use the go back to start a lot during testing.
[17:17:14] <jepler> btw does anyone see a downside to making 'loadrt threads' default to a 1kHz thread with floating-point? this would make doing quick tests with halrun just a tiny bit easier, since so often that's an acceptable thread setup...
[17:17:32] <jepler> (if thread1= period1= nofp1= are specified they would still be used)
[17:19:13] <rayh> I see the advantage for first timers.
[17:19:40] <jepler> oh, and "daisy" sounds fine on it; very important
[17:20:06] <jepler> (actually i have a feeling that if the step generation were uneven it would be pretty clearly heard in that program)
[17:20:39] <jepler> yeah it would also simplify some of the examples in the hal torturial
[17:20:42] <rayh> I'd think so. The ear is a pretty good way to test those sorts of things.
[17:21:06] <rayh> I'm trying to work through that now and will use it in class.
[17:21:38] <jepler> are you updating it as you go? a lot of the screenshots and texts don't quite match what has been changed over time.
[17:22:16] <rayh> I see that. I'm a bit conflicted about the fix up. Local v repository.
[17:22:56] <rayh> I've found that it doesn't work to save as 1.3.7 from the new lyx.
[17:23:16] <rayh> pissed me off a bunch.
[17:24:05] <jepler> unfortunately there are some serious barriers to getting the same lyx version on both dapper and hardy
[17:24:18] <jepler> but I don't want to talk about that now; it'll just get me down
[17:24:29] <rayh> I agree.
[17:24:54] <jepler> if it's best for you to write in some other version (or even other format) in preparation for your presentation/classes, please do -- I'll do what it takes (later) to get it into the online / dapper / hardy documentation
[17:24:57] <rayh> I'll take notes as I work through it.
[17:25:13] <rayh> Okay.
[17:25:48] <rayh> I do like the newer LyX. It has some very handy graphical features and some better work with float fitting and such.
[17:26:26] <rayh> So I may work in that and then we figure a way to move it to 6.06.
[17:26:33] <jepler> OK
[17:27:12] <rayh> I'll keep those docs separate from my repository so I don't screw things way up.
[17:27:36] <jepler> whatever you feel is best. even if you commit by mistake, we can go back in time with cvs.
[17:27:53] <jepler> bbl
[17:28:04] <jepler> time to get away from the computer
[17:28:13] <rayh> see you.
[17:28:17] <jepler> (well, as soon as this gcode finishes and I MDI G28 anyway)
[17:29:43] <jepler> http://git.unpy.net/view?p=zenbot.git;a=blob;f=pluto.hal;hb=master <-- the hal for pluto-step is actually short and sweet
[17:29:57] <jepler> .. and we're back at the reference point
[17:30:38] <rayh> Fastastic.
[19:33:14] <jmkasunich> rayh: you around?
[19:33:59] <rayh> Yes
[19:34:04] <jmkasunich> just got back from HGR
[19:34:17] <jmkasunich> that nice panel with breakers and outlets was sold yesterday
[19:34:17] <rayh> What did you get?
[19:34:27] <jmkasunich> I did get the 2kva xfmr with the quad box on it
[19:34:28] <rayh> shoot.
[19:34:37] <rayh> Okay.
[19:34:40] <jmkasunich> and I got 12 power strips at $1.49 each
[19:34:49] <rayh> Great.
[19:35:50] <rayh> You're better than I at figuring amps on the output of that. What will we be able to draw on each side?
[19:36:14] <jmkasunich> 2KVA = 16.67A at 120V
[19:36:32] <jmkasunich> I haven't looked to see if it is split 120/240 or just single 120
[19:36:38] <jmkasunich> I'm guessing the latter
[19:36:47] <rayh> That's what it looked like to me.
[19:37:02] <jmkasunich> there is also a fuseholder mounted on the side - since there is only the one, I'm guessing it is secondary
[19:37:18] <jmkasunich> looks like the size that would take a KTK or similar fuse
[19:37:32] <rayh> I'd bet split 240 since those are common duplex receptacles.
[19:37:40] <jmkasunich> lemme check
[19:37:51] <rayh> k
[19:39:10] <jmkasunich> this is not to big or heavy - maybe 30 lbs tops
[19:40:31] <jmkasunich> dual secondaries, wired in parallel for a single 120V output, black, white, and green heading into the quad box
[19:40:48] <jmkasunich> FNM20 fuse on the secondary
[19:41:41] <rayh> Sounds like it's wasting some of it's potential.
[19:41:41] <jmkasunich> dual primaries, currently wired in series for 480V
[19:41:48] <jmkasunich> how so?
[19:42:00] <rayh> That will work no matter what Roland has for us.
[19:42:01] <jmkasunich> 2KVA = 16.67A at 120V, its fused at 20AA
[19:42:33] <rayh> Oh right. I was thinking 16 each side.
[19:42:59] <rayh> It does nearly double what was there last year.
[19:43:21] <jmkasunich> incoming connection is a approx 0.8" knockout (1/2" trade size?) with a 45 degree liquitite fitting, and about 1" of liquitite
[19:43:36] <jmkasunich> somebody disconnected it with a large cutter
[19:43:39] <rayh> Okay.
[19:44:02] <rayh> I've got some liquidtite in the shop. I'll bring a chunk.
[19:44:35] <jmkasunich> the LT is about 0.82 OD, dunno if that is 1/2" or 3/4" trade size
[19:45:20] <rayh> 1/2 uses about a 7/8 opening
[19:45:34] <rayh> 3/4 uses 1 1/8
[19:45:57] <jmkasunich> ok, the knockout is definitely 1/2
[19:46:02] <rayh> Is that .82 ID or OD
[19:46:22] <jmkasunich> OD
[19:46:34] <rayh> Gotta be half.
[19:49:04] <jmkasunich> looks like there is a ring that is part of the fitting, but its not crimped to the stub of LT
[19:49:32] <jmkasunich> hopefully those aren't unobtainium
[19:49:42] <rayh> They do make non-crip. Usually have a plastic ring.
[19:49:56] <rayh> Nah. I'll bring extra fittings.
[19:56:06] <jmkasunich> it was marked $39.99 but I got it for $30
[20:01:37] <rayh> Good price IMO.
[20:02:20] <rayh> I remember 2 years ago we had developers and their primary boxes separated from display and test areas.
[20:02:28] <rayh> Do we want to try that again this year?
[20:09:44] <skunkworks> rayh: - maybe you can answer.. we are planning on being there thrus,fri,sat.. How much extra should we pay roland above the weekend rate?
[20:11:01] <rayh> I think I'd take the regular rate - weekend rate / 5 * 2 and a bit for gratuity.
[20:11:39] <jmkasunich> rayh: I think it was fine last year with us right next to the mazak
[20:12:25] <skunkworks> rayh: thanks
[20:13:45] <rayh> Okay jmkasunich
[20:45:09] <Guest604> Guest604 is now known as skunkworks
[21:23:54] <rayh> jmkasunich, Got a question about threads if you've got a minute.
[21:24:16] <jmkasunich> hal threads or 3/8-16 ;-)
[21:24:32] <rayh> I'm thinking base thread in a 3 axis stepper
[21:24:36] <jmkasunich> ok
[21:25:02] <rayh> I see read, make-pulses, write.
[21:25:38] <rayh> Now thinking about one tick of the thread. Does it do all three functions in sequence each time.
[21:26:07] <jmkasunich> yes
[21:26:31] <jmkasunich> read, make pulses, write, go to sleep till next time
[21:27:26] <rayh> Okay. I'm trying to figure a good way for me to illustrate the way that threads work.
[21:28:14] <jmkasunich> work instructions for an assembly line - "for each part that comes down the line, do these steps in this order, then you can doze off till the next part"
[21:28:21] <jmkasunich> maybe?
[21:30:33] <rayh> Yea that's about it.
[21:33:04] <rayh> Say I've got a couple of ddt's connected in series. Do both work on the same data during the same thread?
[21:33:32] <jmkasunich> both run in the same thread
[21:33:43] <rayh> Yes
[21:33:49] <jmkasunich> the signal propogating thru them can be delayed if you have them in the wrong order
[21:34:07] <rayh> Right. I can see that.
[21:34:21] <jmkasunich> if you have input ---> ddt1 ---> intermediate ---> dd2 ---> output
[21:34:26] <jmkasunich> you should run ddt1 first
[21:34:45] <rayh> Okay I think I've got at least a part of it.
[21:35:00] <jmkasunich> ddt reads input and writes intermediate, then ddt2 reads the new value of intermediate and writes it to output
[21:35:30] <jmkasunich> IOW, ddt1's calculations affect its output signals immediately
[21:35:56] <jmkasunich> (I think thats not the way the PLCs you are used to work, but to do it that way could cause huge delays if there are many blocks in series)
[21:36:03] <rayh> So all of the functions assigned to a thread are done in the order for each tick of the thread.
[21:36:08] <rayh> Sure.
[21:36:09] <jmkasunich> right
[21:36:59] <rayh> I see that there is only one function for ladder and that is as it should be for the way a ladder works.
[23:10:48] <jmkasunich> cradek: I have a question about 5-axis (as on max5)
[23:11:23] <jmkasunich> starting at X0 Y0 Z0 A0 B0 C0 U0 V0 W0
[23:11:26] <alex_joni> hi guys
[23:12:02] <jmkasunich> if I move G0W1, then A90 will I get the same result as A90 then W1?
[23:12:34] <jmkasunich> (same end pose - I realise the intermediate pose won't be the same)
[23:17:21] <jmkasunich> hi alex
[23:20:14] <alex_joni> * alex_joni ponders going to bed
[23:21:51] <alex_joni> seems like a good idea.. good night all
[23:26:59] <jepler> jmkasunich: I think you're supposed to (is there something degenerate about the case in your question?)
[23:27:34] <jmkasunich> no
[23:27:47] <jmkasunich> I'm just making sure I understand what W does
[23:28:03] <jmkasunich> and where its origin it
[23:28:04] <jmkasunich> is
[23:29:09] <jmkasunich> what I have in mind is setting W to something like 0.25, then doing all kinds of BCXYZ moves
[23:29:17] <jmkasunich> then set W to zero, and repeat all those moves
[23:29:39] <jmkasunich> the first set should give me a twisty groove, and the second one should deepen the groove
[23:30:10] <jmkasunich> (If I properly understand the way W works)
[23:35:39] <cradek> jmkasunich: imagine W moving the controlled point up and down the tool
[23:35:51] <jmkasunich> thats what I thought
[23:36:17] <jmkasunich> so if I put it 1/4" beyond the end of the tool, I can cut a shallow groove, then repeat with it on the end to get the final depth
[23:36:51] <rayh> That was a fun adventure. I found a combination in qcad that would loop without end and add something to memory on each loop, well long enough to run this box out of memory. It began eating stuff like x, and gnome, and firefox and ....
[23:37:02] <jmkasunich> oops
[23:37:24] <cradek> jmkasunich: yes I think so
[23:38:59] <jmkasunich> ok, thanks
[23:39:07] <jmkasunich> oh, nother question
[23:39:15] <jmkasunich> combined angular and linear moves
[23:39:31] <jmkasunich> feeds tend to be "mysterious" in that case aren't they?
[23:39:37] <jmkasunich> as in I should use inverse time?
[23:39:58] <cradek> it's not a mystery, but yes inverse time is best
[23:40:09] <cradek> let me find the docs
[23:40:37] <cradek> http://www.linuxcnc.org/docview/html//gcode_main.html#sub:Feed-Rate
[23:42:33] <jmkasunich> ok, so for moves that may contain an arbitrary mix of axes, I should compute which has the farthest to move, then calc the time using the appropriate rate (either ipm or deg p m) and finally invert that time to get the feed
[23:43:32] <cradek> I don't see how it helps to decompose it into the various axes
[23:43:51] <jmkasunich> so I know whether it is limited by a linear axis or an angular one
[23:43:57] <cradek> you know the approximate distance the tool will move on the part
[23:44:16] <cradek> you know what rate you want (ipm), so you know the time
[23:44:36] <jmkasunich> for X0A0 to X0.01A90, I am angular limited - so many degrees per minute
[23:44:53] <jmkasunich> for X0A0 to X1A1, I am linear limited, so many inches per minute
[23:44:54] <cradek> hang on
[23:45:13] <cradek> with inverse time feed mode, it doesn't matter what the distance units are, that's the point
[23:45:30] <jmkasunich> but I have to tell it how long the move should take don't I?
[23:45:49] <cradek> yes, in minutes
[23:46:38] <jmkasunich> ok, X0A0 to X0.01A90 - to compute that time, take 90 divided by my max angular feed rate
[23:47:00] <cradek> no, you should program the feed rate you want
[23:47:04] <cradek> it may go slower
[23:47:09] <cradek> but that's fine
[23:47:18] <jmkasunich> you are confusing me
[23:47:25] <cradek> it's mutual :-)
[23:47:48] <jmkasunich> background - I am not writing g-code
[23:47:55] <jmkasunich> I'm writing code that writes g-code
[23:48:02] <cradek> I understand
[23:48:12] <jmkasunich> move_to(x,y,z,b,c)
[23:48:25] <jmkasunich> move_to knows where you are
[23:48:33] <jmkasunich> and where you want to go
[23:48:52] <cradek> say you want to remove meterial at nominally 1ipm
[23:48:56] <jmkasunich> but it doesn't know (unless it calculates it) whether the limiting axis will be linear or angular
[23:49:42] <cradek> if you're making an angular cut of 90 degrees at 1inch radius, that cut will be pi/2 inch, so it should take 2/pi minutes
[23:49:52] <cradek> that's the inverse feed rate you can program
[23:50:19] <cradek> if X moves a tad, who cares, the cut length is about the same, the feed stays about the same
[23:51:18] <cradek> you just have to consider the length of the cut on the work, no matter how many axes move to make it
[23:51:26] <jmkasunich> you are assuming that the tooltip is at 1" radius, and therefore moves (relative to the work)
[23:51:54] <jmkasunich> what if I'm keeping the tip fixed in work coords (or moving it a tiny bit) but radically reorienting it?
[23:52:26] <jmkasunich> the tip might not be cutting at all, but the shank could be
[23:52:27] <cradek> if it will be cutting, consider the "length" of cut the same way
[23:52:36] <cradek> it it won't be cutting, use a G0
[23:53:25] <cradek> (I think that's what makes this challenging)
[23:53:56] <cradek> for any cutting move, you consider how much will be removed, and the removal rate you want; this gives you a time
[23:53:57] <jmkasunich> a strict interpretation of
http://www.linuxcnc.org/docview/html//gcode_main.html#sub:Feed-Rate
[23:54:05] <jmkasunich> says I can overspeed the angular axes
[23:54:08] <cradek> doesn't matter what moves to do it
[23:54:32] <cradek> go up one sentence before that header
[23:54:55] <jmkasunich> right
[23:55:56] <jmkasunich> so I'm using inverse time to allow me to specify two feeds, one angular and one linear, and generate a time based on the limiting one
[23:56:21] <jmkasunich> you are saying don't worry about angular at all, just figure out how much of a cut you are taking and spec that time
[23:56:50] <jmkasunich> I agree that is good if you know how much of a cut you are taking
[23:57:28] <cradek> the proportions between angular and linear feeds is fixed by the move
[23:57:33] <jmkasunich> ok, I think I'm catching on now
[23:57:48] <jmkasunich> does EMC respect the machine limits in inverse time mode?
[23:57:48] <cradek> in units per minute mode, it is sucky because you have to specify one, and the one it makes sense to specify changes
[23:57:59] <cradek> that's why there is inverse time
[23:58:06] <cradek> yes of course
[23:58:17] <cradek> well, axis limits, you know
[23:58:20] <jmkasunich> ok, I'm remembering ancient stuff
[23:59:08] <jmkasunich> if I tell it to make a mixed axis move in 0.001 seconds, it will decide which axis is the limiting factor, and move accordingly?
[23:59:30] <cradek> yes it will maintain coordination and respect limits
[23:59:34] <jmkasunich> ok
[23:59:38] <cradek> that would look the same as a rapid
