I've got an interesting problem with the tolerance for cutter comp concavity.
Posted an image to http://imagebin.org/7368
Left half is what I expect with a current system and one inch tool.
right side is using G64P- ?
Right side was made with essentially the same gcode but greatly expanded tolerance in the compile.
both use g42
what do you mean tolerance in the compile
let me find the file.
#define TOLERANCE_CONCAVE_CORNER 0.05
if that really is radians that should be a couple degrees.
you're saying you changed that number?
I don't understand what you're trying to do, please explain
by enlarging that number, you made it think the arcs aren't necessary to go around the corners
I thought that this variable was the tolerance for a concave corner during cutter comp.
you're trying to allow it to not error when it meets a concave corner?
I looked into doing that - there is no number that you can tweak to allow it - it really requires a different algorithm
not a total rewrite, but it would be pretty significant
Why then this name for a variable and why did Rum;ey bring it out to an ini var?
If it has no useful effect.
it might be possible to very slightly tweak it
I'd have to study the code to be sure
I was more than slightly tweaking.
you're wanting it to be able to (for instance) cut inside a square?
(that's the kind of thing I've wished for)
Well not me but a customer.
unfortunately it would be a significant rewrite to allow that
IMO a part code writer ought to get it right.
otherwise emc has to guess
imagine cutting inside a square where you expect a (real) square part to fit
you have to do something else then (cut into the sides)
I suspect that, usually, people want it to leave the radiuses and just continue on
(and I wish there was a simple tweak to allow that)
don't use comp and just cut a smaller pocket?
yep I guess so
do you know what other controls do?
I believe that flashkut ignores the issue completely.
concave corners issue.
I don't know about professional controls.
so it leaves the radiuses behind but cuts correctly otherwise?
it's actually kind of hard to get that right - imagine scissors closed on a pencil - depending on the angle, the pencil may be a long way away from the pivot of the scissors
so you have to stop and turn the corner way before the end of the programmed move
I can run a slightly concave corner with the existing.
emc has no provision for this currently - it always cuts until the tool touches the end of the line
rayh: I think it actually cuts into your part a bit when you do that
I wouldn't be surprised but that it gouges right at the corner.
yep I'm sure it would
how much of a corner does it allow?
I just ran 0.01 over an inch.
that tolerance should be set so it's "not much of a corner at all"
didn't figure the angle.
just took 0.015
less than 2 degrees
err, my trig is wrong
my trig is always wrong
ok, there it is I think
that's 2.3 deg
I bet .06 doesn't
ah 0.6 trips.
good bet. get any lotto tickets today?
yeah that's past the cutoff which is about 2.9 degrees
nope, lottery is "math tax" as far as I'm concerned
(tax just for people who don't understand math)
It does make an interesting tool path.
interesting good, or interesting bad?
the code is
I suppose that what happens is that the line from y1 to y2 is gouged all the way to the end.
yes I think it is
that tolerance is too high, I bet someone changed it without understanding it
I saw it that way as far back in the emc code as some of fredp's commits
This uses an angle tolerance of TOLERANCE_CONCAVE_CORNER (0.01 radian)
this comment in interp_convert.cc shows it was probably originally 0.01
ah I didn't notice that.
It's odd though that it shifts outside corner stuff as well.
that tells it to assume the lines are pretty much parallel, since the angle it finds is within the tolerance - so it skips the arc that usually would go around the corner
sure enough I recompiled with 0.1 radian tolerance and it will go around 0.06
but not .11
rayh: I just noticed in the comment in interp_convert.cc it explains the three things that tolerance does
Okay let me look.
cradek: want a change of topic? (I'm looking to brainstorm with somebody about 5i20 stuff)
jmkasunich: actually I'm about to go find something to eat
what I really want is to get peter wallace here, but he seems to be IRC impaired (or maybe just busy)
yeah, that would be nice
maybe a phonecall (arranged in email) is warranted
I'd have to get my ducks in a row first though
my cell has "free" (read: prepaid whether you use it or not) long distance
some of what I want to talk about is really not peter stuff anyway since it is about how HAL presents the stuff to the user - he's not very familar with HA:
sometimes I use that, but of course it doesn't work very well compared to wires
I'm not worried about the phone bill
too bad swp is away - you guys design stuff like that well together
go get food - I might ramble on a little, or I might go back to coding
the issue is load time config - the new config has 72 pins of general purpose IO
and it overlays special functions like stepgens over top of that
at load time you have to say "I only need these 4 of the 8 stepgens, leave the other pins as IO"
and in fact, "IO" is too simple...
in? out? if out, should it be open collector or regular drive?
IMO the problem with 5i20 is in the name "anything IO"
one firmware could optionally do all these things?
one firmware can do a pretty big pile of things
maybe 8 stepgens, 8 encoders, and 8 pwms
I like the flexibility but it is darn hard on configuration and running within hal.
this kind of thing is just plain a pain in hal
actually that seems to me like a problem with hal, not the mesa card
too much flexibility?
that you have to represent the configuration, no matter how complex it is, with a string at load time
like cfg="IIOOioioio eieio" in the 8255 and stg? drivers
glad you got the reference :-)
a gui configurator would allow you to pick the valid combinations of inputs/outputs/pwms/quadratures (by greying out things maybe?)
there is another approach, which is to have many fpga configs
don't we already have several in trunk?
recently added I thought
no, only the one
4 axis host based motion control
H4MOT or something like that
there's a m5i20 dir with various things: hostmot5_4, 5_8, 5_8eh etc?
maybe, but I believe only one "compiled" bit file
ok, maybe something is partially done
could be wrong, lemme check
I didn't mean to derail
oh, there are more
but I don't think the driver understands them
we (pete and I have been swappind emails) are planning on a 256x32 ROM in the fpga to tell the driver what the fpga config can do
(apparently thats actually quite cheap in gate terms)
format completely undefined at the moment
we don't have backwards compatibility with the existing hostmot4 config as a goal
there can be a new config that works exactly the same for the user (who only sees the HAL driver pins), but supports the ROM and such
originally I was thinking that there would be no load-time options, because any particular FPGA config would be fixed (no gpio overlayed on unused steppers, etc)
in that case, the driver reads the ROM and exports whatever the config contains
very similar to the PPMC driver
with Jon's stuff, you connect up the board(s), the load the driver and it figures out what you got
hmm, when the screen is full of me talking and nobody else, its time to be quiet
I feel like I don't have much to offer, I think you and peter are the best ones to work it out
rayh: the "anything I/O" part is probably the thing I like best about the 5i20, and at the same time probably the thing that some users will like least
you're saying the 5i20 would tell the hal what it is when it starts.
if the 5i20 was just another motenc, where you get what the vendor gives you, I would have _never_ bought it
from this ROM area
Exactly. I like the idea of running more than one with different configs
if there are no load time choices to be made, things can be pretty simple
but also limiting
if you have 8 stepgens, they will use up 16 I/O pins, even if you only need 4
so pete figured out how to configure the fpga such that you can say "I only need 4 stepgens, turn the other 4 off and let me use them for general I/O"
but - how do we tell it "I only need 4" (or 3, or 7, or...)
pete figures he can stick 8 stepgen, 8 encoder, and 8 pwm (dac) in there
that sounds like cradek's startup string.
stepgen: 8 x 2 = 16 pins, encoder: 8 x 3 = 24 pins, pwm/dac: 8 x 2 = 16 pins
if you _can't_ turn off the ones you don't need, there isn't much gpio left
right, cradek's startup string
which we all agree is ugly
Yes ugly in execution (the string) but not ugly in conceptualization.
what I'm hoping to brainstorm on is a less ugly implemntation of the concept
like the config GUI that cradek mentioned
imagine 72 little drop down boxes
some would have "input, output, step", some would have "input, output, dir", some would have "input, output, encoder-phase-A"
you decide what is gonna be on each pin
If there were a way to config bunches of them at the same time. Like encoder1 takes this set of 4
encoders take 3 I think, phaseA, phaseB, index
but even there, if you aren't using index on a particular axis, it would be nice to use that pin for I/O
3/4 doesn't matter - I understand what you meant
That was my bitch long ago with an 8 axis stg card.
very hard connected.
hard connected is the best way to cram lots of stuff into a little space
you decide exactly what mix YOU want and build a fpga config to suit
but we don't want average (or even advanced) users to have to mess with FPGA configs
Not me for sure.
if something like the 8step/8encoder/8dac config (plus the ability to convert unused stuff to IO) covers 95 or 99% of people, the ones that are left can do custom configs if they really want to
but without that ability to convert unused stuff, one config will NOT cover that many people
maybe only 50% or something
I'd think it should cover any tasks I can imagine for the board.
I'm trying to visualise the config tool
This level of configurability will cause some issues with his secondary boards like the 7i33 but that is not our problem.
but if well thought out, maybe not too bad
Drag and drop blocks that you stack up or down from 1 to 72
if you are gonna put 8 pwm/dacs in there, put them in the cpinout that the 7i33 wants
That is the correct way to think.
the fpga isn't _that_ flexible
In fact one of those blocks or chunks could be a 7i33
well, a single fpga config isn't that flexible I should say
another a 7i37
actually, a drag-n-drop tool that generates vhdl code for a custom config would be really cool, but beyond the scope of this conversation
Gotta run. Maxine is calling.
good talking with you. good luck with the brainstorm.
* jmkasunich rambles on some more, to give cradek something to read
stepgen.0 - checkbox, if checked, p0-00 and p0-01 are stepgen.0.step and stepgen.0.dir respectively
if unchecked, p0-00 and p0-01 are separately configurable as inputs, outputs, with open collector, etc
likewise, encoder.2 checkbox, if checked, would maek p1-06, p1-07, and p1-08 be encoder.2.phaseA, encoder.2.phaseB, and encoder.2.index
I feel like I shouldn't have mentioned guis - unless we're going to gui anything, a gui just for the mesa card is very out of place
maybe, maybe not
there is a user space utility program for loading an fpga config
and I wouldn't object on principle if Jon E wanted to put a self test program for his boards into CVS
sure, it would be nicer to have a "configure EMC" gui instead of a "configure the 5i20" GUI
but I'm more inclined to work on the latter (even if it wasn't going to go into the EMC cvs tree)
I do see that sometime in the future; until we have that, maybe a fixed m5i20 config is more appropriate
we already have a fixed m5i20 config
its made for analog servos though
a second one for steppers then
could be done
6 stepgens, one encoder, the rest is IO
not gonna scratch my personal itch though, so something beyond that _will_ happen, because _I_ need it
why only one encoder?
I want spindle and jogwheel
well you have to pick a number
jogwheel can be done easily on the IO
sure, I could count the jogwheel in sw, but I don't wanna
* cradek shrugs
I didn't buy that board to have my software counting encoder pulses
I thought you bought it to make a mill-drill-lathe work
this is where we have different ways
nothing wrong with that of course
that means an encoder on the lathe for threading, and one on the mill someday for rigid tapping, and the jogwheel (or maybe two, so I can do X and Y without pushing a "select axis" button, and don't forget the spindle motor encoder (its much easier to control a AC servomotor with an encoder, and the motors have them,,,,)
if all I wanted was what you described, Jon's board would do the job
three stepgens and three "encoder" counters for feedback and a fourth encoder for threading
we're on a tangent, and it's my fault
its not really that bad of a tangent
your point is valid - load time config sucks for most users
in fact, if I made a custom FPGA config, then I don't need load time config
I think you and peter should make the flexible 5i20 driver as good as you can ... the load time config can be as nasty as necessary - later when we have gui config, it will be nicer
I'd use that ROM block, so even though I have a custom config, the same HAL driver would export the right stuff
you'd really rather have me talk to SWP about this wouldn't you ;-)
sometimes I just need to bounce ideas off of someone
I'd try my wife, but A) she cares even less than you do, and B) she's sleeping
I really suck at big pictures
they don't interest me really - but you are the opposite, you never think "I want to get the machine to do X by writing the fewest lines of code possible"
that's what I always do
projects need people like both of us - they fail if there's only one type or the other
I just had an idea (see, we weren't even talking about the techincal issues, but it still helped my brain....)
I was just thinking about the two situations
1) the ROM tells the driver "here is what you got, export stuff and get on with it"
2) the ROM tell the driver "here are your options, decide what you want"
1) is cleaner for the driver, but requires more FPGA configs
does this card keep its program or is it programmed every time?
needs reprogrammed after a power cycle
not after shutting down EMC or realtime tho
I don't understand the point of the rom then
why not program it every time if you have to program it sometimes?
programming the FPGA means "downloading a binary file to it"
that binary file would include the ROM content
creating the binary file (if you want a custom config) is a whole nother level
with xilinx tools, etc
I mean the download
every config that we supply would have ROM contents that tell the driver what it has
you lost me
if you're doing the download, why do you then have to read part of it back to determine its capabilities?
download is "bin/m5i20cfg <name-of-the-bitfile>"
loading the driver is "loadrt m5i20"
oh the download is not part of emc or hal?
today, there is only one config, and the bitfile is stored as a 160Kbyte array in the source code
not a good idea even with one config - thats a lot of kernel memory
completely out of the question if you have half-a-dozen configs
why does it have to be kernelspace?
it doesn't, but if you want to load the driver and the bitfile with one loadrt command, then it does
ok I see
today's driver actually has a insmod param that says "load", or "don't load"
so if you had some custom config (not in the big array) you could load it with the user space tool, and then load the driver
of course today's driver wouldn't understand the custom config...
I'm thinking about getting the bitfile completely out of the kernel space driver
you always use the user space tool to load your config, then loadrt the driver
and it uses the ROM to figure out what is in there
paul said something about there being a standard way to load firmwares - but I never know if he's trying to help or trying to troll - do you know what that's about?
he's probably doing a little of both
I bet there is a preferred way
might be worth a look
I'll probably google
but how the fw gets loaded is a side issue
we've digressed from my oh-so-wonderfull idea that I was explaining
yes and no - it's relevant when deciding how many it's reasonable to have
1) ROM says "here's what you got, deal with it"
2) ROM says "here are your choices"
key point - the ROM is actually a RAM that is inited by the VHDL code, but its not hard to make it writable
so - standard configs fit under catagory 1, and thats all the driver will ever deal with
later, do catagory 2, and have a user space utility that explains your choices, and lets you make your decisions, then writes them back to the rom
after that, you load the driver, and it does catagory 1 stuff
so you will want both schemes?
hmm, I already see a problem... the first time it will be nice to load the fpga config, then open this tool and "tweak it" before loading the driver
after that though, you'll want to skip that step
the "tool" could even be a form on a web page
I would prefer catagory 1 - the FPGA is what it is, and the driver simply makes that stuff available in HAL
but that is gonna be very limiting unless we have lots of configs
if the configs are simple 16k files on disk, you can have 100 of them with no problem
pete knows how to make configs that can be easily tweaked (disable unused stepgens/encoders/pwms and use the pins for IO)
somebody has to write the vhdl and feed it through the xilinx toolchain for those 100 configs
if it wasn't for that, I'd be planning for a "config tool" that exports VHDL and builds you exactly what you want, and then uses the ROM to tell the driver about it
that would be cool actually
yeah, for people with the toolchain, and the patience to use it
I sure don't want to be helping rafa troubleshoot his vhdl
there is a good chance I will (some time down the road) do the vhdl generator
(its not like I have to generate generic vhdl, it would mostly be calls to stuff that is already defined)
it looks like linux firmware loading is done using the hotplug subsystem
oh right, I have a wireless card that does that
you know how much I want to replace a perfectly working user space firmware loader with something that requires me to learn about linux hotplug support?
I think I'm gonna focus on step 1
ROM tells the driver what the FPGA has - no load time options
step 2 is redo the current rom to use that?
step2 is to allow a config that can be "tweaked" without having the Xilinx toolchain
load the config as normal, then run a user space config utility to tweak it (which means modifying the "ROM" contents)
then load the driver and it uses the modified rom to do its thing
still has the problem of having to tweak the config every time...
the nice thing about doing step1 first is that I don't have to solve step2 right now
I'm thinking one 32 bit ROM value for each physical pin
and some coding
#define PIN_IS_OC_OUTPUT 0x0001
#define PIN_IS_NORMAL_OUTPUT 0x0002
#define PIN_IS_INPUT 0x0003
#define PIN_IS_STEPGEN_DIR 0x0004
other fields in the 32 bits would have the stepgen number, etc
hmm - if there are less than 32 possible things a pin could be, it could be a bitmap
then deal with step 2 by having another 72 words, that contain all the possible options for that pin
don't forget a rom spec version number for when you want to change the rom spec
the config tweaker would let you choose one of the possibilities
each connector on the board has 24 pins, so 24 words
maybe the very first 8 words would be global stuff, like rom code version etc
then 24 pin codes, 8 empty, 24 pins, 8 empty, 24 pins
if they really are planning a board with 4 connectors, just add another 32
thats 128 words
peter says the memory holds 256
so there could be the actual, and the options
heh, I am seriously liking this split between "driver gets data from ROM and exports" and "some undefined tweak method modifies the ROM"
sometimes partitioning the problem really helps you get started
if we decide that load time params do have benefit, then they would just modify the ROM, the rest of the driver remains unchanged
and of course, unmodifiable configs can easily be tagged as such (most configs probably would be unmodifiable)
time to start coding
thanks for listening
* alex_joni wanted to talk about INI and Joint vs. Axes
jmkasunich: good you're around :P
I don't want to talk about that
I know ..
(was just kidding)
I'll start a wiki page with some ramblings
I saw the talk about 5i20, sounds like something nice
I like the ROM approach
overnight though, I had second thoughts about deferring the "step 2" stage, where people can say "I only need 4 stepgens, turn the others into general purpose I/O"
I read about step2
so you want to do it now I take it?
if I can figure out an approach that doesn't suck
seems yet another user benefitted from the SMI fix
* jmkasunich catches up on mail
this was a german user, on a forum I read once in a while
this is kinda cool -- every key on my keyboard is also exposed as a HAL pin
linux /dev/input/eventN is cool
you have hal pins like kebyd.A ?
jepler: normal keyb or USB?
alex_joni: normal keyboard
21699 bit OUT FALSE input.1.key_a
can't seem to find the key that corresponds to that one
are they active all the time? or only when some particular window has focus?
all the time
linksp input.1.key_c => coffemaker.start
this is like the hal_joystick driver, but one more level of genericness -- anything that appears in /dev/input
otherwise you'll get an error about no signal called 'input.1.key_c'
actually using keyboard keys that way seems dangerous
although it could be handy for some simple testing
[18:07:02] <alex_joni> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?IniChanges
link keys to digital I/Os and blink leds as you type
jepler: I wonder if it would work with a second keyboard
alex_joni: yes I think it would work with a USB keyboard
one that doesn't produce letters to linux, just the HAL keys
I haven't used it, but there's an option to get exclusive access to the device
don't want to do that with your main keyboard I don't think
that "takes away" the events from anything else that might try to see them -- the X server seems to do this with my laptop touchpad
guess you don't want that if you have only one :D
I haven't enabled that functionality in my hal module yet
(there's always ssh.. but still)
alex_joni: in the last line on that page, I'd suggest changing the name from [AXIS_n] to [JOINT_n]
that's what I meant .. I'll write it out
iow: "the current [AXIS+n[ sections will be renamed to [JOINT_n], and will refer actually to joints
of course, that will have 3000 users all confused
I know :(
we could have the emc2.2 install script do sed /[AXIS_/[JOINT_/ on all the ini files ;-)
or better - do it in the emc run script ;-)
that's not the only thing is needed
I was (at least partly) joking
its not usually considered nice to modify peoples ini files
well.. if they are old users they should be used to it
older EMC always changed the ini
I know I get pissed when update-grub changes comments in my menu.list
I'm still trying to decide if we should treat trivkins as a special case or not
thats a tough choice
the purist in me says no
the realist says we'll make life easier for many users if we do
(and thus make life easier for us because of support issues)
yeah, I think the current way is kinda good enough for trivkins users
except the ones that are lacking an axis
well that just plain needs fixing
I wonder if we could help the confusion by having names for joints
names that do _not_ overlap axis names, unless somebody insists on setting them that way
or [JOINT_0] NAME=BASE ?
for example, a btport can have knee, saddle, table, and quill
guess you can write that there even now, and noone will complain :D
I see little use in having the AXIS_ in the ini file
joint names would be freely choosable, axis names would not, they'd have to be one of X,Y,Z,A,B,C
you can ALWAYS have X,Y,Z,A,B,C (as per g-code definition)
but if you want axis_1 to be A, just do that
nah.. I'd rather do it like this: (for trivkins)
that only works for trivkins
that's what I said before the example :)
I'm just rambling here, so this might not make much sense, but...
* alex_joni is also rambling..
generic kins has axis[n] on one end, and joint[m] on the other
the limit of both n and m should be configurable
or maybe not
maybe n is always 6
but you can turn off display and processing of some of the letters
axis[0-5] would _always_ be X,Y,Z,A,B,C in that order (so the kins math doesn't get busted)
right, that's what I said before
(or tried to anyways)
but [JOINT_0] AXIS=A should actually be [JOINT_0] AXIS=3
then it should work with the gantrykins jeff wrote
jepler: hope you don't mind if I name that userdefkins.c and commit it once it's working properly
I guess if you're using trivkins then X,Y.... can be aliases for 0,1,....
jmkasunich: those are details, less important now
they can probably be missing
what is this userdefkins?
if its for a gantry, why name it userdef?
a trivkins, where you can setp some hal parameters
it's more general then gantry
you have one param for each joint
is gantrykins.c somewhere where I can take a look?
and the value of the param is the axis it refers to
[18:25:27] <alex_joni> http://axis.unpy.net/files/01162326817/gantrykins.c
(jeff called it gantrykins, because you can make 2 joints point to the same axis)
so its a patchboard
it would work directly with the [JOINT_0] AXIS=0..5 above
but it doesn't really address the gantry issues
only part of it
but that's why I want to call it userdefkins.c
if we decide we like the [JOINT_0] AXIS=n stuff, it should NOT be implemented in a kins module
maybe it can even be trivkins
jmkasunich: why not?
if we do that, we implement it in the core code
that way _any_ kins module can be used with any arrangement of joints
jmkasunich: I don't say we need to change _only_ the kins
surely LOTS other places (task, motion, etc) need fixing too
but I would like to see that kins too
so lets not go putting userdefkins into CVS until we know what path we want to take for the rest
jmkasunich: I said when I have it all working
including the rest of the ini changes :)
probably at least a month away
anyways, sidetracking again
theres another issue with gantrykins
if you can map two joints to one axis, which one is used for feedback?
the last one
heh, guess there are a number of different solutions to do that
this is the simplest one, whoever needs a better one would have to write a different kins module
the real problem is that gantrys need custom joint behavior, not just custom mapping of joints to axes
e.g. max(j1,j2) or min(), or furthest away, or avg(), or whatever
jmkasunich: I agree, but that's a different topic I think
homing is a joint behavior, for example - but if you home only one side of a gantry , you are fscked
although we want to keep it in mind when specifying the ini layout
gantry is one of the test cases for any concepts we come up with
ok, so if the layout fits gantry, trivkins, puma, lathe, you're happy?
add a paralle kins machine like hexapod, and then I think I'm happy
(parallel kins have the same homing issues)
in fact, gantry is a special case of parallel kins
(never thought about it that way, but its true)
in some ways its simpler (no complex math) and in other ways its harder (more constraints on the two parallel joints) than a hexapod
don't think there are more constraints
if you move a strut on a hexapod it breaks just as easily than a gantry
hexapod: 6 joints, 6 DOF, you can always move a single joint (as long as you stay away from discontinuities)
gantry: 4 joints, 3 DOF, if you move a single joint you can bend things
if you stay away from discontinuities, yes, I'm sure
I thought with hexapods you also have points where you can bend things
disc. .. right
maybe disc.. is the wrong word
places where the math goes wonky ;-)
nm, I got the idea
there are some for puma-typed robots too
e.g. joint 4 & 6 parallel
even scara has one
which way the elbow goes
btw, I placed a bit on that scara I foung
sorry.. my typing sux
but there seems to be a catch there
they have a 'reserve price' which the seller sets
and if the auction doesn't reach that, they don't have to sell
so there will be no great bargain
usually they contact the highest bidder to try to close a deal after the auction
and if the seller overestimates what its worth, it might not sell at all
my guess is they expect something around 5k EUR
my bid was .5k
I assume your bid is a lot lower?
you are basically looking for a toy? or would you use it for your job somehow?
still 3 days to go, but I hope there won't be other bids
I plan to play with it a bit, and maybe sell it to a university or such lateron
but don't want to spend more than 1k
its a shame you aren't over here
I agree it's worth more.. (robot+control+..)
jmkasunich: why's that?
[18:45:33] <jmkasunich> http://www.hgrindustrialsurplus.com/search-products/product-detail.aspx?id=01-968-010&searchtable=1&sortExpression=&SortASC=&pageSize=50¤tPageIndex=0
[18:46:19] <jmkasunich> http://www.hgrindustrialsurplus.com/search-products/product-detail.aspx?id=40-727-005&searchtable=1&sortExpression=&SortASC=&pageSize=50¤tPageIndex=0
yeah, slightly different condition :)
another one, same price
oh, you want it nice and clean?
picky aren't you?
this one I found is 1999, nice and clean, etc
here's a nice scara, pretty clean, $699
[18:47:12] <jmkasunich> http://www.hgrindustrialsurplus.com/search-products/product-detail.aspx?id=40-948-186&searchtable=1&sortExpression=&SortASC=&pageSize=50¤tPageIndex=0
well, a little goopy about the base, but...
and no control :D
but lots of nice stuff..
[18:48:13] <jmkasunich> http://www.hgrindustrialsurplus.com/search-products/product-detail.aspx?id=20-455-046&searchtable=1&sortExpression=&SortASC=&pageSize=50¤tPageIndex=0
that one looks very nice, and really cheap
* jmkasunich is tempted ;-)
just what I need in my basement, right?
you need to control those motors.. but I guess you know a bit about that :D
I wonder how big/heavy it is?
* alex_joni suspects AC servos with resolvers
and what kind of motors
at least the SONY I found must use something like that
that one was 35kg
bet you can pick it up yourself
that base its sitting on is probably another 35kG
how does 5200mm/sec with 2kg payload sound?
that sounds like AC servos to me
the R axis (we called it C) does 1200 degs/second
[18:50:51] <jmkasunich> http://www.hgrindustrialsurplus.com/search-products/product-detail.aspx?id=03-956-006&searchtable=1&sortExpression=&SortASC=&pageSize=50¤tPageIndex=0
big robot for $299
hmm.. google says I'm off by 400lbs
that $299 scara is interesting
wish there was something in the pic for scale
its an Adept, but no model number
heh, no.. the EX100 is exactly 1500kg heavy
guess my guess was spot on
100kg payload though
brushless AC Servomotors
the adept is probably 250kG or so :-(
looks a lot like this one: http://www.adept.com/products/details.asp?pid=22
the pic at HGR shows a couple of eyebolts for lifting - thats not a tabletop robot
* jmkasunich loses interest
not that big
not by industrial standard
but big by basement standards
not ba garage standards
my garage is below 0C right now
you need a bigger basement then
* alex_joni suggest a shovel before the scara
no, I need a smaller robot
if I had one, I'd want to be able to bring it to the CNC workshop, etc
something like this: http://www.adept.com/products/details.asp?pid=62
here you have a reference: http://www.hgrindustrialsurplus.com/search-products/product-detail.aspx?id=41-102-002&searchtable=1&sortExpression=&SortASC=&pageSize=50¤tPageIndex=0
as long as I'm dreaming, might as well go for this one: http://www.adept.com/products/details.asp?pid=49
jmkasunich: take a look at this one: http://www.goindustry.com/offerfiles/1073000/1073923_4.pdf?TimeStamp=0x0000000015040045
how much $?
that's the one I'm bidding for
sure seems nice, doesn't it?
[19:03:09] <alex_joni> http://www.goindustry.com/offerfiles/1073000/1073923_2.jpg?TimeStamp=0x0000000015040041
seems it belonged to an Ericson factory in sweden that got shut down
they had 500 cells like that
each more than 20k EUR when new
the bid is for the entire little cell?
no, I don't think so
only robot, control and pendant
well, I wish you luck winning the auction
winning is not the problem :D
I feel I'm gonna win it, but getting the robot is a different thing
reserve price thing
winning = closing the deal
sorry, I wasn't clear
if the auction doesn't reach the reserve price then the seller has the option not to sell
when I said good luck winning, I meant "good luck closing the deal"
althought that's less likely :P
seems on ebay it's priced 4250$
[19:10:35] <alex_joni> http://cgi.ebay.com/Seiko-TT8550-D-TRAN-4-axis-SCARA_W0QQitemZ110036280246QQihZ001QQcategoryZ100002QQrdZ1QQssPageNameZWD1VQQcmdZViewItem
jmkasunich: still around?
I added a small example for a YA machine to this page: http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?IniChanges
maybe that case is too simple, I'll do one for gantry too
JOINTS in traj section should be AXES I think?
a cartesean DOF isn't a joint
no, I meant actual joints there
we don't care how many axes 'move'
I disagree with that
traj shouldn't know about joints
motion controller gets his data from there
maybe TRAJ is not the best name :)
but I wouldn't wanna change that too
MACHINE would be more appropriate
if [TRAJ]JOINTS is saying how many letters will be in [TRAJ]COORDINATES, then it should not be JOINTS
because COORDINATES are cartesean
no, it's saying how many motors are driven by motion
actually how many JOINT_* sections exist
then put it at the bottom
(I know, order doesn't really matter)
but its confusing
everything in the TRAJ section _except_ JOINTS refers to cartesean stuff
yeah, I know
how about a KINS section
put JOINTS in there
that sounds good
that assumes trivkins
that's only for trivkins, yes
and it's probably only used by the gantry aka userdefkins.c
I must be thinking about this differnetly than you are
I think of the JOIN_n section has having info that the joint controller needs
mapping a particular joint to a particular output of the kins module isn't quite the same
if anything, I'd be tempted to use the 'n' in JOINT_n to do that
say you have a gantry
with joint 0 & 1 driving X
X drives joint 0 and 1 ;-)
so you are hard-coding the ability to map more than one joint controller to an output of the kins module?
didn't quite get that
yeah, this is hard to put into words
I don't expect nontrivkins to have the AXIS=* line
but gantry kins would?
although it probably depends on the implementation
if the one that writes the gentrykins does it like jepler did, then yes
the way I see it, kins is responsible for mapping joints to axes
maybe I wasn't clear enough.. I expect this line to be only used by hal scripts
so why is that info appearing in the joints section
setp gantrykins.joint-0 [JOINT_0]AXIS
only for name consistency..
I guess the same things could be in the [KINS] section
JOINT0 = 0
JOINT1 = 0
for the mappings
the more I think about gantries, the less I think kins is the right way to deal with them
a gantry axis (both motors together) is a single joint from a kins perspective
normal machine movement would _never_ command the two motors to go to differnet places
only homing might command relative motion, and even then it would need to be carefully limited
I think gantry joints should be handled at the joint level or below, not in kins
and the mapping from the joint outputs of the kins module to JOINT_n should be 1-to-1
man, this stuff is complex, if you try to respect the difference between joints and axes
you don't home an axis, you home a joint
but the GUIs are perfectly happy to let you try homing an axis
(sorry.. was away a bit))
jmkasunich: guess users would be a bit deranged by a trivkins machine you need to home as joints
then change to world mode
so for trivkins (most of the users anyways) I'd keep it separate
at least on the look&feel
I guess a proper non-trivkins capable gui would have an ini flag that says "treat axes as joints" or "treat axes and joints separately"
hmm.. what if the joints have names as you suggested
and the names are X,Y,Z,.. for a trivkins machine?
the only thing is that g-code and MDI is in world mode
and gets run through the kins, whereas jogging isn't
but with 1-1 mapping it shouldn't matter
you could make a very confusing config if you try hard enough
map joint X to axis Y
for any non-trivkins, only an idiot would name joints after axes
well.. maybe not
even for trivkins, I personally would name the joints for the machine parts, not the axes
on the scara you probably want to name the vertical one Z :D
joint: quill axis: Z
ok, maybe in that case
but usually it's not carthesian related
I'm not a gui guy, but my preference would be that in world mode, the names be joint names, and the values be absolute joint positions
in axis more, the names would be cartesean, and the values would include whatever offsets etc are in effect
you mean joint mode in case 1 ?
world mode is carthesian afaik
joint and world modes, not world and axis mode (I really had that messed up)
added a SCARA config to that page
I really want to figure out how to only export HAL pins for the joints the machine actually has
not for 8 joints every time
I wanted to do the same
with this occasion I mean
jmkasunich: motion already has user<->RT comms
any reason against a EMCMOT_EXPORT_JOINT command?
theres got to be a better way to set up pre-HAL-export config info
you mean so that "loadrt motmod" would not export any pins, until something in user space sent it an export command?
that would be a problem, because a module shouldn't set hal_ready until its pins are exported (so the remainder of the hal file can connect them)
how about removing existing ones later?
replying to an email, biab
thats the one I'm replying to
guess you're not too tired to try explaining things..
I'll explain once
the next time the tact filter might break
actually, since he's already asked stupid questions before, it might develop a small leak in this message
* alex_joni makes a mental note to make sure to read all emails to JMK twice
wouldn't wanna get hit by an unfiltered reply
I used to get hit with them on here off and on... either I have gotten better or jmk has gotten a little soft. ;)
I think you get immune after a while
ah - didn't think of that. ;)
neither did JMK
everyonce in a while my filter falls off at work
and my boss says "ok, John, tell us how you _really_ feel"
heh, bet you're fun to work with :)
I bet I'm a pain to manage
but my boss is a good guy
did you guys see that maybe my communication problem with the pluto my just be the cable?
skunkworks: no, but good to hear that
I want to get a ieee mumble mumble cable to try.
this is the cable I was using. works with the older computer at work. just not my portable http://cgi.ebay.com/Lot-of-3-Iomega-Zip-100-Drives-With-Cables_W0QQitemZ150093663498QQihZ005QQcategoryZ116251QQrdZ1QQcmdZViewItem
skunkworks: does it have 25 wires in it?
I thought it wouldn't be a problem.. so short. I have not ohmed them out yet. I hooked it up and the samlple hal file made the led work (sending a sin wave to pwm0) so I had just assumed it worked correctly
ok, where were we
* skunkworks hides again. Have fun.
talking about (among other things) how to not export excess hal pins from motmod
which just happens to be another version of my own problem - how to tell the 5i20 driver what pins to export
we have 2 options
1. pass info at insmod time what to export
2. export all, and remove some later
3) implement newinst
hmm.. and export 3-4 motmods ?
that separates the act of loading the module from the act of exporting
we'd still only do one instance of motmod
but newinst would have some better kind of parameter passing
not sure yet
but since newinst is a hal command, not a wrapper around insmod with all of insmod's limitations, we should be able to do something better
newinst motmod joints=4
I see no problem in doing loadrt motmod joints=4
or even joints=[TRAJ]AXES
the latter is the way to go
guess that's pretty easy to do
have the default value = 6 (or 8 as it is now)
and specify it from now on in the HAL files
* alex_joni grins
so you also think we should fix the ini issues?
yes, of course
when is another matter
heh, or where
* alex_joni thinks of a branch
we should fix everything - but differnet things have different priorities for different people
maybe a branch, but not right away
well.. I wanna work on something, and this is something I'm confident I can fix
the sooner you branch the more stuff you have to port later
yeah, I know
for example, adding a joints=N insmod param to motmod can be done without breaking anything (just set the default to 8)
so do it in head
and later when you branch, that part is already done
the only reason for a branch IMO is if the branch is gonna be busted for a while, or will bust a lot of configs
this will probably bust em all
(configs I mean)
2.2 in general is gonna do that
[21:24:52] <alex_joni> https://sourceforge.net/pm/task.php?group_project_id=46285&group_id=6744&func=browse
any others done already?
jepler: maybe the CL stuff?
alex_joni: no, the CL stuff is still the same as awlays
is there any way to remove the end date? I certainly don't plan to work on CL any further
I can close the task
or set it to deleted
* jepler shrugs.
jmkasunich: mind if I add the joints=* to the motion controller?
go right ahead
btw, you asked about Features
[22:01:02] <alex_joni> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?EmcFeatures
one of these days I want to change "axis.N.foo" to "joint.N.foo" but that is more disruptive
that page is more of a wishlist
I was thinking of "here is something we have seriously discussed, we think we know what the issues are and have a plan, and we want to do it for version 2.x"
there's also this: http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?EMC2_Development
juve@taurus:~/emc2.TRUNK$ sudo rmmod motmod
ERROR: Module motmod is in use
any idea how to cure that?
nm.. it seems to be pretty fscked
[34935.529713] MOTION: init_hal_io() starting...
[34935.530079] Unable to handle kernel NULL pointer dereference at virtual address 00000000
doesn't sound healthy
hmm.. can't figure out what I borked to make it oops
[22:41:21] <alex_joni> http://www.pastebin.ca/370843
surely lots of things still count to EMCMOT_MAX_AXIS even if you asked for fewer in the ini?
some still look for active first
but I'll look some more
(found a first thinko)
if you don't export an axis then its HAL pins aren't created .. the assignment of values to the HAL pins will fail
try it under the simulator and you can probably find the line where it barfs
gdb rtapi_app, and at the (gdb) prompt, type run
then run the emc script
Program received signal SIGSEGV, Segmentation fault.
0xb7ccbd47 in rtapi_app_main () at emc/motion/motion.c:503
503*(axis_data->amp_enable) = 0;
jepler: thanks, figured that out by reading the code more carefully
still gotta reboot to get rid of the borken module :D
hmm.. seems to work
[23:03:53] <alex_joni> http://www.pastebin.ca/370864
I'll do some more testing, then commit it