it's too bad I keep missing asdfqwega
my CNC ePenis has more steps than yours.
so i wanna patch a vanilla kernel.org 2.6 kernel RTAI and run on a stripped out slack install and run on a 300mhz amd
think its doabl\e?
it totally just errored out of its first kernel compile...
it's doable if you're experienced with building kernels
with today's modular kernels you don't gain as much as you used to by building your own.
has anyone has luck running on freebsd?
running what on freebsd?
last I checked there was no realtime system for freebsd, so emc can't work there
but I use freebsd for other things
I spent half a day trying to get a RocketPort 8J-RJ11 driver to work in Fbsd
cradek: im fine with building kernels its the fuckin 300MHz amd
i swear this is the most lunix resistant piece of shit ever
like, it even did bad ide cables to me
it forgot its bootloader into outser space or some shit for a few m\in there...
bah fuckit whatever im just gonna run it again
ha, and fuck modularity
modules are for stuff you forgot and you dont wanna reboot
it just went past where it errored out before
could someone please give me a hand with sudo visudo? Final step of emc2 installing
what are you trying to do?
adding myself to the sudoers list
you should be in group admin already
I am not
if not add this line: %admin ALL=(ALL) NOPASSWD:ALL
I am running a slack 10.2
will that preserve security?
oh, crap that wont help you at all
I am not an expert
replace %admin with your username
and no, that's not very secure
I mean ... I could mess all the system even if I log as user...
you have to type sudo to do anything that requires root permissions
thank you very much fenn
I'll never get this working properly... giving up hope
I am not able lo insmode rtapi.ko
why are you using slackware btw?
fact is that I've always used it and even though I got Ubuntu bb on a different partition
I wanted to have a go with emc2 on this
I patched the kernel rtai 3.3
it will take months before I get my way around in the Ubuntu world
somehow i dont believe you
pier_ is now known as pier
fenn: what's wrong in what I said?
03jepler 07HEAD * 10axis/extensions/emcmodule.cc: represent tool with a cylinder of the given diameter, 4 diameters tall
03jepler 07HEAD * 10axis/scripts/axis.py: represent tool with a cylinder of the given diameter, 4 diameters tall
.. patches to fix that for metric machines happily accepted
Although most of the US based guys are probably not up
can you tell me something... i selected x,y,a and b axis in emc.ini file...and i see the coordinates of these axis, but i can move them (in axis interface)
have you taken the machine out of estop
and turned it on ?
there are x,y,z and a axis listed
they are not listed in manual control
hmm you mean you don't see them or are not able to jog them ?
(I don't use axis on regular bases so forgive me if I am a bit slow)
if i use go command and move z axis (which i did not select in axis) it acualy moves A axis, bit the signal comes from z axis pins of paralel port
that is a bug in emc
if you define a z axis in the .ini file it will correctly map the A axis to the right pins
it doesnt matter if there's nothing hooked up to z
Hi fenn, guys.
what i mean is, as things are right now, the A axis always has to be [AXIS_3] in the .ini file
Have you tested to see if you can change the mapping of X=0, Y=1, Z=2 ...?
rayh: no i haven't tested, i think it's just a consequence of how simple trivkins.c is
AXIS with transparent tool using the diameter from the tool table: http://emergent.unpy.net/index.cgi-files/sandbox/transparent-tool.png
03jepler 07HEAD * 10axis/scripts/axis.py: make tool partially transparent
03jepler 07HEAD * 10axis/extensions/minigl.c: make tool partially transparent
jepler: that's cool
I'll try it on my sofware-rendered machine later
I hope it doesn't hurt performance too much
seems like a cone and cylinder would have similar number of polys
and we already had some transparency on the screen
the cylinder has about 1/3 more: it has two end-caps instead of one.
also, it's not being precomputed
we could fix that if we have to
computing the cylinder and caps is not much work: 2 * 3 * 32 ~ 200 trig calls per redraw, all in C code
ok, bet it's fine
bbl, looking for some food
* jepler reads the global notices from last night
three cheers for bad software!
to call that an exploit is pretty generous
seems like we say that all the time - we must not have anyone with the crappy router
cradek: that g18 fixed my problem last night thanks
great, you're welcome
for a lathe it probably makes sense to put that in the startup gcode files in the ini
although best practice is probably to always specify it in the program
fixed it in the postprocessor once i new what i was looking for
here is a pic of the part i was making http://members.iinet.net.au/~petensneak/lathepart.jpg
what tool shape are you using?
it was a 60 deg threading tool
great, that can make a true arc without using tool shape compensation
in cvs head there is shape compensation (g41, g42) for all the tool shapes now
yep worked a treat now i need to install the spindle encoder for threading
me too, I hope to do mine this weekend
i have a 1000ppr encoder will that be ok for threading
I have a hollow shaft encoder that's much large than the back of the spindle, have to make some mounting parts for it
does that mean 1000 line or 250 line?
(4000 transition or 1000 transition)
1000 i think
sorry, I asked two ways so your answer could mean either
second question 1000 i think
if it's 250 line you can thread with the spindle going pretty darn fast, if it's 1000 line (4000 transition) you will be limited to 300 rpm or so
good, that sounds like an ideal encoder
I have to run for a while
sweet cost me 5 bucks from a scrap sealer and its brand new
03jepler 07HEAD * 10axis/extensions/gcodemodule.cc: fix the 'diagonal line' problem in the preview plot when the tool is changed
03jepler 07HEAD * 10axis/rs274/glcanon.py: fix the 'diagonal line' problem in the preview plot when the tool is changed
03jepler 07HEAD * 10axis/extensions/halmodule.c: add hal_ready
03jepler 07HEAD * 10axis/scripts/hal_manualtoolchange.py:
hal_manualtoolchange is a HAL component that shows a graphical prompt when a
tool change is requested, and sets the 'changed' signal when the prompt is
03jepler 07HEAD * 10axis/setup.py:
hal_manualtoolchange is a HAL component that shows a graphical prompt when a
tool change is requested, and sets the 'changed' signal when the prompt is
03jepler 07HEAD * 10emc2/configs/sim/sim.tbl: assign lengths to the tools
03jepler 07HEAD * 10emc2/configs/common/axis_manualtoolchange.hal: make configs/sim/axis use the new hal_manualtoolchange component for tool changes
03jepler 07HEAD * 10emc2/configs/sim/axis.ini: make configs/sim/axis use the new hal_manualtoolchange component for tool changes
03jepler 07HEAD * 10emc2/src/Makefile: make configs/sim/axis use the new hal_manualtoolchange component for tool changes
it is not at all complicated
I'll sure use it on the lathe
all it does is show a dialog that you dismiss after the change
you still can't move the joints or anything
we should see if the old tool change position code works
03jepler 07HEAD * 10axis/thirdparty/dialog.tcl: when the parent is not visible, put the dialog box in the middle of the screen
I would like to run hal configuration assistant, but when i run tcl/bin/halconfig.tcl from emc, i get a reply that there is no halconfih.tcl
i read about this in wiki
rayh took halconfig out of the 2.0 release
I don't know what his current plans for it are
cradek: I'm doing the hal_manualtoolchange as a way to avoid working on teleop mode jogging...
ok I can understand that
so how can i configure the hal
what tutorial should i read?
fogl: I suggest you start by looking at some of the sample configurations provided with emc, look at the .hal and .ini files in a text editor
fogl: There is also a ton of usefull information on the wiki
[18:17:57] <jepler> http://www.linuxcnc.org/Hal_Documentation.pdf
jepler: I was looking for that link :D
Rugludallur: linuxcnc.org, click Documentation
jepler: yup, I was searching under links (looks I need to get my eyes checked)
hey all, simple question? what speed in the .ini file becomes the G0 speed?
Roguish: it's the machine's best possible speed---so it depends on the direction of the G0.
Roguish: for instance, if all your axes can do 1 inch/second, then a G0 along X only will be at 1ips; one along X and Y will be at approx. 1.4ips (sqrt(2))
ok, so how does it compare to traj max vel?
or is that the place to limiit it?
look at getStraightVelocity in emccanon.cc
ok,thanks, i'll see if i can find it. most systems have a specific parameter for G0 velocity.
what benefit does that have?
just a setting.
if g0 is considered a trajectory, then i would hope the traj max vel would be the limit.
or each axis max vel would limit it.
i'm just trying to figure out hwo emc works and how to set it up so not to destroy a machine. (i'm kinda good at that)
any particular axis will never move faster than its [AXIS_n]MAX_VELOCITY, whether during a G0 or G1. If it does, that's a bug.
but I don't think any other restriction is made on the speed of a G0 move
03jepler 07HEAD * 10emc2/src/hal/classicladder/Submakefile: use LDFLAGS so classicladder is able to find libemchal.so at runtime
thank you gentlemen. looks like limiting max traj vel definitely limits the g0 vel.
03jmkasunich 07HEAD * 10emc2/configs/etch-servo/etch.hal: changed sample configs so that threads are no longer created by drivers, use the 'threads' component instead
03jmkasunich 07HEAD * 10emc2/configs/m5i20/m5i20_pidtest.hal: changed sample configs so that threads are no longer created by drivers, use the 'threads' component instead
03jmkasunich 07HEAD * 10emc2/configs/motenc/motenc_pidtest.hal: changed sample configs so that threads are no longer created by drivers, use the 'threads' component instead
03jmkasunich 07HEAD * 10emc2/src/hal/hal.h:
Removed 'period' option (which created a thread) from all drivers - threads are
now created by loading the 'threads' component, or by the motion controller
itself. Having the 'period' option in every driver just added a lot of
03jmkasunich 07HEAD * 10emc2/src/hal/drivers/ (hal_m5i20.c hal_motenc.c hal_stg.c hal_tiro.c hal_vti.c):
Removed 'period' option (which created a thread) from all drivers - threads are
now created by loading the 'threads' component, or by the motion controller
itself. Having the 'period' option in every driver just added a lot of
Roguish, on most controls, the feedrate is modal ...
for example would limit G0 to 400 units .. EMC just goes as fast as it can on G0s
this is sorta good im some circumstances, as for example, adjusting feedrate overide to slow down your maching cuts doesnt slow down your G0 moves, which is a good thing probably in a production enviroment
but a bad thing when setting up and testing ...
03jmkasunich 07HEAD * 10emc2/src/hal/components/ (8 files): Removed 'period', 'period_fp', 'fp_period', etc. options from most HAL components. Threads should be created using the 'threads' component, or by the motion controller. This gets rid of a bunch of duplicated code.
Lester_ is now known as Lester__
someone stole my nick
isnt this your first time on this network?
hehe so it wasnt your nick, it was someone elses
hi guy's g0 should have 3 position's 100%,50%,25% for doing single blocks when setting up machine and prove out of program
my name is too old fasioned for internet people
someone intentionally took it bastards
no rapid overide?
I believe feed override overrides _everything_ including G0 moves
there should definitely be one to overide the rapid speed
you want to just override rapids and not feed when in cut
that turns from 25% down to jog
that would be dieal
problem is everybody has their own idea of what is ideal
if i could slow down rapid, i would crashed many more machines by now
emc has had a single feed-override control for about 10 years...
just showing how industrial machines work
i havent tried it
roltek: have you tried feedoverride on a G0 move with emc?
I _think_ it should slow the G0 like it slows any other move
no just industrial machine's
* jmkasunich fires up a sim emc
jmkasunich: it does, I use it to pause for my plasma
never run my mill at 100% anyway on rapid's 1,000 inche's per min
no need to beat up ways
so, what we have today is a single feed override that overrides everything - rapids, cutting moves, jogs, etc
jmkasunich: yes, that's right. That is also in line with all commercial lathes/mills I've run
and it sounds like some of you guys would like independent overrides for different things
jmkasunich: I'm for behavior as it is now
thats why I said "problem is everybody has their own idea of what is ideal"
If people need lower G0 rates then they *can* change max_vel or have G1 with a variable as the feedrate, changed in the start of the file.
roltek: which machines have you run that have seperate overrides?
if you leave your 50% override on when your proving your program out what happens to your feed in cut
roltek: when would you want/need to only adjust g0 instead of g1/2/3? they can be just as hairy
Lerneaen_Hydra: Exactly, why would you ..
roltek: it would go at 50% feedrate
daweo,hatichi seki , kearney and trecker
if you are cutting something that work hardens, and can't slow down in cut maybe?
what type of machine? mill? lathe?
i don't think you want to be turning at 50% feed rate
roltek: can't you adjust the rate while machining?
roltek: it all depends on the material. stainless/work hardening wouldn't be all too good to go too slowly in
Lerneaen_Hydra: gotta be quick on the knob... down when rapiding, up when cutting...
these machine's have seperate switch for rapid override
it might be a nice feature
jmkasunich: That's what I've been doing, and it has worked so far, though I do see the benefits in some situation
just a thought guy's see you later
roltek: could you post a feature request on sourceforge? dunno how hard/easy it would be to implement, therefore don't know if/when it will happen
but a feature request will last longer than this IRC conversation
Lester__ is now known as Lester_
the last tiem I tried it G0 f400 did nothing in EMC ... as best I remember
F words have no effect on G0
feedrate override control does
I think the other controls I use (Bosch C220, Siemens sinumerik and a couple of PC based things) do accept F words for G0
* jmkasunich repeats: "problem is everybody has their own idea of what is ideal"
so ... isn't the only useful answer to have some method of configuring it to be YOUR version of ideal?
yes and no
when talking about changing the meaning of the g-code language (allowing F words to modify rapids), the answer is no
that is making an assumption that you have it right
rs274-ngc was written in a (probably hopeless) effort to address the proliferation of incompatible g-code dialects
so allowing the user to change the language is _not_ a good plan
wouldn't that create lots of bloat, tons of coding, and many possible conflicts? (when using style A on function B while at the same time applying C). Not to mention breaking rs274 (which is IIRC only *slightly* modified ATM)
depends, for example, if a user NEEDS to be able to change G0 feedrates programtically, then I dont see how useful that is ... to the user.
but, that asside for a monent ...
if you need to change the feedrate programaticaly, its not a G0, its a G1
robin_sz: in that case, wouldn't a G1 with a certain F be what is needed?
the point of G0 is to go at max vel all the time
Lerneaen_Hydra, possibly not, for example, lots of plasma programming systems output code such that G1 is a cutting move, and somehow the control sneses the change from G0 to G1 and lights up the torch,
03jmkasunich 07HEAD * 10emc2/scripts/hal_demo: fixed the (rarely used) hal_demo script to use the 'threads' component to create threads
and yet you _also_ need to make non-cutting moves at other than max speed?
jmkasunich, quite possibly ...
robin_sz: I'm not following you, isn't that the wanted behavior?
how about configuring it so that g1/g0 doesn't affect the torch, but rather a m4/m5?
that would make too much sense
again, dont blame me, its how some nesting/programming systems output their code
if you were trying to configure emc to mimic your existing control ...
robin_sz: what, you mean you can't config the output?
robin_sz: maybe use a python script to convert the files
robin_sz: read g0 as g1 fxx m5 and g1 as it is, and append an m3/m4
probably can .. but if you have 3 machines running some control and you want to add an emc machine that mimics them, you can either output all the code in teo formats, convert a load of existing programs ...
so you want to be able to have EMC emulate any control...
I cant predict what users do/want any better than you can I suspect .. but flexibility is usually a good start
how many commercial controls are happy to digest code in a competitor's dialect?
robin_sz: this sounds like one of the reasons for rs274, to try to get rid of this dependancy/variability
ok, fine .. now, how in rs274ngc would a user modify the feedrate in G0s?
they don't - thats exactly my point
robin_sz: that's not what I meant
its one thing to add flexibility (and I'm all in favor) when it doesn't change the meaning of a part program
its another to change the language
I meant that if every manu. were to follow a common standard (such as rs274ngc) so you don't have differing code between different machines
fair enough, but then you have to ensure your version of the language is complete
too bad that's not how things are though
its not in the manufacturers financial interest to support a standard
what's not complete with the language, other than it having a different format?
jmkasunich: indeed. vendor lock in is what they want, and we don't want...
robin: G0 is defined by RS274NGC as "go from A to B as fast as you can"
its a fundamental part of the definition of the command
well, then it must be what all users want at all times, my mistake
glad we cleared that one up :0
actually, I think I will.
I suppose you like redefining "printf" too?
what would you do in his case, some type of converter script?
I guess... but I think he invented his "case" just to be a troll
indeed, although possibly unintentionally
he has a habit of that
this is far from the first time
oh, then I get where you're coming from
wait .. I thought of a better example ...
imagine a emc controlled arm, for example a robotic arm,
that can have various tools atached ... from a few grammes, to many kilos
the only way to implement what you want would be two have two internal "feedrate" variables... one affects only G0 moves, another affects only G1/2/3 moves, and F words would change only one...
would you not perhaps want to modify the G0 speed when it was waving a dirty great big 50 kilo routing head?
which one would depend on the G word in effect at the time
shrug ... possibly ..
you are coming up with contrived examples...
thats how the other controls I have work
which is fine, IF you are also willing to think about the implementation, not just say "its wrong"
what about using g1 everywhere, and having variables instead of a fixed rate, then you change the variables in the start of a file, such as feedrate_50g, feedrate_10kg, feedrate_50kg and so on
F#5000, F#5001, etc
g0 isn't always the best approach, as you have clearly seen, so what's wrong with always using g1?
that is a way to address the problems you are raising _without_ totally redefining the meaning of G0
it would making coding a pain
what's harder about that?
you'd have to drop in F words all over the place
and how is doing g1 fxx harder than g0 fxx?
persoanlly I prefer set F at the head of the program.
besides, if you are changing the mass of the tool, the real change that you need is NOT the feedrate, its the accel
changing the rapid speed from 1m/s to 0.2m/s won't do a damn thing about the accel, and that is what will cause trouble with the heavy weight
you really need a different ini file for each tool, with suitable accel _and_ velocity limits
I admit it's not pretty to restart with a new ini when you change tools
and if you are using several tools in a program?
feedrate is "sticky" so after picking up a heavy object, enter the lower feedrate, and then don't apply anything more after that, and it'll stay untill you apply something else
but there is probably a solution that fixes both the accel and vel limits
he wants two sticky feedrates, one for cutting, and one for moving
both would be changed (probably) after switching tools
wasn't this a robot?
that moves stuff around?
he's talking about a robot that can pick up tools
no I dont ... iwas simply suggesting that since thats how all the controls I have work, other users might want it also
for instance a tiny die grinder, and then a big heavy drilling head (or something like that)
oh, so a g1.1 and g1.2, where each one is a sticky rate
lets talk specifically about the control you have
if you do:
G0 F20 foo
G1 F1 bar
the first and third moves are at 20, and the 2nd and 4th are at 1?
on the Bosch C220 and the pc based thing
and im pretty certain on the siemens too
how do you reset g0 to the original, maxvel, speed?
so it does exactly what I said... two feedrate variables, and F words change only the appropriate one
Lerneaen_Hydra, you know, I have no idea :)
to which you replied "shrug ... possibly .."
IOW, you just want to stir things up and criticize without actually contributing even the ideas (far less the code) for a solution
what, you don't like my spelling?
* robin_sz isnt even thinking about spelling
why do you see it as critical?
its discussionisnt it?
is not discussion contribution as well?
discussion doesn't generate code
it generates ideas
ideas can be just as worthwhile ...
discussion can generate ideas for code, but only if the discussion is beyond "it should do this"
when I started to talk about how it might be implemented, I got "shrug"
so why not program the machine in a pseudocode, maybe that looks something like this:
1 f100 foo
2 f200 bar
3 f10 blah
4 f50 boink
and so on, after where a script takes that file, and converts the 1,2,3 to g1 with the appropriate feedrate. (which would be in this case 100,200,10,100,10,200,50,100).
when Lerneaen_Hydra asked about how to reset to max speed, he got "I have no idea"
I have no idea how the controls I have reset to max speed
but some method is needed if we're to implement your idea
its nto someting I had even cosnsidered until LH brought it up ...
indeed and a valid point
wait .. this isnt MY idea
you are the only one (at least in this conversation) who is in any position to answer that question
supporting F words under G0 _was_ your idea
the other folks wanted a separate feedrate override for G0 moves
which I was far more receptive to, because it doesn't try to redefine the language
umm no, I think Bosch and a few others got there before me .. presumably they consulted with their users first ...
you're being difficult, I assume on purpose
for the purpose of this conversation, you suggested a feature
therefore its your idea, and you are the (non) user that ewants it
a feature I have seen and used on varous controls
ok, fien lets call it my idea then ...
when LH asks a legit question about how your feature might be implemented, you have no idea
you may never want to return your machine to full speed, but many other users do
sure .. and as I said a very valid point
whatever ... this is all getting WAY out of hand
the discussion was about G0 and G1(etc) feedrates and overides
I was merely pointing out that many controls do things in many ways, perhaops some of theose ways might actually be the way the users want
and perhaps, it might be worth consdiering if some of those ways had merit
perhaops some of theose ways might actually be the way the^H^H^H _SOME_ users want
exactly .. SOME
perhaps the way we're doing it is _ALSO_ the way some (many) users want
whats so bad about allowing the users to CHOOSE?
if it can be made configureable without changing some fundamental definitions, then nothing is bad about it
but what you are describing would change the behavior of F words
for example, this program:
F1 G1 foo
i know what you mean
what speed is the G1?
the F10 applies in G1 but not G0
in current emc, its 10
oh f1 in 2nd example
current EMC: first G1 is at 1, second G1 is also at 1
a human reading the code would expect both G1's to be at 1 and the G0 to be at 10
but the implementation I described (two variables, F words apply to the active one) would get it exactly wrong
because it would apply the F10 to G1 moves, since G1 is in effect when the F10 is seen
if the F10 was on the same line as the G0, it would work right
the idea of having two variables (G0 feedrate, and G1/2/3 feedrate) controlled by one code (F) is dangerous for that reason
the first F10 is ambiguous I guess
depends on what mode the control was left in
so ... the example you give is a valid one, and poitns out a flaw ...
I suspect no one implementation is perfect
A discussion that looks for flaws in a proposed implementation, and either overcomes them or switches to another implementation, is usefull
a discussion that doesn't do that is just a troll
so , you think I just spent 20 minutes trolling?
if it looks like a duck...
fwiw, I was simply tryingto enjoy a pleasant evening
in the comapnayt of some people i have known on the ;net for a while ..
and got told to fsck off and im a troll ...
you have a habit of pointing out real and/or percieved flaws in EMC, without suggesting valid solutions to those problems
this is _not_ the first time (although its the first time I let it make me lose my temper)
again, my time is limted, contributing code is probably not within what I can do right now
spending the 20 mins seriously trying to come up with an alternative (in words, not code) that works, is all I ask
I use various controls, all day, everyday, I was just pointing out how they differ ... I wasn't suggesting that they were perfect
the two overides idea was a good one though .. I wish they had that
If I've understood this correctly, then the point of this is to type fewer F commands, rather than add more functionality, so why add this to emc, with the possible inconsistancies that that could entail, instead of using a 3rd party translator
well, a couple of them did
uh, goodnight all
Lerneaen_Hydra, thats fine, but its not the way the controls I have do it, over the years, I have found that the whole G0 and overides thing is doen in so may different ways, no one implementation can be right
for all users
no one implementation can make everyone happy.... but none of those controls have _multiple_ incompatible implementations, do they?
so why do you suggest that EMC should?
eh? I wasnt necessarlily suggesting that emc should do it exactly like that, but that MAYBE being able to adjust G0 feeds programmaitcally might be useful to some users
perhaps setting a #xxxx variable ...?
although, that seems a bad thing
you did _not_ suggest that, you were focused on F words
im open to better ideas ...
LH suggested using vars for feedrate, and you didn't like that
as the one who raised the issue in the first place, you are the one who gets to suggest better ideas
if you like how control "X" does it, then tell us _exactly_ how control X does it
how does control X solve the "ambiguous F word" problem, and the "reset to max" problem?
you don't need to see or understand control X's internals to answer that, just the programming manual should say so
and, as a result of our "discussion" I will try and find out ...
thanks, I look forward to hearing what you find
I suspect that setting a F higher than Fmax defaults to Fmax,
yeah, that sounds like a reasonable solution to that issue
thats probably what EMC does if you give it a too-high F word too
im pretty sure that the PC control remembers from day to day whethter it was in G0 or G1 last time you prodded it, (it remembres 90/91
(the only other reasonable alternative is to ignore it completely)
I think the PC control doesnt handle the initial F word ambiguity well ... infact im sure it doesnt
so to be safe, you need to issue two F words at the beginning of a program, one to reset the G0 feed to a know value, and one to reset the G1/2/3 feed to a know value
the Bosch and Siemens I think default to G0 on program load
what about the ambiguity within a program
does the controller lookahead to the next G0-3 move to decide which feedrate the F word applies to?
or does it apply to whatever mode is in effect at the time?
those two choices will change the feedrate of the G1 in that code
the former is what a naive human reader of the code would expect, the latter is more in keeping with the modal nature of g-codes
I'd have to do some tests . .on the Bosch and Siemens, I think they default to G0 on program load, so the F1 would apply to the G0 feed
the initial default doesn't matter for the case above
I guess I wasn't clear... that snipped is in the middle of the program, after possibley many G and F words
inthe middel of a program it woudl apply to whatever mode the mchine was in
so, the latter of my two cases
if it was in G1, then it woudl simply set the G1 feedm, then go into G0
and my snippet would set the G0 feed, then go into G1
exactly the opposite behavior of "normal" G-code
right, thats what I would expect it to do
again, your version of normal is different from mine
today, with EMC, that code would set the G1 feed (the only feed) to 1, then do the G1 move at the new rate
when two definitions of "normal" differ, the one documented in the RS274-NGC documents wins, as far as EMC is concerned
so, lets accept that for the moment
but ... do you tink a user should be able to adjust G0 feeds ?
thats the fundamental point I thnk
if thats the fundamental point, then I can agree with it, as long as the implementation doesn't change the language in a way that breaks programs that _don't_ intend to use that feature
I have a hard time seeing how to make such an implementation using the F word
well, using something other than the F word to set feeds seems a bit "odd"
I'd like a (rapid) transverse override for setups but I fail to see the need to define a rapid movement by feedrate, if you don't want to rapid, don't rapid ;-)
stiles: that has pretty much been my argument, but I'm trying to be open-minded
well, other controls do allow users to set G0 feeds ... maybe in non-perfect ways ...
I suppose you could say "if (and only if) an F word appears on the _same line_ as a G0, that F word affects either that G0, or that and subsequent G0's, without affecting G1/2/3
but F words by themselves would always affect only G1/2/3, so (most) existing programs would not change their behavior
you could even have a switch in the ini, or a boolean variable in the #xxxx vars to set whether G0 Fxxx was acted on on or ignored
what would G0 F400
(it is perfectly legal to put an F word on a G0 line today, it will change the feed for any subsequent G1/2/3 moves)
to take your naiive human reader ...
isn't a G0 with a feed really just a G1?
they might expect the opposite
robin: you lost me
jmkasunich, a human reader might expect:
dan_falck: yeah, at least thats the way I see it, but I guess there are controls out there that disagree
G0 X0 Y0 F40
to do the G1 at the G1 feedrat previously in use .. .
if they're used to EMC, they would expect either an error on the G0 line "no F word allowed", or that the G1 would happen at 40
because there is only one feedrate
dan_falck, I use 4 controls fro, day to day, all can set G0 feeds with an F word ...
and the F word changes it, for all future moves
ok, all the fanucs in the shop I work in can't. Seems like a very dangerous feature.
dan_falck, to answer your "isnt a G0 with a feed just a G1" .. no, some controls do other things in G0, liek ignore followign errors, automatically retract a tool for axample
robin_sz: are your controls running mills? or lasers/plasmas?
the bosch is on a laser, the pc controls are on routers and the Siemens is on a punch
seems like it could be delt with with a global parameter for things like tool retract
the fanuc is on a mill I bet
we have lathes and mills
we have some yasnac controls (i80) too
so controls targeted at different markets may well have evolved differnet behavior to serve those markets
kind of like plotters are a form of a small cnc machine with hpgl language
if emc works like a fanuc today, it is impossible to say that making it work like a bosch is better
jmkasunich, for example, on the punch we set lower G0 feeds when we have HEAVY sheets on the clamps, so they dont let go .. as you say, accels would probably be a better plan, but, whatever, we set lower feeds, and thats a useful feature for us
ok I can see that
so, you use G0 feeds as a partial solution of a real problem... but its one that would be handled better with dynamically settable limits on both accel _and_ velocity
then G0 would just run at those (lower) limits
that would be a better solution, yes
how about a seperate knob on the front panel that says '25% 50% 75%' of rapids, seperate from G1 feed?
I wish cradek was here
dan_falck: thats a form of feedrate override
feedrate overide is another whole can of worms ... ;)
for example ...
IOW, we could have two feedrate override knobs, one for G0, one for G1/2/3
on the punch, you might want to slow everything down on one knob ...
on the laser we do have one knob, and it slows everything .. smae on the punch .. and on the punch thats good thing
on the laser thats BAD thing
robin_sz: if we do separate feed overrides, I'm be inclined to make both feedrate override inputs HAL pins
yes, I could see that being bad...
you could then hook a single knob to both, or hook two knobs up
onthe laser, you tweak the feedrate to get a good cut, the G0 slows down, wasting time
jmkasunich, that would be the ideal solution I think ...
as I said to roltek, seperate feedrate overrides is an interesting idea, and I asked him to enter a feature request into SF
(I was too lazy to do it myself, I was coding at the time)
that has since come to a screeching halt ;-/
jmkasunich, imagine the virtual pot that is the feedratre slider ...
one end is at 0v
the other at say +5V .. the output goes off to your hal pin ...
pin or pins
what if, instead of 5V it was fed with the interpreters idea of F.G0 or F.G1
well, it already is (but always F.G1, since we have no F.G0)
then you could hook up the G1 slider to either ignore or accept G1 feeds from the interp
just a thought
the feedrate override is applied to _every_ move, even jogs
yes, the bosch and siemnes do that ...
jogs slow as the knob gets turned down
feedrate override is implemented in EMC as a scale which is applied to velocity
so the net effect is the same as your pot
your pot multiplies the feedrate by a value between 0.0 and 1.0
uh huh. actually, 0 to 1.1, but go on ...
EMC multiplies feedrate by a value between 0.0 and MAX_OVERRIDE (which can be greater than 1.0)
funny, I never saw a pot that could take 5.0V in and give 5.5V out?
I tink I said "virtual pot"
still, virtual pots should work like real ones
if you want a max override of 1.1, multiply the signal by 1.1 _before_ you apply it to the top of the pot
I think we both understand what the other is saying
* robin_sz nods
we already have the multiplication taking place _inside_ the motion controller
(in fact, we have two multiplications.... the commanded feed is multiplied by one "scale" from the user (GUI) that can go from 0.0 to MAX_OVERRIDE (possibly greater than 1.0)
and also by another one, from a hal pin, called "adaptive feed"
that one goes 0.0 to 1.0 (to avoid problems with exceeding limits when > 1.0)
so, splitting to two slider is a work of a moment or two .. .
so far, we've used "adaptive feed" for feedhold from a button, and for EDM (where feedrate is controlled by gap voltage)
or, a few hours anyway
thinking thru the implications will take longer
so, in essence, all that I might be suggesting is ...
right now, the sliders _don't_ go thru hal at all
so VCPs cant have sliders?
the GUI sliders don't go thru hal
VCP's will eventually have sliders (thats just a matter of having the time to code it)
those would go thru HAL
sounds like it might be a nice features
two completely different paths for feedrate override seems scary tho
feedrate overide in the standard GUI is a messy thing anyway, lots oand lots of messaging
it just sends one message when you change it
cradek: we're talking about the possibility of having separate feedrate overrides (and possibly separate program specified feeds) for G0 as opposed to G1/2/3
ask robin_sz ;-)
mostly because some of the controls he uses (like all of them) have it
quick example ...
I'm not just being difficult
I don't see why you would want to slow down g0
robin_sz jmkasunich, for example, on the punch we set lower G0 feeds when we have HEAVY sheets on the clamps, so they dont let go .. as you say, accels would probably be a better plan, but, whatever, we set lower feeds, and thats a useful feature for us
CNC punch ..
what he said :)
a couple other people have expressed interest in slowing down G0 while proofing a program
I think FO already does that
which feedrate override can do... but it also slows down the already slow cutting parts
heh... this is funny. http://18.104.22.168/discopenguin.html
cradek, and for example, on the laser, slowing down the cuttign feed on the slider, but leaving G0 fast is also a good plan
anyway, on the FO part... what if the motion controller had two hal pins, one is FO for G0, one is FO for G1/2/3
for the existing behavior, connect the same signal to both
for dual controls, connect one "pot" to each
does it for me
you want to take FO out of the regular gui?
I'm not sure
if you need your punch to move at the right speed, why do you program G0?
that's also what I'm wondering
thats what LH said an hour ago... ;-)
well it's an obvious question
of the 4 controls I use from day to day, all can set G0 from the program
G0 feed ...
ok, but that's not an answer to jeff's/LH's/my question
either, thwy are all all wrong, or its soemting at least worth considering might be useful ...
IMO it's not a matter of them being wrong or right, it's a matter of deciding whether we really want another slider on all the guis
the answer to jeffs question is that on his controls, he can write fewer lines doing it with G0 feedrate control
cradek: no, not on all the guis
robin_sz has long been a proponent of customizable guis
not true: g1 f10 fast move; g1 f5 slow move
cradek, again .. that spersonal preference .. some users might want another slider, some might not ...
so you'd only add the slider when needed
I'm not going to be dragged into that discussion again today, I'm too busy
we're not discussing sliders and guis, you brought that up
we're discussing feedrates
* robin_sz nods
although what I actually want to ask you is something different, brought up by the heavy sheet on the punch problem
the real issue with the heavy sheet is accel, not vel
feedrate does nothing for that
so this isn't even going to solve the problem.
you know the TP better than I, what are the issues involved in changing accel or vel limits on the fly?
mid-move: hard; for the next move: easy
next move is fine I think
what if there was a way that a custom M code could set the velocity and accel limits?
right, if you're going to do it with a gcode, that's what you'll get
keep G0 defined as "move as fast as you can"
but let them change "as fast as you can" under program control
a custom M code would seem a fair choice
it should be a G, but same difference
there would have to be hard limits in the ini file so you don't break the machine with a badly written g-code program
well, we could implement it whatever way seems best
we already have the ability to execute scripts with custom M codes, so that came to mind
I think generally G is for motion and M is for I/O
and this is certainly a motion-related command
mid-move: hard; for the next move: easy - even with blending?
but we'll hash that out later if we decide to do it
already each move often has a different accel
just like they often each have a different velocity
I suspect the feedrate overide is less contencious
well, an extension that lets us change the limits (vel and accel) would be transparent to folks that don't use it
unlike the G0 F words
so far less contentious
I'm sure ok with adding a gcode
but I think adding still more sliders (whether on guis or in hal) is bad, we already have several that work together in not-always-obvious ways
1) Gaa <maxvel> <maxaccel> sets accel and vel limits for all subsquent moves
2) Gaa <maxvel> <maxaccel> sets accel and vel limits for all subsequent G0 moves
Gbb <maxvel> <maxaccel> sets accel and vel limits for all subsequent G1/2/3 moves
* robin_sz ponders
I can't see why you would want to reduce accel on only some moves
mass is mass
actually, Gbb would only take an accel, velocity comes from the F word
so use #1
maxacc applies to all moves all the time
maxvel applies to all moves too, but usually the F word will be lower than the max on G1/2/3 moves
do we want absolute A or A scaling?
G0 moves will obey only the maxvel, not the F word
A scaling seems better
scale the machine limits
* robin_sz ponders that one
I thought that too, but the asymmetry with the way the F word works bothers me
a g-code programmer is more likely to know that this part needs to run at 50% than at 145mm/sec^2
my wife just called, she's going to be home soon, and we're going out to dinner
well, off you go then ;)
bring something back for the rest of us
can somebody write this up as a feature request, and put whatever gets decided (or not decided) in it?
really, two of them
maybe robin_sz could make a wiki page
the g-code thing and the overrides are completely independent
maybe I could ...
the hardest part will be coming up with letters that make sense in the gcode
obviously F and A are out
G999 Q0.7 => scale accels by 0.7
cradek, FWIW, on all 4 controls O have, G0 F84 would alter the G0 feedrate, and leave G1 alone. that may be not what emc does, or even what you expect, but it deos seem to be common, on at least european controls
I thought we were talking about accel
if you have a mass problem changing the feed rate isn't going to help is it?
regardless of the accel, would you be happy to see a sheet of 10mm steel flying about at the same speed as a 1mm sheet?
there seems to be lots of different ways to do this ... Isuspect the only REAL answer is to make it so the users can plug it up the way they want ...
alternatively, my concern is to do it in the way that doesn't break existing programs (i.e. the ngc spec)
well, the feedrate overides is not involved in that ...
that's why I think we can add a gcode, but not do G0 F99 or the like
I liked jmkasunich suggestion ,.. G0 lways means "as fast as you can"
and "as fast as you can" is settable
fucked up scientologists? http://www.consumerist.com/consumer/top/scientologists-bullying-mans-mind-181442.php
alex_joni, you awake?
* A-L-P-H-A pokes alex_joni in the eye to wake him up.
* alex_joni goes to sleep
alex_joni is now known as alex_joni_away
I'll bbl (about 2 weeks)