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