Back
[00:00:56] <cradek> jepler: did you see that from pcw?
[00:02:57] <cradek> jthornton: yay! I'll go read the new stuff!
[00:03:23] <jthornton> ain't much there yet
[00:03:58] <cradek> what version of lyx is the annointed one now?
[00:04:21] <jthornton> the one that comes with 8.04
[00:04:35] <jthornton> 1.5.3
[00:04:50] <cradek> darn, I have 1.6.2
[00:05:19] <cradek> my two devel machines are <hardy and >hardy
[00:05:20] <jthornton> anything you need to add just e mail it to me and I'll be glad to add it
[00:05:23] <cradek> :-/
[00:05:34] <cradek> thanks!
[00:06:33] <jthornton> sometimes it is hard for me to keep up with new stuff added so when you add a new feature just holler at me :)
[00:07:31] <CIA-65> EMC: 03jthornton 07master * rde6c02be2c13 10/docs/src/gui/ (images/touchy.png touchy.lyx): Add Touchy
[00:08:03] <jthornton> that took a while
[00:08:08] <CIA-65> EMC: 03jthornton 07master * r8dca223092e4 10/docs/src/Master_User.lyx: Add Touchy to the Manual as well
[00:10:36] <cradek> PCW: [I know you aren't here but] I got the file - thank you!
[00:14:32] <cradek> jthornton: amazing how different ours look:
http://timeguy.com/cradek-files/emc/touchy.png
[00:17:36] <jthornton> I used smaller fonts so it would fit better on the page
[00:18:11] <cradek> I like how it can fit different screens with just a few settings
[00:19:04] <jthornton> if your machine has a tiny screen will it be possible to configure it on another computer somehow then copy the config to the machine computer
[00:19:22] <jthornton> or do they even make tiny touch screens for computers
[00:19:38] <cradek> I think by default it will fit on 800x600 ok
[00:19:54] <cradek> you could even just edit ~/.touchy_preferences if you were in a bind
[00:20:28] <jthornton> where is that file located?
[00:20:40] <cradek> home dir
[00:20:51] <cradek> but don't put that in the docs - people shouldn't need to mess with it
[00:20:59] <cradek> it remembers everything on the prefs screen
[00:22:25] <jthornton> ok
[00:24:15] <CIA-65> EMC: 03jthornton 07master * r9e3c18e5f20b 10/docs/src/gui/touchy.lyx: Shrink image to fit in PDF
[00:28:46] <jthornton> should I add sphereprobe.9 to .gitignore or just change .gitignore to *.9 so we don't have to mess with it again?
[00:35:32] <cradek> just add it I think - some of those files are not autogenerated so they are actually in git
[00:35:51] <cradek> it's a sin to put handwritten and autogenerated files in the same directory for this very reason
[00:50:25] <jthornton> ok, I didn't think of that
[00:52:28] <CIA-65> EMC: 03jthornton 07master * r901bf98b7ce3 10/docs/man/man9/.gitignore: Add sphereprobe.9
[01:11:22] <jepler> cradek: yes I see pcw's link
[08:54:22] <alex_joni> configure: WARNING: --enable-run-in-place will be removed soon.
[08:54:30] <alex_joni> ^^ when did that get decided?
[09:02:01] <micges> alex_joni: in master --enable-run-in-place is enabled by default, maybe this is it
[09:10:42] <alex_joni> micges: doesn't sound like that
[09:15:23] <CIA-65> EMC: 03alex_joni 07master * r9b9e48630f6c 10/docs/src/ (Submakefile index.tmpl): add Touchy to the html docs
[09:16:07] <alex_joni> whee.. I still know how to do this :D
[10:04:29] <micges> alex_joni: .configure --help: (snip) --enable-run-in-place A deprecated flag (instead, configure without specifying --prefix)
[13:18:21] <jepler> alex_joni: 54c20223167d6440be66f9537e44de82b9399ee1
[13:21:24] <jepler> we can revsit it if there's a reason to. my logic is that I want the case of people on ubuntu systems who build their own to get RIP and not screw up their installed package with a run-installed version.
[13:21:36] <jepler> you can still get --prefix=/usr/local, you just have to specify it
[13:29:53] <alex_joni> jepler: that sounds ok.. the message is what was confusing for me
[13:36:37] <cradek> you could make it the default behavior without removing the flag or giving a scary warning
[13:41:44] <mozmck> hmmm, I upgraded to 9.10 now and everything went smoothly. But one of the packages it says is deprecated is autogen. Is there a replacement for it?
[13:46:34] <SWPadnos> autogen doesn't show as deprecated on packages.ubuntu.com
[13:47:00] <SWPadnos> it is in universe though, which might be disabled at upgrade time
[13:47:46] <mozmck> ok, let me check some more. it was one of the programs it wanted to remove as part of the "cleanup" after the install.
[13:50:22] <mozmck> huh, it's in synaptic. don't know why it wanted to remove it.
[13:50:37] <SWPadnos> did you have to re-enable univertse?
[13:50:42] <SWPadnos> -t
[13:55:32] <mozmck> no. it upgraded everything. took a day and a half to get it all on my 512Kbps link!
[13:56:02] <mozmck> I think it only ran about half that speed though on average.
[13:58:06] <SWPadnos> I'm sure the million or two others upgrading had soemthing to do with that
[13:59:33] <mozmck> I'm sure. But I was at work so it didn't bother me.
[14:01:24] <SWPadnos> I suppose I should start a CD downloading this morning
[14:02:17] <mozmck> I've got it downloading now, seems to be running normal speed (for me anyhow).
[14:02:54] <mozmck> I think it must have downloaded several gig of stuff to upgrade this machine.
[15:29:25] <jepler> emc doesn't depend on the package 'autogen' to build. emc includes a script that happens to be called 'autogen.sh'.
[16:14:25] <Dave911> micges: >>in master --enable-run-in-place is enabled by default, maybe this is it
[16:14:26] <Dave911> Yes it is .... did that yesterday without run in place and it did it anyway....
[16:16:34] <Dave911> cradek: Threading report - didn't happen yesterday due to flaky index pulse on encoder.... Chan A and B work fine, Index is noisy and intermittent. Verified on Halscope and a hardware scope. Time for different encoder. Sorry..
[16:17:10] <Dave911> Will report back when I have a decent encoder!
[16:55:29] <jepler> pcw_home: is it possible that a file called 'PinExists.vhd' was omitted from the first probe-related zip file you sent Chris a few weeks ago?
[17:04:17] <pcw_home> Yes I just added it because the probe counter was enough bigger that it made some configs not fit
[17:04:19] <pcw_home> so I made the compilation of the counter with probe conditional on their being a probe pin in the pinout file
[17:05:43] <pcw_home> Also changed hostmot2.vhd to add the conditional generate
[17:06:41] <pcw_home> and the top level files... the last zipfile should have all the updated soure
[17:06:58] <pcw_home> (source)
[17:07:25] <jepler> I have the svst8_3p-source.zip you sent cradek. it refers to PinExists but doesn't have the PinExists.vhd file..
[17:10:32] <jepler> the source zip I am referring to is apparently
http://filebin.ca/zedfac 828,948 bytes md5sum e833defdac9bcb4d12b557314da856d9
[17:16:09] <pcw_home> must have forgotten to include it, but here it is:
http://filebin.ca/wtmfsm
[17:19:16] <jepler> thank you
[17:44:25] <jepler> (I'm working on the firmware building script again, in light of the new toplevel structure..)
[17:50:45] <pcw_home> Great, I hope its somewhat easier (and I haven't made it worse)
[17:51:26] <jepler> yes, I think this makes it easier
[17:56:13] <jepler> WARNING:PhysDesignRules:367 - The signal <LBE<0>_IBUF> is incomplete. The signal
[17:56:16] <jepler> does not drive any load pins in the design.
[17:56:23] <jepler> is this an important warning?
[17:57:43] <jepler> -rw-r--r-- 1 jepler jepler 167050 2009-10-31 12:56 5i20_SVST8_3P_72.BIT
[17:57:46] <jepler> whee, I have a bit file
[17:57:50] <pcw_home> No, I should just delete the top module I/O pins for the byte enables since I dont use them
[17:59:49] <jepler> so to change a pinout I modify a PIN_xxx.vhd file, and that's it?
[18:02:10] <jepler> (well, and change the toplevel vhd to refer to it)
[18:11:41] <cradek> jepler: you could come now, anytime you want to try out your stuff
[18:18:37] <pcw_home> Yes to make a new config, you just change the pinout (and point the top level to it)
[18:26:52] <jepler> hm2/hm2_5i20.0: IO Pin 005 (P2-11): Encoder (all), pin Probe (Input)
[18:38:55] <Dave911> http://groups.yahoo.com/group/mach1mach2cnc/message/114249
[18:38:57] <Dave911> http://groups.yahoo.com/group/mach1mach2cnc/message/114245
[18:38:59] <Dave911> Interesting discussion about EMC2 and Mach3 vs threading on the Mach3 Yahoo email forum..
[18:39:01] <Dave911> Threading is a major issue with Mach3 as you guys know..
[18:39:02] <Dave911> In order to defer the threading subject (as it really doesn't affect many people, and it isn't a big problem - (choke choke cough cough - ;-) according to Art ) and he isn't worried about it (although he has been working on it for well over a year - see the Mach3 web forum message list.. ) ... Art is saying jerk limiting is impossible to do in EMC2, (although it is not being done in...
[18:39:04] <Dave911> ...Mach3 yet either) Geez...
[18:39:06] <Dave911> This seems an awful lot like a slight of hand trick ----
[18:39:07] <Dave911> Good news - I have another encoder coming to replace the piece of crap I bought off fleabay which prevented me from threading last night... :-)
[18:39:52] <awallin> can I run emc in simulator mode on ubuntu 9.10 ?
[18:41:42] <pcw_home> "jepler>hm2/hm2_5i20.0: IO Pin 005 (P2-11): Encoder (all), pin Probe (Input)"
[18:41:44] <pcw_home> I think you've got it!
[18:41:45] <pcw_home> bbl hay run (hay ewe)
[18:42:24] <mozmck> jerk limiting impossible in EMC2? that sounds like a challenge to me :)
[18:42:24] <mozmck> awallin: should be able to.
[18:43:17] <micges> awallin: try if it works: sudo apt-get build-dep emc2
[18:43:24] <awallin> mozmck: ok, last I played with this was back in the cvs days... need to learn the git way now I guess.
[18:44:05] <awallin> micges: need to tune sources.list first...
[18:44:13] <CIA-65> EMC: 03jepler 07master * r7b8f6d0d32c8 10/scripts/haltcl.in: add an interactive mode to haltcl
[18:44:14] <CIA-65> EMC: 03jepler 07master * r072a6599a2ce 10/scripts/halrun.in: Add a way to get the interactive tcl prompt
[18:44:48] <jepler> cradek: I'll head out shortly.. I think I have the hm2probe branch in order for trying over there
[18:45:13] <micges> awallin: follow
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Git
[18:47:18] <awallin> micges: if I get the source with git, I still need all the build-dep packages? the install.sh only has repositories for hardy, will they work with karmic?
[18:48:38] <micges> awallin: yes, you need all build dep packages
[18:50:05] <micges> iirc on my 9.04 I've followed compilation istructions and installed packages that were missed (./configure will show them)
[18:50:15] <awallin> hm, not sure if I want to dig into this now. I guess packages for 9.10 are in the works?
[18:51:03] <micges> packages are only for LTS ubuntu versions
[18:51:13] <micges> 10.04 will be next
[18:52:25] <awallin> ok...
[18:52:55] <micges> awallin: you can install packages in 9.10 but it will install hardy version of rtai patched kernel (didn't tried it)
[18:53:22] <micges> but probably this will mess it up
[18:53:31] <awallin> for simulator mode I don't want to change kernels
[18:53:46] <micges> yes you don't need to
[19:04:29] <mozmck> hmm, Art says EMC2 doesn't do any lookahead and therefore can't do SCurve jerk limitation. Is this true? I thought the blending EMC2 does would require some lookahead...
[19:07:07] <awallin> I think it looks at the current segment and the next one.
[19:07:15] <awallin> emc2
[19:12:02] <mozmck> hmm, but there shouldn't be any reason this couldn't be changed if needed is there?
[19:13:36] <micges> mozmck: there is lookahead not only to next segment
[19:14:25] <micges> mozmck: I'm not native english, can you write some details what SCurve jerk limitation is?
[19:14:48] <mozmck> ah, so art was wrong about the lookahead and threading then in the link Dave911 gave above I guess...
[19:18:12] <mozmck> it has to do with smoothing the acceleration profile. I've been reading a bit on it lately but I'm not the best to define it yet.
[19:18:27] <micges> in canon stage of emc there is unlimited depth lookahead for colinear segments joining in G64 Pn mode
[19:18:43] <Dave911> I don't know how you can do CV if you don't have a look ahead... ?? And from what I have heard CV works in EMC2.
[19:19:03] <Dave911> Jerk is the first derrivative of accelleration...
[19:19:18] <mozmck> that's what I thought. maybe art hasn't looked at emc2 in a while.
[19:19:49] <Dave911> So like velocity is distance per time, and accel is distance per time squared, jerk is distance per time cubed ...
[19:20:17] <micges> I see thanks
[19:20:36] <awallin> the trick is to limit acceleration and jerk while allowing real-time adjustment of feed-override
[19:20:48] <awallin> if you dissallow feed-override I think the problem becomes quite a bit simpler
[19:21:16] <awallin> also the kinematics kind get hard. if you move in X,Y,Z, not all machines have joints that correspond to X,Y,Z
[19:21:29] <awallin> 'can get hard'
[19:21:36] <mozmck> yeah, it has to do with the rate of change of acceleration. a machine can't physically change acceleration instantaneously - I think...
[19:23:05] <mozmck> so the feed-override would be the main thing that would make the jerk-limiting function need to be computed in real-time?
[19:24:48] <awallin> I think so. It's a while I looked at this and thought about the problem.
[19:25:20] <awallin> if you want to look far into the future of the g-code stream you definitely have to assume the feed-override stays put at it's current value. I think...
[19:25:35] <mozmck> I'm studying it right now. Don't know what I can do but I have a lot of interest...
[19:25:48] <Dave911> Art really threw out a red herrring in that discussion. The fact is that he does have a demo traj planner that supposidly does S curving or jerk limiting (not clear on which he really has) that you can try with Mach3. However he has flat out stated that it will not be part of Mach3. IMO he brought up jerk limiting/S curving to throw people off track so it would limit the discussion of...
[19:25:49] <Dave911> ...Mach3's threading problems.
[19:26:21] <mozmck> I think SCurve is the graph of Jerk-limited acceleration...
[19:26:54] <mozmck> I thought he was planning to put it in Mach3 eventually?
[19:27:48] <Dave911> No, he flat out stated that it would not be part of Mach3. I can find the quote for you.... I read that very closely.
[19:28:39] <micges> Dave911: can you paste link?
[19:29:02] <Dave911> I think so... let me look for it....
[19:29:17] <mozmck> I think I saw that, but I don't remember exactly what he said. I skim to much...
[19:32:25] <awallin> there is a paper which describes a "segment-queue" trajectory planner which most emc
[19:32:46] <awallin> probably there's a link in the wiki
[19:34:07] <awallin> http://cat.inist.fr/?aModele=afficheN&cpsidt=14525766
[19:34:35] <awallin> the pdf is somewhere online also. I think there was work on this but it never got all the way into emc2
[19:35:25] <mozmck> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Whitepapers_For_Reference
[19:35:46] <Dave911> Sorry I don't have the message number... but in a message from Art2 9/23/09 at 12:54 pm
[19:35:48] <Dave911> >>>This planner is not slated to be used in Mach3 in any near future, but is R&D to try to develop the next generation of planner for the future. It has been a holy grail in CNC for the hobbiest for some time as it emulates ( or tries to ) what the very big boys have been doing for a few years now.
[19:35:49] <Dave911> So why is he mentioning S curving when the discussion is about threading issues ... RED HERRING ... or salesmanship.. ;-) Whatever. He tried to throw the conv off track..
[19:36:04] <mozmck> Some of these are what I've been reading through, as well as others I've found.
[19:44:36] <awallin> if someone is going to run a really fast/big with emc2 they probably will need better lookahead. for hobby mills the current trajectory planner is probably good enough
[19:45:21] <awallin> but commercial machines have accelerations of > 1g and rapids of 40m/min or something crazy. Need to process one or many blocks of code per servo cycle etc.
[19:51:21] <micges> awallin: I have machine with acc = 1,05g and rapid 42m/min under emc2 and Scurve acceleration would be very usable ;)
[19:52:51] <awallin> micges: nice! any pics or videos out there? are you running 'trivial' kinematics with one joint for X,Y,Z? would you be willing to have feed-override fixed for the part program? or at least the lookahead buffer emptied if feed-override is changed?
[19:55:36] <micges> this is double header welder (XYU) configuration, trivial kins
[19:56:05] <micges> feed override can be fixed
[19:56:56] <micges> feed override is usable for 'teaching' mode whis is done in 10x smaller acc/vels
[19:59:31] <awallin> I think it's doable but there are not many emc'ers who are willing to mess with that part of the code...
[20:00:08] <micges> it's only 24h per day ;)
[20:02:06] <micges> bbl
[20:02:08] <mozmck> micges: that's a problem for sure :-) I'm willing to try on the planner, but we'll see if I can actually do anything...
[20:02:17] <awallin> as soon as someone sends me a VMC that really needs lookahead I promise to work on that :)
[20:46:44] <alex_joni> mozmck: I'm not sure it's really useful to write another trivkins planner, even if s-curve
[20:47:02] <alex_joni> it would be more useful to write an s-curve planner based on joint limits
[20:47:13] <alex_joni> which is a HUGE deal harder to do ;)
[20:47:50] <mozmck> that's what I was sort of looking at!
[20:50:02] <alex_joni> well.. the thing is that planning is done in carthesian (world) space
[20:50:11] <alex_joni> so you plan the move in XYZABCUVW
[20:50:13] <mozmck> sonja's paper covers task and joint space planning, and looks fairly thorough if I can through it.
[20:50:31] <mozmck> get through it that is...
[20:50:37] <alex_joni> well.. there were quite a few people reading sonja's (including myself)
[20:50:53] <mozmck> what do you think of it?
[20:50:57] <alex_joni> but understanding the stuff, doing the math and implementing it in emc2 are kinda different thingss
[20:51:07] <alex_joni> mozmck: I think it looks nice :D
[20:51:18] <alex_joni> but I didn't spend the time needed to really get into it
[20:51:22] <mozmck> heh, quite true.
[20:51:23] <alex_joni> e.g. take care of the math
[20:51:38] <alex_joni> btw.. if you want, I can send you some s-curve planner
[20:51:56] <mozmck> yeah, I'm having to brush up / learn new math, but I enjoy that stuff.
[20:51:57] <alex_joni> it's written by Fred P. from NIST
[20:52:08] <alex_joni> and could (theoretically) be integrated into emc2
[20:52:17] <alex_joni> one thing is that it doesn't do blending atm
[20:52:32] <alex_joni> so it is jerk limited, but in exact stop mode
[20:52:35] <mozmck> I'd love to see it! Examples help me learn a good bit.
[20:52:53] <mozmck> interesting.
[20:53:08] <alex_joni> they wrote a new motion controller for robots only
[20:53:10] <awallin> there was a dutch group who describe a jerk and double-jerk limited exact-stop planner. I think I have matlab code for it also.
[20:53:48] <awallin> exact stop, trivial kins, and no feed override = easy
[20:53:52] <mozmck> never used matlab, can it be translated to c pretty easily?
[20:54:28] <awallin> yes it should not be that hard. octave is the free version of matlab, it might work on that too
[20:54:42] <alex_joni> this is exact stop, non-trikins and no feed override iirc
[20:55:48] <mozmck> I was thinking octave was like matlab, but I haven't used that either.
[20:55:57] <awallin> blending + trivial kinematics + no/limited feed-override would be acceptable for most high-end mills I think
[20:56:39] <alex_joni> feed-override < 1 should be quite doable
[20:56:52] <awallin> mozmck: if you send me your email I can dig for the papers and matlab code
[20:57:06] <alex_joni> mozmck:
http://eneas.juve.ro/~juve/emc/related/
[20:57:22] <awallin> fo <1 could just slow down the machine. if you also want the blending to more accurately follow the programmed path it might be hard
[20:58:09] <alex_joni> awallin: right
[20:58:38] <alex_joni> one approach is to precompute the path, then keep the path rigid and just increase/decrease based on FO
[20:58:57] <alex_joni> precompute the path for the fastest possible speed (requested vel * max FO)
[20:59:09] <mozmck> thanks for the link.
[21:01:47] <mozmck> for feed override, if the path is already precomputed for the maximum velocity acceleration given the machine constraints and maximum divergence from the commanded path, if fo > 1 I would think you could just increase the velocity on the straight sections.
[21:01:49] <alex_joni> the first version has some issues.. the second one should have them fixed
[21:02:12] <alex_joni> mozmck: no.. you can increase the velocity on the whole path
[21:02:25] <alex_joni> if the path is computed given max. constraints
[21:02:49] <mozmck> not if you're already at the max constraints I wouldn't think.
[21:03:25] <alex_joni> currently (the existing TP) plans at the max constraints
[21:03:35] <alex_joni> that means max machine velocity/accel settings
[21:03:49] <alex_joni> if you have 100 mm/sec max vel on X,Y,Z
[21:03:51] <mozmck> you can't round a corner any faster than the machine can physically do it, and if you increase the radius you will not meet the tolerance requirement
[21:03:58] <alex_joni> and the program requests 50 mm/sec
[21:04:15] <alex_joni> then even if you have FO at 400%, it still won't go faster than 100 mm/sec
[21:04:46] <mozmck> yes, but on a corner it may have to slow down to 5mm/sec
[21:05:39] <mozmck> so even at FO at 400% you can only go 5mm/sec around the corner.
[21:06:47] <mozmck> but I guess is the requested feedrate is lower than the machine can go around the corner then you would have to recompute that then, but still not the blend functions maybe?
[21:07:00] <mozmck> -is +if
[21:07:19] <mozmck> I'm probably not making any sense.
[21:08:41] <mozmck> I think I'm saying basically what you said >... precompute the path, then keep the path rigid and just increase/decrease based on FO
[21:09:10] <awallin> there are two problems here, that's why it's hard. one is to output trajectory points each servo period and ensure that the max vel/acc/jerk limits are not violated. The other problem is to choose a geometric path that is close to the programmed path but allows an easier solution of problem 1.
[21:09:54] <awallin> mozmck: if you precompute and keep rigid then you get no improvement in accuracy with fo < 1. some people might expect the machine to closely follow the programmed path when going slowly.
[21:11:13] <mozmck> I think you would just change the tolerance setting wouldn't you?
[21:11:25] <mozmck> that's P64 isn't it?
[21:11:38] <awallin> G64 P0.1 or something
[21:12:30] <awallin> precomputing whilre respecting the G64 Pxx limit and then keeping the path rigid while allowing fo<1 is certainly one approach
[21:16:54] <alex_joni> remember there are a couple of FO's in emc2
[21:17:02] <alex_joni> there's the FO coming from the GUIs
[21:17:28] <alex_joni> then there's AF (adaptive feed rate) which potentially comes from a sensor (like for EDM)
[21:17:51] <alex_joni> then there's SO (spindle speed override) which gets used on synced moves
[21:22:21] <mozmck> do they all behave differently?
[21:38:04] <alex_joni> no, they get multiplied together
[21:38:18] <alex_joni> but it's extra things to consider ;)
[21:41:17] <alex_joni> this is interesting:
http://ubuntu-tutorials.com/2009/10/29/use-zsync-to-update-existing-iso-images/
[21:50:15] <mozmck> that's pretty neat.
[22:32:10] <jepler> pcw: how is an "all units" pin supposed to come up? The second bitfile you put up uses unit 0x80 pin 0x5; the one I built from the last sources gives unit 0x80 pin 0x45
[23:05:41] <CIA-65> EMC: 03jepler 07master * r5c1c1ec6ada4 10/src/hal/components/sim_encoder.c: provide rawcounts output
[23:05:41] <CIA-65> EMC: 03jepler 07master * re0f1607d6b3e 10/src/emc/motion/control.c: only update joint-pos-probed when probe tripped
[23:05:43] <CIA-65> EMC: 03jepler 07master * r0220b2fe5012 10/src/hal/drivers/mesa-hostmot2/hostmot2.h: fix HM2_PRINT and friends to be expressions
[23:05:43] <CIA-65> EMC: 03jepler 07master * r37134f92392e 10/src/hal/drivers/mesa-hostmot2/encoder.c: accept new module version
[23:05:46] <CIA-65> EMC: 03jepler 07master * re9ce01206afa 10/src/hal/drivers/mesa-hostmot2/pins.c: handle new "applies to all instances" pins
[23:05:49] <CIA-65> EMC: 03jepler 07master * r35780fed3df1 10/src/hal/drivers/mesa-hostmot2/pins.c: show correct name for pin
[23:05:52] <CIA-65> EMC: 03jepler 07master * rc7869588edb1 10/src/hal/drivers/mesa-hostmot2/hostmot2.h: define additional encoder status register bits
[23:05:55] <CIA-65> EMC: 03jepler 07master * r55011a51cef0 10/src/hal/drivers/mesa-hostmot2/ (encoder.c hostmot2.h): High resolution probing for hostmot2
[23:06:00] <CIA-65> EMC: 03jepler 07master * raf1cced0e006 10/ (4 files in 2 dirs): provide additional probing-related outputs
[23:06:38] <jepler> ^^ I hope that's right
[23:06:45] <jepler> I massaged it a bit since the version that we ran on jr
[23:07:00] <jepler> mostly to take out the "backwards compatible" change that is a bit controversial
[23:07:03] <jepler> bbl
[23:25:38] <pcw_home> Jepler should you read this later, its pin5 channel (unit 0x80)
[23:25:40] <pcw_home> the 0x45 pin was before I though about it long enough to realize
[23:25:41] <pcw_home> "all" should be coded in the unit #, and leave the pins alone
[23:27:20] <pcw_home> (so correct for probe is pin 5 unit 0x80)
[23:44:13] <jepler> pcw_home: makes sense, thanks
[23:45:48] <jepler> pcw_home: we did get it working nicely -- +- 1 count repeatability moving at 20 inch/minute (8.5 counts/ms)
[23:46:11] <jepler> but for some reason the probed position is still speed-dependent
[23:46:17] <jepler> so good-and-bad
[23:46:49] <jepler> (I assume it's some delay in the probe, which is a wireless type)
