anyone knows of a screenrecorder for linux?
I have a puma gone berzerk
this is definately something nice to see
I saw someone told you how to convert between degrees and radians correctly :-)
I was too lazy to check all the code :)
the puma kins are better now
still a bit of problems, but it's working
[00:26:28] <alex_joni> http://imagebin.org/7471
it needs to learn straight lines :D
when switching from joint to world space, make sure the joint 4 is not at 0
Jack Ensor is a danger to himself and everybody around him!
there are two ways to do things
you can just use the samples and be blissfully ignorant, or you can learn the underlying principles and customize
... or you can ask someone else to figure it out for you, one bit at a time, on a mailing list
you CANNOT customize and troubleshoot without knowing what the hell is going on underneath
there are lots of ways you didn't cover there
I have nfc why his his 2nd parport doesn't work, and why the stuff he targets at it comes out the first one
I didn't read his messages well enough to even understand that
his attempt a troubleshooting is doomed, because he doesn't understand the concept of a thread
probably he used the wrong config
he does loadrt, link and sets and expects it to work without a thread or addf
we had another one like that in #emc
only a couple of hours earlier
and when he got a loadrt failure because of unknown symbol, he didn't post the dmesg line to identify the symbol
loadrt hal_par_port "0x0378"
* alex_joni would say what symbol that is, but it wouldn't be appropiate
jmkasunich: I think that's just a typo in his mail
loadrt parport cfg="0x0378"
insmod: error inserting
'/usr/realtime-2.6.15-magma/modules/emc2/hal_parport.ko': -1 Unknown symbol in
that does sound like a proper error
leaving out the cfg= isn't a typo
you've both must misspelled the name of the module, but maybe that's part of the joke
no, that's in his email
hal_par_port is in one place in his mail
and a typo
the place where he actually tried it he did hal_parport
< jmkasunich> loadrt parport cfg="0x0378"
jepler: only jmk tries the other one ;)
< jmkasunich> loadrt parport cfg="0x0378"
I can't rememvber if there is a hal_ on the front or not
there is one
we actually had a good question on #emc earlier, with a lot of useful information presented right away
unfortunately it was about ppmc so I was clueless :(
I found something though :)
more of a luck thing
* alex_joni doesn't like that the usc uses PID
the feedback loop being integrated in stepgen sure is nice
yeah, I've been thinking about that
the 5i20 stepgen works like the ppmc one
so it will need pid too
I've been thinking about pulling the stepgen "position loop" out into a component
either that, or duplicating a bunch of code to embedd the loop in ppmc and 5i20
you could pull it out and make an API in C, not in HAL
you may play with puma now :)
not too hard though.. if you break it you will have to fix it :P
j-<TAB>: I was wondering about the pumagui, where does that backplot come from?
hey that looks really close!
the geometry measurements must not be quite right
alex_joni: in the geometry specification it says where the "work" and "tooltip" are
position and orientation
dunno exactly how it's written, look at the pumagui source if you care
the puma visualization model isn't as nice as the scara one - the segment lengths aren't clearly identified
jmk wrote that part
I wonder if the kins take into account the offsets at the shoulder and elbow joints?
jmkasunich: might be
jmkasunich: btw, the names you changed in scarakins the ones you didn't like
heh, I just noticed the first sentence in Jack's mail: " I am having trouble getting failures on pinout.hal. "
it seems those are the default ways to specify these things
totally wrong - he is actually doing great getting failures on pinout.hal
from the D-H (Denavit-Hartenberg) convention
alex_joni: you are welcome to change them to anything you want, as long as you keep the comments in there so people (including me) can figure out what they are
[00:53:20] <alex_joni> http://en.wikipedia.org/wiki/Robot_control
"standards" are only good if everybody know about them - those comments assume you don't know
jmkasunich: that'll be fixed in English 2.0
" The indications in the
error report indicate a problem with the parallel port."
that sounds bad even to me
he's either lazy or dense
a lot of people are imprecise in their language use.
I'm not talking about his language anymore
he's even lazy beeing dense
I'm sure I've made mistakes like forgetting the "cfg=" part of a parameter
often, but not always, it's a sure sign of fuzzy thinking
I don't drop everything and yell for help, I stop, review what I did, and fix it
he even has it right earlier in his own email
probably something else than I imagine under fuzzy thinking
fuzzy thinking is the opposite of clear, logical thinking
hmm.. I work sometimes that way
not trying to look at actual contents/data, but rather go by workflow
not sure I can explain it right
for example when using PCs.. I stopped a long time ago reading popup messages & such.. I rather go by shape, text arrangement, buttons, etc
sometimes I forget to troubleshoot a problem at first - I just dink around
most of the time it works great
cradek: yeah, that too
but when that fails for a while, I think `maybe I should start troubleshooting for real'
he's been dinking for a week
wonder if it would be very nasty of me to reply something like: "this will be fixed in the next version, in a couple of weeks"
what will? his denseness?
I won't say what will :)
anyways.. nuff' for today
* alex_joni head to bed
good night all
cradek: get a gamepad.. it's sooo nice to jog with it
I have a jogwheel!
well.. this is 4 axes ;)
does it have a detent every .001 inch??
but I guess a jogwheel is more precise
the emc jogwheel works VERY nice
so does hal_input
we'll have to compare at fest...
I'm off to make the hummus... mmmm
one of these fest's
yeah, one of them
maybe I'll have a look at the rigid tapping tomorrow
no hurry, the planner part isn't done yet either
and I can fake something up to test with
can't divide long long ints in kernel space
what are you doing?
got a variable that is 48 bits of counts + 16 bits of fractional counts, gotta divide by scale and return a float
although I thought it would become a double first
maybe thats not where its happening, I do other long long math
dirhold_ns * clock_freq / 1000000000 thats probably it
should probably just do that math in floating point and intify the result
ah, bonus, that actually eliminates a divide
100KHz stepping ;-)
120 KHz - 3600 RPM
and it can accel to that speed in 1/3 second
180 revs/second squared
accel from zero to 1800 rpm at 500 revs/second squared
* alex_joni has a couple of rigid tap questions for when you wake up :)
[13:23:48] <alex_joni> http://wiki.linuxcnc.org/uploads/Haas-G84.PNG
I hear G84 isn't usually a rigid tap
hmm, +pid 11657 (httpd), uid 80, was killed: out of swap space
I found mostly references to G84 for tapping
[14:57:56] <alex_joni> http://www.mmattera.com/g-code/gcodes.html
my rs274d reference says that too
also the rs274ngc doc
[14:58:27] <alex_joni> http://numeryx.com/cnc/drilling6.htm
anyways.. the question I had is how we want to do it?
shouldn't it be like threading?
spindle_sync_on, move forward
stop spindle, reverse, move back
what level are you talking about? canon?
I think the ngc writers intended that - you'd turn on SPEED_FEED_SYNC and then do whatever (like you say) then turn it off
canon and interp
but I'm not sure how it would fit with what you've done already
it wouldn't :-(
it seems to me the TP has to do all those things itself
here's my thinking
(and what I've coded so far)
you start at a certain Z (actually it's generalized for any direction, but let's say Z) with the spindle turning clockwise
you have a goal depth in mind
you synchronize to the spindle (just like a G33 lathe thread) and start moving in Z
when you hit the goal, you command the spindle to reverse
the spindle will keep going forward - you follow it with Z
when you see the spindle stop/reverse, you build another TP segment starting there, pointing up in Z, with the goal being the original position
now you follow the Z axis the same way (notice this following is special because you don't wait for index pulse to start moving)
when you get the to goal, you command the spindle forward, but still follow it since it will be going in reverse for a while
when spindle stops you will be above the original position, so rapid to it
now, the cycle is over, the tool is where it started (this is important, because interp has to know the position)
ok sorry for the paragraph, but that's the special handling of a tap that I think we have to do
so the canon call RIGID_TAP actually does the canned cycle but in motion
if that's many canon calls, (synchronize, feed, spindle, feed, spindle, unsynchronize) I think task will have to intercept those and throw most of them away
well I'm thinking of rigid tap as its own kind of move in the TP - how it gets there doesn't matter too much really
interp's G84 (or whatever) could generate a TAP canon directly, or task could recognize a particular pattern of canon calls and call motion's EMCMOT_TAP (or whatever)
I don't like the second variant
I don't either, but it's more in line with the ngc doc
recognizes sequences of canon's leads to mess in the code
I already violated the ngc scheme with G33 (because I put a pitch parameter on SPEED_FEED_SYNC)
yes I agree
so I think a new canon call is much simpler
we are never going to have SPEED_FEED_SYNC [then do anything you want] then UNSYNC work - it's just a fantasy
so back to interp now
maybe using G84 is more standard, but I don't like that you don't specify the pitch directly
although someone said on mazak you specify pitch with F word
F vs. S ?
I think mostly pitch is F/S, but on mazak pitch is F alone
I think using F/S (inch/min)/(rotations/min) is crazy
[15:19:49] <alex_joni> http://www.shadowcnc.com/shadowmanual.htm
search for G84
F 25. STORE Sets the feedrate to match spindle speed/threads per inch.
so they use F/S
I bet this is not a rigid tap
someone said yesterday G84 is never rigid tap
well.. I saw some pages where they use G84 for rigid too
what do you think is easiest? I hate to get bogged down in these decisions, we can change the interp (accept more than one way to tap) later if we want
G33.1 P(pitch) Z(endpoint)
or K(pitch), like G33
what's G33 again?
single point thread in any direction
to me (programmer, not machinist) rigid tap is exactly like single point thread, but with reversal
looks like either would be easy to add to interp - G84 is almost there already, G33.1 would be just like G33
G33.1, but not G33, should error if the rotary axes change during the move
so.. should I add G33.1 ?
we can change it to G84 later if we want
yes I think so
yes, or we could easily have both
so.. the syntax is:
G33.1 P(pitch-float) Xe Ye Ze
how about K = pitch so it matches G33
fine by me
and the canon calls will be SPEED_FEED_SYNC(k), RIGID_TAP(x,y,z), UNSYNC()
task (emccanon.cc) will know that RIGID_TAP does not move the endpoint
meaning: do not call canonUpdateEndPoint(x,y,z)
or canonUpdateEndPoint(initial point)
maybe RIGID_TAP(x,y,z,a,b,c) where a,b,c are initial
(be sure you're on rigid_tap cvs branch)
yeah, I checked it out :P
[15:48:10] <alex_joni> http://pastebin.ca/381043
should canon throw an error if a,b,c differ?
interp should have already errored and stopped interpreting
except when it's not this interp calling the canon call
maybe RIGID_TAP(xyz) is better for that reason
you decide :-)
bbl, I need shower + breakfast
ok, I'll try to have the rest done by the time you come back :P
thanks for doing this!
cradek: do we need vel/accel settings for rigid_tap ?
* alex_joni wonders why..
alex_joni: I thought there was a spindle up to speed pin or something like that - I remember them fixing it on the mazak - because the first time they went to cut something the spindle was not up to speed before the axis was moving. but later it worked.
skunkworks: I think they used feedhold
alex_joni: because the axis motion still needs to be within machine constraints
especially at the last move which is unsynced
right.. I just concluded that
well.. it compiles :)
(didn't do the G33.1 part yet, only CANON -> tp)
from yesterday - "07:05:13 <jmkasunich> "if spindle-on and not delayed-spindle-on then feedhole = true"
jtr: I know..
thanks for pointing it out though :)
cradek: here you go :)
gotta run for a while.. bbl
* alex_joni doesn't leave anymore..
so.. what's new?
still doing 5i20 stuff
I'm still waiting for mine
I'm going to try my first real VHDL stuff today
found a minor bug in the step generator
in stepgen? or in the vhdl step generator
the 5i20 vhdl one
I think the first step is making sure I have the "build" process right (do a build from the unmodified vhdl files and test it)
it really sucks that the build takes the better part of an hour
side note: sooner or later (sooner I hope) I'm gonna have to commit all my new 5i20 stuff (both vhdl and driver) to CVS
there's already a m5i20 driver and directory full of vhdl
I don't want to break the people who are using that
although eventually I hope to transition them over to the new driver
jmkasunich: an hour? yuck
place and route takes the longest
I would get impatent when pluto took 2 minutes to build
for testing, I'm thinking of doing a top level file that only invokes a single stepgen instead of 8 of them, plus encoder counters plus...
that should cut the time considerably, especially if there are "prefer fast builds to speed/size" settings you can tweak
well the thing about the tweaks is - the default settings don't quite meet a timing constraint
I dunno if peter has tweaked things differently and is meeting the constraint, or if his results are about like mine
(missing a 22nS target by 2-4nS, can probably get away with it because of tolerances and temperature affects
btw do you want emc's 'make' to rebuild the VHDL stuff if a person has the tools installed? I could help out with that part if you do
but on the other hand so few people will have these tools installed, a standalone script or makefile might be the better choice
I'm still vaccilating between using a script and using a standalone makefile
I do (heart) the idea of having the exact commands to invoke in a file
otherwise it ain't pretty
alex_joni: yay thanks!
make can invoke a script just fine
raw_firmware_file: all vhdl files ; sh rebuild-firmware.sh
cradek: should we start testing?
jepler: its a multi-step process, and if I was using make I'd let make handle the steps
[17:38:17] <jmkasunich> http://www.pastebin.ca/381144
my notes so far
alex_joni: the planner part is not done yet :-)
the last part about RAM/ROM and .bmm files is probably something I should forget about
just embed the ram contents in the vhdl
cradek: oh, ok.. I was afraid to try it :P
hmm.. forgot some AXIS part.. will be there soon
jepler: what gets interesting is that I'd like to simplify the task of building different fpga configs
that means not hardcoding the name of the top level vhdl file in the makefile
eventually I'd like to automate creation of that top level file too
but I should start small
I was trying to make my example short, but in reality there would be arguments to rebuild-firmware.sh that depend on the target raw_firmware_file
raw_firmware is the end result - the bitstream?
yes, I think so
you think so?
I think it's desirable to store raw_firmware, not the .h file version, in CVS -- it's a smaller download in bytes, for instance
it could be anything -- whatever the "output" of the script you write is
in fact, I've been planning to drop the entire .h mess
when I asked that question, I wasn't sure if raw meant output or source
embedding the bitstream in the driver implies that there is a preferred bitstream
the new scheme will not have a preferred bitstream - you load the one you want, and the driver discovers what it has and exports the right hal pins
sounds good to me, as long as someone else writes it
thats what the ram stuff is about
jepler: in gcodemodule.cc : _pos_x & co are the positions after an action?
alex_joni: yes I think so
the ram (or rom, depending on your point of view) tells the driver what is available
jepler: if the process always has to start over from the beginning, is there really much benefit to using make?
unlike C, the "link" stage happens very early in the chain, so if you change any source file, the link output changes, and then the rest of the chain needs re-run
jmkasunich: if you have several configurations and one of them doesn't have encoders, then make helps you avoid rebuilding that one when only the encoder vhdl file is changed
although that will require some sort of dependency discovery process
vhdl doesn't have include
verilog is a bit like that as well
you just create instances, and it looks in god-knows-where for the associated source file
cradek: was just about to commit that
for the xilinx tools, the prj file tells it which files to use
didn't know you were still working
cradek: no problem..
make would have to parse that I guess
I'll commit an fix for axis now
wonder if I got it right..
I always wonder that
duh.... /me was wondering why the compile farm didn't react to the latest commits
on a branch ;-)
jmkasunich: given all that, I think a script is just fine
let me know if you want help on the top-level vhdl creation script
I'm thinking that I should define a few conventions
yes, I do
thats why I keep talking at you ;-)
* alex_joni grins
convention: foo.vhdl is the top level file that creates foo.bit
it can invoke all kinds of other vhdl files, but all the working files are named foo.whatever
you'd think the vhdl folks would understand the concept of include files
entity and component are basically the same thing
except one is in the file that defines the item, and the other is in the file that uses it
they are both "prototypes" of a sort
jepler: py is good a parsing stuff isn't it?
(as opposed to doing heavy grep-fu)
jmkasunich: you know I like python for almost every purpose
ghdl - VHDL compiler/simulator using GCC technology
compiler simulator yes
[18:09:09] <jmkasunich> http://www.pastebin.ca/381182
a simulator means you wouldn't have to spend your hours waiting just to test a step generator bugfix
how nasty would it be to pick out lines like 339 and 408
instead I'd spend twice as many hours developing stimulus files
including simulating the PCI bus transactions, and even the execution of some of the driver code
no way I want to go there
hmm, first step on parsing that file is to lose the newlines
are you talking about parsing, for dependency generation?
I think the structure I want to find is "<identifier> : <identifier> port|generic"
it looks like there are available VHDL parsers for python
I should have known
* jmkasunich always tries to re-invent the wheel
* alex_joni wonders what doesn't exist for python
cradek: I would say the interp, canon part works OK
emcTaskPlanExecute(G33.1 K1 Z0) returned 0
Outgoing motion id is -3.
Issuing EMC_TRAJ_SET_SPINDLESYNC -- (+232,+20, +0,1.000000,)
Issuing EMC_TRAJ_RIGID_TAP -- (+237,+84, +0,)
Issuing EMC_TRAJ_SET_SPINDLESYNC -- (+232,+20, +0,0.000000,)
anyway, the 2nd identifier in that structure is the entity that is being invoked
and usually (we could make it a convention) the name of the vhdl file that needs to be "included"
lunchtime here, bbl
lunchtime here too (or breakfast, or something)
so do any of you use lxr on linuxcnc?
I used it twice I think
(since it was set up..)
184.108.40.206 - - [04/Mar/2007:12:15:19 -0600] "GET /lxr/source/src/libnml/buffer/Submakefile HTTP/1.1" 200 4269 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
this is why cvs is so slow today
flooded by google bots?
yeah it's crawling the lxr
well.. it'll pass I guess
don't think they crawl too often
not for a long time - lxr is sllloooowww
must be a way to fix that with robots.txt
"GET /lxr/source/debian/changelog HTTP/1.1" 200 69158 "http://www.google.co.uk/search?hl=en&q=input+scale+emc2&meta="
here's someone who used that to find us though
it's the 3rd hit
and the least relevant imo :D
heh.. didn't see this in a while: http://www.metalworking.net/
can I have more than one Disallow line there?
my usual robots.txt is:
saved me from reading documentation
was that Peter Wallace in #emc ?
wish I had noticed
I only noticed when he went away
he was only there for less than a minute
I wonder how soon google will re-check robots.txt ...
next time probably
that's ok I guess
jmkasunich: peter is back
alex_joni u there?
did u see my post to the dev list re spindle control?
petev: the second one?
I replied to the first one.. didn't see another one
but we can talk it out in here ;)
I only posted once, I think
the first post bounced
jmk said I was no longer subscribed to dev list
ok.. I got that, and replied to it
I'm in digest mode so didn't see a reply yet
First of all, I gotta say it's a very good topic. This is an area that can take some improvement.
Would this input be active only when starting the spindle? When changing spindle speed?
Or always? (e.g. if the spindle speed drops too much, the ladder takes this bit low, and emc2 stops with an error message).
Note: for regular users that don't care about this I'd have the pin default to 1 (current behaviour)
I think it should be active always
most VFD have some IO or relay that can be programmed for such indication
for simple machines, a contact from the contactor could be used
and for dumb machines, just wire it to 1 as you say
guess then it's just like feedhold then :)
I thought about using the feed hold, but it seems like it's combining 2 different funcs
and there is another issue
what about when the spindle transitions from off to on"
the ok input would be ok in the off state
then EMC turns the spindle on
the ok input needs to change
so things get a bit tricky, or we need a special input for spindle
I'd say track it with CL :)
but that doesn't help
would you keep the machine in feed hold at all times?
and only enable when spindle is up to speed and manual hold is off?
no, only when spindle is on (motion.spindle.on) and not up to speed
what's manual hold?
but then you get the glitch when going from off to on
manual hold being some button from the console
the glitch happesn because the feed hold is not on when the spindle starts
but then has to transition to on until the spindle is up to speed
I'm not sure I'm following
at which time it is turned off again
motion sets spindle-on
feed-hold is not set yet
so machine may start to move
then feed-hold is de-asserted because spindle is not up to speed
seems a bit ugly
yeah, but that's in the fast thread
would be nicer to have dedicated pin for spindle and have motion block there until it's ready
so less than a stepper step
why not treat it more like an IO and not even let motion start until it completes?
the same as tool change
tool change is in userspace
I know I don't want my machine moving until I'm done setting the spindle speed right
tool change has the tool-changed handshake
yeah.. I know
I'm still trying to think ;)
also, what about spindle failures?
I think a handshake is the appropriate method
and for dumb systems, a jumper, just like we have now
having a dedicated line would handle this too
it's not really a handshake..
it's kind of a spindle good/up to speed status
* jmkasunich hides again
it's more like a safety input.. while not on, machine doesn't move
I think it indicates spindle status
if anything is wrong with spindle, machine doens't move
right.. and user sits and looks baffled :)
well, you could use ladder and a timeout to generate a fault indication
or we could have two inputs, one for fault and one for status
come to think of it, this brings up some other spindle control questions I had
cradek is working on rigid tapping
but as roltek points out, what he is doing will only be good for through hole tapping
because he doesn't start slowing down until he hits the desired depth
without a servo on the spindle, you can't do bilnd, tool changes, or other oriented spindle stuff with boring bars, etc.
so how is a tool change handled without oriented spindle?
on the mazak, we implemneted spindle orient in hal
if there was a servo on the spindle, I guess you would have the normal amp-fault input
jmk, what about blind hole tapping?
when toolchange-request comes on, the spindle drive command is disconnected from EMCs output and hooked to a pid loop
blind holes would never work with todays design
so the mazak had a spindle servo?
no, it has a rather generic DC drive
and we attached an encoder to the spindle itself so we could use the index to orient the spindle
the drive accepts a speed command only, and had IIRC an analog tach on the motor for feedback
how did it do tool change before the retrofit?
well. thats a long story
the spindle drive in there was not original
so do we need two models for spindle support?
the original drive was probably more capable (it was a fanuc)
and there was an analog sensor for spindle postion
one for servo spindles and one for dumb spindles with an encoder?
I'm thinking that we should keep motion as generic as possible
perhaps it has a position command output and a velocity command output
and a bit that says "switch modes"
that's no bad
along with an ini param or something that says "you can't switch modes, you got a dumb spindle"
how would the trajectory planner use this for tapping?
then the actual position control and velocity control can be done however - if the drive has a position mode, just use it, if not, put pid and a mux in hal
I dunno ;-)
I assume it would use the position mode
tell the spindle to turn 20 times, while telling Z to go 1 inch
so there would be two algorithms in trajectory?
I dunno ;-)
* jmkasunich does hardware drivers
with position it's like a coordinated move
without, it's like a slave axis
cradek should be in this conversation
what time is he usually on?
he was here earlier
he comes and goes all day
(just like the rest of us)
what's your preference for the short term?
I'm up to my elbows in 5i20, and can't really give spindle the thought it deserves
the position mode seems usefull, but I'd want cradek's thoughts on it before I advocated it
I think for short term just adding a spindle-speed-ok input would be good
with the full servo model, it's probably not needed
our spindle actually engages a cog to index the spindle for a keyed tool.
skunkworks: thats what we thought the mazak had - we thought orient was going to be a simple matter of "start turning very slowly, and when you see the pulse, engage the cog"
re spindle, a spindle-at-speed input would be good, and possibly a timeout parameter so that an error can be reported if the spindle doesn't get to speed fast enough
yeah, the true servo spindle would use the amp-fault for that, but something may be needed for the dumb spindle model
ours just rotates the spindle slowly - engages the cog - waits a designated amount of time and assumes it is where it should be. It has no real feedback from the spindle except a tach that is only used for 'at speed'
we hope to do it a bit better.
you'd build external components (or ladders ...) to handle non-simple spindle setups, such as gearchangers and the like
true, but I see two major spindle types, servo (with position control), and simple with just encoder feedback
maybe a third dumb type that can't even support tapping
sure - an on/off with manual speed control (like a BP without servoed sheaves)
btw, the mazak has a gearchanger - we did both gearchange and orient with a combination of ladder and HAL blocks
right - I remember several discussions about spindles and gearchanging
mostly with Ray, I think
I'm trying to remember how we made the machine wait during a gearchange
probably feedhold or a mux into feed override
what happens with feed override at 0?
does motion stop too?
oh, I was thinking spindle speed override
so that's another way of doing at-speed, mux a 0 and the "actual" FO into the FO pin
FO is a float though, no?
yes, but so is the mux
the feed-hold is probably more convenient
it has a bit input for select
though you should still have a mux arrangement so there can be an external feedhold control
(even if it's in halui)
yes, for now I will probably always keep feed-hold on unless no manual hold and spindle is up to speed
you mean off ?
I think when on it stops
no, on to avoid glithces
I guess this may be an issue for rapids and manual mode though
sounds like more complex logic needed
or a new pin ;-)
you'd have to and in the spindle-on output(s)
swpadnos, that's where the glitch is
feedhold unless enabled and ((spindle enabled and at speed) or (spindle disabled))
if you condition with spindle on
then when it first turns on, feed-hold is not set yet
I think there's a hard-coded delay (though it may be commented out now)
Alex and I discussed that in the last few months, but I don't remember what the status is
there is no delay at all
why not just add the spindle-at-speed input and make it simple?
then external logic would be trivial with no glitches
petev: because it needs to get into TP probably
why? I'm not familiar with TP
* alex_joni neither
I though all commands waited for completion
also, is the spindle at speed when commanded to 0 but still turning?
I/O isn't that simple, unfortunately
wouldn't it just be a matter of changing the spindle on command to wait?
(or so I hear - I'm not familiar with the code either)
petev: then it only works when turning spindle on
but it doesn't work if the speed drops later
true, but that would be a decent start
yep - what happens with a set of G-codes that also happen to have Sxxx words in them
and probably needed for final behavior anyhow
petev: don't think it would help lots..
initial ramp up can be long
something is needed
because it would need ot be redone properly
I'm talking about the implementation, not the actual result
actually, you can do it by hand, if we have a "wait for input" M-code
did that ever get implemented?
you can hack a "wait for input" m code today
custom M code can invoke any script
that's a whole nother can of worms
jmkasunich: yeah, but you don't wait for them to finish
it won't wait
we have multiple overlapping worm-sets
alex_joni, sounds like this is similar to feed-hold, but conditioned
emc doesn't wait for a custom M code script to finish?
jmkasunich: no, just spawns it
so it shouldn't be that hard to look at how the feed-hold input works
petev: no, shouldn't be that hard :)
wtf good are custom M codes if the g-code ignores the result?
SWPadnos: I was very much in favour of custom M codes
s/ignores/doesn't even wait for/
I mean ones to check for input pins
yeah - I recall some discussions about M-code for aux I/O
but we talked it through a couple times, and I was convinced we don't want to do that
can't remember what the argument was
something about loops & problems
anyways.. different worms
one of those "like probing, you don't know the state of the machine after it's done" things, no doubt
jmkasunich: I somehow agree with you
petev: regarding feed-hold
as it is now, there are a set of flags (feed-hold is one of them) that get embedded in the trajectory planner along with the move commands (linear, circular, etc)
so maybe feed-hold is not the answer, maybe feed-override is better as SWPadnos suggested
I don't think feed-override is looked at for g0 moves
alex_joni: not quite
the flags aren't feed hole
they are feed hold disable
petev, I think FO is always used
should only be for G1 type stuff
but since G0 is at "full speed" , you can never go faster, only slower, on a G0 move
you can disable feedhold, feed override, spindle override, and adaptive feed, individually, in the g-code
jmkasunich: right, I was assuming they are all enabled
well, for proving that your rapid will clear a clamp, the ability to slow down G0 is great
hmm, that's no good
this is for things like "I know that if the operator slows down the feed on this cut the part is gonna work harden and ruin the tool"
its those enable/disable bits that get attached to individual moves and pass thru the queue
no, I meant for using any for spindle control
or increases the feed (if FO > 1)
the fact that they can be disabled may be bad if you want to use them for spindle control
petev: that's mostly usefull for threading/lathe work
but I wanted to clear up that its the enables, not the actual hold or overrride that gets queued
does FO really effect G0?
jmkasunich: right.. I remembered
that seems totally wrong
others agree with you, but not all others
remember - you can't speed up a G0, only slow it down
some people even wanted a different override for rapids
that has its uses
if you want to change your feed rate, you don't want it to mess with all your rapids
what good is that?
it would mess up the whole program
proving a program while single-stepping
dunno, but I'm not gonna get sucked into _that_ discussion again
the rapid override is a config thing to me, shouldn't need to be touched after that
Ray was a major proponent of G0 being affected by FO, I think
I'm mainly parroting what I believe he said
that makes no sense
thats the way the original NIST spec is written
that make FO worthless
rapid override does seem to have its uses
fine if it's separate
for proofing a program, you turn rapid down to the point that you can estop in time
but shouldn't be the same as for G1
turn feed up to the point that it doesn't waste your time
combining them is the issue
I would rather have nothing for G0 than combined
petev: "guess it's been 10 years like it is now"
one of the few reasons it's like that
you are welcome to start a discussion on -dev and try to convince people, or better yet, make the change and submit a patch
what good is it the way it is?
why would you want changing the feed speed to effect rapids?
not arguing with you about that
not arguing with you about that
petev: to go slower I guess
* alex_joni won't argue either ;)
or maybe too fast on a rapid
we're not discussiing whether it is right or wrong
sounds dangerous to me
it can't go faster than G0
even if you have FO at 10000%, motion is still limited by machien capabilities
the facts are that the last time it was discussed some people (not here at the moment I think) managed to successfully argue that it should stay the way it is
what jmk said
what jmk said is a good reason for a G0 override
you don't have to convince me, you have to convince them
or just do it
not for combining them
I mean the "< jmkasunich> the facts are that the last time it was discussed some
people (not here at the moment I think) managed to
successfully argue that it should stay the way it is
23:46 < alex_joni> what jmk said
petev: I am also feeling neutral about the whole issue
ok, I'll look at the code and see what it takes to add a second override
I'm ok with either way really
petev: it's not hard to do..
I think the biggest hassle is not the motion code, its the guis
they need yet another slider
but you need to fix GUIs, NML, task, CANON, motion
which might hurt the little brains of some of the users
hmm, so how do you guys handle this stuff then?
present for vote?
leave it the way it is ;)
but it sux as is
bring it up on the devel list
usually we manage to come to a conclusioin that makes everybody happy, then we go off and implemnet it
that time, I guess nobody on the "needs to be separate" camp felt as strongly about it as you do
petev: 'we' in here are mostly newer emc users/developers
I don't care to have a G0 override, but I can see it's use
If I wasn't listening to this discussion - I would have never thought about it. the few machines I have run - FO effects g0 and g1,2,3 the same
but I really don't want G0 and G1 combined
there are older users, like ray, that feel very strongly about changing things
skunkworks, what controls were on those machines?
fanuc and a really old ge controller.
you can modify your code to prevent FO with G0
petev: don't know off the top of my head - it was running a laser - maybe 12 years old.
petev: just to make you more upset.... FO affects homing and jogging moves too
jmkasunich: you had to :)
it is basically a global scale on all velocities
as is AF, right? (if it's enabled)
SWPadnos: yeah, but that can't increase
isn't there a FO disable now though?
SWPadnos: only 0..1
for threading and such
yeah, AF, FH, FO all affect a single variable called "scale"
skunkworks: there is a disable for all the overrides
spindle-synchronized ignores FO
spindle-synchronized motion ignores FO
so we still have this problem for spindle and these being able to be disabled
can FH be disabled?
ok - then "yes" is right :)
petev: what do you mean 'these being able to be disabled' ?
there are four "things": AF, FH, FO, and SO
each can be individually disabled/enabled by g-code
ie, g-code can disable FO, FH, and AF, so none can be used reliably for spindle-related feed hold
IMO, spindle-on should not return success until the spindle is at speed
well.. you can use motion.enable :D
I had thought about that, actually
that ignores the separate issue of what happens if the spindle dies mid-cut, but so be it
ok, at least thats a start
the thing is, I dunno if motion commands can "not return"
what happens when motion is disabled?
thats basically "machine off"
you don't want to go there I don't think
so no servo updates?
no motion happens - but I'm not sure if it leaves the motor enables o
jmkasunich: there is no-one reporting success I think
ok - gess not
at least not down in the motion controller
alex_joni: thats what I was afraid of
in the controller, a comment returns an immediate response, no deferred responses allowed
a command, not a commnet
hmm, so sounds like nothing is suitable yet
it has to be done in task I'm afraid
and that's one pile of *beep* I'm afraid to stir too much ;)
it's a tough problem when you consider on-the-fly spindle speed changes
I still have all that emc3 code ;-)
right - constant surface speed will have the speed constantly changing
and your snazzy fast interpreter :)
ok, so we need two solutions
one for the servo spindle, and one for all others
can we break down the features that would be supported for each?
then maybe it will become more clear how to solve this
how did we get from "spindle at speed lockout" to servo spindles
alex says he wants to do it right ;-)
servo spindles are only loosly related to this
so for the big picture, seems like these are the two cases
one thing at a time
some of the control overlaps
the servo spindle solves a lot of this
canonical machine command spindle-start should not return until the spindle is started
regardless of the type of spindle
jmkasunich: I 'think' I might be able to do that
so spindle start is different than spindle at speed during a cut?
can we agree to separate those?
yes, they are fundamentally different
startup, you wait
during a cut is a fault
hold on - if you change speed, then it can't be an immediate fault
during a cut is sort of like following error
change speed = start spindle
it only starts from speed!=0
so for non-servo spindles we need a fault input
and like following error, you'd set an allowable error band
jmkasunich: that's external to motion
petev: lets ignore the fault side for now, stick to the start/stop part
one fault input and a wcomp outside would do the trick
ok, let's address speed change
I thought we agreed to separate the startup issue from the running issue?
this may be manual on some machines
yes, that was for running..
so that need to wait as well
I don't see (implementation-wise) how the 2 things are that different
startup and during cut
so start and speed change wait
ok, I need some background
during a cut is servo controlled or simple fault?
jmkasunich: what background?
S3000 sets spindle speed (internal variable) to 3000 rpm, but doesn't start it, right?
M something starts it
M3 or M4 starts it
I see one difference - it's likely that there is no motion at "startup" whereas there is for a speed change
what if it's already running?
you can do the S before you start it, or after
after = speed change
and then we have CSS, which will be changing the speed all the time, but not by S<nnn> commands
on some machines, you'll want to hold motion until the spindle is at speed (like on machines where you prompt the operator to change speed)
S before = startup, S after = speedchange
I dunno if anybody does S words in mid-cut....
depends on F changes as well
SWPadnos: s/some/all/ I think
jmkasunich: maybe on lathe work?
but that's irrelevant
crude CSS by doing part of a cut, then an S word, more cut, another S word, etc?
I'm not sure that nobody will want to do a continuous motion during a spindle sped change
I agree that it seems not too useful, but I don't know enough to rule it out
I can also bet you that the minute we stop all motion during even a start from zero speed, somebody's gonna say "how come I can't rapid over to the part while the spindle's coming up to speed"
* alex_joni wonders if we can move this conversation to the next weekend
I don't think you would want feed to stop during a change for crude CSS on a lathe
heh - yep
jmk: should only effect G1, 2, 3 etc.
those kinds of things all have to be possible in "machine logic" config, not policy in motion
G0 is not supposed to be cutting, so it shouldn't matter
SWP is right about policy though
that's true - traverse vs. feed
the problem is that where you can do the policy thing you might not have the realtime machine data to do it
I'm thinking CANON or task
the other complication... what seems to be to be the "obvious" implementaton for start from zero (the start canon command doesn't return until at speed) can't make the disctinction between G0 and G1
that would be solved by an at-speed input ;)
no it wouldn't
err - nevermind :)
the "don't return until at speed" behavior would be using the at-speed input
actually, the spindle-at-speed input would be aprecondition for feed moves, not a postcondition for S words
jmk: I take it motion has no concept of machine mode?
petev: we're talking AUTO now
so you could do as many commands as you want, as long as they aren't feeds
e.g. running program
but the other 2 modes are also allowed/present
I think the pre-condition thing might be the answer
then it really doens't matter mode, etc.
if you are in manual, you can do anything - jog with spindle off, jog with spindle on, it doesn't care
that's still a policy (though itone
but you still shouldn't be able to feed with it off
using spindle-at-speed as a precondition for cutting moves should do the trick
so that kind of policy can be a pre-condition I think
then in hal, you implement your policy as to what "at speed" means
void STRAIGHT_TRAVERSE(double x, double y, double z,
double a, double b, double c)
double vel, acc;
void STRAIGHT_FEED(double x, double y, double z, double a, double b,
if you are doing CSS or in-cut changes, you just have to have a wide tolerance for "at-speed"
(sorry bout the paste).. just a short point
TASK who could do the pre/post conditions doesn't know about G0/G1
it only knows about linear moves with a certain speed
same goes for motion
the code you just pasted - where is that? interp? task?
interp calls those calls
interp calls canon which calls task?
Fest topic 1: how much old stuff can we rip out without pissing off the "established users"?
it's a bit more complicated
interp calls canon which queues stuff for task?
task runs interp cyclically, which calls CANON which puts NML on a queue, which task reads, and sends to various places
yeah, I always thought those two should be separate
and pre/postconditions are where?
on the last part
pre and post conditions are done when pulling things off the queue, right?
something that we talked about with Fred when we were at NIST 2 years ago....
the existing design has pre and post condition attached to each queue entry
the suggestions was that they _be_ queue entries
IOW, traverse would queue the move only, and feed would traverse a precondition, then the move
hmmm - "block until X" queue entries
well.. the conditions are hardcoded in task based on the element in the queue
that discussion does represent a change
back to Fest topic 1 :)
jmkasunich: right.. sounds like the proper way to fix it
Fred thought so
wonder who will want to do that :D
Fred is elected
* jmkasunich goes back to FPGA work
has anyone done substantial work on task since EMC1?
damn. I have to read back through that conversation
petev: I added couple of bits here and there
but nothing substantial afaik
nothing of this scale anyway
last time I looked at that code, I just wanted to toss it and start from scratch
the FPGA / mesa conversation
the task code
and interp too for that matter
(... just wanted to toss ... ) ;)
that reminds me, SWPadnos I'd like to brainstorm with you (later) about some of that stuff
sounds good to me
that's what started it
jmkasunich: we talked about machine runlevels a while ago
there were so many issued that couldn't be fixed easily
I think that was also a task limitation
HAL refactor and new interp and lions and tigers and bears ...
the HAL isn't broken
* alex_joni wonders if jmkasunich remembers
trying not to
I don't see a pressing need for a refactor there
[22:28:11] <alex_joni> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?RunLevels
so, I guess there is no way to fix this basic spindle issue?
petev: no perfect ways, lots of imperfect ones
I think it's pretty serious and we need to figure something out
petev: there is a way to 'hack' it to work as you want it to
in your case, who's g-code are you gonna be running?
jmk: like what? I don't think anything gcode can disable is acceptable
if yours, just don't use the "disable feedhold" code, and use feedhold to hold off motion during spindle spin-up
jmkasunich: I think motion needs an spindle at speed input no matter what
the problem is what to do with it :)
probably needs a fault for the non-servo model as well
but that's another issue
1). cheap & easy solution: use it like a FO=0
nothing outside motion knows about it
people just scratching heads why the machine isn't moving..
2). fix it more properly.. which will result in a cascade of other things to fix
anyways.. I'm travelling tomorrow.. gotta get some sleep
ok, get some rest
I'm going to take the kids to the park and think about this some more
petev: I still think this is best addressed on the mailing list.. maybe there are some other strong ideas out there
good night all
I think some input from the likes of Ray and Jon would be a good thing
night Alex - have fun on your trip
SWPadnos: it's a worktrip.. not that much fun I'm afraid
well, have fun anyway :)
I'm adding a linear 3m axis to a 8-axis robot
that sounds like fun
yeah, except when you're missing some cables & stuff
unless some jerk foreman is breathing down your neck to get it done yesterday