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