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