.. didn't immediately get hm2 high-resolution proving to work, unfortunately
something's not right in the communication between the driver and the firmware
I haven't figured out just what, yet
in principle it's nice and easy: the driver tells the firmware to store the exact number of counts when the probe makes contact and set a flag. When it sees the flag set, it converts the stored counts into a probed position. the end.
but my modified hostmot2 driver (not yet commited to git.linuxcnc.org) just doesn't work right. sometimes the probed position just keeps changing, other times it doesn't change at all
probably something I'm overlooking still
micges_work: do you use emc gcode subroutines?
i wrote a tcl/tk script as a frontend gui for subroutines: see http://www.panix.com/~dgarrett/ngcgui/ngcgui.txt
dgarr: Cool, I use my own gcode generators ;)
this gui makes it easy to call up subroutines -- i'm finding it useful for debugging them
dgarr: I was thinking that you want ask about subroutines ;)
no -- i'm trying to get someone to try this gui and give me some feedback
what is the syntax for a font for touchy?
I've tried in the [default] section control_font = sans 16
I saw this in the terminal when running touchy No option 'control_font' in section: 'DEFAULT'
so I added a [DEFAULT] section to the ini
you should edit touchy's font using touchy, not by editing any inifile
I think if one of us can just figure out how to set that for touchy, it will kill the "last button clicked looks funny" behavior
jepler: hey slick
ok, I was just guessing :)
jt-dev: it gives a warning the first time - it's a "feature" of the ini file module - you can just ignore it
.touchy_preferences actually gets filled out with the default entries the first time you run touchy
then it uses that to save your fonts, commanded/actual, block delete, etc settings
so if you wanted to set touchy up on a normal computer then copy it to another one that had a touch screen you would need .touchy_preferences
* jt-dev heads out
Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-10-23.txt
/msg nickserv identify Mp62i-0003uU-QD
time to change your password
wow - I thought I was the only one that did that..
btw - we#re on to something, mail coming
told ya, MBA...
mhaberler: what is the gcode like? is this a g76?
here's the file I ran: http://mah.priv.at/cgi-bin/viewvc.cgi/emc-syncmove/threading-mah.ngc?revision=1.3&root=CVS&sortby=date&view=markup
so what I'm seeing is two consecutive passes in that while loop?
does it oscillate sometimes, or every other time through, or some other pattern?
usually a couple of clean passes, then one or several jerky ones, than clean again - no clear pattern like alternating or so
wait, this must not be the same code I'm running, because sync-accel stays constant
what version is this? 'git describe'
I pulled yesterday and did a branch for the debug pins; no other changes
Error: does not exist
cradek: indeed it doesn't :P
this I know
where's BJT when you need him :P
mhaberler: are spindle-vel and target-vel zero as well as sync-accel doesn't trigger? something is very wrong there.
if you could get a sim configuration where this happens it would be really nice.
alex_joni: I thought you were going to show me some docs you put together ... imagine my disappointment!
I'm working on them :)
our hero as usual :-)
cradek: I can imagine :)
but my plan was to whine enough so that BJT takes pitty in us
I'm retrofittng 85' laser which have mechanical switches and earlier it has switches that slow down homing to about 5 mm/min
cradek: yes, looks like thats the case. other environment change is a self-built smp kernel because its a Core2 cpu but I'll revert to the vanilla kernel for now to exclude that
Any restrictions for adding support for such thing to emc?
micges: how does it work?
as we barely run it
it is huge table laser 2.5x2.5m
seems like you could do it with one switch with emc, since it can find the switch fast, then pull back off, then go slow and find it again
maybe the old control was not smart enough to do that
jepler: the only other thing that might help is to make the pointer disappear
cradek: ah yes you right, nm then
micges: you just have to be sure the switch stays tripped long enough for the machine to decelerate and stop
ideally the home switch cam goes all the way past the limit switch position
cradek: at low speed it is possible
jepler: hm, it doesn't change for me - is that because I'm on dapper?
cradek: yes, it looks that way
I tested it on hardy
I have a way to set the cursor invisible but it makes touchy real hard to use without the touchscreen!
hm, yeah I bet
maybe it could be a preference, if we can fit it on the prefs screen somewhere
how can one additionally secure(in software) machine if it is some very fast machine for mass production (3d mill, velmax=150, acc=11000. some ideas, thoughts?
I've found only some additional soft limits settings
what do you mean secure?
dont fully know, I'm only afraid what suddenly position hold after some errors can do with it
I think that all stops in emc are with deacc?
all normal stops have full deceleration
estop and following error just disable the amps to stop - if you need braking you should have brakes
ah yes brakes
micges: on fast machines, e.g. our robots, each motor has a mechanical brake
if you take off power from the machine, the brakes engage and the axis stops abruptly
this can be pretty scary, but it's safer
(imagine a big axis - maybe 2000kg of moving mass - running at 1m/sec and stopping with a brake)
uh oh inertia ?;)
ok thanks guys
if dc motors, you can get cheap braking by shorting the servo motor leads with a contactor (IF your amps can survive having the motors disconnected for an emergency stop)
cradek: I will check this
micges: some amps will blow up if you remove the motor while the amp is on - some have protection because they expect you to do that to brake
<- not an expert
EMC: 03seb 07master * r7c7714bd83de 10/docs/man/man9/hostmot2.9: clarify hm2 encoder x1 mode
EMC: 03seb 07v2_3_branch * r6905a465d120 10/docs/man/man9/hostmot2.9: clarify hm2 encoder x1 mode
cradek: simulated config done, see mail
EMC: 03cradek 07master * rbb0039c7a71d 10/docs/man/man9/hostmot2.9: Revert "clarify hm2 encoder x1 mode"
EMC: 03cradek 07v2_3_branch * rcbd82b5004fa 10/docs/man/man9/hostmot2.9: Revert "clarify hm2 encoder x1 mode"
cutter compensation gouge at exit -- not sure why, if i increase k2 to 0.1 it doesn't
simulator, 2.4-0pre, 0.5 tool diameter
dgar1: looking ... a little hard to follow the gcode.
using named parameters makes it hard to follow?
well ... all of it :-)
i could change it back to #1, #2 everywhere :-/
also baffling is I'm getting old debug output from my build, even though I did a clean and rebuild
and the string it's printing isn't found by grep
and block delete wasn't working, but now it is after the rebuild
ohhh, that's your output, not mine
jeez, I'm slow tonight
this move is 0.4883 long
ok that doesn't matter
let me show you a picture
? .501 = sqrt(2 *.35426) (not including tool radius compensation)
that too (doesnt matter i think)
len is sqrt( 2 * (.35426)^2 )
yes on sqrt .501i guess my question is (for k2=0) should there be an error/or warning or is it expected to do that
[23:57:23] <cradek> http://timeguy.com/cradek-files/emc/exit.png
this is the uncompensated path, with a tool of 0.5
I changed the exit rapid so you can see it
see how with these two moves you make a corner where the tool can't fit?
it can't get in there to touch that short line that goes up and right
if you were to continue on and program some more compensated moves, you would see this error
in fact I did that by moving the g40 down under the g0, and I got the error
you are hiding the error by turning off compensation at just the right time