* jepler finds to his great surprise that the amd64 rtai is compiled without math enabled!
I wonder how it seems to work at all !?
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
same in current vel in preview
is this correct behaviour ?
why adaptive feed enable/disable commands aren't allowed where rest of FO SO are ?
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
I cannot call set_adaptive_feed
alex_joni: "command (%s) cannot be executed until the machine is out of E-stop and turned on" shows up
micges: got the NML message name handy?
I know where to put it but I wonder why it isn't there? design?
I see EMC_MOTION_ADAPTIVE has waiting for motion as a precondition
the others have waiting for io as a precondition
I think the others are wrong
that's the first bug
I don't understand why SET_FO, SET_FH and SET_SO are waiting_for_io :/
and I was the one that put them there..
maybe it was when spindle conttrol was in io ?
that might have been my initial idea
basicly they shouldn't have a precondition
bbl I'm going to lunch
the only problem is when the disable AF comes during a move
where the AF is supposed to be on
so I think the right way to solve it is to have WAITING_FOR_MOTION as a precondition
what is going if there is no precondition?
command is always accepted ?
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
micges: imagine you have a longer program
some moves are allowed to be overriden by AF, some not
in the middle of the program you will have Mxx to switch AF off
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
even if the execution of the program is still at the beginning
oh ok I understand
now regarding the second question.. your speed
do you mean current X vel or current tooltip vel?
if you are at x0y0, and go to X100 Y100 it will travel diagonally
so that X travels at 100 u/sec and y at 200 u/sec
but basicly both will move at 50 u/sec
for the G1 ?
ok, so F-word allows faster
and the axes are the limiting factor
AF at 0.5 will mean the move needs to be at 500
but your axes limit at 100 and 200
so it will travel at 100 * sqrt(2)
that should be around 141.42
if it goes only in X it should be 100
alex_joni: letme describe what I want to do:
I have laser, which vel must be controlled up to 0.5 mm/min
it must have 4 different vel in 4 directions
x+ = 1000, x- = 1050 , y+ = 1200, y- = 900
and acoording to currentdirection currect vel must changing in rt
it has xmax vel=6000, and ymaxvel=9000
I've written comp module to calculate current adaptive feed value and passed it to motion but above problem exist
AF is simple multiply of current total vel but feedoverride isn't
emc don't have any mode to total direct control of machine in rt from external float signal
any attempt to connect to halui make velocity ossilating
halui isn't real time
I've asked about adding such direct mode to emc but no answer
alex_joni: what do you think about that?
let me reread it a couple times :)
14:23 < micges> emc don't have any mode to total direct control of machine in
rt from external float signal
what do you mean there?
I mean when I setup that mode let see G553
after that F word are ignored
so you want the velocity to be prescribed only from a hal pin?
and feedrate is calculated (from 0 to traj max ) from hal pin
say you have traj max 300
the machine can move 0 .. 300
and the g-code F word is 200
now you want instead of the g-code F word, a HAL pin which sets those 200, or whatever value
if the value is smaller than 300, that value will be used. if it's larger it will be clamped at 300
simply f word I want to write directly to motion , and I want to can do that on at any time
and clamped, yes
there is a slight problem
so I don't have to stop , set f word, start, stop , select line, start
the lines/arcs interpreted in g-code are appended to the motion queue
and when they are put on the queue they already have velocities attached to them
if you later change the HAL pin for velocity, then the moves which are already on the queue won't be changed
I am not sure what to do about it though.. maybe cradek knows more about this part to suggest something sensible
sending vel with commands as I readed was to remove some problems with velocity control
perhaps you should customize emccanon.cc:getStraightVelocity and the velocity calculations in ARC_FEED according to your machine's odd constraints
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
I'll look at them
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
jepler: yeah, but this still happens at interp-time
alex_joni: I didn't fully read the discussion
I thought the problem was that micges needs to meet weird asymmetric constraints for motion
micges wants things to change in RT
while the machine moves
I admit I don't fully understand what he's asking for
the problem is changing the velocity for the already queued moves (inside the TC queue)
is it for another reason than to meet his asymmetric constraints?
so there are two things mixed in here
I think the problem is that he needs user intervention
and tried to hook that into AF
but because of assymetric constraints it doesn't work as it should
or as he wants it
it would be working when xy was symmetric
by the time motion is doing AF, individual velocities are quite mangled
like I said before, bbl
BJT-Work: missed you at the fest.
skunkworks588 is now known as skunkworks_
skunkworks588: I missed everyone :(
work, work, work...
I hear you
I did get my tractor far enough along to start it up yesterday :)
how much more work?
mount the radiator and the sheetmetal
it ticked along at about 450 rpm at idle... what a nice sound after 6 months of working on it
how does axis.n.motor-pos-cmd work? Is it changed at a rate not to exceed the acceleration and velocity settings?
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
you are going to use stepgen by itself to control an axis?
(not using the emc's trajectory planner?)
no, just add to and subtract from the commanded position based on the feedback from the THC card
ah - stepgen does have settable acc and vel limits.
could you use that?
ok, cool yes
during the cut the Z is only moved up and down with the THC adding to or subtracting from the current position
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
so if I set the stepgen.n.maxaccel and maxvel to be equal to my ini settings I should be safe
I would think so
no guys that wont work
the stepgen needs to have a little more accel and vel than the trajectory planner
3-5% is plenty
without that, it'll fall behind during the accel phase and not be able to catch up
do I need more than is set via the ini file?
that's why i added hm2's maxaccel=0 & maxvel=0 modes, which mean "trust the tp and do whatever it says"
or does the ini file set the stepgen?
otherwise you have to maintain two sets of maxvel and maxaccel, one for tp and one for stepgen
the [AXIS_?]MAX_ACCELERATION and [AXIS_?]MAX_VELOCITY set the tp but not the stepgen
the stepgen params need to be set explicitly
got to go, good luck with the THC!
i wonder if we're on the DEA list because of all this talk of thc
wander what seb meant about the DEA list
I think thc is the 'active ingredient' in weed
BJT-Work: is it safe to remove it AFTER the rapid up?
good catch seb
it could be
hmm learn all kind of things here :)
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.
oh I misunderstood
motor pos cmd > correction > stepgen
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...
I agree that's a good time to remove it
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
do you have a sample-and-hold feature?
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
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
that seems easier to me than adding it throughout the move, but YMMV
that would be easier but that might cause me to hit a limit switch...
me too, breakfast
heh - I really have to make sure the email I am replying to is the right one.. ;0
will this url load for anybody at the moment?
[16:00:11] <jepler> https://launchpad.net/~git-core/+archive/ppa
ah it finally loaded here too
cradek: around ?
jepler: down to 35 in stock ;)
skunkworks_: how many did you get?
none.. but tempted. (would work for a nice small/fast pcb mill)
skunkworks: yes that's an interesting e-mail you sent earlier
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.
(umm, what country are they shipping it from? and how badly will I regret that I chose "ups ground"?)
does ground work underwater?
jepler: yah - It could have been worse ;)
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