EMC: 03seb 07TRUNK * 10emc2/src/hal/utils/bfload.c: pulled bitfile opening out to a reusable function
EMC: 03seb 07TRUNK * 10emc2/src/hal/utils/bfload.c: adding some whitespace before I go cross-eyed
EMC: 03seb 07TRUNK * 10emc2/src/hal/utils/bfload.c: look up the boardtype-to-program in the board info table
EMC: 03seb 07TRUNK * 10emc2/src/hal/utils/bfload.c: turn the device_id into a board number (for pci only)
EMC: 03seb 07TRUNK * 10emc2/src/hal/utils/bfload.c: locate the requested PCI board
EMC: 03seb 07TRUNK * 10emc2/src/hal/utils/bfload.c:
EMC: program the device! yay!
EMC: New-style command-lines are now fully supported. The usage output needs
EMC: updating, it needs a manpage, and the old-style command-line needs to
EMC: be deprecated. Its progress output could be prettier.
EMC: 03seb 07TRUNK * 10emc2/src/hal/utils/bfload.c: verify board chip type against bitfile chip type
hey guys anyone here?
i have questions for all you smart ppl
sCOTTo: ask away
i have a customer who is using austocad... he has come to me asking HARD questions.... i need your help....
not sure you'll get any good autocad answers in here, but you can try
he wants to find something - maybe opensource / free - to convert his autocad to either IGES or STEP extension to use with CNC machines.... can you point me in the right direction?
autocad... yes i know - you guys dont use it :)
is it 3D ? or 2D?
not sure but it looks 3d to me.
he is designing a motor or something i think
he has no budget though :(
he should be able to do a save as in acad
he is also a friend - so i want to help him if i can....
I usually use Alibre for 3D (kinda free)
and it exports IGES and STEP
ACAD = autocad
Alibre - is that opensrc?
is it expensive?
but it's free to use
just checked and no on the save as
alex will it open a dwg file?
BigJohnT: yes, but I don't recommend it
it's fine for work on solids
importing 2D stuff is painful
so any other ideas guys?
even if he converts it to IGES or STEP he still has to convert it to G-Code with cam software
all i have is an email...
he lives next door from me i might go chat with him - bbs
sCOTTo: wither way, I think #emc is more appropriate than #emc-devel
(this channel is mostly for development inside emc2..)
I was wondering....
there is also a #cam you might want to visit
BigJohnT: wondering what?
about all the chatter on cad/cam
when EMC2.3 comes out will it be on the 8.n of ubuntu?
emc2.x is not directly tied to an OS
you can run it on whatever you like :)
if we have 8.04 packages and liveCD & so on, by the time emc2.3 comes out, then surely we'll build 2.3 packages for it too
that doesn't mean we won't have 2.3 packages for dapper
[Global Notice] Hi all! It appears we are having some problems making our EU and US hubs speak with eachother, I'm going to do some noisy re-hubbing and hopefully we'll be back to normal shortly! Thank you for using freenode and have a great day!
[Global Notice] Hi all, Sorry about the disturbance there -- all should be back to normal-ish now. Have a good day.
hi, anyone around?
alex_joni: what do you think about a emc-docs package?
fenn: you mean to sepparate the docs?
I'm not opposed
cradek, jmkasunich: let me know when you're around
alex_joni: I'm around right now, but only for a few minutes - I have chores to do this morning
jmkasunich: it can wait for later
I want to discuss how to do homing
(at the task<->motion level)
so I have something to keep myself busy
I wish I had that problem
I have enough stuff to keep me busy for months, maybe years ;-)
well, me too.. but I try to keep myself busy on emc
lately I feel kind of guilty because I haven't done anything for the project
I know how that goes
but I guess we'll strike your pay for the current month
maybe that will make you feel better :)
oh, now I'm poor _and_ guilty
jmkasunich: now, that you've blown your cover ..
I was wondering about a design issue
we can jog joints (incremental, continuous) and axes (velocity mode atm)
should we have a difference at GUI level?
or should GUI just jog the first active thing
and motion decide if it's a joint or an axis
depending on the mode in?
well, from motion's point of view, you are either in joint mode or axis mode
right, I know..
I was thinking to reuse the same EMCMOT_JOG_CONT, EMCMOT_JOG_INCR, etc commands
but I'm not against EMCMOT_JOG_AXIS_INCR and EMCMOT_JOG_JOINT_INCR
I think it would clear up code a bit
if we only have EMC_JOG_CONT and EMC_JOG_INCR
the main difference is that if we do the latter, motion might issue errors like "can't jog axis in joint mode" or "can't jog joints in axis mode"
it would be simpler to just have JOG_INCR etc
ok, sounds good
if the GUI doesn't know what mode the machine is in, we have worse problems than misinterpreting axis jogs as joint or vice-versa
and the pointer to the joint/axis to jog is a simple counter..
0 for joint 0 _or_ axis X
today it works like that, pass a joint number
in this case, it would be treated joint number OR axis number depending on mode
there is another thing
currently for teleop we can supply all vectors
so one can jog in carth. space in multiple directions at once
heh, actually only one direction at a time, but that direction doesn;t have to be aligned with a cartesean axis
ok, right.. that's what I meant
currenty you can sort of do that with joint jogs (but not as nicely)
you can issue a jog for joint 2, then a another one for joint 4, and they sum to produce a vector
but they are not coordinated
that's why I want to discuss this through and find a really good way to do it
what exactly is "it"
so: we have INCR jogging (which is simply an increment in a specific direction for a joint/axis)
INCR, CONT, and ABS
none of the GUIs ever issue ABS, but it exists
we have CONT joggign (which is velocity based jogging - sign determines direction, number for joint/axis)
and ABS for a certain location
they are all implemented as absolute position based
ABS sets the target position to the given value, INCR changes the target position by the given value, and CONT sets the target position past machine limits, so you have to send an abort to stop it
I know, but that's irrelevant for me (I think..)
I'm trying to define a clean interface from GUI <-> task <-> motion
without caring how GUI implements it, or how motion implements it..
are you trying to maintain the "move along this vector" ability that teleop gives us?
here's a thought..
what if a new jog wouldn't abort an running jog?
a new jog on the same axis, or on a different axis? (or joint)
except if there's an explicit jog-stop (implemented as ABORT currently)
on a different joint
you can jog diagonal because it doesnt
ok.. then we're pretty close to the move along this vector
JOG_CONT is stopped by "AXIS_ABORT" today, so other axes can keep moving
I'd say it's pretty close enough
I do agree that I'd rather have JOG_STOP(axis) instead of using the abort
ok, so .. _JOG_CONT (nr, speed), _JOG_INCR (nr, step, speed), _JOG_ABS (nr, pos, speed), _JOG_STOP (nr) ?
ok, sounds easy enough to implement
the hard part has always been keyboard jogging
obviously I'll have to fix all GUIs again (what a joy..)
getting the key release events to work right
I scared myself yesterday
yeah, but that should already be working
my kb doesn't have page up/page down keys (for jogging Z)
changing message names, shouldn't be intrusive
so I hit Z to select Z, then - to jog it down
and you used -/= ?
then I hit down-arrow to move Y
that changed the selection from Z to Y, so when I released -, the Z didn't stop
I was fast enough to the esc key that I didn't crash the tool
* alex_joni strokes his robot pendant
it has 6 pairs of jog buttons
usually I run out of fingers ..
but it's nice :D
any idea why I'm missing 'make' after installing emc2-dev?
yeah, it's not in emc2-dev
you want to install build-essential
sad isn't it - that linux distros are no longer installing build tools by default
now I'm missing stddef.h
awallin_emc: what are you trying to do?
compile vncrec for making the screen video
the compile instructions start with: xmkmf -a
[18:55:55] <awallin_emc> http://www.sodan.org/~penny/vncrec/
no idea why stddef.h is missing
should be in build-essential?
nope, that only holds make & gcc iirc
try an apt-file search stddef.h
(after installing apt-file, and updating)
comes with gcc or linux-headers
fenn: I have bot gcc and linux-headers-2.6.15-magma, but still missing stddef.h
where is it on a properly installed system?
I have it from the linux-headers-2.6.15-magma package
check /usr/include/stddef.h or /usr/include/linux/stddef.h
yep, it's in /linux the script just doesn't search there
a logical link perhaps?
ln -s /usr/include/linux/stddef.h /usr/include/stddef.h
argh. next missing file is stdarg.h
I think something is wrong with that package
where would stdarg.h be ??
can't find it on my system either
wikipedia says it's a standard library...
in libc I think
anyway maybe this screen recording is too complex. point a DVcam at the screen instead :)
libc6-dev is newest version
dpkg -L libc6-dev | grep stddef
that gives me nothing? how about on your machine?
I think stddef is supplied by gcc
I'm just going to forget vnc for now :) doing some hal and halui instead
in HAL, is there the opposite of a mux2? i.e. one input that is directed to either of two outputs depending on a selection bit
sure, use a not and two ands
hm, ok that would work. thanks.
no manual entry for and
hm, it's this edge-triggered vs. level triggered thing again. now I get oscillations with the not+ two ands circuit
basically I want to turn on and off coolant with one pushbutton
yes, but then the toggle output needs to go to halui.flood.on and halui.flood.off depending on the current state of the coolant
you can do it in CL with edge trigger. are you already using CL?
no, I haven't looked at CL at all
-|is on|---|^ button|----(turn off)--
-|is off|--|^ button|---(turn on)--
the toggle works just fine in HAL
would think that based on this working bit signal in HAL I could set the coolant state with halui?
I bet halui triggers on rising edge.
I guess halui gives the order to set coolant on, and before is-on goes up another call to the not+2ands is done and that sets coolant off
you could hook toggle.out->on, /toggle.out->off
by / you mean not?
ah, that works. good. only thing was I get a warning about flood-off cannot be set while machine is not on as emc starts
except you have to press twice if the coolant state changes from MDI or AXIS
toggle is the wrong thing to use isn't it
will you have more stuff like this? I bet ladder really is the easy way to get what you want
it has state, which goes wrong if I control coolant from outside halui
right, it shouldn't have state
(promise it's something simple :P)
was wondering if it's much trouble/overhead to add another branch to the CF
* alex_joni eats CIA-30
* CIA-30 tastes crunchy
EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/nml_intf/ (emc.cc emc.hh emc_nml.hh emcglb.h): started changing jogging NML commands (EMC_JOG_CONT, EMC_JOG_INCR, EMC_JOG_ABS and EMC_JOG_STOP)
EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/usr_intf/ (halui.cc keystick.cc shcom.cc): started changing jogging NML commands (EMC_JOG_CONT, EMC_JOG_INCR, EMC_JOG_ABS and EMC_JOG_STOP)
EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/usr_intf/xemc.cc: started changing jogging NML commands (EMC_JOG_CONT, EMC_JOG_INCR, EMC_JOG_ABS and EMC_JOG_STOP)
EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/nml_intf/emc.hh: fix function names for jogging
EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/task/ (emctaskmain.cc taskintf.cc): changed jogging NML commands (EMC_JOG_CONT, EMC_JOG_INCR, EMC_JOG_ABS and EMC_JOG_STOP)
EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/usr_intf/axis/extensions/emcmodule.cc: update AXIS for changed jogging NML commands (EMC_JOG_CONT, EMC_JOG_INCR, EMC_JOG_ABS and EMC_JOG_STOP)
regarding the toggle coolant thing:
currently halui has input pins that say "turn FOO on", and "turn FOO off"
perhaps it needs an input that says "toggle the state of FOO"
jmkasunich: should I touch motion? or will you ? (regarding the jogging changes..)
alex_joni: I just sat down here after yard work and dinner, let me catch up ;-)
heh, sounds nice
ok, I see new NML stuff
mostly name changes
the next step is changes in emc/motion/usrmotintf.cc and corresponding changes to command.c, etc?
I think the commands in command.c are about right
or is there another layer in there that I'm missing?
EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/motion/ (command.c motion.h): remove *teleop_vector*, those will be handled by regular jog messages (with motion controller in TELEOP mode, not in joint mode)
EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/nml_intf/emc.hh: remove *teleop_vector*, those will be handled by regular jog messages (with motion controller in TELEOP mode, not in joint mode)
EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/task/taskintf.cc: remove *teleop_vector*, those will be handled by regular jog messages (with motion controller in TELEOP mode, not in joint mode)
jmkasunich: I think you meant taskintf.cc - I think I'm done with that
taskintf.c isn't in the emc/motion directory
usrmotintf.cc is generic message handling
now all jog commands from GUIs arrive at motion as: EMCMOT_JOG_CONT, EMCMOT_JOG_INCR and EMCMOT_JOG_ABS
the specific messages must be in taskintf.cc
yes, the EMCMOT_* names were quite good, so I didn't change them
you added NML messages for JOG_STOP
I only changed the name of the functions that send those to shm, the NML that triggered that functions, etc
actually I renamed JOINT_ABORT() to JOG_STOP(), as it was it's only use..
btw, initially it was called AXIS_ABORT()
did you touch the EMCMOT side of that one?
it's still EMCMOT_JOINT_ABORT I think
I need to get a checkout of joints_axes branch
you were wondering about putting that on the compile farm, right?
I think the fastest is to copy your TRUNK
and cvs up -rjoints_axes
works way faster then a fresh checkout..
a complete checkout only takes 5 mins or so, maybe 10 tops
ok.. takes a bit longer here
(the docs are mostly the issue I had..)
hint - use -z9 instead of -z9
* alex_joni is obtuse at this hour
better compression - it helps on a bandwidth limited transfer - there is plenty of CPU at the other end for doing the compression
what's the difference between -z9 and -z9 ?
-z9 vs. -z5
ah, ok ;)
brb, gotta get some food ..
looks like only 3 mins ;-)
emc/task/taskintf.cc:60: warning: ‘emcmotAxesInited’ defined but not used
emc/task/taskintf.cc:82: warning: ‘localEmcAxisUnits’ defined but not used
yeah, I know about those
left them as a remainder mostly
there are a couple of things I haven't thought through yet
for example : canon needs carthesian limits (velocities and accels) when it gets commands from interp
should we have those defined in the ini? or should they get computed from joint limits and kinematics?
do you really think I've thought about that?
no, I'm sure you haven't
I don't think in the general case you can compute them from joint limits
(just bringing it up now, so we can both sleep on it for a couple of days/weeks)
no, but you can probably compute them for a specific move
I don't see how
say you have a linear move, running that through kins should give some max joint speeds, then scaling eveything so that the resulted joint speeds don't exceed the defined limits
unless you are actually gonna evaluate lots of points along the move, before you actually queue the move
basicly you need to simulate the move in userspace
jmkasunich: I'm not sure there is another way
like I said, IMO there is NO way
and I'm pretty sure we want to do this in userspace
because simulating the move in userspace is just so fscking ugly that I consider it not a way
not do the simulation in RT, with deadlines knocking on the door
the userspace sim may be the best way to do joint constraints, but I was planning on quietly ignoring them
jmkasunich: obviously I am a bit biased, by taking a peek at the robots I work with..
but they work like this..
(oh, and they have no FO :)
thinking about it a bit more, and it probably is the only reasonable way
as I said, I only meant to bring it up to attention
I'm sure we won't fix it tonight..
but having an idea/problem in the back of my head, sure helps sometimes
after a while it becomes obvious :D
I wish the parts I need to run were "start the program and do something else" parts
but they need watched - applying cutting fluid, and changing tool
don't feel to bad.. I need to sleep too :)
(the sim configs seem to run on the branch)
go to sleep, I'll try to get the parts done, then think about some code
I'm not sure they use the proper joint limits (accel/vel, etc).. but it's useable for testing codechanges
I'll work on the ini part some more, when we have an idea what to expect there..
I wouldn't haved imagined that one day I would enjoy working with NML messages
it's quite fun actually
good night all
alex_joni: thanks for all that work. it's really coming along.
jepler came up with breaking up the move in userspace and deriving cartesian constraints. I like this because it doesn't change anything in motion/tp. I think it's ugly too, but if there's only one way to do something, and you want to do it, that's the perfect way.
oops, I meant jepler ALSO came up with that scheme