Back
[01:56:42] <jepler> cradek: I don't know if pluggable interpreters is the direction we want to go or not .. but the difficulty of making them pluggable *without the ability to share any implementation with the current interpreter* was not that great
[02:02:09] <SWPadnos> what makes it a lot harder if you wanted to share some implementation?
[02:02:23] <SWPadnos> (assuming that said pieces can be stuck into a shared library)
[02:03:41] <jepler> SWPadnos: my approach creates a base class for all interpreters, but it only has pure virtual functions and no data.
[02:04:12] <SWPadnos> ah, ok. so it's more of a language-y thing than a runtime thing
[02:04:19] <jepler> SWPadnos: you *could* arrange to share implementation by a class with useful methods
[02:04:43] <jepler> but that is work -- work to decide what is useful, and work to separate it out from the specifics of the Interp class as it is now
[02:05:20] <jepler> cutter comp would be one example of something you'd like to share and which might be feasible
[02:05:24] <SWPadnos> sure, I can imagine some of the parsing stuff could be separated, but then again maybe not, for instance if a language actually treats spaces as meaningful separators
[02:05:27] <SWPadnos> sure
[02:05:30] <SWPadnos> on the other end :)
[02:05:53] <jepler> parsing a "line" of gcode might not be, if you want to parse a dialect with multiple words per line with the same letter (G??? X Y X Y X Y)
[02:06:30] <SWPadnos> right, though tokenizing could be shared, as well as numerical interpretation and possibly variable names or something
[02:06:40] <SWPadnos> err, variable expansion ...
[02:06:51] <jepler> all it needs is for somebody to figure out all the particulars
[02:06:59] <SWPadnos> yeah. the "work" part :)
[02:08:22] <jepler> but if someone really wants a 100% "fan*c" or "h**s" interpreter, I think that this is the way to go
[02:08:34] <jepler> as opposed to trying to make rs274 parse rs274 AND something else
[02:08:36] <SWPadnos> oh. for G-code dialects, definitely
[02:08:46] <SWPadnos> right, like STEP or something
[02:09:17] <jepler> I remain firmly disinterested in writing an anything-compatible gcode interpreter (having once done it for about 12% of emc1's rs274ngc!)
[02:09:46] <SWPadnos> hmmm
[02:10:06] <SWPadnos> I probably still have the antlr/whatever code for a nearly complete parser
[02:10:20] <SWPadnos> written by - err - Pete V
[02:11:02] <jepler> reminder, the code I wrote for pluggable interpreters is at
http://git.unpythonic.net/view?p=emc2-jepler.git;a=shortlog;h=refs/heads/plug-interp
[02:11:35] <jepler> urk, 8 hours to download ISE12.3 on my dsl
[02:11:39] <SWPadnos> thanks. I'll see about getting that soon
[02:11:43] <SWPadnos> heh
[02:11:55] <SWPadnos> and you've got real DSL
[02:11:59] <jepler> clone url git://git.unpythonic.net/emc2-jepler.git
[02:12:34] <jepler> oh I think most US broadband is faster than mine by now. I'm on 1.5, though last year I was on 3.0 for awhile. (1536/384kbps)
[02:14:08] <SWPadnos> oh. I'm surprised my 2M/256k is "competitive" with anyone these days :)
[02:15:10] <skunkworks> 1/256 here :(
[02:15:24] <skunkworks> still beats dialup though.
[02:15:28] <skunkworks> ;)
[02:15:59] <jepler> yeah by at least a factor of 2 or 3
[02:16:01] <SWPadnos> I was really bummed when they told me that the 8/2 or 16/2 service wouldn't be available to me (though they do have it in my area)
[02:16:33] <SWPadnos> cheap too, like $59 or something for the 8/2
[02:16:48] <jepler> they're supposed to have 12.0M/768 in lincoln, but my line would only test out for 3.0 and that was not reliable
[02:17:33] <SWPadnos> I'm only 0.8 miles from the CO, so it should be possible
[02:18:14] <SWPadnos> but since I'm with a local (formerly anyway) company which leases lines from FairPoint, and I would need a new line put in, and the pedestal is all the way across the street, it was too hard
[02:18:39] <SWPadnos> (and I'm not kidding, it's directly across the street, less than 100 feet from my house)
[02:19:21] <jepler> did spartan-4 and spartan-5 get skipped in xilinx's naming system?
[02:19:35] <SWPadnos> I don't think so
[02:20:13] <SWPadnos> well, maybe
[02:20:48] <jepler> urp -- the new ise doesn't support spartan2 at all (even in ISE design suite)
[02:20:56] <jepler> I think I remember peter telling me this now
[02:21:12] <SWPadnos> huh, even in the costly one?
[02:21:32] <jepler> yeah, even in the costly one
[02:21:42] <jepler> http://www.xilinx.com/images/tools/ids_prodtable.gif
[02:22:00] <SWPadnos> that's awfully small :)
[02:22:07] <jepler> yeah
[02:22:30] <jepler> I guess I don't need to bother seeing whether 12.3 (with the "map -r" flag removed) can fit the nearly-full designs onto the xc2s200 parts!
[02:22:44] <jepler> I do need to figure out a commandline version check, though
[02:23:51] <SWPadnos> at least they still let you download older versions
[02:24:54] <jepler> hmmm actually one of the designs that doesn't fit without "map -r" is for 7i43-200 which is a spartan3 part
[02:25:12] <SWPadnos> eyah, the 5i20 is the only spartan2
[02:25:33] <SWPadnos> well, other than some of the PC/104 cards maybe
[02:25:40] <jepler> yea, there's also the 4i65
[02:25:55] <SWPadnos> is that the one with the ARM CPU on it as well?
[02:26:02] <SWPadnos> or just an FPGA card
[02:26:04] <jepler> no idea
[02:26:18] <jepler> speaking of small files, those mesa datasheets!
[02:26:28] <SWPadnos> ah - ARM board is 4C81
[02:26:49] <SWPadnos> oh - you linked to the small gif file, not the pdf :)
[02:26:57] <jepler> ohhhh!
[02:27:07] <jepler> http://www.xilinx.com/publications/matrix/Software_matrix.pdf
[02:30:19] <SWPadnos> did you have version 11.x before?
[02:37:48] <jepler> SWPadnos: no, 9.2
[02:37:55] <SWPadnos> ok
[02:38:01] <jepler> positively ancient, I know
[02:38:20] <SWPadnos> looking at the release notes, they don't list spartan2 in 12.1, but I think it did in 11.5
[02:40:00] <jepler> I have never had 11.x. I did find in some documentation that implied -r was removed from map in 11.x. (it referred to the GUI equivalent, the name of which I forget)
[02:40:31] <SWPadnos> hmmm. no, I guess I'm confused
[02:40:54] <SWPadnos> I was looking for the latest version that has spartan2, but might also have better routing than 9.2i
[02:46:49] <jepler> I think ise 11 dropped spartan2
[02:47:13] <jepler> http://www.xilinx.com/support/documentation/sw_manuals/xilinx11/irn.pdf page 26
[02:49:16] <SWPadnos> yeah. my brain isn't working
[02:49:49] <SWPadnos> I looked at the 11.5 release notes and didn't find spartan-2, so obviously I had to check some later release notes to see what had happened to it ...
[02:50:19] <jepler> I'm sure it helps that they write it "II"
[02:50:38] <SWPadnos> yeah, that could be a "help"
[02:56:19] <SWPadnos> well, I think I'll call it a night. see you later
[02:59:13] <jepler> see you
[03:54:40] <KimK> It seems that (on master, at least) the classicladder default value load variables (per Integrator's Manual) numSymbols=Auto, numFloatIn=10, numFloatOut=10 if added to the classicladder load string, cause emc2 not to start (at least here). So: Bug report on classicladder loading? Mark those 3 as "coming soon" in the manual? Remove those 3 from the manual?
[05:13:49] <CIA-2> EMC: 03seb 07master * r44eee4d32536 10/src/libnml/posemath/_posemath.c: remove some dead code
[05:20:05] <CIA-2> EMC: 03seb 07master * rf7e85db8dfec 10/src/hal/user_comps/modbus.c: remove some dead code
[05:26:07] <CIA-2> EMC: 03seb 07master * r1db60d955aa6 10/src/emc/motion/stashf_wrap.h: remove some more dead code
[09:37:53] <sebastian_> hello
[09:38:07] <sebastian_> i've made changes on axis.py
[09:38:25] <sebastian_> can i upload this?
[09:39:38] <sebastian_> I've added a new parameter for the .ini file
[09:40:46] <sebastian_> it sets the default path for the openFileDialog in axis
[09:48:06] <mhaberler> axis video: I'm trying to embed a camview as per wikipage, but the axisrc script gives me a traceback :-/
http://imagebin.ca/view/kGqZfi1.html
[09:48:07] <mhaberler> any clues?
[10:59:34] <KimK> sebastian_: Doesn't this exist already as OPEN_FILE= ?
[11:02:11] <mhaberler> were you referring to me?
[11:23:02] <sebastian_> KimK: no OPEN_FILE sets the default .ngc file that is shown when starting emc
[11:23:44] <sebastian_> KimK the default path for openFileDialog is now "PROGRAM_PREFIX"
[11:24:42] <sebastian_> KimK: i don't think thats a good idea because it's also th path for user defined Codes and pyvcp
[11:27:27] <sebastian_> kimK: with openfileDialog, i mean, if you want to open a file
[13:50:34] <CIA-2> EMC: 03jthornton 07v2.4_branch * ree9d10d3b486 10/docs/src/gcode/main.lyx: update canned cycles description
[17:18:40] <jepler> ISE 12.3 can't fit the SVST4_6 config on the 7i43-200
[18:16:23] <andypugh> jepler: Is it possible that that firmware you sent me might not have active pwmgens? I am trying to exclude possibilities as some part of the chain of software and hardware is not playing the game.
[18:21:43] <KimK> !later sebastian_ (sent via !later) OK, I think I see. So you think the user should be able to keep his ngc files somewhere besides ~/emc/nc_files? All right. But does your improvement make a separate path for the user-defined m-codes? I have a bunch of those, and I'd really like to get them out of nc_files.
[18:22:44] <KimK> andypugh: You wouldn't happen to be using a 7i43-200, would you?
[18:23:31] <andypugh> KimK: No, this is a 5i23. It worked previously with a 7i43-400
[18:26:18] <KimK> andypugh: OK, nevermind then. Just before you entered, jepler said, "ISE 12.3 can't fit the SVST4_6 config on the 7i43-200". I mistakenly thought that might have to do with you. (I put 2 and 2 together and came up with 5?)
[18:27:50] <andypugh> No, this is SVTP6_7I39.BIT
[18:29:19] <cradek> KimK: in master, there is already USER_M_PATH, SUBROUTINE_PATH to separate those things from nc_files
[18:30:31] <skunkworks> can you default a checkbox in the pyvcp to true?
[18:32:55] <KimK> cradek: Good morning, congrats on Wichita. Oh, nice, I didn't know about those. So, maybe I still don't understand, what then is sebastian_'s proposed AXIS improvement?
[18:33:20] <KimK> skunkworks: Hi Sam, how goes it?
[18:33:27] <skunkworks> I guess I could have the checkboxes labled 'disable pump' and 'disable amps'...
[18:34:04] <skunkworks> well - spindle at speed seems to work.. I might want to filter the signal.
[18:34:07] <cradek> KimK: I think the problem he wants to solve is already solved in other ways...? not sure.
[18:34:42] <KimK> skunkworks: I think if you use radiobuttons you can pick a default?
[18:35:50] <KimK> cradek: OK, but why didn't he see that while wandering through the Axis code?
[18:36:42] <KimK> cradek: I guess that's a silly question. Why does anything go wrong?
[18:37:45] <cradek> those options are not in AXIS, they're part of the interpreter
[18:39:11] <KimK> cradek: Oh, so they are available with any display? Nice.
[18:42:28] <KimK> * KimK makes a note of the magic undocumented incantations.
[18:43:52] <KimK> cradek: Should the magic phrases be documented?
[18:45:02] <andypugh> That would leave the High Priests of IRC with no aura of mystery.
[18:46:18] <guest843> KimK:
http://linuxcnc.org/docs/devel/EMC2_Integrator_Manual.pdf section 4.2.4 seems to document these features
[18:50:51] <andypugh> On reflection, it is better for the docs to lag the features than the features to lag the docs. Otherwise folks get frustrated that the things in the docs don't work.
[18:50:59] <KimK> guest843: Ah, yes, I see, thanks. It's documented in the master manuals, but not in the 2.4.5 release manuals. Are the features in 2.4.5 or v2.4_branch?
[18:56:46] <KimK> andypugh: Yes, that was my observation earlier about CL's numSymbols, numFloatIn, and numFloatOut. Oh well, at least USER_M_PATH and SUBROUTINE_PATH got into the new manuals. So the manuals *are* improving, excellent!
[18:57:45] <andypugh> JT Spends a lot of time on the manuals. If there is a problem it is perhaps that too much old and outmoded stuff is still out there.
[18:59:04] <KimK> I am supposed to be helping JT with the docs, but I have slacked off lately due to other things. It will be a good winter project, though.
[19:08:02] <cradek> yeah, unfortunately the docs are always behind the features - sometimes things get through
[19:13:07] <jepler> andypugh: I looked at the 5i23/SVTP6_7I39.PIN file again and I don't see any obvious mistakes (it's identical to the 5i20 one except for the clock speeds in the top block)
[19:13:34] <jepler> andypugh: I can build you another one without the changes I recently incorporated from peter, in case that's a cause of trouble
[19:13:50] <jepler> did you say somewhere what the specific problem is?
[19:14:10] <andypugh> I can't see any PWM on the scope
[19:14:34] <andypugh> I can with the TPEN6_6.BIT file
[19:15:06] <andypugh> However, I could be on the wrong pins, the driver could be set up wrong, any number of things
[19:15:29] <andypugh> I need to go through a few more iterations to be sure where the problem lies
[19:18:22] <jepler> let me build a firmware without the recent vhdl changes so that if you like you can test that as a possible cause
[19:19:36] <andypugh> wait a bit
[19:19:41] <andypugh> I see PWM now
[19:20:29] <andypugh> I thought I had found the problem a while back (watchdog pining for affection)
[19:21:06] <andypugh> But then saw no improvement, but perhaps I was not doing the experiment I thought I was doing
[19:22:51] <andypugh> OK, sorry for the trouble.
[19:22:58] <andypugh> It seems to be working now.
[19:23:08] <jepler> OK
[19:23:09] <andypugh> I just wish I was clear on what has changed.
[19:23:41] <andypugh> There is quite a chain, all experimental...
[19:28:38] <jepler> bbl
[20:01:24] <Xavier_H> Hi all
[20:01:48] <Xavier_H> I encountered some problem to build Hostmost2 firmware
[20:02:00] <Xavier_H> I have ISE installed
[20:02:10] <Xavier_H> settings32.sh Ok
[20:02:39] <Xavier_H> firmware.txt with only this line : "i23 SVST8_4IM2"
[20:03:03] <Xavier_H> and when I run "make" I have this :
[20:03:23] <Xavier_H> xavier@xavier-Latitude-E6500:~/Bureau/hm2-dev$ make
[20:03:25] <Xavier_H> ./build.py i23 SVST8_4IM2_72 fw/5i23/SVST8_4IM2.BIT
[20:03:27] <Xavier_H> # workdir /home/xavier/Bureau/hm2-dev/fw/5i23/SVST8_4IM2_work
[20:03:29] <Xavier_H> # xst -ifn scr
[20:03:32] <Xavier_H> # exited with 127
[20:03:33] <Xavier_H> make: *** [fw/5i23/SVST8_4IM2.BIT] Erreur 127
[20:03:36] <Xavier_H> """
[20:04:10] <Xavier_H> Someone know what this error mean?
[20:04:43] <Xavier_H> GHDL are installed to
[20:04:54] <Xavier_H> too
[20:06:37] <andypugh> Perhaps try shouting jepler so that his IRC client goes "bonk"
[20:07:13] <Xavier_H> shouting? like that?
[20:07:23] <Xavier_H> jepler: Are you connected?
[20:08:22] <Xavier_H> It seems that his speakers are off ;-)
[20:08:30] <andypugh> He did say he was going away for a while.
[20:08:57] <andypugh> Perhaps he has noted that if you ignore people for long enough they tend to solve their own problems.
[20:09:32] <Xavier_H> ok I will try to find myself again
[20:10:14] <Xavier_H> I don't want to bother anybody
[20:10:36] <Xavier_H> Thank you again andypugh
[20:10:58] <andypugh> I don't think I have been any help
[20:11:55] <Xavier_H> You try to help me to find someone who can respond to my questions
[20:12:17] <Xavier_H> (is it English?)
[20:12:39] <Xavier_H> thank
[20:12:46] <Xavier_H> thanks
[20:17:57] <Xavier_H> ok I don't have "xst" executable... I think it is from ISE package
[20:23:12] <Xavier_H> ok I found!!! setting32.sh were not set at the right base path...
[20:23:37] <andypugh> Sounds promising
[20:23:46] <Xavier_H> yes!
[20:24:27] <Xavier_H> "Bitstream generation is complete."
[20:24:36] <Xavier_H> :-)
[20:26:23] <Xavier_H> Ok now how work this gaz-factory...
[20:26:39] <Xavier_H> (french expression)
[20:27:12] <Xavier_H> thank you again andypugh!
[20:27:55] <andypugh> If you can put the value you need in a register, you can read it out with the Hostmot RAW functions.
[20:28:19] <andypugh> See "enable_raw" in the Hostmot2 manpages
[20:28:49] <Xavier_H> ok I will be very usefull!
[20:29:07] <Xavier_H> but I don't have mesa card for now!
[20:29:35] <andypugh> In fact, for a single value you could do it all in hal, just setp hm2_5i20.0.raw.read_address to the right value, then use the *raw.read_value as a pin
[20:37:21] <skunkworks> interesting observation... If I home just the b axis - when I go to rotate it (command a g0b0) I get an error 'linear move in mdi would exceed joint 1's negative limit' so I then home Y axis and then I can do the move.
[20:38:53] <SWPadnos> trivkins?
[20:38:58] <skunkworks> yes
[20:39:03] <SWPadnos> huh
[20:39:48] <skunkworks> not that it is a big deal - once I get everthing situated - force home will be re-enabled.
[20:39:50] <cradek> is 0 outside Y's travel?
[20:40:16] <skunkworks> I don't think so.. my limits are 0 and 36 for y
[20:40:51] <SWPadnos> I wonder if it starts up at -0 or 0- for some strange reason
[20:40:55] <cradek> if Y moves even one count negative after you start up, the error is expected (more or less)
[20:41:50] <skunkworks> ok
[20:41:53] <skunkworks> that makes sense
[20:42:01] <skunkworks> it sags I am sure
[20:46:30] <skunkworks> yay - b axis servo is now hooked into the control box. (before it was run with a extension cord...)
[20:48:03] <cradek> slick
[20:48:58] <skunkworks> hnm - so locking rotorys always needs a g0?
[20:50:19] <cradek> yes
[20:50:33] <skunkworks> cool
[20:50:41] <cradek> can't make any sense to cut with it unlocked, can it?
[20:51:46] <SWPadnos> cradek, do you think genserkins should have some way of showing when matrix inversion doesn't work (as you did on Stuarts machine with rtapi_prints)?
[20:52:03] <SWPadnos> I can add counters attached to HAL pins/params to do that if you think it's useful
[20:52:07] <cradek> I don't know...
[20:52:17] <cradek> that might be better than bombarding the syslog
[20:52:18] <skunkworks> right - it just It threw me off because you can;t do g0b0 then b180
[20:52:34] <SWPadnos> yeah. maybe params so they're easier to reset
[20:52:38] <cradek> oh? that is kind of a thrower then
[20:52:40] <SWPadnos> (can you setp an IO pin?)
[20:52:47] <cradek> I don't know
[20:52:58] <SWPadnos> hmm
[20:57:11] <SWPadnos> ok, yes you can
[20:57:35] <SWPadnos> so I'll make them io so they can be metered and reset
[21:06:37] <psha> SWPadnos: i've added signal object to hal with link command
[21:06:59] <psha> i think i'll bug you tomorrow for review/suggestions :)
[21:17:09] <SWPadnos> I'll be traveling tomorrow, so that won't help :)
[21:18:13] <SWPadnos> did you mean that you have added the "linkp" or "net" commands to python?
[21:21:43] <psha> command to link signal to pin
[21:21:51] <psha> pin to signal
[21:21:53] <SWPadnos> cool
[21:21:54] <psha> :)
[21:21:56] <SWPadnos> either way :)
[21:22:00] <psha> and some signal related stuff
[21:22:07] <psha> create new/find existing
[21:22:18] <SWPadnos> nice
[21:22:48] <psha> i think some high-level interface for listing connected pins is needed too
[21:23:57] <SWPadnos> in general, you would want to be able to list anything: threads, functions, components, pins, params, signals
[21:24:16] <SWPadnos> and also add/remove functions to/from threads
[21:24:22] <SWPadnos> add/remove signals
[21:24:29] <SWPadnos> and of course connect/disconnect pins
[21:24:35] <SWPadnos> (to/from signals)
[21:25:07] <psha> that's too much :)
[21:25:17] <SWPadnos> heh
[21:25:45] <psha> for so huge amount of monkeycode it's better to use some type code generation...
[21:25:54] <psha> python bindings are very verbose...
[21:27:12] <SWPadnos> yeah. we have talked about adding /proc or similar kernel interfaces to get lists of things (cat /proc/hal/pins would give you a list of all the pins)
[21:27:23] <SWPadnos> but it's too muck like work ;)
[21:28:05] <psha> this won't work for ULAPI
[21:28:08] <psha> and it's sad
[21:28:22] <SWPadnos> ?
[21:29:17] <psha> emc2-sim
[21:29:44] <SWPadnos> right. it wouldn't be instead of the existing interface, it would have to be an addition
[21:32:47] <psha> whe you'll be available again?
[21:33:10] <SWPadnos> I'll be on IRC from time to time, but I'm heading to Berlin until next Saturday
[21:34:07] <psha> hah, i'll send you printed hardcopy of my patch! :)
[21:34:19] <psha> my wifes sister is going to germany on 1st of december
[21:34:19] <SWPadnos> fax it to the Berlin Hilton :)
[21:34:41] <psha> but i don't know where exactly, maybe not to berlin
[21:37:07] <andypugh> Germany is fairly small
[21:37:55] <psha> everything is relative :)
[21:38:53] <SWPadnos> even a train station is big when you're looking for a specific person :)
[21:39:05] <micges> SWPadnos: when you will be in Berlin?
[21:39:22] <SWPadnos> arriving Monday, leaveing relatively early Saturday morning
[21:39:27] <SWPadnos> leaving
[21:45:10] <KimK> cradek: Do you have another Axis adjustment for the pulse width of the E-Stop reset? (I'm guessing it's currently about 200ms?) My E-stop relay is a little bigger/slower, 200ms(?) might be a "tease", I haven't tried it yet. I could stretch it with a timer, but thought you might have a direct adjustment?
[21:45:37] <cradek> no, sadly I bet that's hardcoded somewhere deep in task
[21:46:24] <KimK> OK, thanks. I can stretch it if I have to, maybe it'll be OK as is.
[21:46:33] <micges> KimK: on what pin is this?
[21:46:50] <andypugh> KimK: There is an E-stop HAL module that might help?
[21:47:25] <KimK> micges: On iocontrol.0.user-request-enable
[21:47:56] <KimK> Oh, I guess it's not Axis then. Sorry.
[21:48:03] <SWPadnos> hmmm
[21:48:15] <SWPadnos> isn't that output active as long as you're holding the UI button?
[21:48:21] <KimK> I've been flipping the red knob in the corner of Axis, lol
[21:48:24] <SWPadnos> (or for some minimum time if you don't hold it down)
[21:48:43] <cradek> no
[21:48:45] <cradek> it's a strobe
[21:48:46] <KimK> No, you get one hit per push
[21:48:47] <SWPadnos> oh
[21:49:39] <KimK> The steady one is iocontrol.0.user-enable-out so they're pretty similar
[21:50:29] <KimK> andypugh: Thanks, I forgot about the estop component, I'll look at it
[21:50:53] <andypugh> I confess I have never quite worked out what it is for.
[21:51:26] <SWPadnos> you can set [EMCIO]CYCLE_TIME to some higher number, but that will increase the overall response time of iotask related things
[21:52:15] <micges> KimK: this strobe signal is at least [EMCIO]CYCLE_TIME but not greather that 2x of that
[21:53:07] <KimK> SWPadnos: Slowing everything down doesn't sound too good, stretching sounds better (if needed, may not be).
[21:53:22] <micges> but on heavly loaded system it could take longer, iotask is userspace
[21:53:38] <KimK> micges: OK, thanks, good to know.
[21:57:00] <skunkworks> .7 second delay seem to work with the lift/unlock
[21:58:52] <KimK> skunkworks: Hi Sam. Delay? There aren't up/down switches?
[21:59:51] <KimK> skunkworks: Or is this a "switch detect delay" which is sometimes also needed?
[22:00:23] <cradek> I think there's a switch - the problem is that one switch doesn't tell you both "is now fully down" and "is now fully up"
[22:01:54] <KimK> Ah, OK. So Sam is simulating the other side's switch. OK, no problem.
[22:02:47] <KimK> Probably it's a "down" switch, since there's a curvic coupling. OK.
[22:03:50] <cradek> yeah I think it was starting to move before it was fully up.
[22:03:58] <cradek> you can see it in the video.
[22:04:28] <KimK> As long as it detects mismatches (switch doesn't trip if curvic not seated), that's the main thing.
[22:05:09] <cradek> yes - nothing stopping skunkworks from doing g0 b2.5 some evening in a drunken fit
[22:06:57] <SWPadnos> heh. use HAL to fix that (plus a large ferror setting)
[22:07:11] <KimK> Maybe Sam can put an overstuffed recliner chair on the table, like that guy on YouTube that strapped himself into a chair on the end of a robot arm.
[22:07:21] <SWPadnos> with a mod/round comp, just make the command equal to the closest multiple of 5 degrees
[22:07:51] <cradek> you'd get jerky motion then
[22:07:57] <cradek> that's the wrong place to mess with it
[22:08:02] <SWPadnos> true
[22:08:19] <SWPadnos> that would be an interesting addition to the interp - axis resolution
[22:08:25] <SWPadnos> or tp or whatever
[22:08:50] <cradek> it's true interp could validate the axis position for a locking axis
[22:09:20] <SWPadnos> actually, you can do it in HAL, you just need a limit3 there as well, with the same settings from [AXIS_N]
[22:09:31] <andypugh> Sounds more like a job for a hal component
[22:09:31] <SWPadnos> (though that wouldn't work with FO and such)
[22:10:02] <SWPadnos> no, cradek is right, the TP knows how it wants the axis to move, so fiddling with that in HAL is more complexity than should be needed
[22:10:15] <andypugh> This almost comes back to my suggestion of offset pins into the pre-trajectory-planner level
[22:10:35] <SWPadnos> so making the TP/interp aware of additional limitations in positioning makes more sense
[22:10:50] <andypugh> Though, could you do that with an offsetkins?
[22:10:58] <SWPadnos> andypugh, yeah, I wrote a component that does that, which can be chained with limit3 to do what you're saying
[22:11:01] <SWPadnos> (for tool changing)
[22:12:02] <andypugh> Torch height control, non-circular lathe turning, edm orbiting. There are almost three corner-cases where external offsets might be useful some of the time.
[22:12:22] <SWPadnos> sure
[22:12:48] <SWPadnos> I think I wrote an even easier one actually, it's only like 5 lines of comp code (plus the pin defs)
[22:13:35] <SWPadnos> but it prevents motion from knowing where the machine actually is, which is the issue with doing it outside the TP (in HAL)
[22:15:02] <andypugh> That's why I want to do it between Interpreter and Motion
[22:15:25] <SWPadnos> one issue I can think of for doing it inside the TP is that the TP attempts to satisfy both path and speed constraints, which is a problem when you want to add some sudden quick motions to the output
[22:15:46] <SWPadnos> (that's by far not the only issue either)
[22:16:00] <andypugh> Surely that is a feature? Your sudden quick motion will only be containably quick and sudden?
[22:17:30] <andypugh> It is a pity, perhaps, that a long time ago nobody considered the possibility of chaining kinematics.
[22:18:30] <andypugh> (Actually, I am hexapod built of 6 puma robots...)
[22:19:12] <andypugh> I bet very nearly one user would find that useful.
[22:20:01] <andypugh> (Sorry I seem to have gone off on what I could imagine being a rather irritating tangent)
[22:20:39] <SWPadnos> remember, the design was done when CPU power was actually costly :)
[22:21:15] <SWPadnos> the thing about EDM/THC is that you actually want very fast motions, which are not constrained by the normal limits
[22:21:36] <andypugh> Which limits?
[22:21:51] <SWPadnos> the mechanics are sometimes (maybe often) made so that there is a small motor that does the fine quick movements, while the axis motor does the "normal" motion
[22:21:53] <SWPadnos> accel/vel
[22:21:55] <SWPadnos> limits
[22:22:35] <andypugh> Wouldn't that be a UVW axis though, with different accel/vel limits?
[22:22:42] <SWPadnos> probably not
[22:22:53] <SWPadnos> it's not something that really has anything to do with the programmed motion
[22:23:14] <SWPadnos> you don't program it as W motion, because by definition it's not a programmed thing, it's reactive to feedback
[22:23:24] <andypugh> Well, in that case you wouldn't use my proposed idea.
[22:23:28] <SWPadnos> heh
[22:23:31] <SWPadnos> no, I wouldn't ;)
[22:24:13] <andypugh> If you have a THC-only actuator that would run in HAL through a limit3, nothing else makes much sense
[22:24:42] <SWPadnos> incidentally, "chained" kinematics have another interesting application, which would be to e.g. use gantrykins and something non-trivial at the same time, like two motors per joint on a genserkins or hexapod-type machine
[22:24:52] <SWPadnos> yes, that's true
[22:25:01] <SWPadnos> gotta run. bbl
[22:25:57] <andypugh> Non-trivial gantries were my main idea, I just threw in the puma-hexapod for laughs
[22:32:20] <skunkworks> You guys! :)
[22:32:39] <skunkworks> we are very happy with just making sure we type the degrees in right. :)
[22:36:39] <skunkworks> yes - there is an up switch - but it activates a little before the top of travel.
[22:38:16] <skunkworks> so - I think between the halui.mdi-command-mumble, in position, ladder and luck - I should be able to automate pallet changes. :)
[22:41:49] <andypugh> How does Ladder compare to custom-comp for that sort of thing?
[23:06:35] <skunkworks> well - for the tool changer logic - I used ladder. for the transmission I used comp. I mainly used comp because I wasn't sure how I would even do it in ladder
[23:08:06] <skunkworks> I have not decided if I will do a comp for the pallet change. The physical load/unload is in ladder - but making sure all the ducks are in a row might be easie for me in comp
[23:08:17] <skunkworks> easier
[23:08:36] <CIA-2> EMC: 03seb 07master * rf607d8bd70a7 10/src/rtapi/ (5 files): get rid of $Revision$
