huh - I wonder if that's why I sometimes can't boot the liveCD
you saw that too?
I don't think so actually
I thought it did support SATA, but never really tried
I'm pretty sure I have an emc2/6.06 install on a SATA drive
my main box is SATA, but I'm using stock dapper there
ah, I was going to ask about that
the shoptask is older, and uses pata
I guess it could be a 120G I had lying around
I used a normal hard disk for developing the power supply stuff, and I'm pretty sure it's a 300G SATA drive
I have put dapper on a few sata sytems
SWPadnos_ is now known as SWPadnos
me too for dapper, it's the liveCD we're wondering about
I don't have access to any sata cdrom drives
I'm pretty sure it would install on sata disk.
ah - ok. I don't know if I have booted on sata cdrom.
I can try it out in a sec. I've got the little embedded box apart for that purpose
oh - I was at Micro Center and they had slim jewel cases cheap, so don't buy any for liveCDs :)
crap. there's only one SATA power connector on that power supply
hmmm. well, it boots and gets to the desktop, but there were some squashfs errors
I don't want to install it to the hard drive in the machine because it's got data on it
so, has anyone noticed that it's getting fairly close to the time when the CNC workshop website should have been updated already?
hi guys.... 6.06 live boots fine on old pata cdrom,.... just doesnt work on the sata cd drive box.... not sure why
it does work here
this is a 2.1.x CD, but I think it's the same kernel
yeh... this image is one I just downloaded from the linuxcnc site a few days ago 2.6.15-magma
can you try a stock Dapper disc?
I have had issues booting on some machines - can't tell you what caused them at the moment
I will see if I can find one... I think I have a dapper server disk around here
it looks like SATA isn't the issue, though support for the particular chipset could be
Its not a big deal... this box is not my controller box... I was just interested to see what the latencies looked like on the new m/b and E8400 cpu
yeah, it would be interesting
I just booted up on an intel chipset embedded board with a core 2 Duo
it's OK with the stock kernel, but not great. something like 16000 max latency
I will be right back after a reboot...
so I see :)
stock 6.06 server boots to menu, I did get emc2 live cd to boot, but had no mouse action.... wonder if its a timing issue of something like this m/b is too new to be supported
will see what happens when 8.04 hits the street
the beta sure seems good. you could try it
I think there are experimental packages for it, but you'd need to install to check latency
obviously stock 8.04 beta runs on here... I installed a couple of days ago
ok, in that case you can install the experimental packages (if they exist :) )
looks pretty good.....
yeah, it does
I have got emc2 sim built onthis box for previewing gcode
just not the realtime stuff
beta had the web browsers broken for the morning.... 1 update crashed web browsers... about lunch time it was back working with new browser updates
ok, it looks like there aren't RT packages for 8.04 yet. oh well
except sim that is
no problem..... shoptask is very happy running 6.06
I should go update the sf feature request
it's not really an EMC feature though
something to watch for when building next live cd.... I can be a tester to see how it acts on new hardware
here's a question for you: how can we make the distinction between the liveCD and EMC2 proper, while still offering the liveCD for ease of installation?
ie, convince users that upgrading is much better than downloading a new liveCD, that the version of EMC2 on the CD doesn't really matter since it's only there to make RT installation easier, etc.
(well, there are other uses, but still :) )
The live cd makes it very easy for new installs or testing new hardware..... I havent tried taking a live cd into future shop... wonder if they would let me boot it?
heh - dunno. people get paranoid even if you tell them you can unplug the hard drive before booting
yea... getting into the boot to change the boot order can be fun.... even costco has all there display computers password protected
they don't have all the power cords protected though ;)
I wonder if they have the BIOS protected like they have Windows protected
the ones I tried did :}
ok. bedtime here. see you later
EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/usr_intf/axis/extensions/emcmodule.cc: remove comment, it has been fixed
EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/motion/emcmotglb.c: remove an older reference for num_joints (unused ..)
EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/nml_intf/emcglb.h: reenable EMC_AXIS_MAX
got any extra info on the cad to step thing i was askin about?
nope do you
nope not really - i have some industry friends looking int o it for me :)
if they find out anything post it in the #cam channel
i will do that
good morning y'all
alex_joni: looks like your going to town.
and another one http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Simple_EMC_G-Code_Generators
drilling speed and feed calculator
opps wrong channel
aha, nice :)
while your here alex a couple of questions about getting the trunk
if I have used the live cd to install and have cvs installed
do I start with "export CVS_RSH=ssh"
and what does that do?
you need to start here http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Installing_EMC2#On_Ubuntu_6_06_from_source
does that trash my current 2.2.4?
the installed version?
this creates a run-in-place version in your home directroy
I have universe respository enabled
what does this line do "sudo apt-get build-dep emc2"
it grabs all packages needed to satisfy the build dependency for emc2
so I do the above and "sudo apt-get install build-essential" then do the cvs?
you probably need to apt-get install cvs too
I have cvs installed from the last attemp
I guess I'm slow this morning but does sudo apt-get build-dep emc2
sudo apt-get install build-essential
build-dep means install all the other packages necessary to build the stated package
build-essential is a package that pulls in the system compiler and other essential things for compiling stuff
trying to convince my partners-in-crime to go out for breakfast
how's your day?
it's sure a nice weekend here. 60 degrees but windy
pretty ok.. too bad most of it is soon over, and I didn't get to do much
it's colder then the last few days here (about 12C) and not sunny
well I hope you had some kind of fun anyway.
* alex_joni tries to decide if sleeping late is fun
hmm.. I think it surely is :D
sure it is
hmm.. wonder if this is usefull at all
emctaskmain checks newly received commands against XYZ bounds
it doesn't check ABC, UVW
so I think we either want to check all, or none
rotaries could be "interesting" due to wraparoubnd
UVW should be checked the same as XYZ, if they're assumed to be parallel axes
yeah, I think it's not a good idea to check
well, that depends
it's rather better to let the code that has a clue about this to check it
SWPadnos: motion does the check anyways
if there is a way (or a way can be added) to provide limits for rotaries, then they should be checked
SWPadnos: what I mean is that the check in task (and it's not the only one) is a redundant one
(dont mix up rotary joints with rotary axes)
but then you start a move toward a limit, but the machine stops when it's about to move too far
and atm it's busted for nontrivkins
it checks the linear endpoint against the joint limits
i'm of the opinion that a cube work envelope is not very useful
so it checks if X[mumble] is between joint.min and .max
fenn: I agree
it's quite useful, but certainly not universal
SWPadnos: it's _very_ restricted
its only useful for putting your robot in a square box
sure, and that matters for some types of machine :)
and even then, it might hit the wall with an elbow or something
and it doesn't guarantee that a move inside the box is even valid
you still have singularities and whatnot
so moving from one ok position to another ok position inside the valid cube space, might not be possible
(you might get joint limits along the path)
oh sure, I understand it isn't useful for all machines, but it is certainly very useful for some machines
why not just use joint limits?
fenn: that's a bit harder to do
you need to simulate the move (while feeding positions through kins)
and see if any joint limits aren't exceeded
* fenn points at the gobs of spare processing power
fenn: at least I haven't found another plausible way to do it
fenn: I'm not saying it won't work..
you can build up a map beforehand
map of configuration space
you still have to do it to limit speeds so that joint speeds aren't exceeded
(do the simulated move, compute fastest joint speeds, check against the max allowable, and scale the move accordingly)
of course there's still FO in the picture
FO can bite me
* alex_joni kinda agrees
FO: please bite fenn
FO is still possible that way
SWPadnos: just not increasing FO.. only 0..1
you can calculate the max allowable vector velocity (F rate), then clip to that
sure, you can do increasing as well
you calculate the max allowed F word for a segment
if the move would exceed the joint vels, and you scaled it to joint max..
apply all scaling (FO/AF/whatever) to the programmed rate, and clip to that max
SWPadnos: ah, ok.. I was thinking of the case when the g-code F-word would exceed joint limits
SWPadnos: right, that's quite close to how it's done currently
what you have is a dynamic limit, not an ini-stated limit
yep, the same
SWPadnos: right, that's quite close to how it's done currently (in canon..)
I think this calls for additional functions in kins, but I'm not sure how those would get linked to canon
ok, since you guys are quite familiar with the concepts .. maybe you could look at the changes I had lately (just to see if I missed some joint/axis confusion..)
SWPadnos: obviously userspace->motion->kins->motion->userspace is out of the question
I'll try to make the time to do that, but I can't guarantee anything for the next few weeks unfortunately
so it needs to be some runtime thingie
I wonder if a .so can be made with the same kins source as the .ko is made
might be.. you might need some wrapper functions and whatnot
and both need to be specified (and need to match) in the ini
or some other program to load both needs to be there
loadusr something :)
just make sure you have the same something as the loadrt ;)
this might be actually very rarely used, so for the beginning even compiling it in might be ok
(just for prototyping purposes)
well, I'd want to add derivative functions to the KINS interface
maybe a python binding or some sorts
they would be needed at the motion level for accel limiting
and at the canon level for the same thing :)
because motion doesn't know about the ini limits, but CANON does (if I understand the code correctly)
"motion doesn't know about the ini limits" <- which limits?
hmmm - well, I'm not sure actually
joint limits do go to motion
it surely knows about the joint limits
and it would be quite easy to send AXIS limits (defined in the ini) down there.. but just like the box space.. I'm not sure how much good that does
I guess both modules know the limits - motion so it can prevent overdriving the hardware, and canon so it can only provide valid moves
oh right - canon needs to operate with both joint and cartesian limits
right, and motion only with joint limits
so it does need to know the joint derivatives
and for moves it gets a max_something for this move
so FO won't bust things
heh - you could just about do this stuff by just sending the "controlling joint" in the command. "for this move, joint 3 is the critical one - use it for limit calculations"
that will rarely be the case
at least on puma you have multiple joints which are the critical one along one move
on the contrary - I believe there will almost always be exactly one joint that is the constraining factor
sometimes two joints might be "tied"
if you have a longer move it changes
based on the carthesian position
yes, but in the end, if you have checked the entire move, one joint will have the lowest ratio of attainable vs. requested vel
but.. in the first section you can't use that.. because another joitn might be close to it's limits
but I see the point - you can't check only one at all points along a particular path
actually, maybe you can. say the factor calculated was 0.73x max speed for one joint, and that was the lowest of all joints. if you always remain below that, you're guaranteed to always be below the thresholds for the other joints
by definition, because that 0.73 was the lowest factor calculated
it's not optimal, but it will always be correct
ok, I can see that
but what's the advantage?
you only need to do derivatives with respect to one joint in RT
rather than checking all and "voting"
probably not an issue
but you already have the carth. sepeed
done in realtime
jogging along the path (eventually ;) )
I mean.. nowadays you already have the carthesian speed
it gets calculated by TP I think
so you only have to clamp that agains a max admissable carth. speed
calculated by canon
does canon/TP do that correctly for SCARA? (for the entire path)
I think so
because it plans in carth.
and only afterwards it generates joint positions
I think I was talking about calculating a limit on cart speed due to joint limits
I thought we said we already did that in userspace :)
hmm.. I just remembered that jeff already made .so's out of the HAL code when compiling with --enable-simulator
I think the same mechanism can be used for kins too
oh yes, so he did
EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/ini/ (emcIniFile.cc iniaxis.cc iniaxis.hh inijoint.cc): (log message trimmed)
EMC: - reenable iniAxis* used for reading additional things from AXIS_X, Y, .. sections
EMC: in the ini.
EMC: these are things like:
EMC: * carthesian HOME position
EMC: * MIN/MAX limits (for box shaped workspace limiting)
EMC: * MAX_VEL/ACC for carthesian speed/accel limiting
EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/nml_intf/ (emc.hh emcops.cc):
EMC: * add taskintf functions for setting Axis related things (min/max position, max vel/acc..)
EMC: * change EMC_JOINT_LINEAR to EMC_LINEAR (same for ANGULAR): sometimes used for AXES too
EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/task/emctaskmain.cc: add a comment about some wrongly done limit checks
EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/task/taskintf.cc: add functions related to axis things (min/max limits, max vel/acc)
EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/usr_intf/ (emcrsh.cc emcsh.cc): replace EMC_JOINT_LINEAR with EMC_LINEAR (same for ANGULAR), sometimes used for axes-related things too
EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/usr_intf/axis/extensions/emcmodule.cc: replace EMC_JOINT_LINEAR with EMC_LINEAR (same for ANGULAR), sometimes used for axes-related things too
do people often do FO more than, say, 120%?
oops scrollback heh
it means they need to change something in the ini :)
so you could just do moves so that 100% joint limit is at 120% FO
fenn: I'm not so worried about these specifics
if they are insane and need 100% all the time, set max FO to 1.0
they can even disable FO from g-code.. so it shouldn't be that much of an issue
ok, so the issue atm is to add the following:
an extension to canon which can be loaded dynamically at runtime (in order to chose different kins)
before queueing a new command from interp, canon will send it to a motion planner which simulates it, and returns the max speeds/accels encountered for all joints during the simulation
canon then will scale the speed accordingly so that max joint speeds aren't violated (if it was below it can scale up, otherwise down)
canon then sends the move to motion with the max carthesian allowed speed
motion then checks the current speed (programmed + FO's of various sorts) against the max allowed and clamps
I wonder if I should disagree with myself..
sounds good to me
added it here: http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?JointsVsAxes
I'm not even awake yet and you guys are already at it
it's after 8pm here..
not much sunshine left
its 1pm here
hmh, I'm getting a servo jump with G33.1. seems to come just when the spindle reverses the second time
maybe I'm just seeing the dynamics of the spindle then...
in addition to rigid-tapping, has anyone done single-point threading with a mill?
where the spindle would be oriented a certain way at the end of the move before an XY move to the center of the hole and a Z retract
I guess I'm asking for spindle orientation. (might be useful for toolchangers that require that too
like threadmilling but done like on a lathe?
why would you do that? :)
it might be fun. well perhaps more useful is the spindle orient for toolchangers
single point threading on the mill won't work
(I don't mean EMC can't do it, I mean its impossible to do)
i thin you'd need a counterbore for the cutter to spin around in at the bottom of the hole
spindle orient for toolchange, or for extracting a boring tool or reverse counterbore tool would be usefull
I think boring can use spindle orient too, where the tool is disengaged from the material before retract
the reason single point threading won't work is because the tool tip radius needs to change from pass to pass
on a lathe, you spin the work and move the tool tip radially
on a mill, you'd have to spin the tool _and_ move the tool tip radially - the mill axes can't do that
how do cnc boring heads work?
you can preset a boring head for a certain diameter
that's no fun
rough the hole with some other tool, then select the head and do a single boring pass at the target diameter
but it doesnt even have a wifi transmitter
I know there are fancy boring and facing heads with gearing in side - you grab a knurled ring and hold it still, and the boring head moves the tool in or out
jmkasunich: maybe you find a moment to look at http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?JointsVsAxes
seeing how traj runs at the servo rate, why does cartesian position matter in the realtime thread? PID ensures the joints stay on track as well as the computer can keep up anyway
fenn: what are you suggesting? that we do kins in user space?
i'm wondering why kins has to be in realtime
two words: FO
i dont get it
actually there are others - like spindle synced motion, etc
you need to stay synchronised
why does that need kinematics?
fenn: currently planning moves is done in TP
it moves along the carthesian LINE (or whatever it is)
since speed may be changed due to FO or spindle sync, we pass a motion command to RT as "go from here to hear following this path", and let the TP control the speed along the path
alex_joni: it could just as easily move on some weird curve in joint space
"this path" needs to be described in some simple form
fenn: ok, but you have to specify the curve
arcs and lines can, arbitrary curves cannot
well, it would probably be a sequence of lines
I think the main reason is that lines and arcs are easy to express
fenn: how many lines?
one per servo period
fenn: and here you have your problem
so you basicly send points..
why is that a problem? isnt that how it works already?
if FO changes the feed, then the distance traveled per servo period changes, and all your lines go out the window
no, thats NOT how it works already
what is passed to the TP is "go from here to there along a line" (or from here to there along this arc)
that only takes a few bits of data to convey
and then tp does what
the TP then computes a point on that path every servo period
it splits that line into points at each servo period
and then runs the points through kins to generate joint positions
i'm failing to see how this is different
the incremental movement per period can be changed on the fly, since all the individual points are NOT precomputed
fenn: TP only generated the next point
then you aren't listening to us, or you are being thick
if FP changes, the next point which it'll generate will be different
the TP is called ONCE per servo period, and each time it is called it generates ONE point
fenn: these are the complications that differentiate emc2 from a simple thingie attached to USB
they way you picture it can be easily done by simulating through the whole move, and generating waypoints..
but if you slow down or speed up, the waypoints become useless
then sending them to an USB microcontroller, or whatever
(inless your "TP" is going to interpolate between them)
jmkasunich: that method implies no changes while running
not suitable for threading or any other sync'ed moves, etc
you could interpolate between waypoints
fenn: you basicly have speeds/accels hardcoded
if you start to interpolate you might exceed limits
if the local joint transform is so nonlinear that you would exceed limits in one servo period, you'd be screwed anyway
no, I mean if you start interpolating between waypoints
alex_joni: interpolation is theoretically possible, and you wouldn't exceed limits if FO was less than 1.0
you don't have much knowledge what to do..
ok, lowering FO might be ok
raising is a problem though
linear interpolation happens every servo period, right?
jmkasunich: you might still exceed max_accel when trying to lower it very rapidly
the interpolation code would have to handle that - its non-trivial but possible I think
if you assume a microcontroller doing the work.. it might get tricky
one way of looking at what fenn is proposing is that he wants to generate thousands of little lines and queue them to the RT planner
i think planning out the entire move every servo period is a bad idea, that's why they had the trajectory thread originally
fenn: now you are confusing me
fenn: it doesn't plan the entire move, just the next point
wtf do you mean by "planning the entire move every servo period" ?
(well.. it's a bit more complicated during blending..)
it never plans the entire move
jmkasunich: determining if the next waypoint will exceed joint limits
and capping velocity/accel to match
the place you hope to be after 1 servo period
you might as well be speaking a different language if you are going to use terms that aren't defined
we don't "determine if the next waypoint will exceed limits", we compute the next waypoint such that it doesn't exceed limits
there are different 'limits'
and travel limits
right, but if you're looking at a precomputed path you cant make up the path as you go along
thats what we have been trying to tell you
which is why we don't want precomputed paths
i know, but what i'm saying is that if you recompute the path in real-time, at some rate slower than servo thread, ...
why does the rate matter?
and what do you mean by "recompute the path"?
generate waypoints that satisfy joint limits and FO and spindle sync etc
spindle sync changes every servo period
why generate multiple points out into the future that you might turn around and discard?
for a line, the XYZ values for any point along that line can be computed trivially
if X1Y1Z1 is the start point, X2Y2Z2 is the end point, then X = X1+p*(X2-X1), where p is a variable that goes from 0.0 to 1.0 over the length of the line
actually i think i'm thinking wrong. the path should be recomputed in user-space, (or maybe kernel space) not a realtime thread
arcs aren't much more complex
there is no kernel space
user or RT are your only choices
no need for kernel space..
it's more reliable than user space
you would need additional comm's
and wouldn't gain much besides RT space
i'm not saying you should rely on it, it's just a bonus
user space code: premptable
RT code: not preemptable
if your userspace code dies, emc stops
if user space calls a normal Linux operating system call, it may be running in "kernel space", but it is still premptable
i dont care about X11 or whatever
but if you run out of g-code what are you going to do?
wtf does X11 have to do with anything?
you are going way out in left field
there's this myth about the computer completing the part even though X had locked up
if you run out of g-code, motion stops
there is a queue that holds lines and arcs, if userspace dies the machine will still execute all moves that are in the queue
its not a myth
so, you need userspace code for proper function, right?
how big is this queue?
a couple hundred moves
it has to be big enough that even the most fscked up, laggy, prempted user space code can keep it from running empty
at a minimum it should hold a few seconds of motion
since a few seconds of short moves can be many minutes of longer moves, it is quite possible for an entire program or sizable part of a program to be in the queue
there are actually 2 queues
one going from canon to task
and the other one inside motion
lines and arcs is canon->task right?
also, related to the myth: interpreting g-code and queuing up motion is done by task, which is a separate linux process from the GUI, so once the program is started, the GUI can die but if task stays alive the how program will run
does motion do arc interpolation?
and even synced moves along that arc interpolation I think
alex_joni: canon and task are the same process aren't they?
so canon->task->motion isn't really correct
if you are talking about interprocess comms
it's actually task running the interp which calls the canon calls, which puts stuff into the task queue
but all one process
actually I'm mostly sure it's one process
task loop: call interp with a line of g-code, interp in turn calls canon, which queues up stuff in the task queue (not the RT queue), then canon returns to interp, interp returns to task, and the next step in the task loop is to take items out of the task queue and stuff them into the motion queue.... then the task loop repeats, calling the interp again
only the stuffing into motion queue happens only if the motion queue has space available
so effectively the interp/task queue gets way ahead of the motion queue
and probably calling the interp only happens if the task queue has space available
yeah, but that one's pretty big
between the two queues, a lot of motion can be queued
if the GUI dies, task will continue to run the entire program
if you represented the curve as an equation rather than a lot of points, it would reduce the amount of data required
if task dies, motion will continue to run whatever is in the motion queue
hmm. it's a linked list (interp_list), so I'm not sure what the size is..
fenn: yes, exactly
lines and arcs are basically represented as equations
not so easy to do if the curve is arbitrary
especially if this has to run after some nasty CAM program did his optimisations
alex_joni: maybe limited only by memory?
jmkasunich: I might be bothered to look if needed
don't look on my account
I don't care - that queue is only between two parts of the same process
well, if the input is path-o-logical then you cant simplify it no matter what
its not pathological in cartesean space
so that is how we pass it to motion
if it's locally linear in cartesian space it's going to be locally linear in joint space
you can do the same assumptions as you would do in cartesian space (glomming paths together)
it's 1000 right now
or are you inventing terms again
#define EMC_TASK_INTERP_MAX_LEN 1000
say you had a bunch of line segments, all in a line
in joint space it would look pretty much the same, over a short distance
however, if you're next to a singularity, it'll look like a curve
i dont know how short.. that's some magic number that you have to pick
it is a curve in joint space. no matter what
you are trying to pretend that the problem doesn't exist
i'm trying to make some simplifying assumptions so the problem is easier
it is true that for a sufficiently short distance, the difference between a curve and a line is small
but you seem to think just because that is true, that all curves can be represented by lines
fenn: as it is now, it's close to beeing problematic at feeding data from userspace to motion
no, i'm saying if you have a pathological input path, you can simplify it in either joint space or cartesian space
if I have a straight line in cartesean space, I can break it into 1000 straight lines in cartesean space
if we wouldn't be moving little data (lines and arcs parameters), it would be plausible to get into throughput problems
you NEVER have a pathological input path!
huh? lots of little lines is not pathological?
the input path (in cartesean space) is always lines or arcs, because that is all that g-code provides
this is a stupid conversation - you are starting with a proposal that falls on it's face with normal input, then jumping straight to pathological input
prove that it works with normal input first, please
(or admit that it doesn't, and stop wasting time on it)
you started talking about data throughput so i started talking about data compression
we are talking past each other
it sounds like your proposal is to take all input and convert it to pathological input (by breaking it up into tiny slices in user space)
i just think its weird that path planning and PID occur at the same rate
then make PID work faster
would that make you happier?
alex_joni: but then you run into the bogeyman of precomputed paths
why do you think its weird
we cant have that
why run the PID loop 10 times with the same input position?
because it would oscilate nicer
fenn: would you have PID run faster or TP?
PID should run as fast as possible
as jmk said.. it would run on the same data
again, I ask why have PID loop 10 times with the same input position?
so it tracks better
otherwise it's like riding a bicycle with your eyes closed
tracks the same position better?
it might be usefull to get smaller position increments and faster PID
but that means both run faster
the absolute speed is irrelevant here
I'm still waiting for a justification for not having the rates the same
if steppers can run at 40kHz then why can't PID also run at 40kHz?
don't bring steppers into this
because we have this huge path planning algorithm that eats up a lot of time each cycle
steppers are discrete distance, servo rate is discrete time
hmm.. the processor does 2GHz.. why shouldn't PID run at 2GHz ?
that mismatch has its own issues, that have NOTHING to do with trajectory planning
alex_joni: the rate limiting factor is i/o right?
not at all
it's probably for the output from PID
nothing else running, just a PID hal block
but PID itself doesn't have any I/O
how fast can i run the servo thread?
the rate limiting factor is the bandwidth of the external system
I'm considering only real servos here, not steppers, they just confuse things
fenn: I would bet (without trying) that a simple PID hal block is quite able to run in the BASE_THREAD
ok, for high bandwidth, how about a galvanometer
those laser light shows
the servo motor has a bandwidth limit, based on how much voltage you can apply, which limits how fast you can slew the current throught the motor inductance, which means how fast you can slew the torque
you have fast changing motors (like DLP mirrors)
for laser light shows, the "motor" bandwidth is higher, so yes, you can run the PID higher and actually gain something from it
do you agree that it requires kinematics to run one of those?
but for metalcutting machines, long experience has shown that there is little to be gained by increasing servo rate
because you're using a big clunky piece of iron
yes, I am
HSM machines can actually make use of higher PID
a few KHz instead of 1KHz, yes
a bridgeport doesnt need realtime anything
it just needs reliability
sorry, I'm tired of wasting time in this conversation - I have parts to make. If you have a serious proposal, write it up in detail somewhere - there is too much hand-wavium going on right now
now you are either redefining the word 'realtime' or redefining 'reliability', which is it?
reliability is keeping the system going, even though it may stretch the timing a bit
realtime is "this must be done every N seconds, period"
"realtime" = "a guarantee that the code will execute before some deadline is reached" - it doesn't matter if the deadline is measured in uS or weeks
define "keeping the system going" - seems to me that if you miss the deadline for issuing a new position command, the machine is gonna stop at the current position until you do issue a new command
let's say you have a DOS program that does everything it needs to between consecutive position updates
as long as that program doesnt hang, it will eventually update the position
i'd say it's not realtime, because it isnt necessarily going to finish within a certain period
if the update rate doesn't change or hang, it does it under a certain max value
ok, then it's not realtime
but your part might be ruined
yeah you might get a divot where the mill stopped, but it's not going to crash or anything
it might screw your work if you are cutting plastics
anyway, in comparison, the same program run on a HSM might wreck the machine because it stopped in the middle of the program
the more important problem is that a userspace crash of the program that provides new waypoints may leave a cutter spinning at high speed, and in contact with the work
this is a fire hazard depending on the material and time involved
(ie, MDF in an 8-hour run you leave overnight)
i'm not talking about a crash
just non-deterministic computing
uh, damn that's an overloaded word
this will still occur even if you have a RT charge-pump component running, since there is currently no way to monitor the userspace process
crash / "pre-emption" - more same thing with a different time constant
functions that dont complete within a certain amount of time (generally you want this time value to be consistent so you can tune the machine for its optimum performance)
as far as motion is concerned
can I add a comp to 2.2.4 without having the whole source-tree?
I'd bet you can't
comp --install <yourcode>
that compiles it too?
you need the EMC and kernel headers (at least if it's RT)
the easy way is to get the whole source code
yes, that compiles it, but you need the headers
I have build-dep for emc2
you can apt-get source emc2
does emc-dev have the headers?
I doni't know
This package includes files needed to build new realtime components and
mmmmmm - donits
alternate front-ends for emc2
ok, maybe it does :)
I need an 'inverse-deadband' component on the PID outputs
uh - what do you mean?
let me show you a pic
trying to make the output jump from 0 to some minimum?
the servos won't react to a DAC output between around -0.2 and 0.2
that makes the PID loop 'squishy' around the set-point
isn't there a min_output pin? (or am I thinking of PWM?)
err - parameter I mean
there is dac gain and dac offset, but you still go through zero with those I think
awallin_emc: you want to install emc2-dev
then you can comp -install ..
that has the appropriate headers?
I think I have that from yesterday
you can always check with dpkg -l emc2-dev
anyone have a link to the 'comp' html documentation?
[19:14:47] <fenn> http://linuxcnc.org/docs/html/hal_comp.html
are the comments from the source automagically made into a man page?
yes but they need groff formatting
also it includes hal pins in the man page
nice. it compiles. now lets see if it works...
can I then just use "loadrt mycomp"
this is GREAT. the guy who came up with comp must be at least as bright as the one who conceived pyvcp! :)
methinks the pendant buttons will get a special comp and I don't have to learn CL
jepler came up with comp
don't recall who it was on pyvcp.. tomp?
ok, awallin_emc then :P
awallin_emc: sorry for pulling your leg :D
alex_joni: I have a suggestion for halui which I might write to the dev list about
nothing big, just would be easier for the integrator if the feed-override and speed-override had an interface more similar to the jog interface of motion
and that would be?
enable inputs. now I switch between a scale of say 0.01 and 0.0 (disabled)
ah, ok that surely can be done quite easily
are you familiar with 'cvs diff -u > halui-improvements.patch' ?
:) I do emc related things far too seldom to remember such long command lines
awallin_emc: I can always remind you the command lines :P
yay, my inverse deadband component seems to take care of the problem
servo feels much tighter now when twisting side to side
crotchetyGuy: it's CIA-30 in here doing the reporting
* alex_joni kills CIA-30
* CIA-30 dies
so CIA-30 is a program?
a bot .. it's not always the same number
[19:48:02] <alex_joni> http://cia.vc/stats/project/emc
that's our stats page at cia
was it FF0 or FF1 or FF2 that jon elson recommended for his amps?
torque mode control that is
definitely not ff0
I always end up using both ff1/ff2 (but I've never used elson's amps)
now I have P=20 I=200 and FF1=0.1
I like to turn off I in order to see the FF effects clearly
I'm getting around 0.04 of error, or 100 encoder counts
once FF keeps your error low, you can increase I with impunity because it won't tend to wind up
is that .04 mm?
P=0 also when tuning FF?
no, you need the P
yes, 0,04mm if I read halscope correctly. It has 400counts/rev and the screw is 2.5mm/rev
that's pretty good following, but you can probably improve it
this is accelerating to around 6000mm/min in the middle of a 100mm G0 move
that's a nice speed
better take some screenshots and post them on the blog...
what was the screenshot command in ubuntu?
be sure you use a move long enough to get up to cruise velocity, so you see the steady state errors too
poke the printscreen button
does printscreen capture the whole screen? or is there a trick to get just the active window?
alt or ctrl pressed down
I forget which
I know you can set it in the keyboard shortcuts thingy
I usually use Gimp's "file->acquire->screenshot" thing
now the DAC goes to around 8.7 at the cruise phase of the G0 move
I mostly use printscreen, or alt-printscreen
sounds like you better not go much faster then
so I've found about the maximum velocity for the ini file. what about max acceleration, what would be a good test to find that?
try faster and faster accels, watch to make sure you don't saturate the DAC
accel is proportional to torque which is proportional to current
so if you know the max motor current rating, make sure you don't exceed that
(dunno if you can measure peak current or not, got an o-scope? and a current probe?)
yes I could measure the current... is it worth the trouble? if I just see the DAC doesn't saturate. These jon-elsons amps shouldn't be able to deliver the peak current the motors can take
A little FF1 makes the error oscillate in the accel/deccel phases
FF1 should have most effect during cruise
what about FF2?
yes, with FF1 the error was cut tenfold copared to only P
D can help with all oscillations
hmh, FF2 only made the accel/deccel phases much worse
is the sign of FF2 supposed to be the same as for I and P ??
all signs are usually positive
FF2 seems very sensitive
not surprising really
doesn't really improve the accel/deccel phase... perhaps with more mass attached to the motor?
FF2 is the accel term - thats a second derivative of the position command, and derivatives are high-pass filters - they amplify high frequency noise
grep -r -e FIXME-AJ src/* | wc -l
hmm.. those don't seem to decrease :)
now the worst FE happens at the start/end of the accel/deccel phases
i.e. I get mostly zero but four spikes at the beginning and end of the accel/deccel phases
they are one div with the scale set to 20m, so that would be 0.020 mm I guess
ok, so probably something not to worry about atm
you still have the motor on the table.. right?
yes, no load whatsoever
it will be completely different with load
right. maybe stop here then. I'll post the pics so you can all look :)
* alex_joni calls it an early night
good night all
I have some questions about the offsetting code that you've been messing with
going outside, I'll try again later