#linuxcnc-devel Logs

Apr 11 2018

09:27 AM sliptonic: rene-dev: where's your channel?
09:29 AM rene-dev: stmbl on hackint
09:29 AM rene-dev: ah, youtube? https://www.youtube.com/user/gammelpro/videos?view_as=subscriber
10:36 AM narogon: hi
10:37 AM narogon: I have a question about axis and joint max_velocities
10:38 AM narogon: I'm using this kinematics https://pastebin.com/utJYniSH I made with chris radek help for a XYZAB machine
10:39 AM narogon: The problem is joint max velocity limits the speed of the motor but doesn't limit linuxcnc trajectory speed
10:41 AM narogon: so if I set for example AXIS_y max velocity 200 and joint_1 max velocity 100
10:41 AM narogon: Always get a following error
10:42 AM narogon: is there something that I have overlooked?
11:11 AM narogon: {}
11:25 AM seb_kuzminsky: narogon: trajectory speed is limited by [TRAJ]MAX_VELOCITY
11:25 AM seb_kuzminsky: http://linuxcnc.org/docs/2.7/html/config/ini-config.html#_traj_section
11:25 AM narogon: thanks for reply seb
11:25 AM narogon: I was writting a topic on forum
11:25 AM narogon: copy here
11:25 AM narogon: An example to understand the issue AXIS_Y MAX_VELOCITY 200 JOINT_1 MAX_VELOCITY 100 If I execute a g1 y200 f6000 there is any problem due to max_velocity of joint is 100mm/s = 6000 mm/min If I execute g1 y200 f7000 I can see velocity on screen 7000 but the motor is limited to 100 by JOINT_1 max velocity and I get a following error
11:30 AM seb_kuzminsky: that's what i would expect would happen
11:31 AM seb_kuzminsky: you're asking the g1 for more velocity than the joint can deliver, it will give you a following error
11:40 AM mozmck: It does? I thought it would simply limit the whole move to the max joint velocity.
11:40 AM narogon: I would expect linuxcnc calculates the trajectory velocity to follow the slower joint
11:41 AM mozmck: Yes, I thought that is how it worked as well...
11:42 AM narogon: the max axis_y velocity could be a combination of two or more joints.
11:44 AM narogon: so there is movements that can reach this speed without exceed joint max speed
11:45 AM narogon: imagine a circular move of the effector that doesn't imply y movement, only A axe movement
11:49 AM cradek: it is your responsibility to configure the axis max velocities and accelerations so that your joint velocities and accelerations aren't exceeded
11:49 AM cradek: linuxcnc does not do this
11:50 AM cradek: linuxcnc plans and obeys constraints only in axis space
11:51 AM seb_kuzminsky: linuxcnc obeys [TRAJ] and [AXIS_*] constraints in axis space, it obeys [JOINT_*] constraints in joint space
11:51 AM cradek: if you make an axis move two joints, or move joints varying amounts when you change tool lengths, or anything else like this, it is your responsibility to configure the axis constraints with this knowledge
11:51 AM cradek: seb_kuzminsky: it doesn't *plan* according to joint constraints. it can only notice and abort the motion if you exceed them.
11:51 AM pcw_home: Ahh, from a naive perspective a joint following error is surprising since I would expect the TP to bound the joint velocities as well
11:51 AM cradek: nope it does not do that
11:52 AM seb_kuzminsky: cradek: i agree the world-mode planner doesn't take joint constraints into account
11:53 AM cradek: oh you said "in joint space" (ie when jogging joints) and I agree with you
11:53 AM cradek: ok we're both right, sorry about my **
11:53 AM cradek: I got a little excited there
11:54 AM seb_kuzminsky: well i can understand that - this is exciting stuff
11:54 AM seb_kuzminsky: joint constraints are also honored when homing
11:54 AM cradek: cool, that's consistent because homing homes joints
11:56 AM narogon: ok, you have shed light on this
11:56 AM narogon: many thanks for the acclarations
11:56 AM cradek: I wish it did what you want :-/
11:57 AM seb_kuzminsky: yeah, that'd be a cool way for linuxcnc to behave
11:57 AM narogon: I can see the difficult of this, but I got excited when I know about 2.8 and the axis and joint separation
11:58 AM narogon: and I thought it could do also this!! ehhehe
11:58 AM narogon: I will wait for your future improvements
12:00 PM narogon: many thanks everybody, this chats is always very helpfull
01:26 PM skunkworks: Could you maybe add code to the kins to adjust adaptive feed if a movement will cause constraint violation of a joint?
01:28 PM seb_kuzminsky: skunkworks: i guess that'd be where you'd have to do it, since the trajectory planner doesn't know what the joint velocity will be, because in TP the path hasn't gone through kins yet
01:34 PM seb_kuzminsky: or you could make a separate component that monitors joint velocity (by looking at joint.*.joint-vel-cmd) and twiddles motion.adaptive-feed or something when it gets nervous
01:34 PM seb_kuzminsky: those are all hacks, the real solution is probably to make post-kins information available to the trajectory planner, and teach it to take that information into account
01:35 PM skunkworks: sure - although I don't know if adaptive feed is just scaling velocity or velocity and accelerations
01:35 PM skunkworks: sure
01:39 PM cradek: it's a feature and by design that you can tap in any direction!
01:39 PM seb_kuzminsky: i think the exclamation point indicates you're joking :-P
01:39 PM cradek: no I'm totally serious this time for once
01:39 PM seb_kuzminsky: huh
01:39 PM seb_kuzminsky: how?
01:40 PM cradek: it's easy to see how on a 5 axis, less easy on a 3 axis...
01:41 PM seb_kuzminsky: ah, yeah
01:41 PM cradek: on a lathe you could tap in Z or W (like if W is a tailstock or second turret)
01:41 PM seb_kuzminsky: my head keeps being stuck in a 3d world but you're totally right :-/
01:42 PM cradek: if we want a Z-on-a-3-axis-mill tap cycle, it could be a new one, ideally it would be like the other canned cycles with repeat
01:42 PM seb_kuzminsky: ok, then JT-Shop is correct and it's just the docs that are wrong
01:42 PM cradek: but I think no way should g33.1 be made Z only
01:42 PM seb_kuzminsky: i'm convinced
01:43 PM cradek: the second half of the "Warning" is bogus, but otherwise the docs look right to me
01:44 PM cradek: maybe a better Warning in that spot could say if you want to tap in just Z, program only a Z word
01:44 PM cradek: or similar?
01:44 PM cradek: I don't know what the "rapid move" part was supposed to mean
01:45 PM seb_kuzminsky: maybe instead of "rapid move... to the X Y location specified" it should say "do a spindle-synched move to the specified location"
01:45 PM cradek: but that's exactly what #1 in the sequence says
01:45 PM seb_kuzminsky: ... yeah
01:48 PM cradek: I bet some boring heads can do cool things with multi-axis tap moves too
01:48 PM cradek: don't some of them control the radius with the quill motion? you could single point tap a tapered thread.
01:48 PM seb_kuzminsky: that's wild. i don't know anything about that
01:49 PM cradek: but you'd probably use g33 (not reversing)
01:49 PM cradek: btw g33 goes in any direction too :-)
01:50 PM seb_kuzminsky: it might be misleading that the G33 and G33.1 docs only mention the X Y Z axes
01:55 PM JT-Shop: IIRC that warning has been in there for a long time
01:55 PM JT-Shop: I'll fix it
01:56 PM seb_kuzminsky: thanks!
01:56 PM seb_kuzminsky: please fix it in 2.7 and merge up to master
01:57 PM JT-Shop: ok, I'll fix 2.7 but I've never merged
02:00 PM seb_kuzminsky: i'll do the merge if you want
02:00 PM seb_kuzminsky: or walk you through it
02:16 PM jthornton: so G33.1 X- Y- Z- K- in the description should really be G33.1 X- Y- Z- U- V- W- K-?
02:18 PM seb_kuzminsky: i think it should be G33.1 /axes/ K-
02:18 PM jthornton: ABC too?
02:18 PM seb_kuzminsky: /axes/ means "any axis as defined in your configuration", according to http://linuxcnc.org/docs/devel/html/gcode/g-code.html#cha:g-codes
02:19 PM seb_kuzminsky: i bet G33.1 doesn't treat ABC any differently than XYZUVW
02:19 PM jthornton: ok
02:19 PM seb_kuzminsky: but maybe we should double check that first
02:19 PM jthornton: even better
02:24 PM seb_kuzminsky: ugh, no, it's all a lie
02:24 PM seb_kuzminsky: RIGID_TAP(block->line_number, end_x, end_y, end_z);
02:24 PM seb_kuzminsky: g33.1 only accepts x, y, and z, not uvw or abc
02:24 PM jthornton: thanks for checking
02:24 PM * cradek screams in horror
02:25 PM seb_kuzminsky: g33 (without .1) accepts all 9 axes
02:25 PM seb_kuzminsky: ...but only updates x, y, and z at the end :-(
02:26 PM seb_kuzminsky: (sad trombone)
02:28 PM jthornton: https://paste.ubuntu.com/p/KXXYRRnZqW/
02:29 PM jthornton: at least the example code was correct
02:29 PM seb_kuzminsky: heh
02:29 PM seb_kuzminsky: that's much better
02:29 PM seb_kuzminsky: my only comment is that "will be a coordinated move" might be more clearly written as "will be a coordinated, spindle-synchronized move"
02:30 PM jthornton: ok
02:31 PM seb_kuzminsky: the motion described on line 19 of that paste is clear and accurate
02:31 PM jthornton: yea, I changed that too
02:32 PM * jthornton hums the final jepordy tune while the docs build
02:32 PM seb_kuzminsky: you can "make ../docs/html/gcode/g-code.html" if you just want to look at one changed document
02:35 PM seb_kuzminsky: wait, why is it building way more documentation than the page i asked for? sigh
02:36 PM seb_kuzminsky: https://i.imgur.com/ocu5zQS.gifv
02:37 PM JT-Shop: I didn't know that
02:39 PM seb_kuzminsky: it does a bunch of extra work so that it can check the links in the document you asked for, but it's still much faster than building all the docs and everything
02:39 PM JT-Shop: I'll do that next time
02:42 PM pcw_mesa: JT-Shop would you mind updating your servo tuning tutorial with the calculated FF1 value?
02:43 PM pcw_mesa: (you can calculate FF1 based on the machine speed at 10V)
02:45 PM pcw_mesa: Assuming the default +-10V analog scaling FF1 should be 10/Velocity@10V (velocity in machine units per second)
02:46 PM JT-Shop: no problem
02:49 PM pcw_mesa: you can get a pretty good guess at the speed at 10V by finding the machines rapid speed and multiplying by about 1.2
02:52 PM cradek: thanks JT-Shop!
02:53 PM rene-dev: pcw_mesa I think all the tutorials should be changed to use the scale instead
02:53 PM rene-dev: so ff1 is always 1
02:53 PM rene-dev: makes eveythink much easier
02:54 PM rene-dev: because then all your numbers are correct
02:54 PM pcw_mesa: Yes Ive advocated that for years but it confuses most people
02:54 PM jthornton: pcw_home: after getting P set do you need to even mess with FF1?
02:55 PM pcw_mesa: (normalize the parameters to machin units)
02:55 PM pcw_mesa: If you are hand tweaking FF1 its easier to do with a lower P
02:55 PM jthornton: ok
02:57 PM rene-dev: in my opinion its easier
02:57 PM pcw_mesa: The other advantage of normalizing the PID scaling is that equivalent mm and inch machines use the same tuning values
02:57 PM rene-dev: and those pepole I explained it this way do seem to understand
02:57 PM pcw_mesa: not my experience
02:58 PM pcw_mesa: but I agree, its the ideal way
02:59 PM rene-dev: I always set bias,scale and ff1 first
02:59 PM pcw_mesa: you may need a bit of P on a analog servo to keep it from drifting
03:00 PM rene-dev: of course, but its best to do that last
03:00 PM rene-dev: because then you know all the rest is right
03:01 PM rene-dev: I always ask pepole what unit velocity is measured in. the answer is usually not volt, and then they understand :D
03:01 PM jthornton: done I think
03:01 PM * jthornton goes back to cutting metal
03:02 PM rene-dev: you also scale the encoder, as you dont want to program gcode in encoder steps ;D
03:05 PM seb_kuzminsky: there are some good bug fixes and docs improvements in 2.7, i should release 2.7.13 soon
03:05 PM pcw_mesa: sure but that affects machine scaling. once the PID is tuned typically nobody cares about the PID output units
06:13 PM -!- #linuxcnc-devel mode set to +v by ChanServ
09:17 PM Tom_L: pcw_home, can i copy resrom.vhd from the 7i80 to the 7i90 config source or are they different?
09:20 PM Tom_L: nm, i found it in the 90 folder..
09:24 PM Tom_L: eyes must be tired