Back
[03:23:59] <jepler> * jepler finds to his great surprise that the amd64 rtai is compiled without math enabled!
[03:24:10] <jepler> I wonder how it seems to work at all !?
[03:24:16] <jepler> 'night
[08:07:51] <micges> good morning
[08:09:34] <micges> I have question: I've started using adaptive-feed for controlling laser velocity, but I have problem that velocity on axis.0.joint-vel-cmd is commanded vel not real vel
[08:09:47] <micges> same in current vel in preview
[08:10:08] <micges> is this correct behaviour ?
[08:44:13] <micges> why adaptive feed enable/disable commands aren't allowed where rest of FO SO are ?
[08:56:04] <alex_joni> micges: what do you mean?
[08:59:24] <micges> http://cvs.linuxcnc.org/cvs/emc2/src/emc/usr_intf/axis/extensions/emcmodule.cc.diff?r1=1.43;r2=1.44
[08:59:50] <micges> I cannot call set_adaptive_feed
[09:06:48] <micges> alex_joni: "command (%s) cannot be executed until the machine is out of E-stop and turned on" shows up
[09:49:23] <alex_joni> micges: got the NML message name handy?
[09:50:11] <micges> EMC_MOTION_ADAPTIVE
[09:50:55] <micges> I know where to put it but I wonder why it isn't there? design?
[09:51:11] <alex_joni> I see EMC_MOTION_ADAPTIVE has waiting for motion as a precondition
[09:51:20] <alex_joni> the others have waiting for io as a precondition
[09:52:13] <alex_joni> I think the others are wrong
[09:52:34] <alex_joni> that's the first bug
[09:52:38] <alex_joni> in emctaskmain.cc
[09:55:29] <alex_joni> I don't understand why SET_FO, SET_FH and SET_SO are waiting_for_io :/
[09:56:42] <alex_joni> and I was the one that put them there..
[09:57:20] <micges> maybe it was when spindle conttrol was in io ?
[09:58:30] <alex_joni> that might have been my initial idea
[09:58:53] <alex_joni> basicly they shouldn't have a precondition
[09:59:05] <micges> bbl I'm going to lunch
[09:59:13] <alex_joni> the only problem is when the disable AF comes during a move
[09:59:27] <alex_joni> where the AF is supposed to be on
[09:59:44] <alex_joni> so I think the right way to solve it is to have WAITING_FOR_MOTION as a precondition
[10:22:41] <micges> I'm back
[10:23:24] <micges> what is going if there is no precondition?
[10:24:40] <micges> command is always accepted ?
[10:28:38] <micges> alex_joni: about AF: when X maxvel = 100 and y maxvel = 200, motion.adaptive-feed = 0.5, and G1X100Y100 is executed, current vel is different that when executing G1X100Y0
[11:23:26] <alex_joni> micges: imagine you have a longer program
[11:23:40] <alex_joni> some moves are allowed to be overriden by AF, some not
[11:23:51] <alex_joni> in the middle of the program you will have Mxx to switch AF off
[11:24:21] <alex_joni> if there is no precondition, when the interpreter reaches the line with the M-code to switch it off, it will directly send it to motion, and AF will be switched off
[11:24:32] <alex_joni> even if the execution of the program is still at the beginning
[11:25:57] <micges> oh ok I understand
[11:28:02] <alex_joni> now regarding the second question.. your speed
[11:28:15] <alex_joni> do you mean current X vel or current tooltip vel?
[11:28:35] <alex_joni> if you are at x0y0, and go to X100 Y100 it will travel diagonally
[11:28:49] <micges> tool tip
[11:28:55] <alex_joni> so that X travels at 100 u/sec and y at 200 u/sec
[11:29:26] <alex_joni> max speed
[11:29:36] <alex_joni> but basicly both will move at 50 u/sec
[11:30:00] <alex_joni> what F-word?
[11:30:05] <alex_joni> for the G1 ?
[11:30:11] <micges> f1000
[11:30:24] <alex_joni> ok, so F-word allows faster
[11:30:32] <alex_joni> and the axes are the limiting factor
[11:30:46] <alex_joni> AF at 0.5 will mean the move needs to be at 500
[11:30:53] <alex_joni> but your axes limit at 100 and 200
[11:31:00] <alex_joni> so it will travel at 100 * sqrt(2)
[11:31:27] <alex_joni> that should be around 141.42
[11:31:31] <micges> yes correct
[11:31:38] <alex_joni> if it goes only in X it should be 100
[11:32:23] <micges> alex_joni: letme describe what I want to do:
[11:33:05] <micges> I have laser, which vel must be controlled up to 0.5 mm/min
[11:33:35] <micges> it must have 4 different vel in 4 directions
[11:34:13] <micges> x+ = 1000, x- = 1050 , y+ = 1200, y- = 900
[11:34:26] <micges> (theoretical values)
[11:34:57] <micges> and acoording to currentdirection currect vel must changing in rt
[11:35:47] <micges> it has xmax vel=6000, and ymaxvel=9000
[11:36:44] <micges> I've written comp module to calculate current adaptive feed value and passed it to motion but above problem exist
[11:37:31] <micges> AF is simple multiply of current total vel but feedoverride isn't
[11:38:24] <micges> emc don't have any mode to total direct control of machine in rt from external float signal
[11:38:55] <micges> any attempt to connect to halui make velocity ossilating
[11:39:03] <micges> halui isn't real time
[11:39:45] <micges> I've asked about adding such direct mode to emc but no answer
[11:41:35] <micges> alex_joni: what do you think about that?
[11:55:51] <alex_joni> let me reread it a couple times :)
[11:56:37] <alex_joni> 14:23 < micges> emc don't have any mode to total direct control of machine in
[11:56:38] <alex_joni> rt from external float signal
[11:56:44] <alex_joni> what do you mean there?
[11:57:18] <micges> I mean when I setup that mode let see G553
[11:57:29] <micges> after that F word are ignored
[11:58:18] <alex_joni> so you want the velocity to be prescribed only from a hal pin?
[11:58:25] <micges> and feedrate is calculated (from 0 to traj max ) from hal pin
[11:59:17] <alex_joni> say you have traj max 300
[11:59:24] <alex_joni> the machine can move 0 .. 300
[11:59:38] <alex_joni> and the g-code F word is 200
[11:59:58] <alex_joni> now you want instead of the g-code F word, a HAL pin which sets those 200, or whatever value
[12:00:18] <alex_joni> if the value is smaller than 300, that value will be used. if it's larger it will be clamped at 300
[12:00:21] <alex_joni> right?
[12:01:03] <micges> simply f word I want to write directly to motion , and I want to can do that on at any time
[12:01:13] <micges> and clamped, yes
[12:01:32] <alex_joni> there is a slight problem
[12:01:47] <micges> so I don't have to stop , set f word, start, stop , select line, start
[12:01:58] <alex_joni> the lines/arcs interpreted in g-code are appended to the motion queue
[12:02:32] <alex_joni> and when they are put on the queue they already have velocities attached to them
[12:03:00] <alex_joni> if you later change the HAL pin for velocity, then the moves which are already on the queue won't be changed
[12:03:27] <alex_joni> I am not sure what to do about it though.. maybe cradek knows more about this part to suggest something sensible
[12:04:31] <micges> sending vel with commands as I readed was to remove some problems with velocity control
[12:20:33] <jepler> perhaps you should customize emccanon.cc:getStraightVelocity and the velocity calculations in ARC_FEED according to your machine's odd constraints
[12:21:12] <jepler> these external inputs were never intended as a way to enforce machine constraints, so I'm not too surprised it's not working well for you in practice
[12:22:11] <micges> I'll look at them
[12:22:14] <jepler> for other reasons (nontrivial kinematics) it would be nice to make it easier for integrators to customize the calculations for constraints for each move before it's turned into a canon call
[12:22:18] <jepler> bbl
[12:22:47] <alex_joni> jepler: yeah, but this still happens at interp-time
[12:22:56] <jepler> alex_joni: I didn't fully read the discussion
[12:23:06] <jepler> I thought the problem was that micges needs to meet weird asymmetric constraints for motion
[12:23:07] <alex_joni> micges wants things to change in RT
[12:23:11] <alex_joni> while the machine moves
[12:23:44] <jepler> I admit I don't fully understand what he's asking for
[12:23:55] <alex_joni> the problem is changing the velocity for the already queued moves (inside the TC queue)
[12:23:59] <jepler> but why?
[12:24:07] <alex_joni> user intervention
[12:24:12] <jepler> is it for another reason than to meet his asymmetric constraints?
[12:24:21] <jepler> so there are two things mixed in here
[12:24:28] <alex_joni> I think the problem is that he needs user intervention
[12:24:36] <alex_joni> and tried to hook that into AF
[12:24:46] <alex_joni> but because of assymetric constraints it doesn't work as it should
[12:24:51] <alex_joni> or as he wants it
[12:25:06] <micges> it would be working when xy was symmetric
[12:25:27] <alex_joni> by the time motion is doing AF, individual velocities are quite mangled
[12:26:35] <jepler> like I said before, bbl
[12:31:48] <alex_joni> ;)
[12:53:31] <skunkworks588> join ubuntu
[12:53:39] <skunkworks588> heh
[13:17:16] <skunkworks588> BJT-Work: missed you at the fest.
[13:17:22] <skunkworks588> skunkworks588 is now known as skunkworks_
[13:18:16] <BJT-Work> skunkworks588: I missed everyone :(
[13:18:52] <BJT-Work> work, work, work...
[13:18:59] <skunkworks_> I hear you
[13:19:52] <BJT-Work> I did get my tractor far enough along to start it up yesterday :)
[13:23:52] <skunkworks_> NIce
[13:24:01] <skunkworks_> how much more work?
[13:24:31] <BJT-Work> mount the radiator and the sheetmetal
[13:25:12] <BJT-Work> it ticked along at about 450 rpm at idle... what a nice sound after 6 months of working on it
[13:26:24] <skunkworks_> very cool
[13:32:21] <BJT-Work> how does axis.n.motor-pos-cmd work? Is it changed at a rate not to exceed the acceleration and velocity settings?
[13:32:41] <seb_kuzminsky> BJT-Work: yes
[13:33:46] <BJT-Work> so if I hijack it before it gets to stepgen I'll have to be careful not to change it too fast for my THC
[13:34:20] <BJT-Work> hi seb_kuzminsky
[13:38:20] <skunkworks_> you are going to use stepgen by itself to control an axis?
[13:38:47] <skunkworks_> (not using the emc's trajectory planner?)
[13:39:22] <BJT-Work> no, just add to and subtract from the commanded position based on the feedback from the THC card
[13:39:55] <skunkworks_> ah - stepgen does have settable acc and vel limits.
[13:40:17] <skunkworks_> could you use that?
[13:40:23] <BJT-Work> ok, cool yes
[13:41:02] <BJT-Work> during the cut the Z is only moved up and down with the THC adding to or subtracting from the current position
[13:41:59] <BJT-Work> that part is somewhat easy... the part I'm struggling with is how to remove the correction as the Z rapids up after the cut is over
[13:45:21] <BJT-Work> so if I set the stepgen.n.maxaccel and maxvel to be equal to my ini settings I should be safe
[13:52:39] <skunkworks_> I would think so
[13:52:56] <seb_kuzminsky> no guys that wont work
[13:53:11] <seb_kuzminsky> the stepgen needs to have a little more accel and vel than the trajectory planner
[13:53:14] <seb_kuzminsky> 3-5% is plenty
[13:53:27] <seb_kuzminsky> without that, it'll fall behind during the accel phase and not be able to catch up
[13:54:37] <BJT-Work> thanks
[13:55:09] <BJT-Work> do I need more than is set via the ini file?
[13:55:34] <seb_kuzminsky> that's why i added hm2's maxaccel=0 & maxvel=0 modes, which mean "trust the tp and do whatever it says"
[13:55:41] <BJT-Work> or does the ini file set the stepgen?
[13:55:49] <seb_kuzminsky> otherwise you have to maintain two sets of maxvel and maxaccel, one for tp and one for stepgen
[13:56:15] <seb_kuzminsky> the [AXIS_?]MAX_ACCELERATION and [AXIS_?]MAX_VELOCITY set the tp but not the stepgen
[13:56:23] <seb_kuzminsky> the stepgen params need to be set explicitly
[13:56:24] <BJT-Work> ok
[13:56:36] <seb_kuzminsky> got to go, good luck with the THC!
[13:56:40] <BJT-Work> thanks
[13:56:47] <seb_kuzminsky> i wonder if we're on the DEA list because of all this talk of thc
[13:56:56] <seb_kuzminsky> laters
[13:57:16] <micges> bbl
[13:57:49] <BJT-Work> wander what seb meant about the DEA list
[13:58:10] <BJT-Work> wonder
[13:58:22] <skunkworks_> I think thc is the 'active ingredient' in weed
[13:58:27] <cradek> BJT-Work: is it safe to remove it AFTER the rapid up?
[13:58:58] <skunkworks_> good catch seb
[13:59:06] <BJT-Work> it could be
[13:59:25] <BJT-Work> hmm learn all kind of things here :)
[14:00:07] <cradek> also, making your extra stepgen match emc's vel and accel settings is not what you want, since if they both go in the same direction at the same time, the accels and velocities add so you will end up with 2X what you want.
[14:00:31] <BJT-Work> extra stepgen?
[14:00:44] <cradek> oh I misunderstood
[14:00:55] <cradek> forget it
[14:01:07] <BJT-Work> motor pos cmd > correction > stepgen
[14:01:19] <cradek> right
[14:07:44] <BJT-Work> the plan is if it is a positive correction remove it as the pos cmd increases and that will just slow down the actual move so I don't see a problem with that...
[14:08:06] <cradek> I agree that's a good time to remove it
[14:08:40] <BJT-Work> if it is a negative correction I have to make sure not to remove it any faster than the pos cmd comes in so as to not move the Z down
[14:09:41] <cradek> do you have a sample-and-hold feature?
[14:10:47] <cradek> what I'm thinking is that the original position, the final position, and the final +/- correction are all safe, so if you "hold" the correction until after the move up and then "release" it, you'd be safe
[14:10:53] <BJT-Work> yes while cutting and at speed the correction is added to and subtracted from and the current offset is held after the torch goes off
[14:10:57] <cradek> that seems easier to me than adding it throughout the move, but YMMV
[14:12:26] <BJT-Work> that would be easier but that might cause me to hit a limit switch...
[14:12:29] <BJT-Work> bbl
[14:12:57] <cradek> me too, breakfast
[14:14:47] <skunkworks_> mmmm breakfast
[14:23:15] <skunkworks_> heh - I really have to make sure the email I am replying to is the right one.. ;0
[16:00:11] <jepler> will this url load for anybody at the moment?
[16:00:11] <jepler> https://launchpad.net/~git-core/+archive/ppa
[16:03:21] <micges> yes
[16:07:21] <jepler> ah it finally loaded here too
[17:32:22] <micges> cradek: around ?
[18:13:32] <skunkworks_> jepler: down to 35 in stock ;)
[18:43:22] <alex_joni> skunkworks_: how many did you get?
[18:44:18] <skunkworks_> none.. but tempted. (would work for a nice small/fast pcb mill)
[21:10:10] <jepler> skunkworks: yes that's an interesting e-mail you sent earlier
[21:12:42] <jepler> weird, the tracking e-mail from the skycraft motor shipment says: Scheduled Delivery: An additional ship notification with a scheduled delivery date will be sent when your shipment is received by the destination country.
[21:12:57] <jepler> (umm, what country are they shipping it from? and how badly will I regret that I chose "ups ground"?)
[21:13:29] <alex_joni> does ground work underwater?
[21:13:49] <jepler> good question
[21:27:50] <alex_joni> g'night all
[21:54:45] <skunkworks> jepler: yah - It could have been worse ;)
[21:56:08] <skunkworks> my wife and I where wondering why organic milk usually has a longer shelf life than normal milk. It was because the heat it to a higher temp