Back
[00:00:55] <jepler> tfmacz: it's the same .. in your .hal file, connect an input pin to halui.<function desired>
[00:01:27] <jepler> you can see the functions available by "halcmd show pin halui"
[00:02:24] <jepler> 'cycle start' is a bit of a tough one, since in emc terms it includes switching to 'auto' mode and then 'run' -- the AXIS GUI hides this from you
[00:02:35] <fenn> heh its so entertaining to turn on virtual LED's with virtual buttons on a virtual machine
[00:02:45] <jepler> cradek has made a classicladder program that does this for use with halui, but I don't think he's posted about it anywhere...
[00:03:20] <fenn> tfmacz: there's a sample config file halui_halvcp which shows you how to do most everything
[00:03:33] <jepler> oh yes that is a good example to look at
[00:03:55] <fenn> there's program run pause stop etc
[00:04:56] <fenn> program step doesnt quite work right
[00:04:57] <tfmacz> Ok, thanks... I will have a look at the sample and see if I can figure it out...
[00:05:10] <fenn> it helps if you run it
[00:05:19] <fenn> and click the buttons
[00:06:22] <fenn> geez the mach wannabe crowd is going to pee their pants over halui
[00:07:09] <SWPadnos> no way - you have to - gasp! - edit text files to use it
[00:07:34] <SWPadnos> the mach wannabe crowd must have drag and drop and drool interfaces to *EVERY FUNCTION!!!*
[00:09:11] <steves_logging> steves_logging is now known as steve_stallings
[00:09:29] <jepler> hi steve stallings!
[00:09:36] <steve_stallings> Hi Jeff
[00:09:43] <SWPadnos> the lurker awakens :)
[00:10:17] <skunkworks> jepler: 360ipm base period of 30000 scale of 4000
[00:11:05] <SWPadnos> aw c'mon -you should be able to get 480 IPM with that base period!
[00:11:19] <SWPadnos> or mote
[00:11:22] <SWPadnos> more
[00:11:38] <skunkworks> heh yes
[00:11:49] <skunkworks> the thing is a bit scary at that
[00:11:53] <jepler> skunkworks: so it works !?
[00:12:02] <steve_stallings> SWP: I have strangly had luck finding Weidmuller parts at Newark when no one else had them, small qty, high price, but I needed them badly
[00:12:10] <SWPadnos> thanks
[00:12:10] <skunkworks> jepler: so far - still playing
[00:12:22] <skunkworks> jepler: nice work
[00:12:28] <SWPadnos> the price seems to suck anyway - $20+ for a 24-contact plug
[00:14:18] <fenn> SWPadnos: i'm sure something could be hacked together with glade fairly easily
[00:14:29] <fenn> an xml translator tool
[00:14:32] <SWPadnos> patches gratefully accepted ...
[00:14:50] <fenn> i dont mind editing a text file, but then axis seems fine for most everything anyway
[00:15:02] <fenn> maybe the buttons could be bigger for a touchscreen
[00:15:44] <SWPadnos> Robin is one of the ones who keeps on harping on the UI designer in Mach. but then again, 99% of users never use that anyway
[00:16:07] <jepler> I don't think I've said it on IRC, but if someone contributes a set of 48x48 icons I'll write the code to automatically switch to those icons when a "high DPI" screen is detected
[00:16:17] <SWPadnos> heh
[00:16:23] <jepler> increasing the gnome DPI setting seems to be the most effective way to get bigger letters in most applications
[00:16:26] <SWPadnos> or 96x96? :)
[00:16:37] <fenn> but.. touchscreens are usually small and low-res
[00:16:42] <jepler> yes I know it's a lie
[00:17:04] <fenn> ah..er so how do you tell it that your touchscreen is a "high dpi" screen?
[00:17:19] <jepler> gnome > god knows what > oh fuck me > isn't it in here > dpi
[00:17:22] <SWPadnos> touchscreens lend themselves to hierarchical controls - actually something like the old Irix buttonfly program would be great
[00:17:26] <jepler> I think it's hidden down in the "advanced" screen of "font smoothing"
[00:17:43] <jepler> also in gconf-editor
[00:17:47] <fenn> SWPadnos: i loved that thing
[00:17:52] <SWPadnos> heh
[00:17:55] <fenn> it was right up there with dogfight and arena
[00:18:04] <SWPadnos> I should fire up the Indigo so I can play eith it again :)
[00:18:11] <fenn> and all the opengl demos
[00:18:15] <SWPadnos> don't forget the lightcycles game
[00:18:40] <jepler> huh I thought the icons were 32x32 but they're (almost) 24x24
[00:19:03] <jepler> a bit of variablity in the sizes, too .. 21x24, 22x22, 27x24 (?!)
[00:19:11] <SWPadnos> shoddy artwork
[00:19:16] <SWPadnos> how could you?
[00:19:18] <jepler> sigh
[00:19:58] <jepler> which is worse -- icons that look like fischer-price, or like icons that were drawn from a 6-color palette in a pixel-at-a-time drawing program?
[00:20:19] <SWPadnos> that depends on the application ;)
[00:20:31] <fenn> it depends how much screen real estate you've got :)
[00:21:01] <SWPadnos> I wonder how hard it would be to have a semi-automatic scaling feature in AXIS
[00:21:18] <SWPadnos> or just a small set of UI scaling menu options
[00:21:26] <jepler> what do you mean, "semi-automatic scaling"?
[00:21:31] <fenn> i wonder how hard it would be to convince the developers to allow the user to select preferences..
[00:21:36] <skunkworks> jepler: 420ipm
[00:21:47] <SWPadnos> if the axis window is > 1024x768, use the 48x48 pixel icons and font size XX
[00:21:48] <skunkworks> that is as far as I want to push it.
[00:22:29] <fenn> skunkworks: let's see some videos
[00:22:30] <jepler> such a patch is unlikely to be accepted
[00:22:53] <skunkworks> give me a few - I need to set it up for all the axis now
[00:22:59] <SWPadnos> or just menu options: 64x64 + 14 point text, 48x48+12 point text, 32x32 + 10 point text ...
[00:23:28] <SWPadnos> auto is a pain in the ass to get right, so I don't think I'd accept that patch either
[00:23:38] <SWPadnos> in fact it may be impossible to get really right
[00:25:50] <jepler> patches to obey /desktop/gnome/interface/ font and icon size would be happily accpted
[00:26:21] <jepler> (font names can't exactly be obeyed because Tk uses a different font name convention, but the size looks like it can be extracted without much trouble)
[00:26:36] <SWPadnos> heh - nothing like consistency :)
[00:26:42] <jepler> already the gconf database is used to get the screen dpi
[00:26:46] <SWPadnos> tk is consistently different from the host systems
[00:26:56] <fenn> * fenn blames unix
[00:27:02] <jepler> * jepler blames gnome
[00:27:10] <SWPadnos> * SWPadnos blames Canada
[00:29:30] <fenn> i think halui could make a nice gui, with a little work
[00:30:44] <jepler> sigh .. looks like you *still* can't do python + gtk + opengl on ubuntu without compiling something extra, even on feisty.
https://bugs.launchpad.net/ubuntu/+source/gnome-games/+bug/71593
[00:31:18] <fenn> you cant just apt-get gtk-glarea?
[00:31:26] <jepler> https://bugs.launchpad.net/ubuntu/+bug/103642
[00:31:43] <tfmacz> jepler: OK, so I am a dumby.... I guess I need to be taken by the hand... "linkpp parport.1.pin-15-in halui.machine.on" returns an error "pin 'halui.machine.on' not found" ???
[00:31:43] <jepler> libgtkglext1-python
[00:31:51] <fenn> yah that's what i meant :\
[00:32:13] <fenn> tfmacz: you need to loadusr halui
[00:32:28] <jepler> tfmacz: to enable halui, in [HAL] section of your .ini, add HALUI=halui
[00:32:29] <tfmacz> where does that go?
[00:32:43] <jepler> or in the .hal file, put 'loadusr -W halui' before you link to halui pins
[00:32:47] <jepler> do one or the other, not both.
[00:37:00] <fenn> "GtkDrawingArea can be used for OpenGL rendering, and no additional widget is needed.
[00:37:25] <fenn> that doesnt mean ubuntu isn't broken
[00:37:52] <fenn> but its nice to know you dont _need_ gtkglext
[00:38:36] <tfmacz> Cool, Thanks...
[00:39:23] <fenn> or maybe i shouldnt believe everything i read
[00:39:34] <jepler> an example wouldn't hurt
[00:39:56] <fenn> all the examples have 'require gtkglext' or similar
[00:40:49] <jepler> an example in python even
[00:41:12] <tfmacz> OK, the hardware is working but axis is unhappy.... "can't do that (EMC_TRAJ_SET_TELEOP_ENABLE) in auto mode with the interpreter idle"???
[00:41:24] <fenn> that was in ruby actually
[00:41:59] <fenn> it certainly looks like python though
http://snippets.dzone.com/posts/show/1874
[00:42:22] <fenn> another one of those python clones with 'end's scattered about
[00:42:43] <jepler> ruby's best feature are the ".." and "..." operators
[00:42:56] <jepler> 1..10 and 1...10 generate ranges of integers .. one of them includes 10 and the other doesn't.
[00:43:02] <jepler> can you guess which?
[00:43:07] <fenn> no
[00:43:10] <jepler> me either
[00:43:26] <jepler> but I seem to recall that it's the opposite of what I expect, so that 1..10 ends in 10, and 1...10 ends in 9
[00:43:33] <jepler> (since logically "..." would be one more than "..")
[00:43:46] <fenn> but ... is longer so it emphasizes the numbers in between more
[00:44:01] <SWPadnos> it should go downward in steps of -0.1 from 1 to .1 1 .. .1 :)
[00:44:22] <fenn> a repeating sequence of 1's ending in 10
[00:44:29] <SWPadnos> and the 10 is further away from the 1, so it can't quite get there
[00:44:44] <jepler> 1, 1.11111, 2.22222, ...., 9.99999, 10
[00:45:03] <jepler> no that makes no sense .. forget it
[00:45:07] <SWPadnos> ok
[00:45:44] <jepler> http://sitekreator.com/satishtalim/ranges.html
[00:45:56] <jepler> (1..10) === 3.14159 -> true
[00:46:02] <jepler> it's clearly a language for the clever
[00:46:29] <fenn> i wonder what == does
[00:46:51] <jepler> by analogy with .. and ... it should test for equality just a little bit more than === does
[00:47:28] <jepler> I think I should stop this conversation now -- I shouldn't rag on languages I've never used
[00:47:52] <jepler> and I hate religious wars
[01:51:06] <skunkemc> http://www.pastebin.ca/673011
[01:54:16] <skunkemc> according to axis x-z movements are 400.8ipm y-z are 404ipm and xyz moves are 469. now z moves are only 1.75 inches
[01:54:44] <skunkemc> that must be it
[01:54:51] <skunkemc> z never gets up to speed
[01:55:39] <fenn> it should be 565ipm if it were just x and y
[01:57:21] <fenn> 593 actually
[01:57:21] <skunkworks> should max accelleration in the traj section also be sqrt(a^2+b^2+c^2)
[01:57:29] <fenn> yes
[01:57:32] <skunkworks> ah
[01:58:37] <fenn> its still not accelerating as fast as it ought to
[01:59:47] <fenn> hmm lets see
[02:00:48] <fenn> it would be about 16 in/sec/sec the way you had it before (traj accel=30)
[02:01:18] <fenn> so it takes half a second to get to full speed, which it sounds like it's doing in the video
[02:02:37] <skunkworks> it seems to accellerate at 50in/sec/sec so traj is set to 86
[02:05:19] <skunkworks> still the same max speeds according to axis.
[02:07:38] <fenn> does it sound snappier?
[02:09:01] <skunkworks> yes
[02:09:40] <fenn> well, at least you know it's working :)
[02:10:10] <fenn> um, what happens if emc's base period isn't high enough?
[02:10:34] <skunkworks> yes - just think it is odd to only make it to 489 ipm on all 3 axis combined moves
[02:10:40] <fenn> does it just go "crunch crunch"
[02:10:48] <fenn> anyway axis shouldn't know or care what stepgen is doing
[02:10:49] <skunkworks> crunch crunch?
[02:11:09] <fenn> skunkworks: sound of random timing being fed to step pin
[02:11:35] <skunkworks> no - it sounds pretty good.. But something seems to be out of balance on one axis
[02:12:29] <fenn> its open loop, axis is looking at motion.0.current-vel (i think)
[02:13:39] <fenn> yep
[02:14:47] <skunkemc> http://www.pastebin.ca/673033
[02:14:58] <skunkworks> current
[02:16:46] <fenn> maybe it's an aliasing issue with the timing
[02:16:50] <skunkworks> hmm - still is a z thing - I can run x/y and it will run 593ipm. must be the short distance and slow accelleration
[02:17:05] <fenn> skunkworks: try setting max vel to 8.3333 on all the axes
[02:17:28] <fenn> oh, yeah?
[02:17:34] <skunkworks> odd huh
[02:17:52] <fenn> ok i thought you had already tried that
[02:17:58] <skunkworks> I suppose it is a math thing
[02:18:01] <skunkworks> I thought I did
[02:18:08] <skunkworks> but it was aways running z
[02:18:13] <skunkworks> duh
[02:18:33] <fenn> is 600ipm noticeably faster than 400?
[02:19:19] <fenn> and, now you gotta cut something at 600 ipm :)
[02:19:25] <fenn> styrofoam will do
[02:20:03] <fenn> the spiral test would be a good one
[02:20:57] <fenn> maybe scale it up a bit
[02:22:01] <skunkworks> ok - something is not right - even though I have z set to 75in/sec/sec - 7ips - moves with z involved don't go over 489ipm
[02:23:35] <skunkworks> I should say - everthing being the same - if I increase the z accelleration - the top speed doesn't increase
[02:24:08] <skunkworks> max_velocity in the traj section is set to 12.1 - that is correct?
[02:24:20] <skunkworks> if all axis are set to 7ipm?
[02:24:29] <skunkworks> ips I mean
[02:24:53] <skunkworks> I must be missing something
[02:26:23] <fenn> python is so cool
[02:26:39] <fenn> from math import *
[02:26:44] <skunkworks> ok - a long move in all 3 axiss gives me 691ipm
[02:26:48] <fenn> for theta in range(10000):
[02:26:48] <fenn> for r in range(100):
[02:26:49] <fenn> print "X", sin(10000-theta)*r, "Y", cos(10000-theta)*r
[02:26:58] <skunkworks> pretty close to max (726)
[02:28:07] <fenn> ok so maybe those values are a little large
[02:31:42] <SWPadnos> you would only get the max for a move where delta X = delta Y = delta Z, assuming all accels and vels are equal
[02:31:51] <SWPadnos> so a 7" move or whatever your Z stroke is
[02:32:01] <SWPadnos> (in each coordinate)
[02:33:27] <fenn> why would he get less than 593 in an xyz move?
[02:33:45] <skunkworks> this is odd
[02:33:47] <fenn> uh, assuming it was close to 45 degrees
[02:34:08] <SWPadnos> if Z only moves 1" and X+Y move 30 each, the Z vel is 1/3o of max
[02:34:20] <SWPadnos> or 1/30*sqrt2 or thereabouts
[02:34:24] <fenn> but xy alone is 593
[02:35:00] <skunkworks> in mdi - if I do a 45deg I get 564ipm
[02:35:29] <skunkworks> if I do a 1 axis move I get 400ipm
[02:35:46] <skunkworks> (should be 593 and 420 respectively)
[02:36:26] <SWPadnos> so along move in 3 axes getting 691 is probably OK, no?
[02:36:48] <skunkworks> if I jog and axis I get 420ipm
[02:38:36] <skunkworks> hmm - I would expect it to be 726..
[02:38:46] <skunkworks> for a 3 axis move
[02:39:18] <skunkworks> if I start at 0 and go x50y50z50 I get 691ipm
[02:39:30] <SWPadnos> if you ask for 100inches X 100 inches Y and 1 inch Z, then Z will move at 1/100 the speed of X and Y ...
[02:39:36] <SWPadnos> ok, that's a little low
[02:39:52] <SWPadnos> you should measure with halscope and the motion.vel-out pin
[02:40:06] <SWPadnos> not with axis, since sampling will make the readings inaccurate
[02:40:23] <skunkworks> I think that is what fenn says axis is using
[02:40:32] <skunkworks> but I can check. maybe tomorrow though
[02:40:32] <SWPadnos> could be
[02:40:38] <skunkworks> :) getting tired
[02:40:45] <SWPadnos> heh
[02:41:08] <skunkworks> looks like the step doubler is working though :)
[02:41:53] <skunkworks> finally up
http://www.youtube.com/watch?v=KxzTPXBbxXY
[06:12:11] <fenn_> fenn_ is now known as fenn
[08:19:57] <fenn> cradek/swpadnos
http://fenn.dyndns.org/pub/irc/lengthspiral.py
[12:19:30] <skunkworks> jepler: doublefreq looks good :)
[12:22:13] <jepler> skunkworks: thanks for testing it
[12:25:58] <skunkworks> no problem. least I can do. I will be testing it more.
[12:37:42] <skunkworks> someone want to try this ini?
http://www.pastebin.ca/673033
[12:37:51] <skunkworks> your going to have to activate doublefreq
[12:39:21] <skunkworks> and see if they can get a combined 3 axis move of 0,0,0 -> 50,50,50 at 726ipm? I can only get 691ipm
[12:40:35] <skunkworks> strait line moves g0,g1f1000 are only 400ipm also.. but jogging the axis gets you 420 (7ips)
[12:41:34] <skunkworks> (viewing the velocity in axis)
[12:42:21] <skunkworks> heh 'only get 691ipm'
[12:42:56] <steve_stallings> steve_stallings is now known as steves_logging
[12:52:14] <jepler> I also get 691ipm (running your ini on sim, so it can't be due to stepgen)
[12:53:37] <skunkworks> Oh - I was sure it wasn't stepgen.. there isn't any feedback right? I assumed it was something to do with either ini setup - or something else is worng.
[12:54:21] <jepler> in just a minute cradek will show up to confess it's his doing
[12:54:32] <skunkworks> heh
[12:54:46] <jepler> the trajectory planner only ever uses 95% of inifile acceleration or velocity
[12:55:11] <jepler> 7 ips * 95% = 399 ipm
[12:55:33] <jepler> 7ips * sqrt(3) * 95% = 691 ipm
[12:56:19] <SWPadnos> hmmm. there was a report or two about being able to jog faster than G0 ...
[12:56:30] <jepler> bbl
[12:56:35] <SWPadnos> seeya
[12:57:31] <skunkworks> heh
[12:57:44] <skunkworks> that explains it
[12:58:40] <SWPadnos> you don't (both) have FO set to 95% do you? :)
[13:00:16] <skunkworks> no
[13:00:41] <SWPadnos> ok - just checking
[13:09:36] <jepler> if I recall cradek's position correctly, he thinks that inifile stepgen headroom should be unnecessary. since using 100% of accel and vel seemed to occasionaly cause ferrors without stepgen headroom, he put the 95% cap
[13:09:56] <jepler> but the inifile headroom is still required because jogging will use 100 + epsilon %
[13:11:10] <SWPadnos> that seems to be a rather stepper-oriented design decision
[13:11:35] <SWPadnos> a servo user might be surprised when they set maxvel to 1000 IPM and they only get 950 IPM
[13:11:47] <SWPadnos> (unless they're jogging ...)
[13:13:08] <skunkworks> epsilon %
[13:13:09] <skunkworks> ?
[13:13:24] <SWPadnos> greek letter usually used for "very small numbers", similar to delta
[13:13:38] <SWPadnos> very small errors usually, in fact
[13:14:05] <cradek> I'll go take that out.
[13:15:20] <cradek> it was half-baked unless we do a similar thing with jogging
[13:15:25] <cradek> even then, maybe it's half-baked
[13:15:30] <SWPadnos> heh
[13:15:58] <SWPadnos> is there a need for stepgen_maxvel in EMC?
[13:16:51] <SWPadnos> it seems that traj_maxvel takes care of things, and stepgen should be able to go as fast as it can to catch up, since the TP shouldn't ask for more than the motors can give
[13:17:01] <rayh> The idea was to allow a bit of overhead so that it can build back in steps that were put into ferror during accel/decel
[13:17:04] <SWPadnos> actually, it's the Axis_maxvels that do it
[13:17:21] <alex_joni> hi guys
[13:17:28] <SWPadnos> right -I'm saying set it to "whatever the max possible step rate is"
[13:17:29] <cradek> SWPadnos: without john k here...
[13:17:31] <rayh> hi alex
[13:17:31] <SWPadnos> hi Alex
[13:17:33] <cradek> hi everyone
[13:17:40] <SWPadnos> right. he should be on tonight
[13:17:46] <SWPadnos> hi Ray
[13:17:52] <rayh> hey.
[13:17:57] <alex_joni> heh
[13:18:07] <rayh> It's a beautiful morning in Michigan.
[13:18:24] <rayh> Gotta get some testing done.
[13:18:29] <alex_joni> same in La Rochelle, France
[13:18:33] <SWPadnos> bummer
[13:18:47] <SWPadnos> if it's a nice day, better to not be doing testing ...
[13:19:25] <cradek> ok now with g0x2y2z2 and axis limits of 1.2, I get 124.7077 velocity which is full speed
[13:19:43] <SWPadnos> sounds good to me :)
[13:19:59] <SWPadnos> I think that if you set stepgen.maxvel to 0, that means no limit
[13:19:59] <skunkworks> cradek: thank you :)
[13:20:04] <SWPadnos> * SWPadnos goes to check
[13:22:06] <SWPadnos> yep - if you set it to 0, it means no limit
[13:22:41] <alex_joni> * alex_joni heads for the ocean
[13:22:56] <SWPadnos> oooohhh - sounds nice
[13:23:00] <rayh> So does that mean that a axis may run many times faster that max_vel?
[13:23:05] <SWPadnos> or Nice, since you're in France :)
[13:23:07] <cradek> bye alex
[13:23:08] <cradek> rayh: no
[13:23:29] <cradek> 124.7077 is 1.2 * sqrt(3) * 60
[13:23:34] <SWPadnos> rayh, it could, if the TP asked stepgen to do that, and if the max step rate were high enough
[13:23:35] <alex_joni> if I swim long enough I might make it over there for the next fest :D
[13:23:48] <SWPadnos> but since the TP doesn't ask for that, it wouldn't be likely to happen
[13:23:48] <cradek> oh maybe I didn't understand the question.
[13:23:56] <rayh> max step rate?
[13:24:14] <SWPadnos> stepgen can output N pulses per seconds, depending on its configuration
[13:24:35] <skunkworks> rayh:
http://www.youtube.com/watch?v=KxzTPXBbxXY
[13:24:58] <rayh> okay and that is independent of traj max_vel.
[13:25:08] <SWPadnos> if the TP asks the stepgen to move very fast, then stepgen will be limited by that rate
[13:25:29] <rayh> I'm not sure that I have the ability/programs needed to use youtube.
[13:25:35] <SWPadnos> heh
[13:25:45] <SWPadnos> but you're on a fast connection! :)
[13:26:01] <rayh> Yes I am but an old centos.
[13:26:07] <skunkworks> rayh: this then?
http://www.electronicsam.com/video/PICT1179.AVI
[13:27:23] <SWPadnos> I think stepgen.maxaccel is still needed (the stepgen needs to be limited to an appropriate accel rate), but I think the TP will take care of vel limiting
[13:27:47] <rayh> couldn't display.
[13:28:20] <rayh> I guess I was wondering about adding in steps for backlash and such.
[13:28:44] <SWPadnos> the TP still commands the backlash, doesn't it?
[13:28:57] <cradek> the TP limits accel
[13:29:01] <SWPadnos> err - commands the backlash compensation
[13:29:04] <cradek> the TP does not concern itself with backlash at all
[13:29:34] <SWPadnos> hmmm. where is that added in?
[13:29:48] <cradek> motion
[13:29:55] <SWPadnos> ok, above the TP
[13:30:21] <SWPadnos> if you hold the graph upside-down
[13:31:19] <rayh> What happens in TP if you set a very high max_vel to compensate for degrees vs inch moves?
[13:31:30] <SWPadnos> I think the stepgen accel limit is still desirable, because it causes stepgen to slew to the updated velocity over the course of a servo period (make_pulses actually does that in the fast thread)
[13:31:47] <cradek> rayh: it works right, since each axis has its own units and its own corresponding maxvel
[13:32:09] <SWPadnos> if you set stepgen maxaccel to 0, it just switches to the new step frequency immediately
[13:32:27] <rayh> And those are fed into traj - okay.
[13:32:31] <SWPadnos> that may be OK, but "I don't like it" :)
[13:33:05] <cradek> rayh: I've seen you hint several times on the list that there is still a problem with rotary axes or units. I don't know of one. Have you seen a particular problem?
[13:33:35] <rayh> sure g0 as a single axis move turns the table as if it were inches.
[13:33:40] <cradek> Historically there were lots of problems, but to my knowledge I've fixed them all, even the very obscure ones
[13:33:49] <rayh> Really.
[13:33:56] <cradek> rayh: it must be a configuration problem then.
[13:34:09] <cradek> rayh: run the sample config in cvs axis/sim_9axis
[13:34:15] <rayh> Okay. Let me ask for a few ini values.
[13:34:32] <rayh> my linear motion is 2 -- 120 ipm.
[13:35:06] <rayh> my rotary is 1800 degrees per minute or 30 dps
[13:35:10] <cradek> http://cvs.linuxcnc.org/cvs/emc2/configs/sim/axis_9axis.ini?rev=1.3
[13:35:22] <rayh> What setting should I put into traj max vel.
[13:36:21] <cradek> something big enough for any axis, so something like rotary maxvel * sqrt(3) if you have three rotaries
[13:37:18] <SWPadnos> is there a separate angular_maxvel for [traj]?
[13:37:33] <cradek> no, traj is for the tooltip, no matter "where" it is
[13:37:56] <SWPadnos> ok - so I think I see the problem Ray is having
[13:38:35] <rayh> In the sim/axis_9 example we have traj max_vel of 200
[13:38:35] <SWPadnos> if you limit cartesian motion to 5 IPS in traj, then you'll also limit pure angular motion to 5 degrees/s
[13:38:47] <rayh> and individual max of 90 for the greatest.
[13:38:48] <SWPadnos> (or radians, depending on units)
[13:39:22] <cradek> the traj limit is not very useful with trivkins machines, so just set it high enough to not get in the way
[13:39:50] <cradek> in axis_9axis, it's set higher than 90*sqrt(3), so the individual axis limits always do the limiting
[13:40:29] <cradek> that's probably always what you want unless you're doing something unusual like a robot
[13:41:19] <SWPadnos> ther may be a reason to limit overall machine velocity, such as safety concerns or limitations on material removal rates (due to spindle HP, etc.)
[13:41:36] <cradek> that's true.
[13:41:58] <SWPadnos> I think we've discussed the idea of a separate [traj]angular_max{vex,accel} before - I think it's a good idea
[13:42:02] <cradek> but, you can't really do that if you have any rotary axis
[13:42:49] <SWPadnos> for safety, you can ;)
[13:43:02] <SWPadnos> for metal removal I agree you can't
[13:43:12] <cradek> I don't follow
[13:43:21] <cradek> you can limit the rotation of the axis without [traj]
[13:43:55] <cradek> traj is all about the tooltip being able to move much faster in diagonals, and sometimes you don't want to let it do that
[13:43:57] <SWPadnos> I think the problem Ray is having is that a low [traj]maxvel also limits pure rotary moves to some very low value
[13:44:14] <rayh> Okay. The last issue I've got is using traj max and individual max for the top end of gui sliders.
[13:44:22] <rayh> I'll just have to do something else.
[13:44:36] <jepler> your GUI could read "slider max" from anywhere, including new inifile fields you just make up
[13:44:57] <cradek> yes I did that in AXIS.
[13:45:06] <SWPadnos> I think either [traj]maxvel shouldn't be applied to rotary moves (since it makes no sense), or there should be a separate limit
[13:45:17] <jepler> AXIS uses [TRAJ]MAX_ANGULAR_VELOCITY and [TRAJ]MAX_LINEAR_VELOCITY for slider limits
[13:45:28] <rayh> Right and we just have to make certain that we keep those matching with the "real" speeds.
[13:45:35] <cradek> # for gui only
[13:45:35] <cradek> MAX_LINEAR_VELOCITY = .5667
[13:45:35] <cradek> DEFAULT_LINEAR_VELOCITY = .416667
[13:45:35] <cradek> MAX_ANGULAR_VELOCITY = 50
[13:45:36] <cradek> DEFAULT_ANGULAR_VELOCITY = 40
[13:45:58] <cradek> rayh: if you add support for that in your gui, it would be nice to match these names that AXIS uses
[13:46:06] <rayh> Yes it would.
[13:46:23] <rayh> So those are in the display section?
[13:46:34] <jepler> no, unfortunately they're in [TRAJ]; [DISPLAY] might have been a better choice
[13:46:43] <cradek> they're in TRAJ currently, they could sure be moved.
[13:47:10] <cradek> SWPadnos: you're probably right
[13:48:20] <SWPadnos> I'd leave those values in [TRAJ], and add separate angular constraints to the TP/motion :)
[13:48:21] <rayh> There is positive and negitive to both places.
[13:48:51] <rayh> They sure screw up talking about the logical divisions in the ini.
[13:48:53] <cradek> that's an interesting idea. Let's leave them in TRAJ.
[13:49:13] <rayh> But putting them in display screws up the ease of changing max vels.
[13:49:40] <rayh> "oh hey integrator, these values have no meaning to you."
[13:49:54] <cradek> brb
[13:50:00] <rayh> sorry just couldn't resist.
[13:50:08] <SWPadnos> the GUIs should look at [DISPLAY] first, then traj. this allows a setting in [DISPLAY] to override a setting im [TRAJ], but also allows one setting in traj to set the display limit
[13:50:29] <SWPadnos> (or use the min value if both exist)
[13:52:17] <jepler> "use the min" is getting too complicated
[13:52:21] <SWPadnos> heh
[13:52:40] <SWPadnos> for the programmer or the integrator?
[13:54:03] <jepler> you're anticipating that the integrator will make a specific mistake
[13:54:40] <SWPadnos> no, I'm anticipating that an integrator may want to lower the displayed limits below the actual machine limits
[13:55:00] <jepler> right, that's the case where [DISPLAY] and [TRAJ] are both set, and [DISPLAY] is lower
[13:55:09] <SWPadnos> yes
[13:55:23] <SWPadnos> actually, I should ask what sliders this is for before making suggestions :)
[13:55:30] <jepler> the specific error you anticipate is where [DISPLAY] is higher -- why is that anything but a configuration error?
[13:55:56] <SWPadnos> oh - it is an error
[13:56:49] <cradek> these sliders are for jog speed only
[13:57:06] <SWPadnos> ok - that's what I thought
[13:59:36] <cradek> I'm ok with SWPadnos's proposed fix
[14:00:19] <SWPadnos> er - which one? I've been throwing out a lot of to-dos :)
[14:00:26] <SWPadnos> one day, I'll actually do some of them
[14:00:32] <cradek> check [traj] then [display]
[14:00:43] <cradek> and, ideally emc would use the (separate) [traj] values too
[14:00:52] <cradek> yeah, thanks for volunteering :-)
[14:00:59] <SWPadnos> heh - next month
[14:01:10] <SWPadnos> err - late next month (damn. next months starts this weekend)
[14:01:29] <SWPadnos> I think display first then traj, but that's a minor point
[14:01:35] <cradek> err yeah
[14:01:42] <cradek> I meant whatever you meant
[14:02:21] <SWPadnos> this is another place where I really wish I knew how to get a C compiler to do adequate type checking for compile-time constant structs
[14:02:55] <cradek> look! a pterodactyl!
[14:03:14] <SWPadnos> no, that's supposed to be "Look - Elvis!!!"
[14:03:33] <SWPadnos> (then you swipe the brownie off their plate)
[14:11:27] <rayh> I liked brownies when I was a kid and camping with the scouts.
[14:12:41] <SWPadnos> look! Elvis!!!
[14:12:49] <SWPadnos> * SWPadnos swipes Ray's brownie
[14:21:22] <jepler> skunkworks: At local FedEx facility Lincoln NE
[14:21:30] <skunkworks> nice
[14:21:30] <jepler> you were right that it missed a scan leaving lenexa ks
[14:22:00] <cradek> cool, will it be here today?
[14:22:00] <skunkworks> still better tracking than usps ;)
[14:22:30] <jepler> cradek: today's the "estimated delivery"
[14:22:47] <cradek> cool
[14:30:40] <skunkworks> jepler: your going to be able to tese some of your own programming ;)
[14:30:44] <skunkworks> test even
[14:31:02] <skunkworks> physically test
[14:34:22] <jepler> indeed
[22:21:48] <skunkworks> cradek: your change worked - had to up the stepgen headroom - got following errors at first ;)
[22:30:59] <SWPadnos> skunkworks, can you try setting stepgen.maxvel to 0?
[22:31:22] <SWPadnos> but not accel at first - leave that a little higher than traj_maxvel
[22:43:58] <skunkworks> setting it to 0 seems to work.
[22:44:19] <skunkworks> but I also upped the accelleration at the same time (when I got home)
[22:44:52] <SWPadnos> ok - at some point I'd like to hear what happens if you also set stepgen.maxaccel to 0
[22:53:38] <skunkworks> both stepgen vel and acc set to 0 seems to work
[22:53:50] <SWPadnos> ok. does it sound strange at all during accel/decel?
[22:54:13] <SWPadnos> you may have to set the TP accel really low (or high?) to hear a difference
[22:54:35] <skunkworks> not yet. seems to move smooth
[22:54:50] <skunkworks> it is set to 50in/sec/sec
[22:54:58] <SWPadnos> the accel ramp may sound less "smooth"- it'll step from frequency to frequency with stepgen.maxaccel at 0
[22:55:48] <SWPadnos> hmmm. I just realized you won't hear anything - the update rate is 1 kHz - not enough time to hear each frequency
[22:57:01] <SWPadnos> setting those parameters to 0 disables stepgen from limiting acecl and vel, but I think that's OK since the TP is already outputting positions that are properly constrained for the machine
[22:57:11] <skunkworks> I have servo period set to 400000 I think
[22:58:39] <SWPadnos> oh - that's faster than "normal"
[22:58:45] <SWPadnos> so you really won't hear anything :)
[23:13:45] <skunkworks> SWPadnos: it doesn't stall if I set the stepgen vel and acc. 7.5->8 and 50->60
[23:14:06] <SWPadnos> does it stall if you leave them at 0?
[23:14:14] <skunkworks> yes
[23:14:23] <SWPadnos> oh, ok
[23:14:42] <skunkworks> I ran it 2 times and it stalled both. When I set the acc and vel headroom I have run it maybe 10 times with no problems
[23:14:59] <SWPadnos> does it stall if you use acc headroom but leave maxvel to 0?
[23:15:03] <skunkworks> (upping the velocity) poor thing is working hard
[23:15:07] <SWPadnos> heh
[23:15:22] <skunkworks> I think 7.5 may be the safe limit.
[23:15:27] <skunkworks> I can try that.
[23:16:00] <SWPadnos> ok. I suspected that accel limiting would need to be left enabled, but the vel limiting shouldn't need to be since the TP already does that
[23:16:40] <SWPadnos> did you try with maxaccel set to some very large value as well (like 5000)?
[23:18:37] <SWPadnos> just so you know what you're doing for me, here goes: :)
[23:19:02] <SWPadnos> first off, you can disable both vel and accel limiting in stepgen by setting the respective parameter to 0
[23:20:05] <SWPadnos> disabling accel is different from having a very high accel - very high accel still ramps the step rate from the current value to the next value over one servo update cycle, whereas disabling it causes an abrupt change in frequency at the start of a servo cycle
[23:20:54] <SWPadnos> my thought was that since the TP already does accel and vel limiting for us, there shouldn't need to be any in stepgen (which cuold reduce the number of support questions and simplify configs)
[23:22:00] <SWPadnos> so that's what you're testing for me. disabled vel limits plus (1) disabled accel, (2) "infinite" accel, and (3) normal stepgen headroom on accel
[23:45:34] <skunkworks> it does the 3d chips in less than 3 minutes ;)