Back
[01:10:09] <jepler> tclsh8.4 [~/emc2-dev]pulse 1
[01:10:09] <jepler> gpio.071 = FALSE
[01:10:09] <jepler> CCR 1: 2842 LatchOnProbe Filter15 JustOnce
[01:10:09] <jepler> gpio.071 = TRUE
[01:10:09] <jepler> CCR 1: 2842 LatchOnProbe Filter15 JustOnce
[01:10:12] <jepler> gpio.071 = FALSE
[01:10:14] <jepler> CCR 1: 0842 Filter15 JustOnce
[01:10:22] <jepler> OK, on a new day with the hal driver not talking to the encoder, the latch seems to be working
[01:36:31] <jepler> .. and after I back out the weird hacky stuff I added the first night, it seems to work
[01:37:16] <jepler> I bet the original problems we saw had to do with the undesired edges produced by the probe polarity bit
[01:37:57] <jepler> made worse when I forced it to repeatedly write the status register with its LatchOnProbe bit
[01:41:55] <SWPadnos> oops
[01:46:36] <skunkworks> Nice!
[01:47:33] <jepler> don't party too hard yet .. it's not like I was testing it on anything moving
[01:49:15] <SWPadnos> when you said the HAL driver isn't talking to the encoder, is that because no encoders are hooked up or because no encoders were enabled at load time? (or something else)
[01:49:58] <jepler> because no encoders were enabled at load time
[01:50:23] <jepler> so I knew that my little test program (tcl script) was the only thing touching the encoder CCR
[01:50:41] <SWPadnos> got it. I figured there would be some interactions there
[01:54:12] <jepler> I'm still not 100% sure what I was seeing last night, but I'm ready to write it off as having simply done something wrong
[01:57:45] <jepler> cradek: so maybe this weekend we can give it a try on jr again
[02:00:02] <jepler> I suppose I could hook my tool length sensor up again and test it on something moving but less expensive than your fancy probe, though
[02:01:03] <SWPadnos> hook up a button and make sure it trips in air first
[02:01:32] <jepler> I'm pretty confident it'll trip -- that hasn't change
[02:01:33] <jepler> d
[02:01:49] <jepler> (by my high resolution probing changes, that is)
[02:01:54] <jepler> the "when to stop" logic is the same
[02:02:03] <SWPadnos> ah
[02:06:30] <jepler> us.archive.ubuntu.com seems to be hammered
[02:07:43] <SWPadnos> I can imagine
[02:07:52] <SWPadnos> several million people downloading the 9.10 ISO
[02:08:21] <SWPadnos> I figure I can wait for a couple of days - it'll probably finish at the same time anyway :)
[02:33:48] <cradek> oh cool!
[02:42:42] <pcw_home> I built an improved SVST8_3 with the probe logic modified so that changing
[02:42:43] <pcw_home> the probe polarity bit wont generate an edge, plus I changed the pin desc for the probe pin to 0x45
[02:42:45] <pcw_home> unfortunately I didnt move the bitfile to anywhere I can get to till tommorow
[02:43:06] <cradek> cool
[02:43:13] <cradek> don't worry, it's way too late to worry about tonight!
[02:44:18] <cradek> I found that the opto22 module the probe goes to has an turn-on time of 5ms... that'll sure have to change - I figured it was slow but I had no idea it was that bad
[02:51:23] <pcw_home> Why not just mount a fast opto and a resistor on some perfboard add some pins at the opto module locations and replace the slow module?
[02:51:49] <pcw_home> (home-made optp 22 IDC)
[02:52:05] <SWPadnos> or buy an opto-22 for $15 ;)
[02:52:16] <cradek> yeah you'd think it would be that easy...
[02:52:33] <cradek> I tried several times to get through their website and buy them
[02:52:52] <cradek> pcw_home: I bet I can just wire across the opto22 pins because the probe output is already isolated - I will check that.
[02:53:01] <cradek> it would sure be the easiest fix
[02:53:01] <pcw_home> But a HCPL2611? is about 3 usec and $.50
[02:53:41] <cradek> you should make some fast opto22 replacements - I'll take 3!
[02:53:59] <pcw_home> put a 330 ohm resistor across if you are paranoid
[02:54:07] <cradek> good idea
[04:19:17] <CIA-48> EMC: 03cradek 07master * rab0e5b5ebdab 10/src/emc/usr_intf/touchy/ (touchy.glade touchy.py): make invisible pointer an option
[13:18:01] <CIA-65> EMC: 03jthornton 07v2_3_branch * r6354e696eaf5 10/docs/src/gcode/main.lyx: Add to M6 description
[13:18:02] <CIA-65> EMC: 03jthornton 07v2_3_branch * rd73a380ff29d 10/ (21 files in 7 dirs): Merge branch 'v2_3_branch' of ssh://jthornton@git.linuxcnc.org/git/emc2 into v2_3_branch
[13:19:09] <CIA-65> EMC: 03jthornton 07master * r40912663b147 10/docs/src/gcode/main.lyx: Add to M6 description
[13:19:10] <CIA-65> EMC: 03jthornton 07master * r4c9864360e40 10/ (32 files in 12 dirs): Merge branch 'master' of ssh://jthornton@git.linuxcnc.org/git/emc2
[13:19:39] <jthornton> what is that merge stuff?
[13:33:23] <jthornton> * jthornton is off to work
[14:00:35] <cradek> jepler: even though the new code looks fine to me, it gives this warning on at least some compilers: emc/rs274ngc/interp_convert.cc:1286: warning: comparison between signed and unsigned integer expressions
[14:05:55] <Dave911> Good Morning guys .... If I want to control a 3 axis machine with EMC2 but not use the Gcode interpreter to do it, what are my options.....
[14:05:57] <Dave911> I see that jepler has has used tcl to drive emc2 at the hal level, I think...? I found this
http://linuxcnc.org/handbook/part3/emcsh2.html Which apears to be another interface level into EMC2.. does this still work?
[14:05:59] <Dave911> What I need to do is to control a 3 axis machine via a software state engine and interface that with a custom GUI. This is for an industrial spring winding machine. It is a typical definite purpose industrial machine where you enter values into the GUI, hit the run button and it repeats the state engine sequence for ever until it is told to stop. The GUI must be able to accept machine...
[14:06:02] <Dave911> ...parameters in the form of number of turns, timing values etc. I was thinking that Python code tied into hal pins would work initially but I don't think I can tell an axis to spin 21.25 turns via a Python to hal interface ...
[14:06:03] <Dave911> Then I found the emcsh interface at the link above. Do you guys have any suggestions....
[14:06:21] <SWPadnos> I think you have a terminology issue here :)
[14:06:37] <SWPadnos> emc2 is the suite of programs that converts G-code to machine motion
[14:06:39] <jepler> the "handbook" documentation is very old and doesn't apply to the current versions of emc
[14:06:53] <SWPadnos> HAL is the part that makes the motors move and interfaces to other hardware
[14:07:23] <SWPadnos> you can write whatever GUI you want to send signals to HAL, so that HAL can make the motors move
[14:07:54] <Dave911> >>HAL is the part that makes the motors move
[14:07:56] <SWPadnos> this doesn't involve the part that makes the system "emc2", which is the G-code interpreter and machine model
[14:07:56] <Dave911> Right.. it seems to me that I need to feed commands to the EMCMOT ??
[14:08:03] <SWPadnos> you can do that too
[14:08:40] <SWPadnos> there is a level of abstraction between G-code and motion which is called "canon" - it's a list of movement primitives and other machine related things
[14:09:00] <SWPadnos> so you can also remove the G-code interpreter and pit e.g. a STEP interpreter in its place
[14:09:24] <SWPadnos> as long as it issues the same CANON calls via NML, the lower layers don't have to change
[14:10:36] <Dave911> I'm not familiar with the STEP interpreter ... would a search reveal that?
[14:10:49] <SWPadnos> take a look at the standalone interpreter and what it outputs - it more or less just prints the CANON commands to the console
[14:11:05] <Dave911> OK
[14:11:11] <SWPadnos> STEP is another machine control language, we don't have an interpreter for it
[14:12:57] <SWPadnos> but conceptually, one could be written, and it could then sit on top of the same system that the current RS274NGC interpreter sits on
[14:14:18] <Dave911> Do the diagrams on this page still work with EMC2 - I know the top one is missing the hal layer but other than that are these fairly correct?
[14:14:21] <Dave911> http://www.linuxcnc.org/content/view/42/13/lang,en/
[14:15:44] <Dave911> I guess I should say - is the second one from the top correct?
[14:16:05] <SWPadnos> I think that's right
[14:16:43] <Dave911> OK, thanks
[14:17:37] <SWPadnos> you more or less don't need the EMCIO part, since that is what (theoretically) controls the spindle, coolant, tools, etc. etc.
[14:17:51] <SWPadnos> those functions would be done directly in HAL in your system, I suspect
[14:25:58] <Dave911> I'd still like to be able to use Classic Ladder if possible. Actually if I could use Classic ladder to drive motion moves that would be almost ideal. But I don't think that is possible??
[14:27:04] <alex_joni> it is in theory possible to code it all up in classicladder + HAL compoenntes (stepgens etc)
[14:27:15] <alex_joni> the problem with such a system is making it fault tolerant
[14:27:22] <alex_joni> how do you recover from an error, etc
[14:27:33] <alex_joni> forseeing a lot of bad cases is not that trivial
[14:27:54] <Dave911> How would that differ from driving motion via the interpreter?
[14:28:19] <cradek> it's not already written for you
[14:29:11] <Dave911> cradek: I don't follow
[14:29:52] <skunkworks_> http://www.youtube.com/watch?v=0RH_H7jgQQY&feature=channel
[14:30:04] <cradek> with full emc, if you get a following error it stops motion and turns off the amps. detecting of following error is one thing that comes to mind that you will have to figure out how to handle.
[14:30:08] <skunkworks_> he is using axis to run a screen printing press :) use what is easy :)
[14:32:31] <Dave911> I'm all about what is easy .. ;-) Perhaps I am making this too hard..
[14:32:33] <Dave911> Alex is that machine being driven via Gcode?
[14:33:09] <jepler> libata trim
[14:33:10] <jepler> argh
[14:33:20] <Dave911> I've worked with silkscreeners before... One was used to apply a coating to automotive pistons
[14:33:47] <SWPadnos> the easiest thing to do is probably to make a "wizard" that gets loaded in AXIS, which then writes a G-code file (to stdout) that does a loop, calling a function to do the motion
[14:34:23] <SWPadnos> it then uses an input check every loop, or the optional block delete switch, to exit from the loop to get more parameters
[14:34:29] <SWPadnos> lather, rinse, repeat
[14:34:44] <SWPadnos> s/more/new/
[14:35:53] <Dave911> I never considered doing a wizard ....
[14:36:39] <SWPadnos> you might have to fiddle with AXIS to get it to automatically reload your wizard when the user hits the "new part" button, but otherwise all the functionality is there
[14:37:52] <SWPadnos> you may even be able to make a pyvcp panel that has the input values, since halui can run g-code from a bit input, and g-code can call external M-codes, and external M-codes can (a) run the wizard, (b) tell axis to reload the file and (c) tell axis to start running the newly loaded file
[14:37:59] <SWPadnos> this all works in theory at least :)
[14:38:14] <Dave911> alex_joni: Was that silkscreen machine driven via the standard G code interpreter??
[14:38:25] <SWPadnos> skunkworks posted the link ...
[14:38:39] <Dave911> SWPadnos: On "problem" I thought I would have with using the G code interpreter is that I don't think I can get a move distance from the GUI to a Gcode. Am I wrong about that.. (tell me yes ! :-) )
[14:39:16] <SWPadnos> you probably can, but it's not trivial
[14:39:49] <SWPadnos> there are pyvcp knobs and sliders, I don't know if there's a numerical input version of those
[14:40:00] <Dave911> SWPadnos: Yes but I just saw alex_joni on the IRC and I see that was his video, Thanks skunkworks .... I forgot about that video
[14:40:00] <skunkworks_> alex_joni posted the video :)
[14:40:17] <skunkworks_> (on you tube)
[14:40:21] <SWPadnos> you can connect a HAL "analog" pin to one of the motion controller analog inputs, and read them with M65 or M66 or something
[14:40:23] <SWPadnos> right
[14:40:28] <SWPadnos> that's micges' machine, I think
[14:40:42] <SWPadnos> or he did the retrofit anyway
[14:43:42] <Dave911> SWPadno: >>halui can run g-code from a bit input
[14:43:44] <Dave911> I somehow missed that.. I thought that the Halui could only control and monitor pins - running Gcode is in the docs for halui I suppose... more reading to do... If halui can do that I may be all set..
[14:44:14] <SWPadnos> it can run a single line of G-code from each of the 8 or so inputs it has for that (I don't know the limit)
[14:44:32] <SWPadnos> it's the equivalent of canned MDI commands
[14:44:52] <SWPadnos> but you can't change the g-code lines on the fly, they're set at load time
[14:45:26] <SWPadnos> there is a program that can tell axis to do certain things, called axis-remote
[14:45:40] <SWPadnos> which can tell it to start, stop, reload, etc.
[14:47:06] <Dave911> If I could do canned MDI commands I think I could do everything I need, the trick is that I need to be able to alter the list of canned MDI commands via the setup screen.
[14:47:36] <SWPadnos> which you can't do at this point
[14:48:26] <SWPadnos> it might be possible to make that work though, since you can use analog inputs and put the values in parameters, then use those parameters in a subroutine call
[14:49:01] <SWPadnos> you can make a simple-ish ladder or HAL setup that strobes several of the MDI inputs to halui in sequence
[14:49:22] <SWPadnos> so you could fire off several commands in sequence
[14:49:37] <SWPadnos> the commands wouldn't change, but the data they use could
[14:49:59] <SWPadnos> I think you can call subroutines from MDI now, which would make things a bit simpler
[14:50:20] <Dave911> >>the commands wouldn't change, but the data they use could
[14:50:22] <Dave911> That is really what I need..
[14:50:54] <Dave911> The machine does the same thing over and over - it all to what degree the motors turn....
[14:50:57] <skunkworks_> so - could the pyvcp have a sub as its string?
[14:51:11] <skunkworks_> the the sub could be called from the program directory - that could be changed.
[14:51:12] <SWPadnos> halui - yes, I think so
[14:52:54] <SWPadnos> well, without rewriting any files, if a subroutine can be written that takes in a few numbers and does the right motion, then all you need are two subroutines
[14:53:10] <SWPadnos> one reads the UI values and puts them in parameters, the other does the motion
[14:53:36] <SWPadnos> of course, those can be collapsed into one subroutine as well, so a single MDI call might fire off a relatively long string of actions
[14:53:52] <SWPadnos> there would be no AXIS preview, which is probably desirable for an infinite loop :)
[14:54:49] <Dave911> I think I sense a solution ..... :-)
[14:55:23] <SWPadnos> how many operator-set parameters do you have?
[14:55:31] <Dave911> >>one reads the UI values and puts them in parameters
[14:55:33] <Dave911> This was the one thing I was missing
[14:55:49] <SWPadnos> look up analog input to the motion controller, it should be in the manual
[14:56:26] <Dave911> Maybe 10-20 I haven't counted them yet..
[14:56:33] <Dave911> That might be high
[14:56:45] <SWPadnos> ok, that's a lot. you may have to maintain some patches to the motion controller code
[14:57:07] <SWPadnos> I think there are only 4 or 8 analog inputs by default, and I don't know how high that number can go
[14:58:01] <Dave911> >>4 or 8 analog inputs by default
[14:58:03] <Dave911> inputs to what?
[14:58:11] <SWPadnos> the motion controller
[14:58:15] <SWPadnos> http://linuxcnc.org/docs/html/gcode_main.html#sec:M66:
[14:59:07] <SWPadnos> it might just be easier to write your own UI instead of doing all this goofy junk
[14:59:27] <SWPadnos> you can issue mdi commands from a python script
[14:59:35] <Dave911> OK, I sort of remember reading that .....
[15:00:28] <Dave911> >>issue mdi commands from a python script
[15:00:30] <Dave911> I didn't think that was possible.... I thought I would only deal with hal pins?
[15:00:38] <SWPadnos> axis is a python script
[15:01:56] <Dave911> I've looked at the Axis source code and I have a hard time figuring out where Axis starts and stops from a functionality standpoint. It is a really big script!
[15:01:58] <micges_work> there is 4 analog inputs, can be up to 16 in hal parameter
[15:02:54] <Dave911> micges_work: Hi... did you do that silkscreen machine control that is on Youtube?
[15:03:08] <SWPadnos> I guess I'd start by searching for the string "mdi" in axis
[15:03:12] <micges_work> nope
[15:03:24] <SWPadnos> I don't know the code well, but I know it's python, and I know it can issue mdi calls
[15:03:31] <micges_work> going home, bbl
[15:03:35] <SWPadnos> oh, I thought thatwas yours
[15:03:38] <SWPadnos> his
[15:03:40] <SWPadnos> oh well
[15:03:49] <Dave911> np....
[15:05:08] <skunkworks_> maybe acemi.. I think
[15:09:02] <Dave911> Well I have got a ton of ideas now to consider... I really appreciate everyones help! Just reading the manuals is a lot to swallow and not everything sticks...
[15:09:04] <Dave911> I'll print this chat out and go through the ideas one by one .... I've got two spring machines to consider and one bottle casepacker also. From a motion standpoint they all have similar requirements...
[15:09:42] <SWPadnos> enjoy
[15:10:15] <Dave911> Gotta go load up my car to do some EMC2 lathe testing today including threading with a low count encoder via the LPT port .. :-) I'll report back on that.. Thanks!
[15:15:39] <CIA-65> EMC: 03cradek 07random_toolchange * re1f8d02f8cf7 10/ (8 files in 6 dirs): restore old functionality for nonrandom toolchanges
[15:15:39] <CIA-65> EMC: 03cradek 07random_toolchange * rfe31d2b6c6da 10/configs/ (41 files in 37 dirs): fix all these crazy tool tables again
[15:15:40] <CIA-65> EMC: 03cradek 07random_toolchange * re743c98f9025 10/configs/sim/ (axis.ini random_tc.ini): make a sim config with a random toolchanger
[15:16:42] <cradek> anyone interested should try this out
[15:16:45] <cradek> the only way it (purposely) differs from the old behaviour is that large tool numbers are allowed.
[15:34:41] <cradek> the tool table has columns POCKET and TOOL and when written out they both get the tool number
[15:37:51] <cradek> Merge made by recursive! Merge made by recursive!
[15:37:55] <cradek> that makes me so happy
[15:40:55] <skunkworks_> somebody likes git... ;)
[15:41:20] <cradek> I tried a merge of both random_toolchange and ss-wrapped-rotary and they both just worked
[15:41:42] <cradek> unless someone objects soon, I'll merge them both...
[16:25:17] <jepler> cradek: to the extent that I know what's in the branches, I think that's fine
[16:28:02] <cradek> jepler: I'm finishing a little more of ss-w-r first
[16:28:15] <cradek> making some gigo cases into errors
[16:28:57] <jepler> post-2.4 we should consider doing like the git people do with the "next" branch
[16:29:25] <jepler> big new features are done on their own branches and almost never have master merged into them
[16:30:06] <jepler> the guy in charge of "next" merges all the "getting done-ish" branches into "next", which adventurous people can use for testing
[16:30:55] <jepler> "next" is rewound / rebased every time, so it doesn't accumulate cruft
[16:31:15] <cradek> doesn't that screw up everyone's tracking of next?
[16:31:28] <jepler> everyone knows not to base their own changes off "next"
[16:32:30] <jepler> .. if you don't have any changes to an upstream branch that gets rebased, it's no big deal
[16:52:48] <CIA-65> EMC: 03cradek 07ss-wrapped-rotary * r4d07a4b8f819 10/src/emc/rs274ngc/ (interp_convert.cc interp_find.cc rs274ngc_interp.hh): reject commanded values outside (-360,360) for wrapped rotaries
[17:11:25] <mshaver> If I change a file (like tp.c) in my git files, how do I get git to forget my changes? In cvs all I had to do was either delete the file (and a checkout would replace it for me), or copy an unchanged version into the source and cvs would be happy.
[17:11:52] <cradek> for one file: git checkout tp.c
[17:12:05] <cradek> for all your changes including commits since origin/master: git reset --hard origin/master
[17:16:41] <mozmck> tp.c is the trajectory planner right?
[17:16:46] <cradek> yes
[17:16:50] <cradek> most of it anyway
[17:17:58] <mshaver> OK, that fixed my tp.c problem. Now, I added a couple files, did a git pull --rebase, and a git add <my_files>, and a git push, and I get:
[17:18:05] <mshaver> $ git push
[17:18:06] <mshaver> To ssh://mshaver@git.linuxcnc.org/git/emc2.git
[17:18:06] <mshaver> ! [rejected] master -> master (non-fast forward)
[17:18:06] <mshaver> ! [rejected] v2_3_branch -> v2_3_branch (non-fast forward)
[17:18:06] <mshaver> error: failed to push some refs to 'ssh://mshaver@git.linuxcnc.org/git/emc2.git'
[17:18:22] <mshaver> I wonder why it's rejected?
[17:18:50] <cradek> not fast-forward means you need to pull others' changes and incorporate them with yours, using either rebase or merge
[17:18:51] <mshaver> ok ,and a commit
[17:19:08] <cradek> you probably want to do a git pull --rebase
[17:19:16] <mshaver> so, just a plain git pull?
[17:19:26] <mshaver> oh, never mind
[17:19:27] <cradek> either, depending on whether you want to end up with a merge
[17:19:41] <cradek> if your changes are simple and won't conflict with others', a pull --rebase is probably preferable
[17:19:58] <mshaver> I want a merge, I think. I want to just be up to date with everybody.
[17:22:29] <mozmck> what kind of algorithm is used for the planner now?
[17:22:44] <CIA-65> EMC: 03mshaver 07master * reaa7cd63fbb5 10/configs/smithy/ (516gecko.hal 516gecko.ini): Add support for 516 milling machine
[17:22:45] <CIA-65> EMC: 03mshaver 07master * rd04cf3dec8a7 10/configs/smithy/README: Add support for 516 milling machine
[17:22:48] <cradek> trapezoidal velocity profile with overlap
[17:23:49] <mozmck> have not heard of that. is there somewhere I can read on it?
[17:25:27] <mozmck> I saw the stuff Art was talking about with Mach and have been reading a number of papers on smooth trajectory planning. I'm quite interested in the stuff.
[17:27:07] <cradek> by all means, please rewrite it :-)
[17:27:40] <mozmck> heh, I've got a lot to learn, and when they mention "jerk-limited" I think that might rule me out...
[17:27:50] <cradek> not sure where you can read about it - it means there is no limit on the derivative of accel
[17:27:59] <mozmck> but I'm studying stuff anyhow...
[17:28:18] <cradek> so for a single move (accel, cruise, decel), accel profile looks like +a, 0, -a
[17:28:39] <cradek> vel profile is derivative of that (looks like a trapezoid)
[17:28:51] <CIA-65> EMC: 03mshaver 07v2_3_branch * r217b41771707 10/configs/smithy/README: Add support for 516 milling machine
[17:28:52] <CIA-65> EMC: 03mshaver 07v2_3_branch * r130d8bbefdc4 10/configs/smithy/ (516gecko.hal 516gecko.ini): Add support for 516 milling machine
[17:28:53] <cradek> position profile is derivative of that, looks smoothish
[17:29:28] <mozmck> yeah, C1 continuity? and what would be nice is C2 from what I read.
[17:29:57] <cradek> to blend, if you overlap your trapezoids so the decel of #1 and the accel of #2 add, you get constant velocity through the blend
[17:31:03] <cradek> if you move the "no limt on derivative" to jerk, you get trapezoidal accel (for instance), S-curvy vel, even smoother position
[17:31:16] <cradek> bbl, lunch
[18:04:54] <CIA-65> EMC: 03mshaver 07v2_3_branch * rb4fe44cca124 10/configs/smithy/ (23 files): Fix the whitespece errors by removing all the trailing spaces
[18:06:27] <CIA-65> EMC: 03mshaver 07master * rd8f9067e691d 10/configs/smithy/ (23 files): Fix the whitespece errors by removing all the trailing spaces
[18:52:21] <CIA-65> EMC: 03cradek 07master * ra53d0c6c166a 10/src/emc/ (24 files in 8 dirs): checkpoint: building and running
[18:52:21] <CIA-65> EMC: 03cradek 07master * rb6a81de85597 10/ (configs/sim/sim.tbl src/emc/iotask/ioControl.cc): tool table regeneration works now
[18:52:22] <CIA-65> EMC: 03cradek 07master * r028dd2b265c5 10/src/emc/ (7 files in 5 dirs): stop being ridiculous and start counting properly from zero
[18:52:23] <CIA-65> EMC: 03cradek 07master * r9b589317e78c 10/src/emc/ (8 files in 4 dirs): g10 l1 works right now - so writing entries works
[18:52:26] <CIA-65> EMC: 03cradek 07master * rd5ad5faf9e07 10/configs/sim/axis.ini: tooledit needs work now, so disable it for now
[18:52:29] <CIA-65> EMC: 03cradek 07master * rc52ebfcbcc6d 10/src/emc/usr_intf/axis/scripts/axis.py: fix traceback when typing into the touch off window
[18:52:32] <CIA-65> EMC: 03cradek 07master * r24910dacc94e 10/src/emc/ (7 files in 5 dirs): give both prepped pocket and tool number to hal. fixes manual tool change.
[18:52:35] <CIA-65> EMC: 03cradek 07master * r5bdc4f06a0b9 10/ (8 files in 7 dirs): hide the detail of pockets when on a nonrandom machine
[18:52:40] <CIA-65> EMC: 03cradek 07master * r43358dc9c380 10/ (43 files in 39 dirs): change existing tool tables to the new format for non-random changers
[18:52:43] <CIA-65> EMC: 03cradek 07master * re15a6674127e 10/src/emc/rs274ngc/interp_convert.cc: remove debug messages
[18:52:46] <CIA-65> EMC: 03cradek 07master * r38914a3f7b2f 10/ (108 files in 36 dirs): Merge branch 'master' into random_toolchange
[18:52:49] <CIA-65> EMC: 03cradek 07master * rdb14b6328f3f 10/ (3 files in 2 dirs): make axis.ini a random-carousel machine, also a few cleanups
[18:52:54] <CIA-65> EMC: 03cradek 07master * r1bc050308980 10/configs/sim/sim.tbl: demonstrate that large tool numbers are now possible
[18:52:57] <CIA-65> EMC: 03cradek 07master * r415a0b937031 10/nc_files/arcspiral.ngc: for testing TLO
[18:53:01] <CIA-65> EMC: 03cradek 07master * rd78a0f310bd3 10/src/emc/rs274ngc/interp_convert.cc: fix getting the wrong TLO when M6 and G43 were in the same block
[18:53:04] <CIA-65> EMC: 03cradek 07master * r42462fb19fad 10/src/emc/rs274ngc/ (interp_check.cc interp_convert.cc): G10 L20 to set a G5x coordinate system relative to the current position
[18:53:09] <CIA-65> EMC: 03cradek 07master * r410af7ebc429 10/src/emc/ (4 files in 3 dirs): fix AXIS's tool display, tool touch off
[18:53:12] <CIA-65> EMC: 03cradek 07master * r0f5cf0ab3dca 10/ (27 files in 16 dirs): Merge branch 'master' into random_toolchange
[18:53:17] <CIA-65> EMC: 03cradek 07master * r22e21e484021 10/src/emc/rs274ngc/ (interp_check.cc interp_convert.cc): G10 L10 to touch off a tool
[18:53:20] <CIA-65> EMC: 03cradek 07master * r342b6b27bdd2 10/src/emc/usr_intf/axis/scripts/axis.py: use new G10 L10/L20 to simplify touch-off code
[18:53:25] <CIA-65> EMC: 03cradek 07master * r51cd36dc7970 10/src/emc/usr_intf/axis/scripts/axis.py: Merge branch 'master' into random_toolchange
[18:53:28] <CIA-65> EMC: 03cradek 07master * r0f97da7fc08e 10/src/emc/usr_intf/axis/scripts/axis.py: machine coordinates should be modded too, I think
[18:53:33] <CIA-65> EMC: 03cradek 07master * ra8aa3ddced24 10/src/emc/rs274ngc/ (interp_find.cc rs274ngc_interp.hh): fix G53, ss-style
[18:53:36] <CIA-65> EMC: 03cradek 07master * ree1472b4491f 10/src/emc/rs274ngc/interp_find.cc: fix eventual range problem caused by going through an int
[18:53:41] <CIA-65> EMC: 03cradek 07master * r6504c7e89e8e 10/src/emc/rs274ngc/ (interp_convert.cc interp_find.cc interp_internal.cc): fix probe result, g28/g30, g28.1/g30.1
[18:53:44] <CIA-65> EMC: 03cradek 07master * r985939818ae5 10/src/emc/ (3 files in 2 dirs): at least G0 seems to work
[18:53:49] <CIA-65> EMC: 03cradek 07master * r94c478f07639 10/src/emc/task/emccanon.cc: Merge branch 'master' into ss-wrapped-rotary
[18:53:54] <CIA-65> EMC: 03cradek 07master * r061de904ff50 10/ (7 files in 3 dirs): make this properly configurable with an ini entry
[18:53:57] <CIA-65> EMC: 03cradek 07master * r8a20888daf91 10/ (46 files in 20 dirs): Merge branch 'master' into random_toolchange
[18:54:00] <CIA-65> EMC: 03cradek 07master * r3654c98e1eb3 10/src/emc/usr_intf/touchy/emc_interface.py: show prepped tool, not prepped pocket
[18:54:05] <CIA-65> EMC: 03cradek 07master * r286910510f26 10/ (26 files in 5 dirs): Merge branch 'master' into random_toolchange
[18:54:08] <CIA-65> EMC: 03cradek 07master * r5fa491d570d9 10/src/emc/ (9 files in 5 dirs): Merge branch 'master' into random_toolchange
[18:54:11] <CIA-65> EMC: 03cradek 07master * re1f8d02f8cf7 10/ (8 files in 6 dirs): restore old functionality for nonrandom toolchanges
[18:54:14] <CIA-65> EMC: 03cradek 07master * rb9080e3db4a0 10/ (20 files in 9 dirs): Merge branch 'master' into random_toolchange
[18:54:19] <CIA-65> EMC: 03cradek 07master * rfe31d2b6c6da 10/configs/ (41 files in 37 dirs): fix all these crazy tool tables again
[18:54:24] <CIA-65> EMC: 03cradek 07master * re743c98f9025 10/configs/sim/ (axis.ini random_tc.ini): make a sim config with a random toolchanger
[18:54:27] <CIA-65> EMC: 03cradek 07master * r4d07a4b8f819 10/src/emc/rs274ngc/ (interp_convert.cc interp_find.cc rs274ngc_interp.hh): reject commanded values outside (-360,360) for wrapped rotaries
[18:54:32] <CIA-65> EMC: 03cradek 07master * r641cc414ce1d 10/ (8 files in 3 dirs): Merge branch 'ss-wrapped-rotary'
[18:54:35] <CIA-65> EMC: 03cradek 07master * r7e8cb078b848 10/ (74 files in 49 dirs): Merge branch 'random_toolchange'
[18:54:38] <CIA-65> EMC: 03cradek 07master * r1ca511955f19 10/ (8 files in 7 dirs): flog sai into working again, and update the tests due to canon change
[18:54:41] <CIA-65> EMC: 03cradek 07master * r08265acbf9e2 10/configs/smithy/ (25 files): Merge branch 'master' of ssh://cradek@git.linuxcnc.org/git/emc2
[18:55:49] <cradek> whew
[18:56:59] <CIA-65> EMC: 03cradek 07master * rc83c69c6c4ab 10/src/emc/usr_intf/touchy/ (emc_interface.py touchy.glade touchy.py): Merge branch 'master' into random_toolchange
[19:04:47] <skunkworks_> wow
[19:51:27] <cradek> lotsa new features...
[20:36:54] <micges> cradek: yes indeed
[20:54:03] <cradek> hope someone other than me tries them...
[20:54:16] <cradek> lots of doc updating needed - I should try to figure out (again) how to edit the docs
[20:56:23] <micges> cradek: I can try wrapped rotary on my mill
[20:56:30] <micges> on monday
[20:56:56] <cradek> cool
[21:01:52] <micges> I have feature to consider: velocity type joints(not positions), no ferror, no position pins in axis.* and such, what do you think?
[21:04:16] <micges> very usable to Z axes in 2d machines with only partial Z axis (like stepper + switch only) where position is useless
[21:04:50] <micges> (or DC + home switch)
[21:18:36] <micges> err, this can be achieved without any emc modifications
[21:19:15] <cradek> yeah sort of - depends how you want to control it I guess
[21:19:26] <cradek> I don't understand what you want well enough to comment
[21:19:36] <cradek> bbl, going home (weekend! yay!)
[21:58:23] <CIA-65> EMC: 03cradek 07master * rce21f446d159 10/nc_files/arcspiral.ngc: Revert "for testing TLO"
[22:35:18] <PCW> cradek: heres a patched SVST8_3P bitfile and the changed sources
http://filebin.ca/hkgfzu
[22:35:20] <PCW> changes are:
[22:35:21] <PCW> 1. Probe polarity bit can be changed dynamically without triggering a probe event
[22:35:23] <PCW> 2. Channel number of probe pin is 0x80 to indicate a global or "all" pin
[22:58:12] <CIA-65> EMC: 03jthornton 07master * r37dcfc88f1ff 10/docs/src/hal/rtcomps.lyx: Add info on Hal Meter
[22:58:13] <CIA-65> EMC: 03jthornton 07master * rd74da6500496 10/docs/src/ (Master_Integrator.lyx hal/components.lyx): Minor Edits
[23:19:01] <CIA-65> EMC: 03jthornton 07master * r747a3c7740d1 10/docs/src/config/ini_config.lyx: Add Random Tool Change to manual.
[23:23:41] <CIA-65> EMC: 03jthornton 07master * r6d96438f7a92 10/docs/src/hal/images/ (hal-meter01.png hal-meter02.png): Add Hal Meter images
[23:33:16] <jthornton> * jthornton wanders off to see if the buildbot is still failing...