Back
[00:00:09] <skunkworks> how are you going to know if it is a rapid move or not... (thinking out loud)
[00:00:35] <cradek> * cradek mumbles under his breath
[00:02:15] <skunkworks> wait - doesn't matter - because the torch will be off..
[00:02:52] <skunkworks> (you know because the plasma is not active)
[00:08:35] <cradek> I actually could make a pin that shows the current motion type (rapid, feed, arc, probing, toolchange)
[00:09:37] <cradek> but that was not in the original spec... :-P
[00:09:53] <cradek> hal pins don't grow on trees you know
[00:10:02] <skunkworks> heh
[00:10:08] <cradek> you can't go throwing them around all willy-nilly
[00:28:41] <Jymmm> Um, wanna bet? Hal tree -->
http://www.linuxcnc.org/docs/html//halshow-3.png
[03:57:16] <garage_seb> micges, are you around?
[04:03:52] <cradek> how was your trip?
[04:09:44] <garage_seb> it was ok... people sleep better at night not knowing how laws and sausages and standards are made
[04:09:58] <cradek> eek, don't tell me then
[04:10:17] <cradek> well sausages won't bother me
[04:10:28] <garage_seb> i just wish i could reproduce micges hm2 encoder nan here
[04:11:09] <cradek> did he have any instructions for you? I don't remember seeing anything concrete.
[04:11:43] <garage_seb> he emailed me most of his config, but not enough to run it here, even if my servo params matched his
[04:12:15] <cradek> yuck
[04:12:20] <garage_seb> and he pastebinned a couple of halscope screencaps showing the velocity value at inf
[04:12:46] <cradek> can you see anything special happening at those times?
[04:13:22] <garage_seb> i guess i'll go trawl for div-by-zeroes in my code, but i'm wary of changing stuff when i cant tell if it's fixing anything
[04:13:47] <cradek> yeah I was just studying vel = dS_pos_units / dT_s;
[04:13:49] <garage_seb> one of the pastebin pics shows position and rawcounts looking normal
[04:17:16] <garage_seb> well that looks like a bug
[04:17:32] <garage_seb> encoder.c:806 should probably have <= instead of <
[04:20:00] <cradek> so if you get a timestamp difference of exactly 0xffff you'd get a div by zero?
[04:21:06] <cradek> er 0x10000 (same 16 bit number twice)
[04:21:17] <garage_seb> if the new edge came in exactly 16 bits of tsc after the previous one, the two times would be equal, so it would *not* increment the rollover counter... exactly
[04:22:14] <cradek> cool, so one particular count rate (not scaled velocity) would trigger it
[04:22:42] <garage_seb> looks like
[04:23:16] <garage_seb> my servos are fast (8k rpm) and have 512-line encoders, and run un-loaded, so maybe i just got "lucky" and never ran in to this in my testing
[04:23:26] <cradek> can you calculate it? I could test for you
[04:23:38] <cradek> oh you've got some hooked up, ok
[04:23:45] <garage_seb> i wonder if i can trigger this by feeding a stepgen into the encoder...
[04:24:20] <cradek> what time does exactly one tsc rollover represent?
[04:24:33] <garage_seb> the hm2 tsc clock is configurable
[04:24:57] <garage_seb> it's currently running at 1 MHz
[04:25:08] <garage_seb> so 64K us per rollover
[04:25:51] <cradek> $ units micron/64000microsec inch/minute
[04:25:53] <cradek> * 0.036909449
[04:26:05] <garage_seb> i <3 units
[04:26:08] <cradek> that's pretty darn slow on my mill
[04:26:19] <garage_seb> i think micges is running in mm
[04:26:24] <garage_seb> he's got "UNITS = 1.0"
[04:26:54] <garage_seb> how's your jr doing?
[04:26:55] <cradek> yeah but it's still slow unless his resolution is much more coarse than mine (very possible)
[04:27:03] <cradek> just great. I've been using it a lot.
[04:27:40] <cradek> I've cut big blocks of steel and also engraved tiny lettering - it's good at both
[04:27:46] <garage_seb> his encoder scale is 1000 on the axis that's nan-ing
[04:27:59] <garage_seb> cool
[04:28:03] <garage_seb> what are you making out of steel?
[04:28:05] <cradek> 1000/mm is the same as jr
[04:28:53] <cradek> the steel was a project for someone else - a part that fits the lift (jacking) point on a unibody car
[04:29:41] <cradek> simple part, but had a slot .875 deep x .3125 wide
[04:29:52] <garage_seb> heh
[04:30:23] <cradek> with .25 carbide - i cut it dry at high speed, many shallow passes
[04:30:57] <garage_seb> shallow meaning .025 DOC per pass or so?
[04:31:25] <cradek> .075 maybe? I don't recall for sure
[04:33:13] <cradek> the other fun thing I've noticed is that nobody else wants BT40 tooling but there's lots of it
[04:33:47] <cradek> I've got a bunch of $.99 to $10 end mill holders, drill chucks, etc from ebay
[04:35:31] <garage_seb> nice :-)
[04:43:10] <cradek> wonder how to trigger on nan in halscope...
[04:43:30] <cradek> I'm running a G1 F0.036909449 move and I'm not seeing them right off
[04:44:15] <cradek> although the velocity is sure noisy and nasty
[04:50:49] <garage_seb> bummer, it should be smooth and nice :-(
[04:52:28] <garage_seb> enc.vel looks good here with the stepgen for input
[04:55:10] <cradek> ah, the nasty is when it reverses
[04:56:03] <cradek> http://timeguy.com/cradek-files/emc/encoder-velocity.png
[04:57:01] <cradek> I wish I knew for sure if I'd trigger on a nan/inf (I have it set to level positive, rising)
[04:57:15] <cradek> since you said his looked like +inf
[04:57:37] <garage_seb> guh, that does look bad
[04:58:01] <cradek> it's dithering, moving very very slow
[04:58:40] <garage_seb> cradek, ah yes, that's another known bug that i havent gotten to yet :-(
[04:58:47] <garage_seb> here's micges' plot:
http://imagebin.ca/view/BpN9pD0.html
[04:58:47] <CIA-40> EMC: 03cmorley 07v2_3_branch * r6c567f0b0c8a 10/src/emc/usr_intf/stepconf/stepconf.py: Fix parallel port direction settings
[05:00:02] <cradek> hm, very start of a move - going very slow - maybe it is what you found
[05:00:10] <cradek> wish I could get it here though...
[05:05:44] <garage_seb> i think you're seeing a different problem
[05:05:57] <cradek> yeah that's just an aside - I'm looking for the nan/inf
[05:06:10] <garage_seb> ah gotcha
[05:06:42] <cradek> are you sure about the rollover time?
[05:07:06] <cradek> 0xffff/1MHz is .065 sec
[05:07:19] <garage_seb> i think so
[05:08:15] <garage_seb> the tsc rate is set at encoder.c:428
[05:08:56] <cradek> ok I get the same thing - sorry, being dense
[05:12:13] <garage_seb> gak, too many cables
[05:12:57] <cradek> I have been doing g91g1x20f.036044934 for some time and have not seen the inf
[05:13:45] <cradek> I think that is the feed that should give 1 micron per rollover (assuming a perfectly spherical milling machine)
[05:14:55] <cradek> wonder how rare it is... I notice he did not trigger on it to get that plot.
[05:22:19] <garage_seb> i have a test script here that slowly varies the stepgen rate across the critical value and watches encoder vel using halsampler, and so far i have not seen it mess up
[05:23:24] <cradek> your test is much smarter than mine
[05:23:50] <cradek> (I figured it might be really easy to see at the right speed)
[05:24:06] <garage_seb> i'm surprised we're not both seeing it
[05:24:17] <garage_seb> that looks like a pretty blatant bug in the code
[05:25:23] <cradek> maybe getting the count in the right microsecond isn't as easy as we think
[05:25:59] <cradek> could you make the clock much slower and do the same test?
[05:31:19] <cradek> I'm off to bed, goodnight
[05:36:08] <garage_seb> thanks for your help chris
[05:36:12] <garage_seb> goodnight
[13:24:50] <alex_joni> jthornton_: hi
[13:24:56] <alex_joni> just ask nicely at webersys
[13:25:05] <alex_joni> worked for me
[13:26:45] <jthornton_> alex_joni: hi
[13:26:47] <jthornton_> ok will do
[17:20:39] <cradek> http://timeguy.com/cradek-files/emc/touchy-axes.png
[17:20:51] <cradek> except for the homing buttons I'm happy with it...
[17:24:09] <CIA-40> EMC: 03cradek 07master * r618ba36dc181 10/src/emc/usr_intf/touchy/touchy.py: This nothing-change is only to make emacs happy.
[17:24:09] <CIA-40> EMC: 03cradek 07master * r43f513d028d8 10/src/emc/usr_intf/touchy/ (touchy.glade touchy.py): Undisplay wheel buttons for absent axes
[17:26:20] <Jymmm> cradek: Is that intended for a touch screen control?
[17:28:14] <cradek> Jymmm: yes, I've been using it for a while, only now I'm adding support for machines other than just XYZ (like mine)
[17:29:39] <cradek> Jymmm: I couldn't bear to put a pc keyboard on my new mill so I wrote this gui instead.
[17:29:48] <Jymmm> Ah. Wouldn't chunkier square controls be better than thin rectangles? A person's finger isn't very wide.
[17:29:59] <Jymmm> LOL, I understand =)
[17:30:03] <cradek> it works surprisingly great
[17:30:20] <Jymmm> what size display?
[17:30:27] <cradek> mine is 15"
[17:31:53] <Jymmm> MY Bank's ATM machine uses touch screens. I find them to be a pita as you have to hit it exactly on target. They use a lot of rectangles instead of chunkier squares.
[17:32:19] <cradek> bad quality or badly calibrated touch screens suck
[17:32:33] <Jymmm> And if you are not looking at it at the right angle, it's even worse.
[17:33:04] <cradek> the research I've read says a 3/4" square is the minimum size button you should expect the user to be able to hit reliably
[17:33:47] <cradek> a design goal of touchy is that hitting an incorrect button doesn't cause the machine to do an unwanted thing - you can simply correct it by trying again
[17:34:20] <cradek> that's true for program control and jogging and mdi, but currently not for homing
[17:34:46] <Jymmm> If that screen shot is to scale, it's 5/8" not 3/4"
[17:35:00] <cradek> heh
[17:35:25] <cradek> with all these axes it's tougher, but you can resize stuff however you want if your screen is better or worse.
[17:36:15] <cradek> on my monitor the window image measures about 11" diagonal, fwiw, but that's nothing universal
[17:36:42] <Jymmm> Heh.
[17:37:02] <Jymmm> The rectangles might be good for sliders
[17:37:18] <cradek> sliders don't work on touchscreens
[17:37:27] <Jymmm> well, that sucks.
[17:37:29] <cradek> touchscreens don't do anything but clicks well
[17:37:43] <cradek> it doesn't necessarily suck, but it IS a design constraint
[17:37:54] <Jymmm> No, it sucks. =)
[17:38:16] <Jymmm> means you can't even do drag-and-drop
[17:38:20] <cradek> many of the usual widgets we manipulate with a mouse don't work well - a certain application can't work well with both.
[17:38:36] <cradek> nope, no dragging, no right click, etc
[17:39:01] <Jymmm> Is it quick enough to bring up a sub-screen/control?
[17:39:13] <cradek> I don't understand
[17:40:03] <cradek> oh you mean click one thing, more things appear, you click one of them?
[17:40:09] <Jymmm> Right.
[17:40:13] <cradek> I bet you could do that, but touchy doesn't
[17:40:18] <Jymmm> k
[17:41:11] <Jymmm> I was thinking a sub-keypad for MDI input, or some such thing to emulate a slider type control.
[17:41:37] <cradek> you should try touchy's MDI input. I think it's really good.
[17:42:06] <Jymmm> a wide ruler that you can tap on at various points to get a slider-type effect - if that makes sense.
[17:42:35] <Jymmm> But as a sub-control so it's not on the screen all the time.
[17:42:35] <cradek> well --- I think sliders suck, even with a mouse, and you're just making it worse with a touchscreen
[17:43:06] <cradek> with touchy you use the wheel where a normal gui would use a slider
[17:43:59] <Jymmm> mouse wheel?
[17:44:19] <Jymmm> or like a on-screen dial
[17:44:35] <cradek> no no no
[17:44:39] <cradek> no mouse wheel (no mouse)
[17:44:44] <cradek> no on-screen dial (UGH)
[17:44:50] <Jymmm> heh
[17:44:52] <cradek> encoder style jog wheel
[17:45:06] <cradek> remember, it's a cnc control :-)
[17:45:36] <cradek> http://timeguy.com/cradek-files/emc/jr.jpg
[17:46:03] <cradek> the controls along the bottom are required and are part of touchy. it will not work without them.
[17:46:18] <Jymmm> ah, ok.
[17:47:40] <Jymmm> Now, this would be cool...
http://www.3dconnexion.com/3dmouse/spacenavigator.php
[17:48:09] <cradek> you're just mistaken about that IMO :-)
[17:49:13] <Jymmm> Nah, it does have a coolness effect, not sure about functionality > 3 axis
[17:49:29] <cradek> cool is for video games
[17:49:53] <cradek> precise control and oil-proof and coolant-proof is for cnc machines
[17:51:01] <cradek> I definitely see the appeal of using cheap video game type usb doohickeys but I don't think they would hold up very well.
[17:51:17] <Jymmm> Well, since I just do wood/plastic, I don't think along those lines too much.
[17:51:27] <cradek> ah
[17:51:38] <cradek> I'd think wood dust is just about as nasty, no?
[17:52:55] <Jymmm> It would be, but I had built a dust enclosure for the whole machine and use a shopvac attached to the rear and a HVAC filter to keep it contained.
[17:53:21] <cradek> that sounds nice
[17:53:31] <Jymmm> I had been doing a lot of MDF, and that is just some nasty dust to breath in.
[17:54:02] <cradek> wish there was an equivalent for metal (other than lots of sheet metal to try to keep the splashing contained)
[17:54:31] <cradek> I end up wearing and mopping a lot less coolant with this machine than the last one though, so it's all good
[17:54:52] <Jymmm> http://farm1.static.flickr.com/149/424362153_e80fc2eb16_b.jpg
[17:55:22] <cradek> wow, well contained indeed
[17:55:48] <cradek> I like the workbench made of shelving - clever
[17:56:39] <Jymmm> The wall just bolt together and to the gorilla rack. It's lined with aluminim screen then clear vinyl. the aluminim screen has ground wire to keep any static build up minimal
[17:57:43] <Jymmm> Yeah, the gorilla rack has that configuration as an option - and includes these little lock adapters to lock the two pieces together.
[17:58:54] <Jymmm> the doors are removable by pulling the hinge pins.
[17:59:50] <Jymmm> The base has like two coats of PU, so it *could* hold fluids if I sealed the edges.
[18:07:18] <Jymmm> cradek: Just be sure to have a dead-blow hammer or you'll never get it assembled
http://www.gorillarack.com/raptor/grz648185bdi-storage-rack-p-54.html
[18:07:33] <cradek> something tells me I'm going to need a different approach:
http://timeguy.com/cradek-files/emc/homehomehomehome.png
[18:08:19] <jepler> that's funny
[18:09:00] <Jymmm> What about a 3x3 layout?
[18:09:30] <cradek> "Home All" "Home the axis selected by that button over there --->"
[18:09:41] <cradek> ?
[18:09:45] <jepler> cradek: I was thinking about the same idea
[18:09:50] <jepler> but I'm not sure that constitutes my endorsement
[18:09:55] <Jymmm> heh
[18:10:08] <cradek> but "Jogging" has to turn into something else because it enables those
[18:10:17] <jepler> would the axis buttons be available when Jogging is not selected, then?
[18:10:28] <cradek> yeah, that's what I'm wondering
[18:10:31] <jepler> or do you have to select jogging, then X, then Home Current?
[18:10:38] <cradek> the interaction is already a bit muddled
[18:11:12] <cradek> and, if I lose the separate butticators I have to show which axes are homed some other way
[18:11:33] <jepler> yeah
[18:11:50] <Jymmm> Can the buttons display current position?
[18:12:02] <cradek> I can show it on the status tab, but that's a bit hidden
[18:12:12] <cradek> Jymmm: I don't follow
[18:12:30] <jepler> cradek: what about a home symbol up on the DRO, like in axis?
[18:12:40] <Jymmm> [Home X \n-0.0032]
[18:12:46] <cradek> yeah that must be it
[18:12:57] <cradek> Jymmm: why put the position in two places?
[18:13:32] <Jymmm> If you places the position on the buttons, you wouldn't need it in a seperate area.
[18:13:42] <Jymmm> save soem RE
[18:13:52] <cradek> Jymmm: notice the home buttons are in a tab
[18:14:16] <cradek> (also notice there are several different pieces of position information displayed up above)
[18:14:58] <cradek> I'm not sure you need the DRO when homing, but I like the consistency of it always showing the same way
[18:15:38] <Jymmm> do you need the tabs?
[18:15:59] <cradek> brb
[18:18:28] <Jymmm> I was just looking at these scrnshots for ideas...
http://www.bg-cnc.com/wordpress/?p=183
[18:43:18] <dgarr> a tooledit.tcl patch for consideration:
http://www.panix.com/~dgarrett/stuff/0001-preclude-warnings-when-file-mtime-changes-but-file-m.patch
[19:02:51] <robh_> it would be nice if with tooledit you could add or subtract an ammount from a tool offset with out doing the sums manuly
[19:09:16] <cradek> dgarr: what is the user supposed to do when he gets this message?
[19:19:44] <dgarr> cradek: reload it to see what was changed (of course local edits will be lost)
[19:20:20] <dgarr> the patch eliminates warnings when nothing changed (but the mtime changed)
[19:20:34] <cradek> ok I understand
[19:21:58] <cradek> (I think tooledit or anything else other than task reading and writing the file directly is the wrong approach for these reasons)
[19:23:44] <cradek> but maybe that is neither here nor there
[19:46:20] <CIA-40> EMC: 03cradek 07master * rc1347b9a7348 10/src/emc/usr_intf/touchy/ (emc_interface.py touchy.glade touchy.py): new homing scheme that works better when there are many axes
[20:52:39] <PCW> Sebastian: re- velocity estimation:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-07-16.txt : 2009-07-16 20:37:27
[20:54:15] <cradek> heh, this is relevant to my interests...
[20:57:50] <Jymmm> ?
[20:58:16] <cradek> I think this might be in response to the plot I made late last night
[20:58:40] <cradek> http://timeguy.com/cradek-files/emc/encoder-velocity.png
[20:58:48] <PCW> Yep i looked at the irc log and saw that raspy plot
[20:59:31] <PCW> And vaguely remembered that I had promised to fix the hardware (but never got around to it)
[20:59:42] <cradek> PCW: normally I wouldn't ever go that slow :-)
[21:00:21] <PCW> Well you would not want to use the velocity estimate for dampling even at stop
[21:00:38] <PCW> (or especially at stop)
[21:00:42] <cradek> yeah
[21:01:00] <micges> Tomorrow I'll do some more tests and screencaps, maybe that helps (Today I'm sick at home :|)
[21:01:44] <micges> seb described me what is important to look
[21:01:50] <cradek> ah good
[21:01:58] <cradek> and hope you feel better soon!
[21:02:11] <micges> thanks
[21:15:28] <jt-plasma> cradek: thanks for the requested-vel pin that makes it work real slick :)
[21:15:58] <cradek> cool, you're welcome, glad it was what you needed, since it was about all I could give you :-)
[21:16:49] <jt-plasma> it was exactly what I needed
[21:44:57] <alex_joni> jt-plasma: cool
[22:29:23] <jt-plasma> alex_joni: hi
[22:35:39] <alex_joni> hi
[22:46:14] <jt-plasma> I'm getting closer to the final test :O
[23:08:24] <alex_joni> nice
[23:10:26] <jt-plasma> yea, I'm stoked :)
[23:12:33] <jepler> cradek: I dunno when it changed, but today having touchy running is pegging the CPU (top reports it's xorg)
[23:14:00] <cradek> jepler: hmmmm
[23:14:08] <cradek> with today's changes?
[23:14:30] <jepler> wait a bit, I'll check
[23:14:43] <jepler> by the way, this seems to get rid of that unwanted focus indicator: fg[INSENSITIVE] = darker (@bg_color)
[23:14:46] <jepler> + GtkWidget::focus-line-width = 0
[23:15:17] <cradek> I'm not seeing it - touchy 27% Xorg 10%
[23:15:22] <cradek> (still pretty high)
[23:15:53] <jepler> bbl, apparently I have a prior engaugement
[23:22:34] <dgarr> cradek: getting closer i think,
http://www.panix.com/~dgarrett/stuff/0001-Numbered-parameters-for-current-tool-items.patch
[23:22:41] <CIA-40> EMC: 03cradek 07master * raa2e913a4397 10/src/emc/usr_intf/touchy/touchy.py: jaunty needs this - gnome version difference?
[23:29:32] <cradek> dgarr: digesting...
[23:30:05] <dgarr> it keeps getting more complicated
[23:30:18] <cradek> I was just thinking about how it's surprisingly complex
[23:31:26] <cradek> especially the parameters_modified thing - i'm trying to follow it
[23:32:19] <cradek> also I think you must have lost your mind by the time you wrote this ",cur_zoffset // z offset" stuff - hope you're not permanently damaged :-)
[23:34:13] <cradek> oh heck I see another thing - there is sometimes a W tool offset instead of Z
[23:35:43] <cradek> for example see convert_setup_tool's use of GET_EXTERNAL_TLO_IS_ALONG_W
[23:37:29] <cradek> off to dinner, bbl
