Does this mean I need to supply the donuts?
(being the lowest common demonimator?)
coffee should be provided by BigjohnT
skunkworksemc: thank you
holy crap, all the same people!?
skunkworks: thanks, I think you would have been a good choice too.
eh - bigjohn has done a ton more than me...
I am more of a jester..
there were no bad choices, only good
I lost no sleep about it.
The board is strong. this last year was very exciting.
[Global Notice] Hi all, I'm going to need to take down services (Nick,Chan,MemoServ etc) for a few moments to apply a tiny little fix. It shouldn't take more than a couple of minutes and I'll let you know when they're back up again. Apologies for the inconvenience and have a good day!
[Global Notice] Hi all, as promised I return services to you, I'm all done and they're nearly as new! Have a good day and thank you for using freenode.
doing a full rebuild of the linux-image packages takes quite a while
paul is a really good instigator.. Is that something you are born with? Some sort of class? (at least he tries to be)
Good Morning! :)
I'm sure it's a gift
I just verified that his email is in the list the board sent to michael. if that is his accusation (he doesn't say what it is, actually) he is wrong. but, maybe he has a much larger conspiracy in mind.
I am sure.
what other list would there be? I just don't understand.
are you supposed to get every users email also?
I won't guess what his conspiracy theory is. who knows.
I dunno, but here's what not to do if you have something constructive to contribue to make the emc board election better and more fair. 1: read announcement of nominations and say nothing. 2: read announcement that ballots have been sent and say nothing. 3: read announcement of results, and scream bloody murder
(I'm hope michael doesn't have to deal with him)
jepler: but coincidentally and surprisingly, that's just what you might choose to do if you're a troll trying to spread FUD around!
Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-02-05.txt
is there a display that is suitable for a touch screen display (800x600). I haven't tried tkemc yet but that looks the part
cradek: now that there is a tab for dro in axis - maybe a tab for a keyboard? ;)
"Slippery Slope" ;)
and a web browser...
skunkworks, like your thinking
skunkworks_: don't be ridiculous
the way the BOSS does mdi with a limited (numeric only) keypad is kind of clever
it says G? and you type 01 enter
then it knows G01 takes X,Y,Z,F and prompts you for each one (you can leave them blank if you don't want that word specified)
then, once through all the letters, you can review the command and press execute
so you really don't need a full keyboard
if I wanted a touchscreen only gui I'd try something similar to that. I think you couldn't have a full keyboard on a touchscreen.
(they work bad enough for just a few buttons)
our fanuc has a numeric keypad with letters. so you first press the key with the letter you want - then it turns to a number pad
Big John - minor manual typo ini_config.lyx line 2277: mm should be inches
pcw: can you give me a couple of words of text from that line?
desired units of mm
and 10 revs/inch gearing, and desired units of mm, we have
hmmm it is in there twice
heres another in the same file: units on the I gain are volts per machine unit per second
should be something like : units of I gain are volts per machine unit second
the first one sounds right to me... but I'm not sure that I don't know everything I don't know about that yet :)
the formula is right but not the words in the I section (the "per" is wrong)
* compare with "D"
I was reading a patent last night and everything that should have been expressed in formula was spelled out in sentences. it made it very hard to understand. if we can display the formula, maybe just remove the words.
BigJohnT, the I term is multiplied by the integral of machine units of error over time, so the resulting unit (of the integration) is machine units * seconds
and since the result of multiplying by IGain is volts, IGain has to be "volts / (machine units * seconds)
most people just call it I though :)
start of a program to convert the output of "rs274" back into gcode--a possible basis for gcode preprocessors that correctly understand all gcode syntax: http://emergent.unpy.net/files/sandbox/unsai.py
doesn't do much yet, but it does do G0 and G1 moves
I can see people liking rotatecnc and flipcnc from that ncutils dir
and shift, for that matter
a rewrite of them in jepler's style would be so much better. ad-hoc parsing of gcode with strstr() is a bad way to approach the problem.
oh, for sure
although, even jepler's style will unroll loops and subroutines for instance
every approach stinks
(but, it'll actually work)
they just have different, interesting smells
sniff sniff ... ancient brie
man. dealing with all legal g-code is really a mind boggling problem (unless you don't mind screwing up the original text)
it's not a hard problem if you just use the interpreter
oh, there's an idea
that's what jeff just did
just the fact that you can have spaces anywhere is an issue
for regexp things anyway
so, here's a cron question
[15:56:15] <cradek> http://www.codinghorror.com/blog/archives/001016.html
it looks like the way to make a program "stay running" is to set it up as a * * * * * cron job, and have the program (script) itself check to see if it's already active
yeah I wish there was a good way to do that
is there a way to have cron monitor processes and keep them running (or some other program, similar to the way init does things)
I wish cron had "if this program is still running, it's an error" and "if this program is still running, just do nothing"
yep, that would be nice
not that I know.
tempting: if [ -z "`pidof program`" ]; then program --args &; fi
yep. that's what I've been looking at
yeah, that's all there is to it, but ick
probably in the script, but maybe in the crontab
cradek: his regular expression is wrong
pidof is not smart enough to return only your own processes
cradek: it will permit stuff inside <a> tags that shouldn't be
pgrep -u is smart enough
a "-u" option to pidof would be obvious
if ! pgrep -u myuid program; then program -- args &; fi
(ah, in the "full program" he has additional checking of <a> tags that is not in the basic regular expression he showed there)
[16:06:43] <fenn> http://linuxcnc.org/docs/
should have a link to 2.3
they are still /devel until we branch
hey pcw, have you ever considered replacing the power connectors on your daughtercards with a pair of screw terminals?
fenn: the bottom link is to 2.3
SWP: Yes, the -TA series have screw terminal power conns (and all terminal blocks included)
(and wider spacing of TBS so you can actually pull then TBs off without being a tough-guy)
good morning guys
pcw: neat - the only complaint I had about using the -T boards was I had to pull the strip off to access the screws. is the TA the same or is it a different kind of screw?
cradek, you can use shorter terminal blocks, but you need to be careful plugging them in
The TA use top screw/side entry plugs
pcw: perfect, I will get those next time
(also plugs are 3x8 so are easier to pull off)
one of these days I will retrofit the mill...
if only it would croak I'd do it now
* SWPadnos chants "angled socket for the outer connector"
SWP: We had to buy a gazilion of the plugs so they are unlikely to change
the plugs would be the same, it's the board-mount sockets I'm chanting about
pcw: will the base 5i20 be available for a while? It's enough for me and I like how it's so much cheaper
the 5i22 isn't much more
We have no plans on obsoleting the 5I20
$229 instead of $199, 400k gate FPGA, 3 connectors
many non-EMC customers
huh, I thought the 5i20 was MUCH cheaper than that
the 5i23 is the expensive one, $369 or $429 depending on FPGA sice (1M and 1.5M gates)
you mean 22
yes, yes I do
another plug is nice, but I won't need it on the mill
operator panel :)
cradek: lots less 'misc stuff' than the lathe
jepler: yeah, lots less
it's really quite simple in comparison
which is funny, considering that it has an extra servo and all
and limit/home switches ...
one limit switch and one home switch per axis
ok, home is -limit?
no, both limits are one switch
oh, right - there's a cam doohicky that hits the same switch at either end
We _may_ have cheaper (no bridge) PCI and PCIE cards this year if I get a round to-it
plus some 2m gate 144 I/O cards
config EEPROM on the cards, I presume?
I have no complaint about your prices - the stuff works great for me. if you fixed the screw problem, that's icing on the cake.
that will be cool
while your here pcw what is the P1 plug on the 7i31?
PCIe version will use PCIe-PCI bridge with 4 GPIO bits so it can be bootstrapped
don't connnect a floppy power cable to it :)
unless you first remove the 12V wire
and make sure the 5i20 is configured for 5V
No its our pre 3.5" floppy power connector weve used for 15+ years
connect floppy power = asplode PC
have you let the magic smoke out of one SWPadnos ?
Slowly removing it from everthing
I noticed it before plugging anything in :)
I just had the thought of making a little power supply board that plugs into your connector, and takes maybe 9-36V in via screw terminals
Normally they aux power connector are not needed
Only when you can supply enough power for encoders etc through the flat cable
We should probably just remove it from the 7I31
yeah, the anyIO or daughtercard would need power, not the 7i31
* copy&paste PCB error
though adding the 7i31 could make the total draw too high to run the "card under test", so having it on the 7i31 allows you to do a slightly less invasive test
incidentally, the second 50-pin header might be nice on some of the other cards as well
using the 7i33 for example, if I want to use only 3 servo axes and the rest for GPIO, it's a real pain to break out the few pins needed
SWPadnos: just add another IDC to the cable...?
sure, that's an option
seems better than making the board bigger and more expensive
Yeah its usually a space issue
but you probably need to cut and/or move some wires around
I'd just split the cable before terminating the 7I33 end 50 pin receptacle
I guess it's a PITA no matter how you s(p)lice it :)
yeah, its where the flexibility of the FPGA I/O ends
What do you think of the idea of some module IDs being "hints"
that a certain range of I/O pins are preconfigured for a certain type
of daughter card?
loadrt ... p1=7i31 p2=7i33
I think a dedicated person could set up the equivalent of this using only hal aliases
that's true once the pins have been created
it would keep the complexity out of the driver (whether that's good or bad I can't say)
Well i was thinking an i/o pin range as being more generic
this is mainly for complicated cards (say 7I65) that have very specific
requirements (BSPI on some pins MuxedEncoder on others etc)
ah, you have more in mind than I do. I was thinking about how people using the old 5i20 driver are going to have a hard time updating to hm2 because the pin names are much more obscure
too bad sed can't do math (?)
Yeah, at least dropping the P? is a good thing for hostmot2 card-card config file compatibility
a "5i20_compat.hal" file using alias might be a nice contribution
load hm2_pci with 4 encoder+pwm and alias everything to hal_m5i20 naming
how does the older naming work?
Yes, that would be a good starting point for someone upgrading
I know the connector number is in there, is the other number the pin or the "consecutive GPIO" number?
old naming is directly the screws on the 7i3x cards
SWPadnos: I dunno, and you can look at the hal file as easily as me
it assumes which cards you have
oh right, 1 servo card, 2 GPIO cards
it's very simple
pcw: my initial reaction is opposed... it seems to me to build too much deployment-specific information into the firmware
it seems better to get that information from the user and supply it to the driver somehow (i dont know exactly how though)
seb_kuzminsky, I don't know if you saw the conversations with motioncontrol in the last couple of days
the problem he thought he had wasn't there
i didnt see it
was it here on #emc-devel?
using two cards, the second one wasn't seen
but then it turned out to not be a problem after all and the second card appeared?
yes, but ...
the config string is supposed to be an array of strings, but I didn't see how that happens
and there were times when I loaded the driver, got no error messages or anything, and had no HAL objects exported
hm that sounds strange
yeah. I don't recall what was in dmesg
here's an example of how the config argument to the hm2_foo drivers is an array of strings:
[17:38:46] <seb_kuzminsky> http://highlab.com/~seb/lots-of-pins
I'll look at it more, but just mull over what could be wrong in config line parsing
not sure if that works so well when there's spaces in the per-array-entry strings...
right, I thought spaces could be (part of) the problem
seb_kuzminsky: what happens if you chenge the board order?
then you have to change the order of the config strings to match
in the end, using config="firmware ... num_encoders=4 ...,firmware=... blah blah" worked
hm2_5i20.0 is the first one handed to the driver by the linux hotplug system, hm2_5i20.1 is the second one etc
so how do I know what the card order is?
with or without a space after the comma
in your example there's a 5i20, 5i22, and 4i68
the driver detects and numbers different anyio boards separately, so if you have one 5i20 and one 5i23, it's always hm2_5i20.0 and hm2_5i23.0
but the first one found gets the first config string etc
say I have a 5i20 and a 5i23
and I want to load them both with hal_pci
do I supply the 5i20 firmware first or the 5i23?
alex_joni: it depends :-(
on what order the kernel hotplug wants to give them to you in
I know it does, the question was more like.. how do I find out?
just try & mix and match till it works?
i dont know a better way than "try it one way and if it doesnt work try it the other"
ok, that answers my question :)
maybe starting up without any firmwares could show a list of probed boards
i *think* the hotplug system is repeatable in the order it gives boards to drivers (same each time it loads), but i dont know how to predict the order apriori
or something like that
the driver prints a lot of stuff, maybe if "config" is blank, it should print a board list
alex_joni: currently starting without firmware makes the driver assume the boards already have firmwares and it tries to initialize them
hm2_pci: found board 0: 5i23-1.5
hm2_pci: found board 1: 5i20
he always mixes those
good thing he has a couple of each?
at driver load time, it currently already lists all boards it finds, and what name it gives each one
that's independent of whether the board(s) actually successfully initialize or not
seb_kuzminsky: ah, right.. than that should be enough
ok. the dmesg is long, so I don't see it all ;)
so we sort of already get that info, though not in the most convenient format
simply run loadrt hal_pci, and then you get the info
that's what humans are for, parsing and interpreting
I'm happy with that
ok wait there were some bug reports up in my irc buffer
seb_kuzminsky: I only have one 5i20 on a shelf
* seb_kuzminsky reads back
so this is not an issue for me, but wanted to know in case users pop up in #emc
<SWPadnos>: and there were times when I loaded the driver, got no error messages or anything, and had no HAL objects exported
ok, it does report what it finds, but only as the boards are configured and HAL objects exported
if a board is detected but fails to configure (because it doesnt have firmware and you didnt ask it to load some using config="firmware=foo.bit") it should be listed with a "failed to init"
I think a concise list at the beginning would be good for determining board order
SWPadnos: that's not easy to do
at "the beginning" there are no boards
right, you get "hotplug" events when the driver is loaded
then over time the board hotplug callback gets called zero or more times (^^ right)
i think i had the hm2_pci driver emit the pci address as well as the hm2 name it gave each board
it prints the address at the start of initialization, and the name at the end
i'm more concerned about the report above about it failing to do anything at loadtime
it should enumerate all the anyio boards and say *something* about each one
the name is only printed because the message is "hm2_5i20.0: initialized ..."
including the pci address, and whether or not it initialized it
i see on feb 1 motioncontrol got the encoder vel warning in 2.2.8
that's fixed in trunk
hmmm. I wonder if the "nothing shows up" problem occurs when the board hasn't yet been programmed, and the firmware mane is unrecognized or something
in that case it should say "found a board (at PCI addr foo) but failed to initialize it, no firmware??"
yeah, and the component should fail to load, right?
at that point its already loaded successfully
right, since init is done by hotplug
ok, so that's probably the problem
messages go to dmesg
nothing is printed on the terminal
the component loaded fine
that's awkward isnt it... :-(
and no pins exist, so emc bombs later with errors about nonexistent pins / functions ...
ok i found some stuff from motioncontrol on feb 3
ideally, hal_ready shouldn't be called until all initialization has been done, including doing configuration of all specified cards
but I don't know if that's even possible
i think it's possible, but i think it's working against the hotplug system rather than with it
do you know if the driver will get hotplug events before it has finished "module_init"
(after hotplug_register, but before "I'm done now")
i think it won't, but i'm not sure... hold on i'll check
hotplug actually works against us
we want a stable system, defined by our hal files
not one that may change over time, as hardware is plugged/unplugged
these are opposite goals
the only common feature is that both EMC and hotplug want to be able to load firmware
firmware loading and hotplug are separate facilities in linux, you can have either one without the other
I thought the whole reason for using hotplug was to have access to request_firmware?
the reason for using hotplug is that that's what the kernel people are recommending these days for dealing with pci devices
they're working on unifying all the pci-ish busses, and hotplug is the interface they chose for it
sure, and there's also support for PCI hotplug, so it makes sense
too bad it's the opposite of useful to us :)
[18:08:25] <SWPadnos> http://pastebin.ca/1328188
Sebastian: I guess a command line hint would do as well but it would duplicate hardwired information in the FPGA config
oh, I should have restricted that to hm2*
EMC: 03jepler 07TRUNK * 10emc2/src/hal/halmodule.cc: better support for assigning longs to hal pins. related to SF#2569072 but may not totally fix it.
only 418 pins when I do that :)
what does the fpga know about the daughter boards? i thought nothing - if that's not true then my initial reaction is probably wrong
seb_kuzminsky: you didn't run halui :)
stupid tabcomplete doesn't read my mind..
one of those "s" guys anyway ;-)
darned stupid tab complete
some days I wonder why it won't complete words I'm typing
Sebastian: It does implicitly because of pinouts, for more complicated daughtercards I think it
might be appropriate to know a little more (its just a hint and can be ignored)
SWPadnos: looks like maybe pci_get_device() can be made to iterate over all the currently connected devices, avoiding hotplug
(lots of free module IDs)
seb_kuzminsky, ok. I wonder if it would keep the same order like hotplug is supposed to
seems likely, since that's probably how hotplug gets the card info in the first place :)
SWPadnos: no idea, all the docs i've seen say "dont rely on the ordering"
pcw: is the 7i65 the impetus for this?
pcw, any chance of sticking a serial number in the EEPROM on these cards?
and silkscreening the serial number on the board ;-)
or making a utility to check/set/blink LEDS for a specific serial number (or PCI ID)
lol, morse code the sn out the leds
Yes mainly but also 7I48, though it can be mostly transparent
7I65 does have an EEPROM (for A-D cal)
flexible stuff like this really benefits from all the components being able to identify themselves
i realize that that adds complexity and expense :-(
Thats the problem...
but if the hardware can't be probed and identified we're stuck telling the computer what it is, which gets hairy too
That was kind of my idea of the hint (7I65 on IO pins 24..47)
(then enable or not)
but what if the user would prefer to plug it into io 0-23? because they're on a stepper maching maybe
we could have different firmwares with different hints, but that's just another way of the user providing the hint
If the hardware was there (on pins 0..23), there would be another hint
* if I had it to do all over I'd put a EEPROM on all daughter cards
* with a common access method for probe
i'll think about it peter
Maybe it can be done in the existing framework
maybe something like that can work
currently you get the *first* n instances of the module you request, there's no way to say "gimme encoders 0, 1, 4 and 7"
seems we'd want to specify *where* the 7i65's are connected, in addition to how many there are
You would be stuck with the aggregate # of encoders/dacs
something like that should work, but note that the user specifies it all; it doesnt use any hints from the firmware
Sebastian: hint could validate user choice
PCW: i'm not sure, does the driver still talk to the 7i65 via 8xPWM, 8xencoder, etc? or is it totally different?
No, 7I65 has SPI DACs, SPI ADCs SPI enables and Muxed encoders
(though the muxed encoders should be trivial to support just another module ID)
ok i see
does muxing the encoders decrease the maximum count rate much?
Maybe to 4 MHz max
(4 m counts/sec)
PCW: does it have a single spi with all the devices on the 7i65, or one spi per device on the 7i65?
one spi for all the spi-stuff on the 7i65, plus all the non-spi stuff on the 7i65
(muxed encoders etc)
There's a buffered SPI interface in the FPGA (BSPI) so writes dont need to wait
i see why you want some sort of shorthand to say "P2 has a 7i65 on it" rather than breaking everything out into fine-grained configurations
Could be just a command line hint
to avoid all the pin twiddling in HAL
The 7I65 will need quite a bit board specific setup
(SPI channel descriptor setup etc)
will the driver poll the ADCs on the 7i65, or does the 7i65 push it?
* seb_kuzminsky doesnt know spi...
in the SPI I know the slave clocks data onto the MISO (master-in slave-out) line as the master clocks SCK (serial clock) line
that's on AVRs -- I don't know that the mesa cards work like that
is spi full duplex? there's a "mosi" line next to the miso?
data is often clocked in and out at the same time
so yes, it is capable of being full duplex
so maybe the 7i65 sends you the adc values as you send it the dac values
that would be more efficient than doing separate transfers
but the hm2 spi interface is buffered so you dont have to wait to clock out the dac values, so it seems like you'd be "one cycle behind" on adc values
like serial, there are TX and RX pins. the only addition to serial are clock and chip select (for the most part)
you always have the latest data, it just isn't from "now"
it's from the last full SPI transfer cycle
which could be maybe 20 microseconds old, depending on clock rate and how much data has to be trasnferred in total
The A-D and DAC need separate SPI transactions, probably the easiest thing would be for the A-D data to always be 1 sample time late
jepler: do you remember anything about the additions to emc2 regarding NURBS ?
I mean, where the code might be ..
PCW: you mean one servo-period late?
one SPI cycle late
unless the SPI cycle is triggered by the driver reading/writing something
at the end of each servo loop, the driver would put the new dac values in the bspi buffer, and it would put read-requests for the adc values
One servo period
ok, so the transfer would only be done under software control?
alex_joni: xemet (or somebody) worked on it for research. I have no idea where any actual patches are. It's certainly not in CVS.
right.. thought you might have seen a copy
I also remember it was xemet
( the read requests might be semi auto - one write to autosend)
Yes SWP for now its software
alex_joni: it was on pastebin and his homepage for a while (emc2cnc.altervista.org)
for my analog boards, I used a state machine that continually refreshed the data
all the driver had to do was read the AD results registers or write the DAC settings registers
Right, this is not for general DAQ use its really made for motion control
well, the write could certainly be dependent on software, but having the read free-running might be a good thing
fenn: I'm there now, can't seem to find it though
the driver then just reads the latest data, even though it might be a few microseconds old
alex_joni: i thought i saved it from pastebin but i cant seem to find it
Right, but its not possible with the 7I65 (shared SPI interface)
yeah. I guess you'd have to keep everything or nothing running
i guess i should look for files from 2008-01-03
(well maybe possible with arbitration and sends interrupt A-D task)
heh, started looking for NURBS, ended up with talk about early AXIS http://www.linuxcnc.org/old-www/irclogs/2005/%23emc.freenode.20050529.log
has anyone just emailed manfredi and asked?
here's the annoying part. after a google search for "xemet nurbs", this is the summary:
"My Proxxon MF70 CNC machining a NURBS made Tux using a modified version of EMC2. ... you can find it here: xemet(dot)altervista(dot)org/c nc ..."
just a few more characters in the summary and I'd have it :)
wait wait! i've almost got my command line sorted: find -mtime 9576 -not -newer 9000 or something
whoa.. can't believe it's here
[20:26:07] <alex_joni> http://www.pastebin.ca/640476
almost 2 years later
[20:26:20] <SWPadnos> http://www.pastebin.ca/640476
just found it too :)
from here: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emc/2007-07-31.txt
the default used to be no expiration
anyone knows any plans about implementing SPINDLE_RETRACT canon call ?
and what is it used for (docs are unclear)
not without reading for a while
retract means moving where? up? left? down?
I think its up but how far
micges: now you know why it's not implemented
that way would be way too machine specific
but how usefull...
I see codes for tailstock spindle retract, nothing for a "regular" spindle
I can't see it being useful on a mill, since Z (or W) position would be a better way of controlling this
what is tailstock ?
micges: part of a lathe
the holder opposite from the spindle end (the headstock) on a lathe
in polish tailstock->konik :D
what's a headstock? :)
konik podporowy szlifierki
or konik podporowy szlifierka for the ladies :)
lathes are not well know by me :)
maybe wrzeciennik for tailstock?
I meant headstock
rfl seems to have made tom happy :)
yeah, I'm sure
I wonder if JonE is using TRUNK :)
he usually does
various versions of TRUNK though :)
heh, like 10 year old TRUNK? :)
yeah.. something like that
"it was called TRUNK back when I last updated"
would have guess less than 10y
it was called HEAD back then
maybe it was 8 years old when he finally upgraded to EMC2
if you have actual work to do, updating cvs may not be the right thing to do
that version from 1998 or 1999
exactly, unless there's a bugfix you need
unless you prefer to apply a patch
I've asked about retract becouse I have material with holes made by stopping spindle in material not above it
EMC: 03jepler 07TRUNK * 10emc2/tests/halmodule.0/ (README expected test.sh): new test
I added MDI call after EASCAPE to move up a few mm but sometimes it is execurted too late after c.abort()
let me see if I understand what you're asking for: when the operator hits "abort" (but of course not "estop"!), you want a preprogrammed move like G53G0Z0 before the spindle is stopped?
G0 Z1 specifically but yes
if Z0 is the level of material
I don't think that's at all related to SPINDLE_RETRACT, whatever exactly SPINDLE_RETRACT is
"things that happen at abort time" are pretty much entirely separate from "things the interpreter does", like making canon calls such as SPINDLE_RETRACT
and this is certainly not a "one size fits all" item
for instance, when cutting a T-slot on a mill, that move would be a terrible one to do!
or when rigid tapping :)
whats rigid tapping ?
what if the user aborts between a tool change (which probably takes place more than 1" above top of material) and the return to cutting? would the tool move down?
micges: putting a thread on a hole with a tapping tool
lathes also offer multiple different scenarios for "how to get the tool safely away from the work"
depending on whether you're doing an inside or outside operation, for starters
IOW I wouldn't want to touch this feature with a ten foot pole
for it to make sense for more than a tiny proportion of people, it probably needs the same thing tool changing really needs: the ability to specify a series of (possibly conditional) movements
lots of programming to be done there, by somebody
can be done simmilar to homing sequence in motmod (I think)
as rack tool changer is impossible now due O call errors
I'll try to add this somehow to EMC
(this make no sense I'm tired)
good night all
jepler: that's fun: set f 89884656743115795386465259539451236680898848947115328636715040578866337902750481566354238661203768010560056939935696678829394884407208311246423715319737062188883946712432742638151109800623047059726541476042502884419075341171231440736956555270413618581675255342293149119973622969239858152417678164812112068608 8.98846567431e+307
I wonder if you typed that :D
alex_joni: no, I didn't
mv output expected; cvs commit
I just did a bunch of lathe work using trunk. everything is working great.
I like how you can switch between AXIS's manual and mdi tabs without messing anything up
also, you can type a long mdi command, then hit F9-F12-F12 to turn the spindle on, then F8 for coolant, then hit enter and run the mdi
but I would like some facing/boring/turning cycles...
too bad about that cutoff date that's in the past...
EMC: 03cmorley 07TRUNK * 10emc2/src/hal/classicladder/spy_vars_gtk.c: Fix display of variable names in var window. Change the name of the signed integersvars to analog variables which makes more sense