Back
[03:14:47] <SWP_Away> SWP_Away is now known as SWPadnos_
[06:21:08] <SWPadnos_> thank you
[06:21:24] <petev> had to bail u out a bit
[06:21:51] <SWPadnos_> yeah - I'd just like for him to tell us why it's so bad for this, not why he hates it
[06:22:03] <petev> yeah, doesn't seem like he can
[06:22:30] <SWPadnos_> nope
[06:22:37] <petev> sure some range checking, etc will need to be done by emc, but at least the file is dosumented and valie
[06:22:46] <SWPadnos_> actually, I'm not sure that XML will really help much for several situations
[06:23:17] <petev> yeah, there are some limitations, like enums only in attributes
[06:23:26] <petev> but it's still the best thing I have seen
[06:23:29] <SWPadnos_> one - signals. The user has to be able to add an unspecified number of signals, with arbitrary names, to a config
[06:23:41] <petev> SQL is way over the top, I can't even beleive he suggested it
[06:24:00] <SWPadnos_> yeah - he's coming at it from the data transport side
[06:24:02] <petev> signals aren't a problem
[06:24:06] <SWPadnos_> shich is what it was made for
[06:24:09] <SWPadnos_> which
[06:24:14] <petev> XML uses some of the EBNF notation
[06:24:29] <petev> you can do something like (SIGNAL)*
[06:25:35] <SWPadnos_> ok, will a DTD allow you to specify that you can have as many signals as you want, along with as many links as you want, but only one output per signal? :)
[06:26:07] <petev> I don't see how u would do the one output part
[06:26:16] <SWPadnos_> yeah
[06:26:20] <petev> some stuff will have to get checked at run time
[06:26:29] <petev> but it's still better than what we got now
[06:26:31] <SWPadnos_> and that's probably going to be the most common problem
[06:26:35] <SWPadnos_> yep
[06:26:49] <SWPadnos_> I think a config program like qconfig would be nice
[06:27:11] <petev> yeah, a fancy GUI using an XML parser object
[06:27:13] <SWPadnos_> but that would have to be modified and maintained by us
[06:27:19] <petev> true
[06:27:31] <petev> the simple XML folding tree thing isn't bad
[06:27:45] <SWPadnos_> not necessarily XML - the underlying format isn't important as long as the user interface and validation requirements are met
[06:28:12] <petev> true, but I want to use the XML parser object in EMC to access the data too
[06:28:37] <petev> I would like task to open the config, create an XML parser object, and pass it around
[06:28:38] <SWPadnos_> well, the "config tool" can just write files that emc can understand
[06:28:55] <petev> yeah, but then we have to write an object to deal with it
[06:29:03] <SWPadnos_> that may be
[06:29:06] <petev> other goal is to reduce EMC to machine control code
[06:29:23] <petev> there are bindings for a bunch on languages for gnome libxml2
[06:29:39] <SWPadnos_> there's another viewpoint on that - that there should be as few external dependencies as possible
[06:29:59] <SWPadnos_> right now, stock Linux + RT is enough for emc2
[06:30:17] <SWPadnos_> since there is some editor, and probably a compiler, on every linux distro
[06:30:26] <petev> true, but these are standard packages that most systems probably already have
[06:30:32] <SWPadnos_> I didn't
[06:30:39] <petev> didn't have which?
[06:30:41] <SWPadnos_> and I just did a full Ubuntu install on this machine
[06:30:49] <SWPadnos_> didn't have any XML editor
[06:30:56] <SWPadnos_> or XML libraries
[06:31:02] <petev> but u can apt-get kxmledit
[06:31:07] <petev> pretty easys
[06:31:27] <petev> we can also put one on the BDI
[06:31:28] <SWPadnos_> right, but only if I have a debian install, and internet access on the machine (not necessarily the case)
[06:31:37] <petev> look how many packages emc already needs
[06:31:48] <petev> we need all the GTK stuff
[06:31:50] <SWPadnos_> BDI is gone -there will need to be a different distribution for emc2
[06:32:07] <petev> why can't we make more BDI without Paul?
[06:32:19] <SWPadnos_> I'm not saying it's a deal breaker, only that there will be another viewpoint
[06:32:19] <petev> did he keep all the anaconda stuff to himself?
[06:32:31] <SWPadnos_> because Paul owns the BDI trademark, and it's his baby
[06:32:44] <SWPadnos_> he has moved BDI discussion away from SourceForge
[06:35:47] <SWPadnos> SWPadnos is now known as SWP_Away
[10:13:34] <petev> .part
[15:47:23] <okalleo> * okalleo is away: back in 5min
[15:56:50] <okalleo> * okalleo is back
[16:03:30] <okalleo> * okalleo is away: will be back soon
[16:20:47] <alex_joni_> alex_joni_ is now known as alex_joni
[16:25:30] <okalleo> * okalleo is back
[16:33:31] <alex_joni_> alex_joni_ is now known as alex_joni
[16:50:32] <okalleo> * okalleo is back
[16:56:10] <okalleo> * okalleo is away: wbbs
[17:02:21] <rayh> I got a brute force tcl script running that shows a tree version of hal pins and params.
[17:02:38] <rayh> Just enought so that I can play with some config ideas.
[17:02:43] <alex_joni> great
[17:02:52] <alex_joni> hard to work with it?
[17:03:04] <alex_joni> I mean.. hard to work with HAL in tcl?
[17:03:25] <rayh> No it is easier for big hal configs that the menus that I was trying.
[17:03:39] <SWP_Away> SWP_Away is now known as SWPadnos
[17:03:46] <alex_joni> morning swampy
[17:03:51] <SWPadnos> morning
[17:05:02] <SWPadnos> ok - now this is annoying
[17:05:12] <alex_joni> what is?
[17:05:15] <rayh> I'll have to finess it a bit. the [set [set [set $thispinname]]] is aweful.
[17:05:35] <SWPadnos> remember the questrion about emc that I posted yesterday?
[17:05:40] <alex_joni> no
[17:06:05] <SWPadnos> well - I'll paste in the question, and an answer - typical FUD crap
[17:06:14] <SWPadnos> not my answer, of course
[17:06:30] <SWPadnos> >I looked at EMC a couple years ago when I was looking for a option to
[17:06:32] <SWPadnos> >>Flashcut. Went with Mach2. I hate all the problems with windows and
[17:06:34] <SWPadnos> >>would love to jump to the linux wagon but my problem is how do I
[17:06:35] <SWPadnos> >>create the toolpath in linux?
[17:06:36] <SWPadnos> What problems with windows?
[17:06:38] <SWPadnos> >>Other than my router and quickbooks for me there is no reason to stay
[17:06:39] <SWPadnos> >>with windows.
[17:06:41] <SWPadnos> There's two, and with the endless reinstalls of linux and waiting for
[17:06:42] <SWPadnos> EMC till your old and bald - two more ;)
[17:06:44] <SWPadnos> Steve Blackmore
[17:07:31] <alex_joni> bleah..
[17:07:37] <SWPadnos> yeah
[17:07:40] <alex_joni> what group was this?
[17:07:52] <SWPadnos> yahoo CAD_CAM_EDM_DRO
[17:07:56] <SWPadnos> sorry
[17:08:03] <rayh> Oh thought it was mach10
[17:08:06] <SWPadnos> this was the CNC Toolkit group
[17:08:26] <alex_joni> url?
[17:08:49] <SWPadnos> http://groups.yahoo.com/group/CNC_Toolkit/
[17:08:59] <alex_joni> thanks
[17:09:04] <SWPadnos> sure
[17:49:38] <okalleo> * okalleo is away: _
[19:22:31] <SWPadnos> SWPadnos is now known as SWP_Away
[20:51:11] <rayh> Hi jmkasunich
[20:51:53] <jmkasunich> hi ray
[20:52:26] <jmkasunich> this is the devel channel, right?
[20:52:34] <rayh> Question. I was trying to reverse the polarity of limits on emc.run
[20:52:44] <rayh> yes
[20:53:08] <jmkasunich> ok, (my IRC client displayed some strange things, probably from autojoin)
[20:53:16] <jmkasunich> ok, polarity
[20:53:28] <rayh> Oh. Right I get that everytime I start it up.
[20:53:37] <jmkasunich> you want to make the limit switches active low or something like that?
[20:53:59] <rayh> I just thought it was old age but can't be if you get it also.
[20:54:08] <jmkasunich> heh
[20:54:43] <rayh> I didn't see limit polarity in ini nor in an axis pin
[20:55:04] <jmkasunich> polarity is addressed at the hardware driver
[20:55:12] <jmkasunich> so once inside the PC, everything is active hi
[20:55:46] <jmkasunich> for an input pin, the driver exports 2 hal pins, parport.0.pin-xx-in, and parport.0.pin-xx-in-not
[20:55:54] <jmkasunich> connect to the -not one and it is inverted
[20:56:25] <rayh> I'm still confused.
[20:56:33] <rayh> I tried hooking a sig to
[20:56:52] <rayh> axis.0.neg-lim-sw-in
[20:57:01] <rayh> and then twiddle the sig
[20:57:13] <rayh> but it said something about not being able to do that.
[20:57:34] <rayh> I don't remember exactly now. Let me try again.
[20:59:32] <jmkasunich> sets to twiddle the signa;
[20:59:35] <jmkasunich> signal
[21:00:19] <rayh> musta been a brain fart last time. works fine now.
[21:05:15] <rayh> ah it's the home that doesn't seem to respond.
[21:05:30] <jmkasunich> the home switch?
[21:05:47] <rayh> I make a signal connect it to home-switch-in and it does not make a difference what the polarity is.
[21:06:03] <jmkasunich> what is your HOME_SEARCH_VEL in the ini?
[21:06:04] <rayh> It always homes as soon as I press the button.
[21:06:19] <rayh> emc.ini stock
[21:06:33] <jmkasunich> if it is zero, then that tells EMC "this machine doesn't have switches, home wherever they push the button"
[21:06:50] <jmkasunich> I think stock emc.ini has zero
[21:07:03] <rayh> shit another undocumented "machine logic"
[21:07:21] <jmkasunich> actually, its very well documented
[21:07:31] <alex_joni> evening
[21:07:34] <jmkasunich> (but you gotta know where to look :-(
[21:07:38] <jmkasunich> hi alex
[21:07:56] <alex_joni> how's things john?
[21:08:06] <jmkasunich> not bad
[21:08:18] <alex_joni> nice.. tried to run a rotary table today
[21:08:27] <alex_joni> with a mm setup.. that was havoc :/
[21:08:34] <rayh> I confess I looked for home switch polarity both in the ini and hal and hal but found none.
[21:08:44] <rayh> didn't look in HAL_Int
[21:08:46] <jmkasunich> rayh:
http://www.linuxcnc.org/EMC2_Code_Notes.pdf, starting on page 20
[21:09:01] <jmkasunich> that info should probably be moved somewhere more accessible
[21:09:05] <jmkasunich> but its all in there
[21:09:13] <alex_joni> jmkasunich: okalleo here (previously known as chinamill) is using emc2 with mm setup
[21:09:21] <alex_joni> and he kept getting ferrors
[21:09:39] <alex_joni> untill I told him to increase the values for stepgen max_vel and max_accel
[21:09:58] <jmkasunich> that headroom problem is gonna cause us no end of grief
[21:09:58] <alex_joni> seems increasing by a factor of 25.4 made a big difference
[21:10:02] <rayh> * rayh slinks off to work on hal_tree
[21:10:03] <jmkasunich> ?
[21:10:13] <alex_joni> I think it's a problem of units here, not headroom
[21:10:16] <jmkasunich> !?! 25.4
[21:10:27] <jmkasunich> yeah
[21:10:29] <alex_joni> he said 10 times more is getting him less ferror
[21:10:38] <alex_joni> so I suggested 25.4
[21:10:48] <jmkasunich> thats just fscked
[21:10:53] <alex_joni> I think stepgen is getting inch command from emc
[21:10:58] <jmkasunich> can you get me a copy if his ini?
[21:11:00] <alex_joni> but is reading mm units from the ini
[21:11:03] <alex_joni> it's in SF
[21:11:06] <alex_joni> under the latest bug
[21:11:18] <jmkasunich> * jmkasunich looks
[21:13:43] <jmkasunich> he has 500 counts per mm?
[21:14:05] <alex_joni> and a speed of 4mm/sec
[21:14:20] <alex_joni> okalleo: you around?
[21:14:33] <alex_joni> seems away..
[21:16:03] <jmkasunich> lemme scope the output of the motion controller and see what is coming out
[21:16:12] <alex_joni> ok
[21:16:22] <alex_joni> * alex_joni is analysing the changes in emc1
[21:16:27] <alex_joni> reading cvs logs
[21:17:21] <rayh> sucks that BWidget tree will not allow the same node name in different nodes.
[21:28:22] <jmkasunich> okalleo's ini file has some funny values in it
[21:28:36] <alex_joni> it sure has..
[21:28:45] <jmkasunich> trav max_vel is 8, but the axis are 4,4,4,5.4
[21:29:08] <jmkasunich> traj accel is 40, axis are 2,2,1,3
[21:29:09] <alex_joni> shouldn't matter
[21:29:16] <alex_joni> not sure about accel
[21:29:21] <alex_joni> but vel shouldn't matter..
[21:30:47] <jmkasunich> on a 1mm jog, I see a max vel of 0.25mm in 200mS = 1.25mm/sec, well within limits
[21:31:05] <jmkasunich> but the feedback is falling behind and then overshooting
[21:31:28] <alex_joni> hmm.. how so?
[21:31:53] <jmkasunich> hmm, the command has an initial step of about 0.01mm
[21:32:01] <jmkasunich> bet thats the backlash
[21:32:19] <alex_joni> btw, he reported the jog moving a bit further then coming back
[21:32:28] <jmkasunich> yes, thats the overshoot
[21:32:34] <alex_joni> yeah, seen some backlash on axis X
[21:32:41] <jmkasunich> he has huge following error limits, 10 mm min, 12mm max
[21:33:03] <jmkasunich> so he has all kinds of ugly stuff going on long before he trips on an error
[21:33:42] <alex_joni> yes, he set them in order not to get ferrors
[21:33:42] <alex_joni> although that's not a wise plan
[21:34:07] <jmkasunich> I find it very hard to put myself in other peoples shoes
[21:34:21] <alex_joni> you think backlash might be the problem of the ferrors?
[21:34:26] <jmkasunich> when I see something funny, the first thing I do is haul out the scope and try to understand what it is
[21:34:29] <alex_joni> backlash combined with slow speeds & accels
[21:34:37] <jmkasunich> yes
[21:34:45] <jmkasunich> slow accels especially
[21:34:57] <alex_joni> 2 mm/s^2 does seem incredibly slow
[21:35:03] <jmkasunich> 2mm/sec^2 is very slow
[21:35:05] <jmkasunich> heh
[21:35:19] <alex_joni> like I said .. great minds think alike
[21:35:20] <alex_joni> :P
[21:35:36] <jmkasunich> maybe he has a 50kG flywheel on his leadscrew, and a NEMA 17 stepper?
[21:35:38] <alex_joni> jmkasunich: we should get a decent mm ini in CVS
[21:35:54] <alex_joni> I think he has some very small steppers
[21:36:57] <jmkasunich> ok, I'm gonna get rid of the backlash and see what difference that makes
[21:37:03] <alex_joni> [17:45] <alex_joni> what steppers do you use?
[21:37:03] <alex_joni> [17:45] <okalleo> vexta
[21:37:17] <alex_joni> does that mean anything to you?
[21:37:30] <jmkasunich> its a brand name
[21:37:46] <jmkasunich> by itself doesn't mean much
[21:37:53] <alex_joni> probably..
[21:38:04] <jmkasunich> vexta does tend to make a lot of 5 phase steppers, which need special drivers
[21:38:23] <jmkasunich> but they make regular ones too (I think), so name alone doesn't tell much
[21:38:38] <alex_joni> Hi Alex,
[21:38:38] <alex_joni> ich kann es mir nicht erk�ren: Irgend jemand muss dio_init()
[21:38:38] <alex_joni> auskommentiert haben. Unglaublich! Ich habe im cvs nachgesehen, ob Du es
[21:38:38] <alex_joni> warst. Anscheinend nicht. Ich glaube echt, ich werde unzurechnungsf�hig.
[21:38:38] <alex_joni> Nun ja, jetzt funktioniert alles wieder, d.h. , nachdem ich noch mal
[21:38:38] <alex_joni> gebootet hatte, weil die stg-karte total durcheinander war.
[21:38:40] <alex_joni> Was bleibt ist der eine input, der immer flattert, aber das scheint ja nun
[21:38:42] <alex_joni> wirklich ein elektrisches Problem zu sein.
[21:38:44] <alex_joni> Die Referenzpunktfahrt funktioniert jetzt 1a. Auch, wenn man w�hrend der
[21:38:46] <alex_joni> phasen dauernd neue ref-befehle gibt. So was nennt man einen robusten
[21:38:48] <alex_joni> zustandsautomaten!
[21:38:58] <alex_joni> yay...
[21:39:07] <jmkasunich> if you say so... ;-)
[21:39:10] <alex_joni> that's a letter from till in case you are wondering ;)
[21:39:22] <alex_joni> he's reporting homing works ok on a stg2 with emc2
[21:39:28] <jmkasunich> cool
[21:39:40] <alex_joni> and he's appreciating your homing mechanism
[21:39:51] <alex_joni> the state machine actually
[21:40:02] <jmkasunich> I'm glad he likes it
[21:40:14] <alex_joni> he's impressed that he can send multiple homing signals even when the state machine is advanced
[21:40:24] <alex_joni> and it doesn't crap out ;)
[21:40:42] <alex_joni> and I'm sooo GLAD it works on the STG2 ;)
[21:40:47] <jmkasunich> ah, it's so nice to have scope come up with the right signals and everything...
[21:40:52] <alex_joni> I didn't even have one to test..
[21:41:02] <alex_joni> did most by email with till
[21:41:09] <jmkasunich> impressive
[21:41:16] <alex_joni> btw, he had some problems with 'realtime start/stop'
[21:41:24] <alex_joni> your favorite problem
[21:41:25] <alex_joni> :P
[21:41:32] <jmkasunich> ?
[21:41:35] <alex_joni> if you remember :)
[21:41:39] <alex_joni> the symlink for ksched
[21:41:44] <jmkasunich> oh
[21:41:54] <alex_joni> and you (me) thought it was fixed
[21:42:16] <alex_joni> I think we should change ksched with up
[21:42:31] <alex_joni> beause it's unlikely for people to run anything else
[21:42:40] <alex_joni> and the ones who do.. well they can change it
[21:43:20] <jmkasunich> might not be a bad idea
[21:43:25] <jmkasunich> wow
[21:43:30] <alex_joni> what?
[21:43:36] <jmkasunich> backlash is gone, but I get massive overshoot from stepgen
[21:43:48] <alex_joni> granularity problem?
[21:44:20] <jmkasunich> I'm doing a 1mm move, using 400mm/min max vel (I think) and 2mm/sec^2 accel
[21:44:47] <jmkasunich> it lags behind by about 0.04mm during the accel phase (which never reaches full speed in this short move)
[21:44:56] <jmkasunich> then it overshoots by nearly 0.3mm
[21:45:31] <alex_joni> then jogs back?
[21:45:37] <jmkasunich> yes, then it recovers
[21:45:49] <jmkasunich> I'm gonna try giving stepgen some accel headroom
[21:48:18] <jmkasunich> heh, perfect tracking (at least at 200um per division)
[21:49:12] <okalleo> * okalleo is back
[21:49:25] <jmkasunich> following error of about 2 microns, if I set the stepgen accel to 2.2 instead of 2.0
[21:49:56] <alex_joni> so it needs to have more than emc
[21:50:16] <okalleo> Howdy
[21:50:27] <jmkasunich> yes
[21:50:30] <jmkasunich> hi okalleo
[21:50:51] <okalleo> Do You have a metric ini to share?
[21:50:51] <alex_joni> okalleo: jmkasunich is kind enough to look at the troubles you're having
[21:51:16] <okalleo> Nice... I think already it getting better
[21:51:20] <jmkasunich> okalleo: question: why are your accel rates so low?
[21:51:27] <jmkasunich> 2mm/sec^2 seems very low
[21:51:39] <okalleo> thanks to all the hints I got from the channel
[21:52:23] <okalleo> Yes I know all vallues are little higher now, and it seemes not to give any following errors
[21:52:25] <jmkasunich> alex: I scoped the following error, and it never exceeds 2 microns during the entire move
[21:52:36] <alex_joni> jmkasunich: great..
[21:52:43] <alex_joni> okalleo: what machine do you have?
[21:53:03] <alex_joni> 500 steps / mm is awfully much (big precision..)
[21:53:03] <okalleo> Due to no money it's a hack...
[21:53:17] <jmkasunich> 2um per step
[21:53:26] <alex_joni> and 2 mm / sec speeds is awfully slow
[21:53:42] <jmkasunich> he has 4mm/sec
[21:53:42] <okalleo> not realworld precition but without extra electronics
[21:53:48] <jmkasunich> that is 2000 steps per second
[21:53:57] <okalleo> yepp
[21:54:07] <jmkasunich> what kind of motors and drives?
[21:54:42] <okalleo> its 2 phase steppers with 10 microstep drivers
[21:55:05] <alex_joni> screw the 10 microsteps..
[21:55:25] <alex_joni> go without .. they don't provide anything for you, except less speed I think..
[21:55:32] <jmkasunich> what drives? geckos, xylotex, etc?
[21:55:38] <okalleo> not possible without building more electronics...
[21:56:44] <okalleo> its protobyte2000 (more or less like gecko basic driver)
[21:56:45] <alex_joni> then forget it..
[21:56:45] <jmkasunich> alex: they are smoother, and might provide a higher top speed without stalling, IF the computer can deliver the step rate
[21:56:48] <jmkasunich> but of course they require a higher step rate
[21:57:14] <alex_joni> okalleo: the gecko driver has a selector for steps I think..
[21:57:27] <okalleo> not the basic one..
[21:57:30] <jmkasunich> okalleo: you are running BASE_PERIOD at the stock 50uS, which means 20K interrupts per second
[21:57:39] <jmkasunich> that means a maximum of 10K steps/second
[21:57:52] <jmkasunich> with your motors and drives, that is 20mm/sec
[21:58:14] <jmkasunich> I don't know if your motors will actually move the machine that fast, that depends on the size of the motors and the machine
[21:58:16] <okalleo> ok...
[21:58:25] <jmkasunich> hang on a minute
[21:58:37] <okalleo> I think I dont need more
[22:00:50] <jmkasunich> back (had to go stir dinner)
[22:01:13] <jmkasunich> 20mm/sec = 1.2 m/min, I guess that is pretty quick
[22:01:21] <jmkasunich> (for a smallish machine)
[22:01:39] <okalleo> yes
[22:01:50] <jmkasunich> the accel should probably be much higher
[22:02:05] <okalleo> Do you run emc2 with a metric ini?
[22:02:11] <jmkasunich> I expect your motors could go from stopped to 20mm/sec in less than 1/2 second
[22:02:19] <jmkasunich> right now I'm running it with your ini
[22:02:35] <jmkasunich> (I ususlly use inches, I'm in the USA)
[22:02:43] <okalleo> ok
[22:03:50] <okalleo> I changed the ferror and min_ferror back to more normal values with success after raising acc and vel room in stpper core file
[22:04:12] <jmkasunich> sorry, a small cooking crisis has just happened, and I need to run to the grocery store... back in about 20 mins
[22:04:21] <jmkasunich> good, sounds like you are on the right path
[22:05:06] <alex_joni> okalleo: but you also need to set accel a bit higher in the ini
[22:05:13] <alex_joni> or the whole machine will run slow
[22:05:16] <okalleo> I'm about to go to sleep, good luck with, Your domestic affairs :)
[22:05:19] <alex_joni> and it could run faster
[22:05:22] <alex_joni> night okalleo
[22:05:40] <okalleo> ok... I'll try tomorrow...
[22:06:00] <okalleo> Nigty.
[22:23:31] <rayh> aha. got just a bit of hal_tree working.
[22:24:15] <rayh> can build the tree and click on comp, pin, param, sig, funct, or thread nodes and display
[22:24:30] <rayh> the return from bin/halcmd using that node name.
[22:25:21] <jmkasunich> back
[22:27:45] <alex_joni> jmkasunich: emc's internals are pretty screwed .. I'm afraid
[22:28:09] <jmkasunich> I'm seriously wondering if we should add [AXIS]STEPGEN_MAXACCEL to the ini, and have core_stepper.hal get its accel from there
[22:28:29] <jmkasunich> and but a big honking comment in the ini saying to set stepgen accel about 10% higher than the main accel
[22:28:48] <alex_joni> one question for you: what does [AXIS_1]MAX_VELOCITY refer to?
[22:28:54] <alex_joni> tricky question..
[22:29:07] <jmkasunich> max velocity for axis 1
[22:29:19] <alex_joni> axis 1 beeing?
[22:29:29] <alex_joni> think non-trivkins
[22:29:36] <jmkasunich> joint 1
[22:29:46] <alex_joni> and the answer is... wrong
[22:29:53] <jmkasunich> with non-trivkins, it is truly fscked
[22:30:02] <alex_joni> axis 1 is Y
[22:30:03] <alex_joni> I agree
[22:30:20] <alex_joni> as it is now, you need to calc your joint speed
[22:30:30] <alex_joni> run that through kins, and get the axis speed
[22:30:33] <alex_joni> and put that in the ini
[22:30:40] <alex_joni> if that is even POSSIBLE..
[22:30:53] <alex_joni> I can surely think of some cases where it's not possible
[22:31:07] <jmkasunich> its the same old thing.. in order to accommadate the 90% with normal machines, and not fsck with their heads, we gloss over or hide important issues - then when you do non-trivial kins it bites you in the ass
[22:31:44] <alex_joni> yeap.. just pointing it out, as cradek (and I) read some of the code the other day
[22:32:35] <jmkasunich> ideally, the kins code not only transforms position from one coordnate system to another, it can also transform accel and velocity limits
[22:32:52] <jmkasunich> (for that, you need to be able to take the deriviatives of the kines equations)
[23:06:41] <SWP_Away> h iguys
[23:06:47] <SWP_Away> no wait - try this:
[23:06:48] <jmkasunich> howdy
[23:06:49] <SWP_Away> hi guys
[23:07:07] <SWP_Away> the joint max_vel issue is an interesting one
[23:07:25] <SWP_Away> with something like a hexapos, the max_vel may depend on the position
[23:07:29] <SWP_Away> hexapod
[23:07:33] <jmkasunich> yes
[23:07:42] <SWP_Away> (that'll teach me to type just after coming in from the cold)
[23:07:45] <jmkasunich> kins are a huge ball of worms
[23:07:55] <SWP_Away> yes
[23:08:28] <alex_joni> SWP_Away: try figuring out homing
[23:08:45] <alex_joni> that'll make speed look like smthg very simple
[23:08:45] <jmkasunich> for non-trivial kins? hah!
[23:08:46] <SWP_Away> switches on all joints are the only truly reliable way, IMO
[23:08:59] <alex_joni> yeah.. but how do you move?
[23:09:04] <jmkasunich> for a hexapod that isn't enough
[23:09:08] <alex_joni> you don't know where you are
[23:09:20] <SWP_Away> and homing would be a process of getting all joints to home, then setting the cartesian location to a known value (usually 0,0,0,0,0,0
[23:09:26] <alex_joni> and you need to move all joints, in order not to break the machine
[23:09:31] <jmkasunich> and you can't neccessarily move one joint at a time, without crashing the machind
[23:09:36] <SWP_Away> yeah - it's a PITA
[23:09:48] <alex_joni> moving joints depends on the kins
[23:09:52] <alex_joni> which depend on position
[23:09:59] <alex_joni> and you're basicly screwed
[23:10:07] <SWP_Away> I had mentioned (to petev) that non-trivial kinematics are a requirement for emc, is that still true?
[23:10:09] <alex_joni> I found only one way to do it..
[23:10:12] <jmkasunich> imagine a robo-crane, you pull in on only one cable, and you break the other cables
[23:10:22] <SWP_Away> or the one you're pulling
[23:10:44] <jmkasunich> Fred told me that with the robocrane, they always parked it in the same spot, and called that home
[23:11:04] <jmkasunich> on power up, it assumes that spot, so the kins at least partly work
[23:11:20] <jmkasunich> then they used teleop mode to move it around till it was exactly at home
[23:11:22] <SWP_Away> heh -but let one cable slip, and boom! you don't know where it is any more
[23:12:01] <jmkasunich> I think they literally "parked" it, it was setting on the floor, cables (slightly) slack
[23:12:07] <SWP_Away> with a stewart platform, the cables / legs only need to be moved in pairs, as long as the overall motion isn't that far
[23:12:29] <alex_joni> jmkasunich: heh
[23:12:31] <jmkasunich> but homing is often all the way at one end of motion
[23:12:35] <alex_joni> I came to the same conclusion
[23:12:48] <alex_joni> before switching off, always a G0X0Y0Z0
[23:12:59] <SWP_Away> all the way at one end by design, or because that's where the switches end up?
[23:13:08] <jmkasunich> where the switches end up
[23:13:15] <jmkasunich> I suppose a hexapod could home elsewhere
[23:13:44] <SWP_Away> I'll probably home my Bridgeport somewhere in the middle for X and Y
[23:14:07] <SWP_Away> gives me a zero in the center of the work envelope (except Z)
[23:14:28] <SWP_Away> SWP_Away is now known as SWPadnos
[23:14:35] <jmkasunich> you gonna actually put the switch in the middle, or just use offsets to put the home position there?
[23:14:47] <jmkasunich> the latter is easy, the former has issues
[23:14:54] <SWPadnos> switch actuated when the table is in the middle
[23:15:18] <jmkasunich> and not actuated on both sides of the middle?
[23:15:20] <SWPadnos> I actually want it to move to center when homing (makes it faster as well)
[23:15:22] <SWPadnos> nope
[23:15:42] <SWPadnos> I have encoders with index, so I can get pretty precise
[23:15:53] <SWPadnos> I expect to use a cam to actuate a lever switch
[23:16:14] <jmkasunich> so it will turn on at the center, and remain on all the way to one side?
[23:16:27] <SWPadnos> no -turn on at center, off again when past
[23:16:43] <SWPadnos> unless that complicates the homing procedure significantly
[23:16:46] <jmkasunich> that's ok then.... if it is on at the center and off on both sides, EMC doesn't know which way to go when you tell it to home
[23:17:00] <SWPadnos> that would be thr problem
[23:17:28] <SWPadnos> does emc always move toward what it thinks is 0, or always in one direction (e.g. toward -X)?
[23:17:48] <jmkasunich> it moves in the direction (and speed) set by HOME_SEARCH_VEL
[23:18:03] <SWPadnos> ok - that may need to be settable
[23:18:12] <SWPadnos> HOME_TOWARD_ZERO
[23:18:12] <jmkasunich> it can't move to what it thinks is zero, pre-homing it has no clue
[23:18:25] <SWPadnos> it should be saving and restoring machine coordinates, I think
[23:18:25] <jmkasunich> HOME_SEARCH_VEL is settable, its in the ini file
[23:18:41] <SWPadnos> yes
[23:18:58] <jmkasunich> what if somebody cranks it past center while powered off?
[23:19:05] <SWPadnos> that's a problem
[23:19:31] <SWPadnos> I have several switches - I may be able to figure sometihng out
[23:19:49] <SWPadnos> like a -side switch and a + side switch, neither means somewhere in the middle
[23:20:10] <alex_joni> SWPadnos: on older robots where we had that kind of homing
[23:20:15] <alex_joni> we had only one switch
[23:20:23] <alex_joni> with a cam on the +side
[23:20:35] <alex_joni> so when homing it looked at that for the direction
[23:20:38] <SWPadnos> sure - that would work as well, I may need to do that
[23:20:48] <alex_joni> ran till off the switch, then inverted direction, and homed as usual
[23:21:22] <jmkasunich> homing is described at
http://www.linuxcnc.org/EMC2_Code_Notes.pdf, starting on page 20
[23:22:19] <SWPadnos> yep - saw that
[23:22:30] <SWPadnos> it isn't exactly too important right now ;)
[23:25:34] <jmkasunich> jmkasunich is now known as jmk_eating
[23:26:54] <SWPadnos> SWPadnos is now known as SWP_Away