Back
[00:00:14] <jmkasunich> found that note on a webpage
[00:00:35] <SWPadnos> hmmm
[00:01:13] <jmkasunich> I see two possibilities - try getting that libc package
[00:01:25] <SWPadnos> that's installed - but it doesn't provide the bitops header
[00:01:28] <jmkasunich> or add a 86_64 stanza to rtapi_bitops
[00:01:52] <SWPadnos> yep
[00:01:56] <jmkasunich> by copying the _64 specific code from your kernel header, just like we did for the i386 code
[00:02:12] <alex_joni> or use cvs up
[00:02:37] <jmkasunich> heh
[00:03:17] <SWPadnos> well, I can try that last ;)
[00:03:36] <jepler> it built on my 64-bit edgy
[00:03:53] <jepler> I ran axis and "machined" a bit of the splash screen
[00:04:43] <jmkasunich> we just have to trust that the code is good - you'll never be able to test it
[00:04:54] <jepler> indeed
[00:05:16] <jmkasunich> I think Linus knows what he's doing tho
[00:05:59] <jmkasunich> jepler: why did you include __set_bit?
[00:06:18] <jepler> jmkasunich: I just copied the whole header
[00:06:19] <jmkasunich> and __change_bit (the non-atomic ones)?
[00:06:33] <jmkasunich> oh
[00:08:38] <jepler> want me to take them out?
[00:11:27] <jepler> the file is a lot smaller when only the two rtapi uses -- test_and_set_bit, test_and_clear_bit -- are defined
[00:20:37] <jepler> meanwhile my debian 3.1 install is 6% done
[00:21:24] <jepler> i saw something about python2.3 scroll by, I guess 3.1 is old?
[00:21:28] <jepler> "stable"
[00:21:33] <alex_joni> yeah, that's sarge
[00:21:55] <alex_joni> the 'latest' people use is testing usually
[00:22:19] <jepler> now you tell me
[00:22:37] <alex_joni> you didn't ask
[00:22:46] <alex_joni> http://www.debian.org/releases/testing/
[00:23:07] <SWPadnos> ok. thanks for the bitops update, it compiled
[00:23:21] <SWPadnos> I think I'll have a list of issues with high res screens ;)
[00:23:29] <jepler> SWPadnos: fucking whiner
[00:23:31] <SWPadnos> heh
[00:23:34] <alex_joni> oh
[00:23:47] <jepler> SWPadnos: send me a 200dpi screen and I'll consider looking into it
[00:23:51] <SWPadnos> at least I'm not asking for a configurable GUI!
[00:23:59] <alex_joni> * alex_joni makes a new entry in the bug & feature requests on SF
[00:24:03] <SWPadnos> what if I let you look at it at Fest?
[00:24:06] <alex_joni> and I'm autoassigning SWP to that
[00:24:08] <SWPadnos> heh
[00:24:27] <SWPadnos> I note that pickconfig.tcl is using a font that's oh so tiny on this screen ...
[00:25:10] <alex_joni> * alex_joni passes SWPadnos one instance of xmagnify
[00:25:35] <jepler> I think that in many places, pixel fonts such as {Helvetica -12} are used, when it should be the point-based {Helvetica 12}
[00:25:42] <SWPadnos> hmmm
[00:25:44] <SWPadnos> right
[00:25:56] <SWPadnos> the preview looks stunning though, I've got to say
[00:26:03] <jepler> I'm sure it does
[00:26:09] <jepler> looks nice on my 150dpi (I think) laptop
[00:26:34] <SWPadnos> that's a 17"?
[00:26:39] <SWPadnos> or is it 15
[00:26:40] <jepler> it's a 15" 1920x1200
[00:26:43] <jepler> not sure what DPI that makes
[00:26:49] <SWPadnos> oh - that's very good.
[00:26:51] <jepler> it seems I've told xorg it's 75dpi though
[00:26:56] <SWPadnos> heh
[00:26:59] <SWPadnos> how odd
[00:27:12] <SWPadnos> you must have very good near vision
[00:28:15] <jepler> I use a huge 18-pixel-tall font in my terminals
[00:29:00] <SWPadnos> hmmm. 18 pixels is about 6 points on this monitor
[00:29:55] <jepler> closer to 9 points here
[00:30:14] <SWPadnos> ok, 133 DPI or so
[00:30:28] <SWPadnos> about the same as the Apple and Dell 30" monitors
[00:30:38] <SWPadnos> wait, that can't be right
[00:30:59] <jepler> 1920x1200 pixels, 15.1 or 15.4 inches
[00:30:59] <SWPadnos> ok, it is I guess
[00:32:00] <jepler> this 5x9 font ain't bad
[00:33:26] <jepler> apparently that gives me 317x105 characters in my terminal
[00:33:37] <SWPadnos> heh
[00:34:42] <SWPadnos> the funny part is that I can't take a screenshot to show you any issues I have
[00:34:51] <jepler> because it'll look fine to me?
[00:35:03] <SWPadnos> yep - other than the really big title bra
[00:35:06] <SWPadnos> bar
[00:36:04] <alex_joni> bit title bra?
[00:36:21] <jepler> alex_joni: he means "big titty bra"
[00:36:21] <jepler> it was a typo
[00:36:42] <SWPadnos> hmmm - that reminds me. bbl
[00:36:44] <jepler> SWPadnos: what resolution is this 30" monitor? My math says that a 2560x1600 30" monitor is 100dpi
[00:36:47] <SWPadnos> :)
[00:36:59] <SWPadnos> hmmm - could be. I thought it was a bit higher
[00:37:21] <jepler> (dell 3007WFP)
[00:37:33] <SWPadnos> yp
[00:37:52] <SWPadnos> yep - that's the one. it looked higher res to me, but that could have been due to overall sizxe
[00:37:54] <SWPadnos> size
[00:37:59] <SWPadnos> they're very large monitors
[00:38:38] <SWPadnos> they're on the border of being too big
[00:39:32] <jepler> the comfortable viewing distance must be further away
[00:39:58] <SWPadnos> yeah - it's quite a large portion of the field of view
[00:40:18] <SWPadnos> Enemy Territory looks nice on them :)
[00:41:31] <SWPadnos> heh - I went to load a big ngc file but couldn't find one on that machine, so I tried to load a big jpeg - a very big jpeg
[00:41:52] <SWPadnos> I ended up with a very little window: "Exit code 1" :)
[00:42:14] <alex_joni> load the big jpeg into emc?
[00:42:38] <jepler> using image-to-gcode?
[00:42:44] <SWPadnos> (not as big as Matt's bitmaps, but still large at 5400x2700)
[00:42:54] <SWPadnos> I guess - it showed up in the Axis file selector
[00:43:09] <jepler> I doubt I ever tried a jpeg, and none that big
[00:43:26] <jepler> greyscale too of course
[00:43:41] <alex_joni> bet this was full colour
[00:43:52] <SWPadnos> heh - this is one of the high res blue marble images - very non grayscale
[00:44:08] <SWPadnos> it was in the list, so I clicked it
[00:44:11] <SWPadnos> ow!
[00:45:17] <alex_joni> Mmmm, you guys might want to consider this beauty sleep
[00:45:16] <alex_joni> thing in a serious way. <grin>
[00:45:23] <alex_joni> ROFL..
[00:45:27] <alex_joni> * alex_joni decides to do just that
[00:45:31] <alex_joni> good night all
[00:45:33] <jepler> see you alex_joni
[00:45:59] <jepler> me finds a 1920x1200 crop of some apollo moon thing and tries to load it in axis
[00:46:03] <jmkasunich> goodnight alex_joni
[00:46:08] <SWPadnos> night Alex
[00:46:10] <jepler> that sure makes my firewall go up
[00:46:27] <SWPadnos> hmmm. jepler - there's a buglet in AXIs regarding file loading
[00:46:32] <jepler> SWPadnos: what's that?
[00:46:44] <SWPadnos> I accidentally clicked the reload button after the failed image load
[00:47:01] <SWPadnos> the preview for the prior file is still onscreen, but I got theerror again instead
[00:47:04] <jepler> if you do that it should try running the converter again
[00:47:18] <SWPadnos> then maybe the preview should be blanked at file load time
[00:47:27] <jepler> hm I guess I knew what I expected it to do but you expected something else
[00:47:33] <jepler> yeah could be
[00:47:44] <SWPadnos> right - I see tor.ngc preview, but reload tells me there's an error
[00:47:48] <SWPadnos> tort
[00:47:52] <jmkasunich> bugfix: adjust user expectations
[00:47:57] <SWPadnos> wham!
[00:48:05] <SWPadnos> (not you pete
[00:48:09] <SWPadnos> )
[00:48:14] <alex_joni> jmkasunich: congrats on the stepgen fixes.. they seem right
[00:48:22] <jmkasunich> hope so
[00:48:30] <alex_joni> at least Ed says so
[00:48:37] <jepler> they broke some of the tests, but they're dumb "compare to expected output" tests
[00:48:40] <SWPadnos> at least Ed thinks so ;)
[00:48:40] <jmkasunich> it won't be conclusive until he runs flowsnake on the old code
[00:48:55] <jepler> (stepgen changes in TRUNK)
[00:49:19] <jmkasunich> thats the problem with regression testing - not all differences are regression
[00:49:32] <jmkasunich> and for sufficiently complex problems, the "correct" output isn't easy to define
[00:49:54] <jepler> yow this made a big g-code file: 351661 lines
[00:50:06] <jmkasunich> the jpeg?
[00:50:11] <jepler> yes
[00:50:30] <jmkasunich> thats significantly less than one line per pixel
[00:50:34] <SWPadnos> wow. and that converter actually collapses colinear segments, doesn't it?
[00:50:42] <jepler> yes
[00:51:39] <jmk-vm02> don't need this anymore...
[00:52:12] <jepler> eek axis just segfaulted
[00:52:36] <SWPadnos> oops
[00:53:25] <jmkasunich> jepler: you didn't remove the unused _64 stuff from bitops yet did you? if not I'm going to do that
[00:53:45] <jepler> jmkasunich: I have it ready to commit
[00:54:01] <jepler> jmkasunich: just hadn't gotten to it yet
[00:54:03] <jmkasunich> thats why I asked ;-)
[00:54:10] <jepler> was actually waiting on a rebuild on edgy but forgot about it
[00:54:38] <jepler> done!
[00:54:50] <jmkasunich> * jmkasunich updates manpage and lyx for the modified stepgen
[00:55:36] <jepler> I can't find where in my X server config I've selected 75 dpi!
[00:55:39] <jepler> didn't this just come up earlier?
[00:56:04] <SWPadnos> system -> Preferences -> fonts
[00:56:13] <SWPadnos> details, resolution
[00:56:41] <jepler> hmph -- I don't use gnome
[00:57:51] <SWPadnos> oh, then try Option "DPI" "100x100" in the driver section of xorg.conf
[00:57:59] <SWPadnos> it may work, it may not ;)
[00:59:45] <jmkasunich> does anybody know if there is an equivalent to <pre></pre> in man page format?
[01:00:22] <jepler> jmkasunich: no, I don't know how to set typewriter font or preserve whitespace
[01:00:55] <jmkasunich> darn
[01:01:06] <jmkasunich> no ascii art timing diagrams in the man page
[01:01:17] <jmkasunich> http://www.pastebin.ca/390138
[01:01:41] <jmkasunich> that is a comment block in the source, where only the intrepid will find it
[01:03:37] <SWPadnos> are manpages closer to groff or nroff?
[01:03:52] <SWPadnos> this groff page may be slightly helpful:
http://faustus.homelinux.org/mom/momdoc/definitions.html#TERMS_FIXEDWIDTHFONT
[01:03:57] <jepler> I always read 'man groff_man' when trying to learn what to type
[01:06:38] <SWPadnos> jepler, do you know the algorithm for finding what object the user has clicked (in the preview pane)?
[01:06:58] <SWPadnos> does it just go through fake-plotting objects until it finds one on the same point (or nearby)?
[01:07:25] <jepler> SWPadnos: it uses the opengl feedback buffer
[01:07:43] <SWPadnos> uh - ok :)
[01:07:59] <jepler> SWPadnos: a special projection matrix is computed, which includes only items within a small rectangular aperture of the clicked point
[01:08:04] <SWPadnos> ok
[01:08:07] <jepler> SWPadnos: then the scene is drawn
[01:08:37] <jepler> SWPadnos: for each primitive (line, etc) which would have appeared at least partially in the projection, some information about it is recorded -- transformed depth values, as well as which line it belonged to
[01:08:37] <SWPadnos> gah. I hate it when I select "quit" instead of "properties"
[01:08:53] <jepler> SWPadnos: axis looks at all the ones that matched, and picks one. possibly it chooses the one with the least Z value but I don't remember for sure
[01:10:04] <SWPadnos> ok - the reason I asked is that I loaded a large file - 21M of g-code, and I can spin it around in very nice realtime (maximized)
[01:10:20] <SWPadnos> when I click in the preview, it takes roughly 2 seconds to hilight the line
[01:10:34] <SWPadnos> 2 seconds before hilighting, I should say
[01:11:44] <SWPadnos> it's 515634 lines of g-code (and roughly 2755 minutes as programmed :) )
[01:12:37] <jepler> SWPadnos: it could be the "hit" routine or it could be the next part, which figures out which other primitives belong to that line of g-code, and creates a new display list with only those items in it
[01:12:44] <jepler> that runs at python speeds, not opengl speeds
[01:12:58] <SWPadnos> ok
[01:13:11] <SWPadnos> true - it needs to search the G-code, not just the buffer
[01:13:45] <jepler> and it can't do something like a binary search, because "line 100" could be responsible for movements that are well separated in the program -- if it's part of an O-sub for instance
[01:13:59] <SWPadnos> yep - when you pick a line in the text area, it's very quick to hilight it in the preview
[01:14:03] <SWPadnos> right
[01:14:54] <SWPadnos> I'm assuming that the G-code is still treated more or less as a stream, even though you can scroll through it in the text area
[01:15:17] <jepler> but that means it's the common step (prepare a display list) that is fast, and the uncommon step (find the primitive under the cursor) that is slow!
[01:15:43] <SWPadnos> no, because you don't need to prepare a display list if you click on the "source" of the preview line
[01:15:54] <SWPadnos> ?
[01:16:24] <jepler> the display list draws the part that is in cyan and thicker
[01:16:35] <SWPadnos> err - unless you're talking about the openGL display list, not the small area where the line could be (window)
[01:16:37] <SWPadnos> right - ok
[01:16:56] <jepler> yes, sorry
[01:17:43] <jepler> is your card a "workstation" card? I have heard that stuff like the feedback buffer is accelerated on workstation cards but not "gaming" cards, though I don't know that for sure
[01:17:55] <SWPadnos> yep - it's a Quadro FX3500
[01:18:13] <jepler> so much for that theory
[01:18:38] <SWPadnos> I had tried it on my opteron workstation, and benchmarks were much slower than the 7800GT
[01:19:03] <SWPadnos> in this other computer (slower overall, single CPU), the benchmarks are ~50% faster than the 7800GT
[01:19:13] <SWPadnos> much slower = 1/3 the frame rate
[01:24:49] <SWPadnos> ok - about the same amount of time on the opteron, 7800GT, maximized to one screen at 1920x1200
[01:25:05] <SWPadnos> so it doesn't seem to be the video card or the total number of pixels involved that's doing it
[01:25:39] <SWPadnos> assuming that axis is single-threaded, I'd bet it's CPU-bound (a single core of the opteron is around the same speed as the A64)
[01:36:05] <SWPadnos> hmm. it takes about the same amount of time to un-hilight the line by clicking far away from any preview objects
[01:40:08] <jepler> huh
[01:42:09] <SWPadnos> I should try again when there's less of a memory load. the system was getting a bit bogged down (but not on the Opteon ...)
[01:45:54] <SWPadnos> ok - about the same with lots of other stuff closed, on a 1G machine
[01:46:06] <SWPadnos> (memory use at 80%)
[01:48:08] <jepler> jmkasunich: it is truly barf-worthy but I have a little python program that takes your ascii-art diagram on input and writes something on output that shows up OK on terminal and html
[01:48:17] <jepler> jmkasunich: I'll check ps/pdf next, and if that works I'll share it with you
[01:48:51] <jepler> yep, looks right there too
[01:50:14] <jmkasunich> heh
[01:50:49] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/mkpre.py http://emergent.unpy.net/index.cgi-files/sandbox/mkpre_example.man http://emergent.unpy.net/index.cgi-files/sandbox/mkpre_example.ps http://emergent.unpy.net/index.cgi-files/sandbox/mkpre_example.html
[01:52:07] <jepler> jmkasunich: turns out the fixed font is called ".CR" (and .CB and .CI) but whitespace and newlines weren't preserved
[01:52:18] <jmkasunich> wow, the groff looks really messy in a text editor
[01:52:40] <jmkasunich> oh, hence the  
[01:53:55] <jmkasunich> so I segregate the ascii art in a file (remove leading and trailing text) then pipe it thru mkpre.py?
[01:54:23] <jmkasunich> and embed the resulting chunk in the manpage
[01:54:23] <jepler> right
[01:54:50] <jepler> it's .. not exactly automated
[01:54:53] <jmkasunich> thanks
[01:55:09] <jepler> you'll have to weigh the pros and cons
[01:55:42] <jepler> if you're going to use it, put the .py script somewhere in the source or doc tree
[01:55:54] <jmkasunich> and commit it?
[01:55:57] <jepler> yes
[01:56:02] <jepler> or I can
[01:56:12] <jmkasunich> go right ahead
[01:56:38] <jepler> but .. where?
[01:57:17] <jmkasunich> we don't have "source" for the manpages... I think there is exactly one foo.1.in file
[01:57:43] <jmkasunich> not that you can actually build manpages even with this tool
[01:57:48] <jmkasunich> how about emc2/scripts
[01:57:52] <jepler> too late
[01:58:16] <jmkasunich> that works
[02:09:06] <jmkasunich> funny, I don't recall writing the man pages in "infinitely long line" mode
[02:09:25] <jmkasunich> does something in the make system go in and remove newlines?
[02:09:39] <jmkasunich> or am I just getting senile
[02:10:10] <jmkasunich> I have a distinct feeling its the latter - I see a couple of lines that are broken
[02:30:34] <jepler> in what files?
[02:32:27] <jmkasunich> stepgen.9
[02:32:26] <jmkasunich> I
[02:32:33] <jmkasunich> I'm almost certain it was me
[02:32:46] <jmkasunich> I might have had the editor set to do soft line-wrapping
[02:32:54] <jmkasunich> (although thats not normal for me)
[02:33:09] <jepler> nothing in the build system should change newlines in those non-generated files
[02:38:12] <jmkasunich> musta been me
[15:36:48] <jepler> while it is a new feature, I'd like to backport hal_input
[15:37:23] <rayh> What does it do?
[15:37:25] <SWPadnos> it's a separate module - aren't those supposed to be OK for backporting?
[15:37:26] <jepler> I think it works right, and if it doesn't, all you have to do is not use it
[15:37:51] <jepler> rayh: it lets you hook any linux-recognized input device with HAL
[15:37:59] <SWPadnos> rayh, turns things like a keyboard into a bunch of HAL bits (for the keys and lights)
[15:38:00] <jepler> rayh: like hal_joystick but for more devices
[15:38:19] <jepler> http://linuxcnc.org/docs/devel/html/man/man1/hal_input.1.html
[15:38:22] <rayh> Great.
[15:39:08] <jepler> for instance, you should be able to plug in a USB keypad, and hook each key to a different action with halui
[15:39:18] <jepler> or a joystick, or one of those USB jog wheels, or ..
[15:39:41] <jepler> in fact one person on the mailing list is using it with the "shuttlexpress" jog wheel
http://www.contourdesign.com/shuttlepro/shuttlexpress.htm
[15:39:48] <rayh> This ought to come with a "warning, use with machine tools at your own risk."
[15:40:11] <SWPadnos> hmmm. I guess I should try loading it with my force feedback joystick - does it bother with analog outputs (if it sees them)?
[15:40:31] <jepler> SWPadnos: alex tried some force-feedback joystick but found that linux had no force feedback support for that particular device
[15:40:42] <SWPadnos> then again, I have no RT system that can use that stick
[15:40:44] <jepler> SWPadnos: hal_input doesn't have any force feedback support yet
[15:41:11] <SWPadnos> hmmm. ok, I think this one is supported - it's a Logitech Wingman
[15:41:15] <rayh> cradek: You around?
[15:41:20] <SWPadnos> I'd just epect to get a bit or analog output for that
[15:41:24] <SWPadnos> expect
[15:41:52] <jepler> rayh: I happen to know he's not around
[15:42:01] <rayh> Ah thanks.
[15:42:37] <rayh> I was wondering if he found out what was happening with stepping through gcode and g4, m2.
[15:42:50] <jepler> I haven't heard anything more about that either
[15:43:02] <rayh> k
[15:43:07] <rayh> I'll experiment a bit more.
[15:43:08] <jepler> if it worked for you in mini (or was it tkemc?) it seems most likely it's a bug in axis..
[15:43:17] <jepler> were you able to confirm the bug in axis?
[15:44:45] <rayh> It works properly in both mini and tkemc.
[15:44:54] <rayh> Not tried axis yet. Will now.
[15:46:05] <jepler> hm
[15:46:09] <jepler> I'm using TRUNK and tried configs/sim/tkemc
[15:46:25] <jepler> I think I'm hitting the problem
[15:46:30] <jepler> running this program:
http://pastebin.ca/393441
[15:47:04] <jepler> I hit run, then pause, then step
[15:47:18] <jepler> pause when it's running the line 'g1x1f20'
[15:47:44] <jepler> I wait several seconds after it reaches X 1.0000, then press 'step' again
[15:48:10] <jepler> I wait several more seconds, then press 'step' a third time
[15:48:27] <jepler> now I think it should be executing 'g1x0' but it it still shows 'g1x1f20' as the highlighted line
[15:51:27] <rayh> okay. I see that axis does not move on when it hits the g4
[15:52:01] <rayh> I'll go get the paste
[15:52:14] <jepler> when you tested in tkemc, did you: hit run, *then pause*, then step?
[15:52:27] <jepler> it looks like tkemc works if I hit run, then step
[15:52:48] <jepler> (axis won't let you do this -- for some reason we only let you hit step while already paused, probably due to a bug we saw in some version of emc)
[15:53:21] <rayh> I start the program using step.
[15:53:49] <rayh> I see you are using the pause on a line by itself.
[15:53:54] <rayh> I've never tried that.
[15:54:12] <SWPLinux> actually, I see the problem with tkemc after starting with step
[15:55:19] <SWPLinux> open file and press step (or press step after a run finishes)
[15:55:45] <SWPLinux> g1x1f20 gets hilighted
[15:55:53] <rayh> Mini does not highlight the g4 on a line by itself but it does go on when you press step.
[15:56:08] <SWPLinux> press step, motion happens and the g1 line remains hilighted
[15:56:26] <SWPLinux> press step, the g1 remains hilighted
[15:56:39] <SWPLinux> press step, the second g1 gets hilighted, and motion occurs
[15:56:45] <rayh> The step routine works its way into the program a logical element rather than block at a time.
[15:57:00] <SWPLinux> I was pausing for some time after each press
[15:57:04] <rayh> Some program starting routines will require a number of steps before any motion starts.
[15:57:35] <SWPLinux> ok - right
[15:57:47] <SWPLinux> tkemc does the same thing when running normally
[15:58:03] <rayh> the g1x1f20 requires two step presses.
[15:58:04] <SWPLinux> the g4 line is only hilighted for a fraction of a second
[15:58:18] <jepler> I don't think I've seen the g4 line be highlighted at all
[15:58:38] <SWPLinux> right - I think I saw it flicker one time
[15:59:22] <rayh> But in the case of the tcl stuff it does go past when you press step again.
[15:59:46] <SWPLinux> yes. it looks like the G4 line never gets hilighted, even wien you just run the program normally
[15:59:51] <SWPLinux> when
[15:59:58] <rayh> step is executing the g4 line and then waiting for another step to execute the next.
[16:00:17] <rayh> No it won't because there is no motion there.
[16:00:35] <rayh> In my testing I had a motion command x1 g4 p5
[16:00:56] <rayh> It did not highlight the line until after the dwell.
[16:01:47] <SWPadnos> odd. the dwell is after the motion, isn't it?
[16:02:45] <rayh> if a dwell is on a line it is the first thing executed.
[16:03:19] <SWPadnos> ok
[16:03:55] <rayh> That has always seemed wrong to me but it has always been first.
[16:04:33] <rayh> Because dwell is most often used at the end of a drill or mill to depth to finish the bottom of the hole.
[16:05:30] <jepler> I've never seen a dwell and a motion on the same line unless it was a canned cycle
[16:06:10] <rayh> We all do em different.
[16:06:38] <SWPadnos> ok - that was my thought - move, pause (clear chips or whatever), then move on
[16:07:15] <rayh> And when it is on a line by itself, it requires an extra step press.
[16:07:26] <rayh> I think that may be the clue to this.
[16:07:43] <SWPadnos> it doesn't seem to need an extra press
[16:07:59] <SWPadnos> it just seems that there's no feedback in the GUI that the G4 line has executed
[16:08:04] <SWPadnos> (or is executing)
[16:09:07] <rayh> non motion lines don't often trigger a move in the active line variable
[16:10:22] <rayh> I added a y1 move to jeff's paste
[16:10:47] <SWPadnos> just after the dwell?
[16:10:53] <rayh> If I put it on the line with p4p1
[16:11:08] <rayh> the single step initiates the dwell and then the motion
[16:11:27] <rayh> If I put it on a line after it requires two step presses.
[16:11:33] <rayh> with mini anyway.
[16:11:58] <jepler> try it this way: hit run, *then pause*, then step
[16:12:28] <jepler> when I do it that way, no number of "step"s gets me to the "g1x0" motion
[16:16:26] <rayh> Yep.
[16:16:53] <rayh> and since you don't initiate a program run using step you don't see what I'm seeing.
[16:21:45] <rayh> I wonder why there is a difference in the execution of the two ways of using step.
[16:23:19] <jepler> in tkemc, if I start at e.g., x=.5 I have to hit 'Step' 'Step' to go to x=0 (the first 'g0x0y0z0' line), and the third 'Step' goes to x=1
[16:28:19] <rayh> Right there are some setup "steps" in program start.
[16:28:39] <rayh> step does not match up one to one with blocks of gcode
[16:32:01] <rayh> same lack of step happens with t1m6
[16:32:12] <jepler> I put an item on sourceforge about the "run-pause-step" problem:
https://sourceforge.net/tracker/index.php?func=detail&aid=1680007&group_id=6744&atid=106744
[16:32:27] <jepler> with run-pause-step? or with step-only?
[16:33:55] <skunkworks> I thought cradek was also saying it paused on the m2 also
[16:34:06] <skunkworks> (got stuck)
[16:34:30] <jepler> yes he said that too
[16:35:38] <jepler> I, umm, dwelled on the other issue
[16:35:51] <SWPLinux> hahahahaha
[16:35:53] <SWPLinux> uhm
[16:36:18] <rayh> It looks to me like a message on a line also requires a step.
[16:36:28] <skunkworks> :)
[16:36:31] <rayh> * rayh runs some more tests.
[16:37:04] <SWPLinux> in my naive thinking, step should be equivalent to sending a single line of G-code through
[16:37:19] <SWPLinux> it "shouldn't" be any more complex than that
[16:37:38] <SWPLinux> (ie, no mode issues in task/motion, etc.)
[16:37:51] <rayh> run-pause-step trips on tool change
[16:38:44] <skunkworks> should be like typing the commands one by one in mdi
[16:38:57] <SWPLinux> right (I thought I said that ;) )
[16:39:07] <SWPLinux> but much less eloquently
[16:41:56] <jepler> the other point of view would be that it should perform a single "primitive operation" each time, so that complex movements (whether a predefined canned cycle or an "O- call" canned cycle) can be stepped through
[16:48:39] <SWPadnos> true. there have been some discussions about "G-code debugging"
[16:49:02] <SWPadnos> start, pause, stop, reset, skip, skip over (sub) trace into (sub) run out (to sub exit) ...
[16:51:32] <SWPadnos> most are already there (start, stop, pause, skip/step, reset)
[16:51:44] <SWPadnos> trace into, step over, and run to exit of course aren't
[16:55:45] <jepler> I have a feeling that while I see 'step' as the beginning of a source-level debugger, machinists see it in a different way
[16:55:51] <SWPadnos> heh
[16:55:51] <jepler> I don't know exactly what that way is
[16:56:12] <SWPadnos> "do one thing, and then stop"
[16:56:42] <SWPadnos> whether "thing" means "change the tool and return to position" or "move to toolchange position" is another question
[17:36:31] <rayh> yep "machinists see it in a different way
[17:37:02] <rayh> The original definition was "block" mode.
[17:37:18] <SWPadnos> when I press this button, "don't kill me" :)
[17:38:20] <rayh> In fact when you put it into block mode, it would complete the current block.
[17:38:36] <rayh> That's part of the reason I don't like pause mode.
[17:38:41] <rayh> it stops immediately.
[17:38:53] <rayh> rather than end of block.
[17:39:07] <SWPadnos> shall we make that list of possible refinements to EMC G-code?
[17:39:33] <SWPadnos> I think we have a list (several actually) of ideas, it may be good to consolidate those
[17:40:15] <rayh> I don't really see any consistency to the step interp mode.
[17:40:48] <SWPadnos> in terms of how the UIs/system act, or in terms of the spec (or both)?
[17:43:14] <rayh> What EMC does with a ui step command.
[17:44:16] <rayh> I've got a twice around a triangle here. On one corner it takes to step presses to initiate the next move while the other time around takes only one.
[17:49:39] <rayh> Okay I see that EMC_TOOL_PREPARE takes a step.
[17:50:09] <rayh> EMC_TOOL_LOAD does not.
[17:51:30] <rayh> I see that we have twisted up or somehow trashed the returned number of seconds Motion id # took.
[17:51:40] <rayh> They all wind up motion id 0
[17:53:21] <rayh> No wrong. I get two motion id returns one for the real number and one for 0.\
[17:55:36] <rayh> When I run-pause-step I get an entirely different set of debug info.
[17:56:03] <SWPadnos> hmmm
[17:57:06] <rayh> It looks like step to start a program is essentially MDI while run-pause-step is auto mode where all the motions are queued up.
[17:57:43] <SWPadnos> ok - that makes some sense
[17:58:03] <SWPadnos> (in programming terms, not necessarily desired outcome)
[18:00:18] <rayh> In auto mode, it looks to me like some of the codes are placed on a stack that step does not have access to.
[18:02:36] <SWPadnos> aren't there still some things that get done immediately, whereas other things are queued? (specifically M-code related actions)
[18:02:50] <SWPadnos> I guess there shouldn't be
[18:05:38] <rayh> I'm thinking that mshaver's work on stand alone interpreter will be needed to sort out some of this.
[18:06:09] <SWPadnos> it should be a useful tool
[18:06:25] <SWPadnos> but it's not the interpreter that does step/pause, is it?
[18:06:43] <SWPadnos> that should be the task controller (?)
[18:08:04] <rayh> should probably.
[18:08:20] <rayh> hows that for a waffle.
[18:08:27] <SWPadnos> heh
[18:08:33] <SWPadnos> would you like syrup with that?
[18:08:43] <SWPadnos> or fresh fruit
[18:09:01] <rayh> both
[18:09:08] <SWPadnos> that'll cost extra
[18:09:11] <rayh> np
[18:10:59] <SWPadnos> so, if I may interrupt the bug/anomaly-hunting for a moment, I'd like to get some thoughts regarding "stacks of cards", defininf G/M-code actions with external "microcode" files, etc.
[18:11:08] <SWPadnos> got a minute (or three ;) )?
[18:32:07] <rayh> phone
[18:32:17] <SWPadnos> k
[18:32:42] <rayh> back
[18:33:10] <rayh> "stack's of cards"?
[18:33:19] <SWPadnos> your analogy ;)
[18:33:38] <SWPadnos> when the interp gets a command, it places some number of ops on the queue
[18:33:47] <rayh> Right
[18:34:41] <SWPadnos> we have also discussed the idea that some (or all) input words could be mapped to these primitives via an external file(s), so an integrator can define what the words do on their machine
[18:35:11] <SWPadnos> this was discussed mostly in the context of toolchange and spindle, I think
[18:35:45] <SWPadnos> maybe other I/O as well, and very briefly touched upon as a method of implementing some canned cycles
[18:35:54] <rayh> I'm not sure what you mean by external files?
[18:36:23] <SWPadnos> user-configurable, like ini/hal/XML ...
[18:36:39] <SWPadnos> also like a "library" on some controls (I think)
[18:36:52] <rayh> Okay
[18:37:34] <SWPadnos> in the most extreme case, you might have an interp/machine config directory, which has files named G61.1, M2, ...
[18:37:46] <SWPadnos> each file contains a list of things to do, and conditions to check
[18:37:54] <SWPadnos> (in some as yet undefined language)
[18:38:21] <SWPadnos> that's probably the most flexibility anyone would need, I imagine
[18:39:09] <rayh> Okay.
[18:39:55] <SWPadnos> I'm thinking about designing this system, so I'm soliciting input on what's important for an integrator, what probably isn't, what's good/bad about the idea ...
[18:40:14] <rayh> So a command (card) would be passed to this file
[18:40:34] <SWPadnos> not quite
[18:40:36] <rayh> and after it passed back.
[18:40:44] <SWPadnos> the file has a list of cards for a given command
[18:40:53] <rayh> Oh.
[18:41:04] <SWPadnos> semantic thing, I think
[18:41:29] <rayh> Right now, task does most of this
[18:41:46] <rayh> So we would break up task into a set of "primitives"
[18:41:48] <SWPadnos> some words are simple: they aren't commands, they're data (XYZABC, IJK, R, P, Q ...)
[18:42:00] <SWPadnos> yes, that's it effectively
[18:42:32] <SWPadnos> but there are other things that I'm not sure could be reasonalby put into this system
[18:43:05] <SWPadnos> auto/mdi/jog, teleop/free modes, etc
[18:44:03] <SWPadnos> and I guess it needs user interaction as well as machine interaction (prompts, errors ...)
[18:44:04] <rayh> auto/mdi/manual in the old emc_mode notion
[18:44:10] <SWPadnos> rigth
[18:44:13] <SWPadnos> right
[18:45:08] <jepler> My half-baked idea is to identify places in task where integrators might wish to replace or augment the existing behavior (e.g., tool change) and allow them to specify that behavior in a dynamic link library
[18:45:35] <SWPadnos> that's a good solution actually, though it suffers from the "I've got to compile" flaw
[18:45:54] <SWPadnos> (which may be a flaw in those who complain about it)
[18:46:10] <jepler> yes, with two differences: It moves it from "I've got to change and recompile emc" to "I've got to compile an additional thing for emc"
[18:46:33] <SWPadnos> but if we can identify those places, then we may be able to make an externally configurable "macro language" for them
[18:46:34] <rayh> The additional thin to compile is not a bad notion.
[18:46:44] <rayh> We see it happening all the time with hal
[18:47:01] <SWPadnos> yes, it's a lot better than "download the kernel, RTAI, EMC, RCSlib, then ....."
[18:47:02] <jepler> secondly, I'd provide an implementation of the "task behavior dynamic link library" that executes integrator-provided Python code for each hook
[18:47:16] <SWPadnos> oh, well that's good then :)
[18:47:26] <jepler> Python will be light-years better than any "macro language" we'd try to design within our project
[18:47:35] <rayh> Python code is the point where I get off.
[18:48:09] <SWPadnos> I know it's a lot more powerful, but it's not a machine integrator's language
[18:48:15] <rayh> Although I must admit that I'm hearing a lot of things that would benefit from cases and inheritance.
[18:48:24] <anonimasu> agreed
[18:48:59] <SWPadnos> yes - pre/postconditions are not trivial to encapsulate in a macro language, with the possible combinations of state, and the number of possible errors to return
[18:49:44] <rayh> Can we think of "abort" as one kind of exception handling?
[18:50:19] <SWPadnos> there are things that proabably need certain specific actions, then user-supplied additions
[18:50:26] <anonimasu> hm that's not nearly true
[18:50:37] <SWPadnos> what?
[18:50:49] <anonimasu> there are several cases where a abort isnt a good way to handle exceptions..
[18:51:10] <SWPadnos> no - the idea was that an abort is an exception, not that any exception causes an abort
[18:51:16] <anonimasu> ah ok
[18:51:19] <anonimasu> that's sane
[18:51:21] <SWPadnos> I think
[18:52:10] <anonimasu> jepler: I'm wondering(feature) for axis..
[18:52:18] <rayh> jepler: I wasn't meaning to turn you off with my python comment.
[18:52:31] <anonimasu> the line display, why dosen it tag along with the g-code execution?
[18:52:39] <rayh> I'm sure that you know much better than I do how able it is to handle all of this.
[18:52:46] <jepler> rayh: no problem
[18:53:21] <jepler> rayh: since I've been programming it so long, I forget that it's not just obvious code to anyone who reads it.
[18:53:40] <rayh> Sure.
[18:53:50] <jepler> rayh: I should take people like you and SWPadnos seriously when you say things like "[python is] not a machine integrator's language"
[18:54:12] <SWPadnos> heh
[18:54:23] <anonimasu> jepler: having to scroll around to find what line is executing isnt that nice when besides the machine
[18:54:59] <jepler> anonimasu: so you want an explicit "go to current line" button or menu item?
[18:55:26] <anonimasu> no, I'd like ot to scroll along as the program is executing..
[18:55:45] <jepler> anonimasu: it does! but it's easy to accidentally disable this by left-clicking on a particular line to highlight it
[18:55:45] <SWPadnos> all the UIs do that, I think
[18:55:54] <anonimasu> really?
[18:55:56] <jepler> anonimasu: then it doesn't automatically scroll anymore
[18:56:00] <anonimasu> :D
[18:56:00] <rayh> That is how the machine controls I know do it.
[18:56:08] <SWPadnos> if you have a line selected, there's no scrolling
[18:56:13] <jepler> anonimasu: maybe you've done that but don't realize it, and didn't know how to un-highlight the line (click on the background)
[18:56:17] <anonimasu> probably
[18:56:22] <anonimasu> I'm not running a really recent emc either
[18:56:30] <SWPadnos> very small lines are hard to see
[18:56:33] <anonimasu> pre-2.1 or someting
[18:56:34] <SWPadnos> well, update!
[18:56:44] <jepler> anonimasu: it's not the first time someone has brought this up -- I probably should improve it somehow
[18:57:03] <rayh> This is an axis specific thing?
[18:57:07] <jepler> it's easy to select part of the g-code when trying to rotate/pan
[18:57:13] <SWPadnos> it's funny. when I hear these kinds of things, I think "oh great, we can discuss it at Fest"
[18:57:27] <jepler> rayh: yes, axis specific -- you can click on a line in the preview plot and it jumps to that line in the program
[18:57:31] <anonimasu> oh
[18:57:33] <rayh> Oh sure.
[18:57:51] <SWPadnos> I know most people think the opposite - "I hope we don't waste too much time talking at Fest this year, so we can get some coding done" ;)
[18:57:56] <rayh> But that is very different than running a program in auto mode.
[18:58:05] <SWPadnos> it's only for display
[18:58:07] <anonimasu> yeah
[18:58:14] <SWPadnos> the program continues executing normally
[18:58:27] <anonimasu> I think you shouldnt have that working in full auto.
[18:59:36] <jepler> by "jumps to" I mean that it highlights that line in the preview and in the g-code listing, and scrolls to that line of the listing
[19:00:00] <jepler> it doesn't skip to a different part of the program and start milling there -- even I know that would be nuts
[19:00:05] <anonimasu> yeah I undestand
[19:00:29] <anonimasu> but when running you usually just turn the preview around :)
[19:00:33] <anonimasu> atleast I do :)
[19:01:04] <jepler> anonimasu: if you make sure and click on the background, does the listing start following the execution of the program again?
[19:02:46] <anonimasu> I dont know I can check tomorrow
[19:02:48] <SWPadnos> it does for me, FWIW
[19:05:29] <rayh> Do we know the status of Matt's SAI.
[19:05:57] <jepler> rayh: it's in TRUNK and seems to work -- we've started using it to add some regression tests of tool compensation
[19:06:06] <jepler> rayh: it's called bin/rs274
[19:06:59] <rayh> Okay.
[19:07:42] <rayh> Can we use it to start down SWPadnos's path to primitives.
[19:08:17] <SWPadnos> probably, but it's built on the same base as the "integrated" interpreter
[19:08:38] <SWPadnos> also, I don't know how much of what I want to do is in the interp vs. task/canon/???
[19:09:09] <rayh> Right I understand that issue
[19:09:40] <rayh> but if this sai gives us a stackof canonical output, we should be able to work both ways at the same time.
[19:10:10] <SWPadnos> yeah, it's a question of whether the canon remains the same ;)
[19:11:27] <rayh> So your thought is that changes to canon might need to happen as well.
[19:12:20] <SWPadnos> I don't want to rule them out in my initial thinking
[19:12:29] <jepler> just to show in general form what I meant by "hooks":
http://pastebin.ca/393658
[19:13:20] <rayh> you guys and your fast connections!
[19:13:28] <SWPadnos> heh
[19:14:17] <SWPadnos> ok. that looks good
[19:14:54] <SWPadnos> it's obviously flexible enough
[19:15:06] <jepler> of course, the hard stuff is all not shown: the implementation of call_hook(), and finding all the places where we want the integrator to be able to modify/replace the behavior and adding the calls to call_hook()
[19:15:13] <SWPadnos> though it doesn't allow you to replace the original tool handling code, only add to it
[19:15:21] <jepler> not true
[19:15:36] <SWPadnos> oh right - RESULT_HANDLED
[19:15:37] <jepler> that example shows me replacing it, because tool_change_pre() returns HANDLED
[19:16:19] <SWPadnos> (though that wouldn't work unless HANDLED == RESULT_HANDLED ;) )
[19:16:33] <jepler> er yes
[19:16:58] <rayh> How does this relate to tool_prepare - tool_prepared and tool_change - tool_changed
[19:17:17] <SWPadnos> that's not shown in this example
[19:17:48] <SWPadnos> but it could work the same. it's not necessary in this case
[19:18:15] <SWPadnos> if you want to use an external PLC, you could use python code to set/check/reset those pins
[19:18:36] <SWPadnos> the advantage of this method is that you can do anything you want
[19:19:18] <SWPadnos> the disadvantage is that there isn't a nice, well-defined list of things to choose from
[19:21:02] <jepler> there will still be a limited number of hooks, and a limited number of routines you can call from the hooks -- whatever the developers anticipate integrators may need
[19:21:31] <SWPadnos> ok, in that sense, it may be OK
[19:21:46] <SWPadnos> I'm just not sure about things that look like programs rather than lists of things to do ...
[19:22:11] <SWPadnos> (not that there's much difference between the two)
[19:22:49] <jepler> in this simple example, it's necessary to do arithmetic: traverse(toolchange_x, toolchange_y + tool_num * toolchange_dx, UNCHANGED)
[19:23:22] <jepler> if you are implementing the mazak's tool_prepare, you have to go through the "which way is shortest to get to tool N" logic, which is probably easiest to express as a loop
[19:23:35] <SWPadnos> yep, that's true. that implies either some weird "features" or an arithmetic parser
[19:23:49] <jepler> (possible to express as "mere arithmetic" of course)
[19:23:53] <SWPadnos> sure
[19:24:28] <SWPadnos> a lot of that is expressible in ladder logic though, which integrators are accustomed to
[19:24:29] <rayh> Um I wasn't thinking of Mazak specifically.
[19:25:09] <SWPadnos> we're just thinkning of examples that demonstrate additional features needed by an externally configurable system
[19:25:19] <anonimasu> hm..
[19:25:23] <SWPadnos> math, logic, motion ...
[19:25:36] <anonimasu> SWPadnos: yeah doing that with a external plc works great
[19:25:52] <anonimasu> ;)
[19:26:15] <anonimasu> though I wish I had toolchanging working
[19:26:15] <anonimasu> :)
[19:26:19] <SWPadnos> heh
[19:26:46] <rayh> Sure I can understand that. What's missing in my head is the connection between the first encountered tool "card" from the interpreter
[19:26:49] <anonimasu> though that's more a mechanical issue then the plc stuff :)
[19:26:58] <rayh> and the code that you pasted.
[19:27:15] <SWPadnos> that wasn't a card stack approach
[19:27:19] <SWPadnos> it was an alternative
[19:27:45] <rayh> so you are developing a new interpreter
[19:28:04] <rayh> that takes a T1 word
[19:28:06] <SWPadnos> it was a modification to the toolchange code (as an example) to call some external code, optionally continue with "normal" toolchange code, then run some external cleanup code
[19:28:22] <SWPadnos> it depends on what you call the "interpreter"
[19:28:41] <jepler> yes -- this code I showed doesn't help the integrator add a new "pierce" M- or G- code, it helps the integrator modify existing behavior like "M6 tool change"
[19:28:48] <anonimasu> normally I think toolchange is done by the plc..
[19:28:57] <SWPadnos> this would be an interpreter that does exactly the same thing as now, unless functions are added to modify its actions
[19:29:17] <rayh> I submit a g-code file or whatever to the zzz and one of the things I get back is
[19:29:20] <jepler> (I mention "pierce" because some discussion of it went by yesterday on #emc, and went way over my head :-P)
[19:29:25] <anonimasu> on the heid machines you can write custom macros with the plc moves(add M codes) and stuff..
[19:29:28] <rayh> ??
[19:29:33] <SWPadnos> right - as jepler said - you can't add G875 with this method
[19:29:54] <anonimasu> I did my piercing with a piece of python to turn on the plc outputs..
[19:30:03] <anonimasu> no preheat and stuff..
[19:30:05] <anonimasu> just a delay
[19:30:11] <anonimasu> err no circular preheat
[19:30:17] <SWPadnos> right now, the "input language" is defined by the RS274ngc spec. G1 = "linear move at traverse rate"
[19:31:28] <SWPadnos> some of the more complex things, like toolchange or spindle control, are only implemented as "waaaahhh - I need help" in the interpreter
[19:31:40] <anonimasu> yeah
[19:31:54] <SWPadnos> but the problem that comes up perennially is that external helpers can't command motion
[19:31:55] <anonimasu> and some commands may not be aplicable to all machines either..
[19:31:58] <anonimasu> * anonimasu nods
[19:32:02] <rayh> No they are defined as an output that expresses the need for something out there to handle tool change
[19:32:05] <SWPadnos> (though they can with some very big machinations)
[19:32:35] <SWPadnos> right, but there are physical interactions between motion and I/O that need to happen, but can't really with the current system
[19:32:59] <rayh> Because task is inadequate?
[19:33:02] <anonimasu> I'd with we had the possibility for the plc to handle motion..
[19:33:14] <SWPadnos> because the partitioning of control is incompatible, I think
[19:33:23] <anonimasu> but, that's hard to do with cl I think..
[19:33:33] <rayh> partitioning of control?
[19:34:06] <SWPadnos> you can move the machine, if you intercept the position command from motion, inject your own offset, and remove that from the feedback (there's a component to do this)
[19:34:26] <anonimasu> gah
[19:34:27] <rayh> right
[19:34:38] <SWPadnos> but there's no way for motion to tell if you restored control to it, or if you zeroed your externally-generated offset
[19:34:51] <anonimasu> SWPadnos: what a damn freaky way to do it
[19:35:00] <SWPadnos> so there's some agreement that that method is a kludge?
[19:35:15] <anonimasu> SWPadnos: ideally I'd use the plc to store the position, then command a new move..
[19:35:15] <rayh> I don't agree so there may be some
[19:35:34] <anonimasu> and then return, to the same position
[19:35:34] <jepler> last time I was thinking about this, my half-baked solution was here:
http://article.gmane.org/gmane.linux.distributions.emc.devel/201/match= but besides not having anybody think it was a great idea, it also turns out that the implementation would have been harder than I thought
[19:35:43] <rayh> And if the problem is in motion, why fix it in interp?
[19:35:45] <cradek> Breakpoint 1, ARC_FEED (first_end=2, second_end=2.53125, first_axis=2,
[19:35:45] <cradek> second_axis=3, rotation=1, axis_end_point=9.9999999999999995e-21, a=0,
[19:35:45] <cradek> b=0, c=0) at emc.hh:1145
[19:35:59] <cradek> uh
[19:36:08] <anonimasu> isnt the problem really how to inject new movement in a sane way?
[19:36:09] <SWPadnos> hi chris :)
[19:36:17] <cradek> darnit
[19:36:20] <SWPadnos> yes
[19:36:35] <anonimasu> wher would that kind of thing end up?
[19:36:54] <jepler> cradek: that reminds me, I don't know when it started, but I noticed this in debug output today:
[19:36:57] <jepler> Issuing EMC_TRAJ_LINEAR_MOVE -- (+220,+88, +0,0.000000,0.000000,0.000000,0.000000,0.000000,nan, +1,1.200000,1.200000,20.000000,)
[19:37:00] <jepler> see the "nan"?
[19:37:05] <SWPadnos> right now, there are two ways to command movement: 1) do it in the interp/canon/motion or 2) fool motion into thinking it's in position
[19:37:20] <cradek> jepler: eek
[19:37:35] <petev> SWPadnos, u there?
[19:37:38] <SWPadnos> yep
[19:37:42] <cradek> jepler: I think that's "C"
[19:37:55] <petev> have u looked at connection a jog wheel to the axisui.jog interface?
[19:38:02] <petev> connecting
[19:38:12] <SWPadnos> no, but I think anonimasu has
[19:38:14] <cradek> petev: looked at?
[19:38:21] <SWPadnos> and chris
[19:38:24] <cradek> petev: I have a jogwheel that uses that
[19:38:27] <SWPadnos> and alex
[19:38:30] <petev> yes, what is the increment input scaled in?
[19:38:41] <SWPadnos> user units?
[19:38:48] <petev> does it need some delta conditioning or is it raw from the encoder
[19:39:19] <SWPadnos> oh - axisui, not halui. can't help you there :)
[19:39:21] <anonimasu> hm, I'll be back later..
[19:39:25] <anonimasu> need to go bowling
[19:39:26] <jepler> petev: hold on for a URL
[19:39:28] <SWPadnos> (can't help much with halui either ;) )
[19:39:33] <petev> jepler: ok
[19:39:35] <cradek> petev: my config is "max" in cvs trunk
[19:39:37] <jepler> petev:
http://cvs.linuxcnc.org/cvs/emc2/configs/max/jogwheel.hal?rev=1.1
[19:39:42] <cradek> yeah that
[19:39:49] <cradek> it's very simple
[19:40:11] <jepler> it uses a hardcoded jog distance: .00002 user units (inches in this case)
[19:40:24] <jepler> for an angular axis you probably would want a different value :-P
[19:40:39] <cradek> heh, definitely
[19:41:04] <jepler> on TRUNK, theres a new axisui pin for the incremental jog distance selected onscreen
[19:41:37] <SWPadnos> logger_dev, bookmark
[19:41:36] <SWPadnos> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2007-03-13.txt
[19:44:06] <petev> jepler: your config has me more confused now
[19:44:15] <petev> I was looking at axisui, not axis
[19:44:22] <petev> I didn't even see the pins under axis
[19:44:29] <petev> so what is axisui for?
[19:44:30] <SWPadnos> axisui is part of axis, are you using halui?
[19:44:42] <petev> you mean part of GUI axis?
[19:44:44] <cradek> halui has nothing to do with jogwheels
[19:45:02] <petev> SWPadnos, no halui
[19:45:18] <SWPadnos> doesn't the GUI AXIS export some pins, which are named axisui.* ?
[19:45:23] <cradek> yes
[19:45:32] <SWPadnos> or is it a separate component?
[19:45:32] <petev> ok, that's my confusion
[19:45:53] <SWPadnos> halui can accept jogwheel input as well, I believe
[19:45:53] <cradek> axis.* are the joints in the motion controller; axisui.* are pins from the AXIS ui
[19:46:07] <petev> but halui sends NML
[19:46:08] <cradek> SWPadnos: I don't remember if we took it out yet or not, but it sucks
[19:46:12] <SWPadnos> right
[19:46:15] <petev> I'm looking at an all HW config here
[19:46:20] <SWPadnos> ok - right. axis.n.{jog stuff}
[19:46:41] <SWPadnos> scale is "user units per count"
[19:46:57] <SWPadnos> you can connect the raw count output to the jog input (I believe)
[19:47:03] <petev> right, I was looking under axisui and there was no scale there
[19:48:02] <cradek> 29611 float OUT 0 axisui.jog.increment
[19:48:03] <SWPadnos> ok - my confusion was that halui can use a jogwheel for spindle speed / FO and that kind of thing, I think
[19:48:22] <petev> while we're here, what do you guys think of updating the current m5i20 driver to the fixed FPGA image and making provision to support index-enable?
[19:48:46] <SWPadnos> I'm for it, though it does represent a pin function change (bugfix)
[19:48:55] <SWPadnos> I'm not sure what the manual says about pinouts
[19:48:59] <cradek> it doesn't support the canon index-enable?
[19:49:15] <petev> I was thinking of subtracting the lathced value to support the clear function
[19:49:34] <petev> then make come new pins to export the latched value and real count so it could still be used
[19:49:36] <SWPadnos> hmmm. isn't there a mode for that in the FPGA?
[19:49:47] <SWPadnos> the reset part
[19:49:51] <petev> no, it does it the right way by latching the count on index
[19:49:59] <petev> but not all HW supports this
[19:50:29] <petev> you can clear the count, but not sync to index
[19:50:32] <SWPadnos> right. there is a canonical encoder interface that drivers are supposed to (try to) support, regardless of the underlying hardware
[19:50:36] <petev> you can latch the count sync to index
[19:51:21] <petev> so I can make it match the canonical model and export extra pins for the non-conditioned values
[19:51:41] <petev> but it might break some peoples configs if they are using the latch feature
[19:51:47] <petev> what do you guys think?
[19:52:17] <cradek> 2.1 or 2.2?
[19:52:40] <petev> that's fine, but can the changes be made in head now?
[19:52:40] <cradek> (have to maintain config compatibility in 2.1)
[19:53:05] <petev> roltek is building a test system and would be able to test it too
[19:53:21] <cradek> sure, if it doesn't work in trunk, and you want to make it work, please do
[19:53:29] <petev> ok
[19:53:32] <cradek> doubt you'll have any objections to that
[19:55:08] <jepler> I know jmk wants to change how the firmware is loaded during 2.2, you might make sure you're not stepping on his toes or duplicating effort
[19:55:16] <SWPadnos> I actually dusted off my BP today, so I may have a system to test with some day sooner than never :)
[19:55:24] <petev> he's doing a completely new thing
[19:55:35] <petev> firmware will not be loaded by his driver
[19:55:46] <petev> it will be done by the m5i20 config app
[19:55:57] <SWPadnos> it's a different driver anyway, so it shouldn't conflict
[19:55:56] <petev> he has a separate dir for the new stuff
[19:56:00] <petev> right
[19:56:27] <petev> and I would like to delte that old broken FPGA config too after testing the new one
[19:58:32] <SWPadnos> yes, the broken one should go away
[19:59:27] <jepler> if at the end we have a working .bit file and corresponding source code I'm all for it
[19:59:48] <petev> supposedly it's already there
[19:59:52] <petev> just hasn't been tested
[19:59:58] <jepler> I see
[20:00:39] <SWPadnos> right - it's in a subdir (along with 3 other similar configs), due to concerns about changing how the card works
[20:00:49] <SWPadnos> within a stable release series
[20:00:59] <a-l-p-h-a> anyone own a civic? or acura?
[20:01:37] <a-l-p-h-a> NGK platinum spark plugs don't require you to gap them... weird... cause the ignitor is ultra fine, so they say don't do it. weird.
[20:02:00] <a-l-p-h-a> I don't own a japanese car, the GF does... I choose american iron, thank you.
[20:03:14] <rayh> we done with discussing primitives and interp and task or...
[20:04:35] <SWPadnos> I'm not done - just sidetrack-able ;)
[20:04:37] <jepler> rayh: we all got distracted by the next thing somebody mentioned
[20:05:01] <rayh> I did get sai running here.
[20:05:23] <rayh> had to add a blank line between header and data in .tbl.
[20:05:35] <jepler> rayh: yeah I ran into that too
[20:05:49] <jepler> I never got around to checking whether the documentation says that is required in a tool table
[20:05:55] <rayh> That is very old tom spec\
[20:06:25] <SWPadnos> yes, it's required
[20:06:47] <SWPadnos> optional header line(s), exactly one blank line, tool table
[20:07:31] <rayh> so how is the proposed relating to interp?
[20:08:33] <rayh> interp now spits out a SELECT_TOOL(1) when it encounters a t1 in code
[20:09:27] <SWPadnos> well, one relatively easy concept would be to have a list of canon calls that should be made for each encountered code
[20:09:36] <SWPadnos> easy concept, not easy implementation
[20:10:27] <rayh> So we (task) adds stuff to the stack when it sees SELECT_TOOL(1)
[20:10:45] <rayh> in mazak terms it's spin the carousel to tool 1
[20:10:54] <SWPadnos> so some integrator could output something like RETRACT, MOVE(x,y,z), CHANGE_TOOL(), MOVE_TO_CP ...
[20:11:13] <SWPadnos> yeah - change tool would probably be several steps
[20:11:18] <rayh> in a pick and place environment it pics out the tool one location and puts that in the cue.
[20:11:26] <petev> SWPadnos, change is different than prepare
[20:11:30] <petev> there are 2 canons
[20:11:32] <SWPadnos> though I'm describing the M6 process and you're talking about T1
[20:11:36] <SWPadnos> right
[20:12:41] <rayh> So what we are saying is that it is easy to think about task adding these elements to the SELECT_TOOL(1)
[20:12:56] <rayh> canon but it is not an easy thing to do in software.
[20:13:17] <rayh> ??
[20:14:29] <petev> I don't think it would be too hard to do in SW, but it's a fairly big re-write
[20:14:50] <SWPadnos> I'm saying that I want to be able to define which canon mesasges the interp spits out, not necessarily redefine what each canon message means
[20:15:17] <SWPadnos> that's why I said I might want to redefine canon - to make it more compatible with being snippets of functions rather than whole functions
[20:15:21] <SWPadnos> (machine functions, that is)
[20:15:48] <petev> sure, and the interp would have to read this config on startup
[20:15:55] <SWPadnos> yes
[20:15:55] <petev> so it's major changes to the interp
[20:16:51] <SWPadnos> one central thing in my thinking is that a "machine person" should be able to understand how to make these customizations
[20:17:01] <SWPadnos> yes, it's a pretty major change - just brainstorming at this point
[20:17:18] <SWPadnos> I'm thinking about writing a spec of sorts before Fest
[20:17:36] <petev> maybe this could be layered under the interp
[20:17:41] <petev> really as part of canon
[20:17:46] <SWPadnos> this is similar in concept to HAL - it's just at the interpreter level instead of at the I/O level
[20:18:09] <petev> make conon configurable in terms of more primitive operations
[20:18:19] <petev> so I guess canon isn't quite canon
[20:18:24] <SWPadnos> heh - canon2
[20:19:11] <petev> sort of a micro code for canon
[20:20:09] <SWPadnos> yep, exactly
[20:20:18] <SWPadnos> micro/macro code
[20:20:40] <SWPadnos> I think it could also be used to implement all sorts of canned cycles
[20:20:50] <petev> I think it's best to do this below the interp, then it would work for different interps as well
[20:21:19] <petev> so maybe some minor cleanup to canon, then define the micro words
[20:21:22] <SWPadnos> I think the lowest level needs to deal in very primitive "primitives"
[20:21:30] <SWPadnos> then you can stick whatever you want on top of ot
[20:21:34] <SWPadnos> it
[20:22:13] <petev> canon doesn't seem too bad now, it just isn't flexible in how the canons are implemented
[20:22:25] <petev> it seems like an appropriate API for interp
[20:22:32] <petev> just need more flexibility
[20:22:41] <petev> for actual implementation
[20:23:30] <SWPadnos> ok, that's a reasonable argument
[20:27:35] <SWPadnos> I guess the problem lies between the interp and motion - there's no Y-connector there like you can make in HAL
[20:27:53] <rayh> pete's way of talking sounds somewhat like what we were working on for task a couple years back.
[20:28:23] <rayh> I remember working up a diagram.
[20:28:29] <rayh> with my notions.
[20:28:37] <SWPadnos> yes - those are the discussions I was thinking of when starting this discussion
[20:28:47] <SWPadnos> it seems to happen every year or so :)
[20:29:24] <rayh> I don't have any problem with putting hooks for each "canon" word.
[20:29:40] <rayh> That a person can attach to with whatever code they wish.
[20:30:02] <SWPadnos> that's only part of the solution, I think
[20:30:17] <SWPadnos> and I knew why about 30 seconds ago ...
[20:30:28] <rayh> The y connector idea to motion is disturbing
[20:31:18] <petev> I think all commands should go through the shmem intf to motion
[20:31:18] <SWPadnos> Y connector to "micro-canon" may be a better way of saying it
[20:31:21] <rayh> but something needs to be done in there to allow one stream of motion commands to be interrupted by another.
[20:31:41] <petev> I think ioControl.cc should go away
[20:32:16] <SWPadnos> that gets into the whole remote/NML/??? discussion, which I think is separate
[20:32:30] <petev> no, it 's more directed an how to sync stuff
[20:32:49] <petev> when you need to sync some move to a tool change or whatever
[20:33:04] <SWPadnos> ok. this isn't my favorite of the EMC system, from a comprehension standpoint
[20:33:08] <SWPadnos> ^part
[20:33:11] <rayh> If I have a plc doing tool change, I'd want a way to send tool change messages to it.
[20:33:26] <rayh> and sync it with motion even though it is a separate processor
[20:33:35] <petev> yes
[20:33:43] <petev> and having one queue would help with this
[20:33:45] <SWPadnos> for some value of "sync"
[20:34:07] <rayh> one queue?
[20:34:19] <petev> one queue to the RT part of motion
[20:34:25] <petev> and all commands go through it
[20:34:57] <SWPadnos> I guess that's one key thing
[20:35:12] <rayh> Don't we have a single path into motion now?
[20:35:18] <SWPadnos> we want to maintain one controller for motion, but that controller needs to be configurable
[20:35:33] <SWPadnos> rayh, yes, but it's not flexible enough to allow customization
[20:35:38] <SWPadnos> (without recompiling)
[20:35:42] <rayh> right
[20:35:42] <petev> rayh, there's one path to motion now, but it's not a queue
[20:35:53] <petev> and from what I understand, io is a separate path
[20:35:52] <SWPadnos> I think it is a queue
[20:35:53] <rayh> ah okay
[20:36:02] <SWPadnos> ah - no I/O queue
[20:36:02] <petev> SWPadnos, it's not a queue
[20:36:15] <rayh> Well there are motions and ios that need not be coordinated.
[20:36:15] <petev> motion takes one command at at time
[20:36:38] <petev> in that case you wouldn't queue a pre condtion to wait for them
[20:36:43] <SWPadnos> ok - semantics. there's a motion queue, but "motion" is fed one item at a time
[20:36:56] <SWPadnos> and it doesn't include pre/postconditions or I/O
[20:37:02] <petev> right, a bottle necj
[20:37:48] <rayh> One thing we don't want to loose is the ability to dump thousands of motions into it in quick succession.
[20:37:56] <SWPadnos> not a problem
[20:38:23] <SWPadnos> at least, I wouldn't consider a solution complete unless that could happen
[20:39:12] <rayh> I agree that the motion and IO as now is messy.
[20:40:37] <jepler> without changing the architecture, the throughput of transferring motion primitives to realtime was increased markedly for emc2.1. right now the biggest practical problem is that the implementation of anything but motion -- even "dwell" -- requires the real-time motion queue to be drained.
[20:40:53] <rayh> And I like the idea of being able to patch or link things together at the task level like we do with HAL
[20:41:18] <SWPadnos> jepler, good point - hadn't considered this stuff as a bugfix :)
[20:41:52] <petev> jepler, what were the basic changes that improved performance?
[20:42:49] <jepler> petev: make "task" not sleep when it is successfully transferring motions to realtime
[20:42:59] <jepler> petev: before it would sleep (sometimes twice) after each transfer
[20:43:28] <petev> interesting, I had always thought the bottle neck was in a bit lower layer
[20:43:35] <petev> task is a real mess now
[20:43:49] <petev> it really needs to be 2 threads and the code would be much simpler
[20:44:15] <petev> one to call interp, and one executing canons
[20:44:49] <petev> I think the interp thread would also service the UIs
[20:46:03] <SWPadnos> well, there are other issues that might as well be considered:
[20:46:26] <SWPadnos> files needing to be in identical locations on UI and controller computers
[20:46:52] <SWPadnos> <much bigger picture>binary format interpreters
[20:46:58] <petev> that's a shortcoming of the UI API (ie NML definitions)
[20:47:10] <SWPadnos> where the UI can't necessarily figure out what a block is
[20:47:23] <SWPadnos> yes, mostly
[20:47:38] <SWPadnos> I think there are some incremental changes that can help for remote UIs
[20:47:41] <petev> yes, the whole comm code should be broken into client/server parts that don't polute the rest of the EMC code
[20:48:21] <SWPadnos> comm is one part, file access is another, visualization interface (like having the ability to preview non-gcode)
[20:48:34] <jepler> when you imagine that the use for remote UIs is having motion run on a small embedded system, it also forces you (me) to conclude that conversion from binary format to some common lower-level format would go on the general-purpose computer with the remote UI
[20:49:12] <jepler> that's the model I promote with AXIS: a UI-side filter converts the non-ngc file into g-codes
[20:49:27] <SWPadnos> there are more expectations and different resources than were available when EMC was first designed, so it makes sense to think about those older specs from time to time
[20:49:43] <SWPadnos> jepler, that makes a lot of sense
[20:49:43] <petev> I think it's asking a bit much for the EMC side of things to support visualization conversion for all types of interpreters
[20:50:01] <SWPadnos> unless you have a visualization API that interps can use ...
[20:50:03] <petev> I think that type of stuff has to be on the client side like jepler says
[20:50:23] <jepler> I imagine an NML call which is "transfer the next X bytes of the ngc or canon program" (I don't think NML can transport arbitrary-size messages)
[20:50:23] <petev> SWPadnos, you would have to have a huge amount of code for each file format
[20:50:36] <petev> better left in some library linked with the GUI
[20:50:51] <jepler> we'd probably find that X=a few thousand bytes would not require too much additional time when the user hits "run" on the UI
[20:50:51] <petev> jepler, right
[20:51:03] <petev> and it should be trasnparent to what interp is being used
[20:51:14] <petev> as long as both GUI and interp match, all will work
[20:51:38] <SWPadnos> that's true. it may make sense to make UI and interp go as a package
[20:52:31] <petev> or at least the part of the GUI that deals with the file format and visualization needs to match the interp
[20:53:01] <rayh> My problem is that I started using emc before there was a gui.
[20:53:05] <SWPadnos> yeah, but there can be primitives for that - like GL primitives (which may make sense anyway)
[20:53:08] <SWPadnos> heh
[20:53:31] <rayh> And visualization was way off in the distance and a problem for some other system than emc.
[20:54:11] <petev> rayh, I'm just thinking that different interps should be supported to be able to handle things like conversational programming
[20:54:19] <SWPadnos> I guess I'm thinking about the fact that lots of things have come a long way, and peoples expectations include more now than they did 10+ years ago
[20:54:19] <petev> and maybe other languages
[20:54:31] <rayh> Oh yes. No problems with those concepts.
[20:55:02] <SWPadnos> those new expectations can be met with external programs that run off in all sorts of directions, or we can define some more advanced baseline features for modern machining centers
[20:55:52] <rayh> If we do build lots of Interps and guis to go with, we really need a clear distinction between these and lower level systems.
[20:56:02] <SWPadnos> yes
[20:56:31] <SWPadnos> we had talked way back when about "pluggable interps" as well - so you could load a STEP file and run it in the same uwer interface as you run G-code
[20:56:33] <rayh> It's a bit like me coding mini to write to the tbl or var file,
[20:56:42] <SWPadnos> that works with AXIS, since it can run filters
[20:56:45] <rayh> rather than having an emc write
[20:57:04] <SWPadnos> but you can't look at the source - you only see the converted data in the text area
[20:57:28] <SWPadnos> rayh, I think that may be an implementation detail, not an architectural decision, but it illustrates the point
[20:57:48] <rayh> axis having HAL pins is the same thing.
[20:57:52] <SWPadnos> sure
[20:58:17] <rayh> we get tentacles all wrapped around one another.
[20:58:34] <SWPadnos> yep, and they're all different colors and sizes
[20:58:50] <SWPadnos> the idea is to standardizethe tentacles, or design them out of the system ;)
[20:58:55] <rayh> and there are some really nifty shortcuts that present themselves.
[20:59:47] <rayh> gotta run to town. thanks for the great work and great thinking guys.
[20:59:56] <SWPadnos> see you later Ray
[21:08:05] <anonimasu> 1hm
[21:08:12] <anonimasu> I see how you can do a toolchange.
[21:08:24] <anonimasu> with a external plc..
[21:08:39] <anonimasu> though you need both hal and nml and the ability to throw nml messages..
[21:09:47] <anonimasu> as you can do mdi with nml, you can pause/kill the running progam and store the position you are at.. and move to the toolchange position and do your stuff, continue your program run on the line after the toolchange..
[21:11:33] <anonimasu> that's one way to do it..
[21:13:30] <SWPadnos> I don't know if that's less kludgey than faking out motion feedback in HAL
[21:13:56] <anonimasu> SWPadnos: well, it's very much like the way the plc would do it in a comercial controll
[21:13:56] <SWPadnos> and it'll truly suck for some programs, such as those that are 500000+ lines of code
[21:15:25] <anonimasu> can you pause the interpreter and do motion?
[21:15:31] <SWPadnos> the "NIST way" would be to pass control to the PLC, which can then issue motion commands - the problem inthe current system is that the motion controller is a little too chummy with the interpreter, and would throw a following error once the external device took control
[21:15:40] <SWPadnos> no, you'll get a following error
[21:15:51] <alex_joni> hi
[21:15:55] <anonimasu> SWPadnos: that sucks pretty much
[21:16:03] <SWPadnos> or there's some mode problem - auto mode prevents some stuff, I'm sure
[21:16:08] <SWPadnos> hi Alex
[21:16:15] <SWPadnos> caught up yet? :)
[21:16:25] <alex_joni> SWPadnos: I'm pondering about changing some of that
[21:16:31] <alex_joni> (gotta read back first)
[21:16:51] <alex_joni> wheee.. I missed a lot today
[21:16:54] <SWPadnos> it's another episode of the yearly "split things up into little pieces" discussion :)
[21:17:01] <anonimasu> hehe
[21:17:35] <SWPadnos> plus a dash of "make a "microcode" to define G/M-code functions"
[21:21:29] <anonimasu> hm, I wonder how hard it would be to implement a IEC-61131-3 plc..
[21:21:50] <jepler> first, get a copy of the standard
[21:22:12] <anonimasu> jepler: it's pretty big.. but it's basically like pascal..
[21:22:24] <anonimasu> jepler: and mutithreaded and stuff..
[21:22:27] <jepler> second, get another implementation to check against, because there's no way you'll understand standardsese
[21:22:40] <anonimasu> I work with that language..
[21:22:53] <SWPadnos> that's different from understanding the standard :)
[21:23:10] <anonimasu> *sigh*
[21:23:20] <anonimasu> jepler: I do have another.
[21:24:04] <anonimasu> the good thing is that it's really easy to do more advanced stuff in..
[21:24:41] <anonimasu> as it's more like writing code for a computer, then doing ladder stuff
[21:26:01] <anonimasu> http://www.oacg.co.uk/plcopen.pdf
[21:27:31] <anonimasu> _if_ im just talking crap and cludging up the devel chan say so and I'll just go away or something :)
[21:28:43] <SWPadnos> an IEC-61131-3 PLC should be a standalone-ish thing, like calssicladder
[21:28:51] <SWPadnos> so it shouldn't clutter up much
[21:29:04] <anonimasu> yeah..
[21:29:09] <SWPadnos> but there are architectural issues with having such a PLC issue motion commands in an emc system
[21:29:18] <SWPadnos> (if that's one goal)
[21:29:31] <anonimasu> SWPadnos: I dont see how you do motion for toolchange in a better way..
[21:29:45] <anonimasu> SWPadnos: the motion has to come from somewhere..
[21:29:57] <anonimasu> I dont see a user macro as a good way of doing it..
[21:30:07] <SWPadnos> yes, and right now that's canon or HAL fakery - that's the point of this whole discussion
[21:30:35] <SWPadnos> there are two goals (at least - I usually have feature creep :) )
[21:30:49] <anonimasu> two goals?
[21:30:52] <SWPadnos> 1) allow an integrator to define the meaning of existing G-codes
[21:31:21] <SWPadnos> 2) allow the integrator/EMC team to make changes to canned cycles and the like without compiling
[21:31:58] <SWPadnos> #2 allows someone to set up EMC to act like another control, so they can use their 100G of Fanuc code unmodified
[21:32:25] <SWPadnos> #1 could be done in gcode or a PLC, or HAL, but there are problems with that now
[21:32:58] <SWPadnos> I guess 1 is more related to machine-stuff, not motion stuff, so that should be "define the meaning of M-codes", for the most part
[21:33:00] <anonimasu> SWPadnos: yeah, im just thinking about a softplc that would do it easier then cl ;)
[21:33:05] <SWPadnos> sure
[21:33:17] <anonimasu> SWPadnos: if you are throwing off a motion command for toolchange cl isnt all that great.
[21:33:21] <anonimasu> :
[21:33:25] <anonimasu> :)
[21:33:29] <anonimasu> or well ladder..
[21:33:55] <SWPadnos> heh
[21:34:13] <anonimasu> or did something magic happen to cl while I were not watching?
[21:34:14] <anonimasu> ^_^
[21:34:41] <SWPadnos> I don't know if CL has floats at this point ...
[21:35:24] <anonimasu> I guess a real plc would be better in the end, but there's the problem of communication also..
[21:35:43] <SWPadnos> ye
[21:35:45] <SWPadnos> p
[21:36:10] <anonimasu> im running rs232 in my setup, but for a real world app I'd use something like can...
[21:36:23] <alex_joni> my head spins
[21:36:28] <SWPadnos> heh
[21:36:40] <SWPadnos> it's getting late there, maybe you need sleep ;)
[21:36:43] <alex_joni> you talk too much
[21:36:46] <SWPadnos> :P
[21:36:48] <anonimasu> sorry :/
[21:36:47] <alex_joni> and mostly gibberish
[21:36:49] <alex_joni> ;P
[21:36:55] <alex_joni> kidding
[21:37:07] <alex_joni> SWPadnos: here's what I was thinking while driving today
[21:37:39] <SWPadnos> at least I didn't say anything like "the primary facilitators will conduct an emerging feature feasibility study, and correlate their findigs with the marketing depatment"
[21:37:42] <alex_joni> when we run a program and pause, there's no way how to change to mdi or manual
[21:38:16] <alex_joni> if that would be possible, then one could write a python M-code that does something like this:
[21:38:22] <SWPadnos> right - I noticed that today
[21:38:25] <alex_joni> use the emc module, and pause the program
[21:38:34] <alex_joni> then use mdi to send whatever commands it needs
[21:38:43] <alex_joni> use the hal module to export drive hal pins
[21:38:46] <SWPadnos> err - problem ...
[21:38:52] <alex_joni> use the emc module to switch to auto and resume
[21:38:57] <SWPadnos> sure
[21:39:06] <anonimasu> a toolchange is always followed by a positioning move..
[21:39:07] <SWPadnos> does the interp wait for external programs to finish?
[21:39:12] <anonimasu> for starting the cut.. also..
[21:39:16] <alex_joni> SWPadnos: not atm
[21:39:23] <alex_joni> but it should imp
[21:39:25] <alex_joni> imo
[21:39:37] <SWPadnos> anonimasu, strangely, the NGC spec specifically says that the new tool will *not* be compensated for after a tool change
[21:39:37] <alex_joni> and if someone has a program that doesn't end, they should just & it
[21:39:51] <SWPadnos> what if it's supposed to end ...
[21:39:51] <jepler> SWPadnos: surely it forbids toolchange while tool radius comp is on
[21:39:56] <alex_joni> SWPadnos: different topic
[21:39:58] <jepler> and changing tools won't turn on radius comp
[21:40:04] <anonimasu> length compensation.. that would be..
[21:40:05] <SWPadnos> jepler, yes, but not tool length comp
[21:40:30] <SWPadnos> alex_joni, right - how do you deal with runaway external programs?
[21:40:33] <anonimasu> SWPadnos: that has nothing to do with the code the program spits out..
[21:40:42] <alex_joni> SWPadnos: what do you mean?
[21:40:55] <jepler> SWPadnos: oh, sorry -- have radius/shape comp on the brain
[21:41:14] <SWPadnos> anonimasu, ok, I assumed you were thinking that the toolchange code should do the next compensation move on automatically
[21:41:23] <anonimasu> oh, ofcourse not :)
[21:41:43] <SWPadnos> alex_joni, I write a program, but it has a bug - if EMC is waiting for it, that's a problem
[21:41:54] <SWPadnos> (if it has an infinite loop, of course)
[21:41:55] <jepler> right now in our implementation the new tool position is undefined after the tool change
[21:42:10] <anonimasu> jepler: what do you mean?
[21:42:12] <alex_joni> SWPadnos: imo, your problem
[21:42:20] <SWPadnos> it's defined as the old position plus the difference in length in Z
[21:42:23] <SWPadnos> heh
[21:42:27] <alex_joni> but we already fixed that you write programs with bugs..
[21:42:32] <anonimasu> heh
[21:42:36] <alex_joni> so I guess you should stop :P
[21:42:36] <SWPadnos> I know that, that's why I'm concerned ;)
[21:43:05] <jepler> SWPadnos: you may be right about what the kramer doc, or even our documentation, says
[21:43:10] <anonimasu> I wondef if that can cause a crash.. but the cam program/programmer should be at a safe height before starting a toolchange..
[21:43:16] <alex_joni> SWPadnos: honestly now.. would you prefer for emc to just keep going and ignoring the bad program?
[21:43:16] <jepler> SWPadnos: but in the current implementation, the position after tool change *is* the toolchange position
[21:44:00] <SWPadnos> alex_joni, no, but I may want the EMC UI to still be active, and have the option of killing its child process ...
[21:44:13] <alex_joni> SWPadnos: not it's child process
[21:44:17] <SWPadnos> jepler, I'm not saying the spec is any good, but ...
[21:44:22] <jepler> when it was fixed up a few months back (I think the toolchange position was just ignored or not used) we decided that the idea it would move the (possibly different-length) tool back to the same uncompensated position seemed .. problematic
[21:44:29] <jepler> cradek: can you back me up on this?
[21:44:48] <SWPadnos> I remember some discussions on the topic - that's the only reason I know that part of the spec ;)
[21:44:53] <anonimasu> jepler: maybe im confusing the cam/emc part..
[21:45:09] <anonimasu> jepler: I may be missing what emc should do, and what the post should spit out after a toolchange..
[21:45:43] <alex_joni> SWPadnos: so.. any other possible problems with my plan?
[21:46:11] <jepler> anonimasu: in terms of g-code, you should run 'M6' toolchange from a safe location, and follow it with another move to a safe location
[21:46:36] <SWPadnos> alex_joni, it seems OK in the short term, and may be good enough for the long term. there are issues with the way pause / step/start/stop work with non-movement words though
[21:46:37] <jepler> defining all three coordinates (or more if you've got a machine with rotary axes)
[21:46:39] <anonimasu> yeah
[21:47:10] <alex_joni> SWPadnos: I'm SURE lots and lots of stuff will appear while I go through specifics
[21:47:12] <anonimasu> SWPadnos: what prevents you from piping the pause command to your plc?
[21:47:22] <SWPadnos> from?
[21:47:28] <anonimasu> that pauses the mdi your executing..
[21:47:39] <SWPadnos> that's what alex is suggesting, more or less
[21:47:46] <SWPadnos> it's not MDI
[21:47:55] <anonimasu> SWPadnos: it requires 2 different levels of pause..(plc) and user..
[21:48:27] <SWPadnos> the PLC should do a specific sequence every time it's "activated" - you shouldn't need to pause it
[21:48:35] <SWPadnos> ah - nevermind
[21:48:41] <anonimasu> SWPadnos: well, why did you talk about _pause_ in a toolchange?
[21:48:48] <anonimasu> there are issues with the way pause / step/start/stop work with non-movement words though
[21:48:52] <SWPadnos> there's one pause in EMC, whre it comes from ismakes no difference
[21:49:00] <SWPadnos> I didn't :)
[21:49:06] <alex_joni> anonimasu: implementation specific problems atm
[21:49:09] <anonimasu> SWPadnos: 22:50 < SWPadnos> alex_joni, it seems OK in the short term, and may be good enough for the long term. there are issues with the way pause / step/start/stop work with non-movement words though
[21:49:11] <alex_joni> but those will be fixed
[21:49:14] <SWPadnos> ah - that
[21:49:14] <anonimasu> err sorry..
[21:49:27] <anonimasu> SWPadnos: I assumed you wanted to pause in the toolchange..
[21:49:42] <SWPadnos> ales said "pause the program and do other stuff ..."
[21:49:42] <alex_joni> anonimasu: he just brought it to my attention, so I don't overlook that while touching the same areas
[21:49:49] <SWPadnos> alex, that was
[21:50:01] <alex_joni> anonimasu: right, I said pause on a custom M-code
[21:50:29] <alex_joni> anonimasu: that way one can (from the custom M-code) send some MDI movement commands
[21:50:34] <anonimasu> yeah
[21:50:47] <SWPadnos> the other part of the documentation was making it so you don't have to use a custom M-code to do that (but that's not up for implementation any time soon, I think)
[21:51:13] <alex_joni> SWPadnos: even if it would be.. I think the functionality might still be needed
[21:51:14] <SWPadnos> alex_joni, did you notice jepler's idea for external hooks in canon?
[21:51:23] <alex_joni> yeah, also a nice idea
[21:51:35] <alex_joni> maybe we can call canon stuff from M-codes ?
[21:51:37] <SWPadnos> that may be useful for what you're thinking of
[21:52:14] <SWPadnos> well, you're thinking of making python (or whatever) programs with custom M-codes - you could also put in hooks like jepler suggested and still write python code for those functions
[21:52:26] <SWPadnos> but then they'd be on the "normal" M-codes
[21:52:36] <alex_joni> right
[21:53:04] <SWPadnos> I think it's advantageous to have M6 do toolchange, rather than M106 ...
[21:53:19] <anonimasu> agred
[21:53:21] <anonimasu> err agreed
[21:53:25] <alex_joni> yeah, I like that too
[21:53:32] <anonimasu> though it may be implementation specific..
[21:53:41] <anonimasu> but, the more standard the better..
[21:53:48] <SWPadnos> that's the point - you'd use the new hooks to write implementation specific things
[21:53:51] <anonimasu> or well "integration" specific..
[21:53:52] <alex_joni> I don't like things that need compiling though
[21:54:01] <anonimasu> ,)
[21:54:02] <anonimasu> ;)
[21:54:06] <SWPadnos> since G-code defines M6 as the "change tool" function, it makes sense
[21:54:14] <alex_joni> SWPadnos: that's where python comes in
[21:54:19] <SWPadnos> I agree, but then again, the python code doesn't need it
[21:54:25] <anonimasu> yeah, what it actually does isnt important..
[21:54:26] <anonimasu> :D
[21:54:35] <alex_joni> you need to compile the hooks I think ?
[21:54:36] <anonimasu> err "how it does it in the enc"..
[21:54:58] <SWPadnos> all the canon code needs "compiled in" is a function that looks for a named function/file somewhere, and loads/runs it if found
[21:55:00] <anonimasu> as long as it's possible to change what it does..
[21:55:16] <SWPadnos> yes, there need to be changes to canon
[21:55:38] <alex_joni> SWPadnos: hmm
[21:55:50] <SWPadnos> did you see jepler's code?
[21:55:50] <alex_joni> M6 might be a bunch of canon calls
[21:56:05] <SWPadnos> it should be CHANGE_TOOL() or similar ...
[21:56:23] <alex_joni> ah ok
[21:56:35] <SWPadnos> I don't know that it is, but it should be ;)
[21:57:00] <alex_joni> hmm.. this makes it a bit simpler
[21:57:13] <SWPadnos> http://pastebin.ca/393658
[21:57:18] <alex_joni> implementation wise I mean
[21:58:02] <SWPadnos> yes. I think it addresses a lot of the concerns, other than re-specifying the meaning of G-codes (g-code "personalities")
[21:58:24] <anonimasu> hm, I like that example..
[21:58:32] <alex_joni> it also makes it probable for people to redefine stuff completely
[21:58:57] <SWPadnos> yes, it's possible to do that, which is a support nightmare, but still ;)
[21:59:02] <alex_joni> but I guess people doing those things won't need hand-holding anyways
[21:59:33] <anonimasu> toolchanging isnt something all hobbyists will have anyway or custom codes..
[21:59:41] <SWPadnos> there have been so many questions about getting Haas or Fanuc code to run right, or which post to use in some CAM program - I finally thought it may be better for EMC to be able to change dialects
[21:59:48] <SWPadnos> (but that's topic #2)
[22:00:13] <anonimasu> I'd think that's more if you are running lasers/plasmas.. which may need other commands..
[22:00:24] <SWPadnos> the nice thing about jepler's code is that it doesn't change anything unless there's a reason to
[22:00:26] <anonimasu> special machines.. or maybe robots..
[22:00:34] <anonimasu> SWPadnos: yeah agreed
[22:00:37] <alex_joni> anonimasu: I plan to run emc one day on a bot
[22:00:37] <SWPadnos> if you don't implement "tool_change_pre", the behavior is the same as before
[22:00:48] <alex_joni> but I need to write another interpreter for that
[22:00:58] <alex_joni> I think G-code is not suitable
[22:01:14] <SWPadnos> that's where the "canon becomes microcode" thing gets useful
[22:01:17] <anonimasu> alex_joni: you would want a teach in mode also?
[22:01:29] <alex_joni> anonimasu: sure do, it wouldn't be usefull without
[22:01:44] <anonimasu> * anonimasu nods
[22:01:59] <alex_joni> err... useful
[22:02:18] <anonimasu> jepler's idea solves the multiple command issue..
[22:02:36] <alex_joni> * alex_joni goes to write 'It's wrong to spell useful as usefull' a 100 times on paper
[22:02:42] <SWPadnos> it effectively pauses canon while some other stuff happens
[22:02:48] <anonimasu> yeah
[22:02:59] <SWPadnos> it doesn't help with getting motion done externally though, I think
[22:03:03] <anonimasu> also, you can plug hal pins there to verify toolchanger operation..
[22:03:09] <SWPadnos> hmmm. actually it does
[22:03:14] <anonimasu> yep
[22:03:33] <anonimasu> though not injected..
[22:03:40] <alex_joni> SWPadnos: so if I get it right..there would be a longer file with all those python functions already defined (but void)
[22:03:41] <SWPadnos> oh duh. he said there would be a library of functions that could be called from the external python code
[22:03:51] <alex_joni> and the user just needs to add their code
[22:04:00] <SWPadnos> sort of. a library with "pycanon" functions
[22:04:13] <SWPadnos> I'm not sure how he planned to find the various functions
[22:04:19] <alex_joni> which all are pre/post conditions on canon calls
[22:04:25] <SWPadnos> I think the idea was that you'd recompile to change things, but I'm not sure
[22:04:28] <alex_joni> maybe even for FEED & ARC and whatever
[22:04:49] <SWPadnos> I'd change the scheme a little, I think
[22:04:51] <anonimasu> no..
[22:05:01] <anonimasu> you dont need to recompile unless you want to redefine something completely
[22:05:14] <SWPadnos> the split of preconditions/<work>/postconditions is pretty flexible
[22:05:29] <anonimasu> if you want to change your toolchanging code modify the python and run...
[22:05:30] <SWPadnos> I'd have the ability to replace those individually
[22:05:54] <alex_joni> SWPadnos: all of them?
[22:06:20] <SWPadnos> not the conditions themselves, the 3 sections of the canon code that do anything
[22:06:20] <alex_joni> then I guess the way to do it is to have emccanon.cc have only wrapper calls to the python code :)
[22:06:32] <alex_joni> and reimplement all canon calls in python
[22:06:37] <anonimasu> I like that scheme..
[22:06:43] <anonimasu> though python isnt realtime..
[22:06:43] <alex_joni> then the user can replace them easily :P
[22:06:49] <alex_joni> or extend them or whatever
[22:06:54] <alex_joni> anonimasu: CANON isn't realtime
[22:06:58] <anonimasu> oh
[22:06:58] <anonimasu> :D
[22:07:06] <SWPadnos> so in the example, I;d have another return value like SUCCESS, which could then go on to the next bit
[22:07:07] <SWPadnos> one sec
[22:07:31] <anonimasu> * anonimasu curses that he dosent know enough about the stuff inside emc2 :D
[22:07:43] <anonimasu> all I can do is yell and have ideas :/
[22:07:47] <anonimasu> troll around :/
[22:08:01] <alex_joni> anonimasu: I've been reading the code for the past 2 years :P
[22:08:29] <anonimasu> alex_joni: kind of tough to come from a day of coding and look at more code :)
[22:08:39] <alex_joni> anonimasu: I know..
[22:10:01] <SWPadnos> http://pastebin.ca/393877
[22:10:10] <jepler> i'd much rather look at emc code than the code I get paid to look at
[22:10:20] <SWPadnos> that's been more pseudo-ified, but that's what I've been trying to describe
[22:11:00] <SWPadnos> of course, tool_change_pre should have been modified, because it actually does it all ...
[22:11:39] <alex_joni> SWPadnos: the problem I see here is with the param passing
[22:11:48] <alex_joni> maybe it's not enough to pass only the tool number
[22:11:52] <SWPadnos> varargs, baby!
[22:11:55] <anonimasu> ^_^
[22:12:03] <anonimasu> I guess you should pass all args..
[22:12:10] <anonimasu> and leave it up to the integrator to handle them
[22:12:11] <SWPadnos> I don't know - that's concept code only, details are left as an exercise for the reader
[22:12:23] <alex_joni> SWPadnos: how about passing world view?
[22:12:31] <SWPadnos> dunno
[22:12:33] <alex_joni> one huge struct with everything in it?
[22:12:45] <alex_joni> that would allow for the code to use whatever it might need
[22:12:50] <alex_joni> current pos
[22:13:02] <alex_joni> work extents
[22:13:02] <SWPadnos> I'm not sure. I don't know that these snippets would get a full world view
[22:13:05] <anonimasu> that's a good thing if you are defining a custom cycle..
[22:13:30] <anonimasu> (here I go again) on the heidenhain you can do a "sysread" to read position and stuff..
[22:13:31] <SWPadnos> sure, but then again, asking for "traverse(-INF,+INF) should return an error or soemthing
[22:13:53] <anonimasu> like for implementing custom cycles... drill with variable retract height based on depth..
[22:14:06] <SWPadnos> those library functions certainly need some access to world view, but the hooked functions may not
[22:14:11] <petev> cradek, why do I always see this when axis starts?
[22:14:13] <petev> Can't open MDI history file [/home/petev/.axis_mdi_history] for reading
[22:14:33] <SWPadnos> even so, that stuff can be passed - possibly a different set for some functions, or not if it's easier
[22:15:05] <jepler> petev: it's harmless
[22:15:15] <petev> yes, I fugured that
[22:15:25] <alex_joni> petev: touch /home/petev/.axis_mdi_history
[22:15:29] <petev> but who creates the file, if not axis?
[22:15:31] <anonimasu> petev: does that file exist?
[22:15:39] <petev> no
[22:15:43] <anonimasu> create it like alex said
[22:15:54] <petev> so a manual create is needed?
[22:16:07] <alex_joni> petev: I think it got created automatically here
[22:16:12] <petev> why not add the create if doesn't exist to the open call?
[22:16:21] <SWPadnos> is that supposed to be in the home directory or in the machine config dir?
[22:16:42] <anonimasu> run-in-place poses a issue there :)
[22:16:55] <alex_joni> SWPadnos: home dir
[22:16:58] <SWPadnos> it's an issue for a computer that controls multiple machines
[22:17:04] <alex_joni> machine config dir is not writeable for default configs
[22:17:17] <SWPadnos> right - hence the question :)
[22:17:19] <anonimasu> in the nc-files directory?
[22:17:26] <SWPadnos> though I could have actually read pete's information
[22:17:43] <anonimasu> that's where my control puts the mdi stuff.. with the other programs as a file with the name $MDI.h
[22:17:49] <alex_joni> hmm.. I'll ponder some more on the canon changes
[22:18:00] <SWPadnos> cool
[22:18:12] <anonimasu> nice :)
[22:18:34] <alex_joni> but I'd still like to be able to do things like this from custom m-codes
[22:19:27] <SWPadnos> sure - that would be another good thing :)
[22:19:35] <anonimasu> wouldnt it work to expand it?
[22:19:46] <anonimasu> so canon could hook other stuff on the fly?
[22:19:57] <alex_joni> anonimasu: not quite
[22:20:04] <SWPadnos> not really - the interpreter issues a fixed set of canon calls for each input G/M code (rmore or less)
[22:20:28] <anonimasu> alex_joni: I'm lacking how the interp calls canon..
[22:20:44] <anonimasu> gah *goes away to browse the cvs*
[22:20:52] <alex_joni> SWPadnos: another more extensive change would be for task to open a pipe to the spawned process
[22:20:57] <SWPadnos> that's where #2 comes in - you make the canon a lower level set of commands, and then allow someone to define G29.3 or M22 or whatever as some set of those commands
[22:21:08] <alex_joni> and expect g-codes through there, which it would feed to interp
[22:21:19] <anonimasu> * anonimasu nods
[22:21:20] <SWPadnos> alex_joni, yes, as long as it can time out, I'm happy
[22:21:38] <SWPadnos> hmmm. there was a discussion of this kind of thing in the distant past
[22:21:56] <SWPadnos> as long as it's treated like a subroutine, it should be OK
[22:22:04] <SWPadnos> there's probably some state that needs to be preserved
[22:22:05] <alex_joni> right
[22:22:17] <SWPadnos> (actually, we need "push" and "pop" G-codes)
[22:22:24] <alex_joni> although it might be a pita to open a pipe from bash :D
[22:22:44] <SWPadnos> I don't think it's too hairy
[22:23:01] <anonimasu> heh
[22:23:07] <SWPadnos> that would be done by the spawn/exec call, bash/whatever would just write to stdout
[22:23:10] <alex_joni> anyways.. nuff food for thought
[22:23:25] <SWPadnos> hmmm -emc can grab stderr also, and pop up nice error messages ...
[22:23:36] <alex_joni> * alex_joni stops thinking about it and goes to bed :)
[22:23:41] <SWPadnos> night night :)
[22:23:54] <alex_joni> good night.. I'll read back tomorrow morning
[22:24:00] <anonimasu> jepler TRUNK * emc2/docs/man/man1/halcmd.1: document getp, gets
[22:24:14] <alex_joni> leaving for germany on thursday though, so I'll be missing this weekend :(
[22:24:16] <SWPadnos> don't worry, wecan stop discussing it now :)
[22:24:18] <anonimasu> whoops
[22:24:27] <SWPadnos> me too, but going to Manchester, not Germany
[22:24:38] <alex_joni> Manchester UK?
[22:24:38] <petev> SWPadnos, do u have a 5i20 with secondary encoders connected?
[22:24:38] <SWPadnos> NH, not GB :(
[22:24:52] <SWPadnos> petev, no, I have no 5i20 with anything connected
[22:24:58] <petev> oh
[22:26:09] <petev> jepler, you care to move all the 5i20 files under the hal/driver/m5i20/XXX into one sub dir?
[22:26:19] <petev> seems a bit over kill to have a dir for each file
[22:26:30] <petev> maybe make one "bit" dir or something
[22:26:58] <alex_joni> petev: that was jmkasunich working on the 5i20 driver(s)
[22:26:59] <SWPadnos> will the driver detect the config?
[22:27:16] <petev> alex_joni, no this is old stuff, he started a new dir for his stuff
[22:27:38] <SWPadnos> alex_joni, this is the stuff from peteW, committed by anders(?)
[22:28:25] <alex_joni> oh, ok.. didn't see the connection to jepler .. that's why I said that
[22:28:42] <petev> I thought the CVS was on jeplers machine
[22:28:45] <alex_joni> and jepler's busy enough doing all sort of emc things
[22:28:59] <alex_joni> petev: moving things in the repo will bust peoples checkouts
[22:29:10] <petev> if someone else can move the files, then that's fine too
[22:29:12] <SWPadnos> petev, jepler does cvs stuff "remotely", unless it's fixing something
[22:29:19] <petev> the files aren't used in any builds right now
[22:29:23] <alex_joni> so if it gets moved it will be probably cvs remove, cvs add
[22:29:25] <petev> but I'm about to change that
[22:29:44] <SWPadnos> if you want to delete / re-add the files, then go ahead. I don't think there's any history on them
[22:29:52] <SWPadnos> check first though ;)
[22:29:59] <petev> shouldn't be, they are bit files ;-)
[22:30:19] <SWPadnos> there you go - shouldn't be a problem
[22:30:30] <petev> i'll del/add them
[22:31:07] <petev> the new FPGA config runs here, but I have no secondary encoders to test properly
[22:31:45] <SWPadnos> you can hook your encoders to the secondary inputs and reconfigure the HAL for testing
[22:32:12] <petev> I have nothing but some IO connected, it's just a test box
[22:32:17] <SWPadnos> ah
[22:32:18] <petev> but not very good for testing ;-)
[22:32:26] <SWPadnos> that's what I don't have at the moment
[22:32:41] <petev> roltek is building a real test setup
[22:32:46] <SWPadnos> I need to fix my RT machine before I can test anything
[22:32:49] <SWPadnos> cool
[22:32:49] <alex_joni> petev: you can generate encoder signals on the parport :)
[22:32:51] <petev> but I hate to push broken stuff into the repo
[22:32:56] <alex_joni> and link that to the 5i20 for testing :)
[22:33:01] <SWPadnos> heh - loopback from the 5i20 :)
[22:33:07] <petev> alex_joni, what par port?
[22:33:13] <SWPadnos> use some 5i20 outputs
[22:33:13] <petev> my HW isn't that old ;-)
[22:33:20] <alex_joni> petev: or even 5i20 IO
[22:33:22] <petev> yeah, that's painfull
[22:33:37] <SWPadnos> you don't need to do a full EMC config
[22:34:06] <SWPadnos> just load a stepgen or two, connect it to 2 pins, and connect those pins to any/all encoders you want to test
[23:03:32] <jepler> petev: looks like the file hal/drivers/m5i20/HOSTM54E.BIT is the one being used to generate the linked-in firmware "header" file
[23:03:54] <jepler> (see hal/drivers/Submakefile)
[23:05:10] <petev> yes, that's the dir with the broken FPGA config
[23:05:18] <petev> the good configs are in subdirs
[23:05:32] <petev> after roltek tests with the new config, we can delete all those files