Back
[00:56:13] <cradek> jepler: where can I find your 7i48 hm2 driver patch?
[01:13:51] <jepler> cradek: maybe
http://media.unpythonic.net/emergent-files/sandbox/0001-untested-support-for-muxed-encoders.patch
[01:14:02] <cradek> yay thanks
[01:14:13] <jepler> do you have a firmware?
[01:15:16] <cradek> I have /lib/firmware/hm2/5i20/SV12IM_2X7I48_72.BIT from hostmot2-firmware-5i20 version 0.7.1
[01:15:50] <jepler> ah
[01:15:55] <jepler> I don't remember putting that in, but evidently I did
[01:25:41] <cradek> well it looks better when it loads now...
[01:27:59] <cradek> now adding 24 to a bunch of pin numbers
[01:32:32] <cradek> I don't think it's quite right
[01:32:47] <cradek> [ 2845.329367] hm2/hm2_5i20.0: IO Pin 010 (P2-21): Muxed Encoder Select #0, pin Mux Select 0 (Output)
[01:32:57] <cradek> [ 2845.329520] hm2/hm2_5i20.0: IO Pin 034 (P3-21): Muxed Encoder Select #0, pin Mux Select 0 (Output)
[01:33:04] <cradek> this is with
[01:33:16] <cradek> firmware=hm2/5i20/SV12IM_2X7I48_72.BIT num_encoders=1 num_pwmgens=0 num_stepgens=0 enable_raw
[01:33:35] <cradek> I think P3-21 should be IOPort
[01:34:25] <jepler> looks that'd be a bug/limitation in the bitfile idrom
[01:34:36] <jepler> it matches what the PIN file says
[01:34:45] <jepler> P3-21 34 MuxedQCountSel 0 Muxed Encoder Select 0 (out)
[01:35:20] <cradek> ok
[01:35:36] <cradek> is that something for pcw to sort out or do we have control over it?
[01:35:59] <jepler> I wonder if saying it was channel 3 would work out (since the hostmot2 driver always uses lowest numbered instances, and you need the pin as soon as you have any channels on that connector..)
[01:36:30] <jepler> if we decide what makes sense to do with that pin, I'll put it in the hostmot2-firmware git
[01:37:17] <cradek> http://timeguy.com/cradek-files/emc/dmesg-with-7i48
[01:37:31] <cradek> there are a few other pins that I think should also be IOPort?
[01:38:25] <jepler> which one? P4-01?
[01:38:48] <cradek> yeah I guess it's just that one
[01:38:49] <jepler> I don't think the driver gives you a choice whether to use the index mask function when you use the corresponding encoder
[01:39:19] <cradek> I think it's a param
[01:39:46] <cradek> if you don't set the param, it ignores the state of index-mask, so you're free to use it as an io
[01:39:46] <cradek> pretty sure I do that on the hnc
[01:40:42] <cradek> yes it's in man hostmot2
[01:40:51] <cradek> hi pcw!
[01:41:41] <jepler> cradek: encoder.whatever.index-mask? That can't be used at hardware detection time, though, you can't have set it yet
[01:42:22] <cradek> jepler: but it doesn't matter - you still get corresponding gpio pins that you can use
[01:42:36] <pcw_home> Hi
[01:42:38] <pcw_home> I the I fixed the mux pin problem in my source by making the second mux be channel 6 (so its not enabled by the driver unless more than 6 encoders are enabled)
[01:42:45] <cradek> it just tells the encoder to not mask index according to it
[01:44:49] <pcw_home> (I think I)
[01:44:52] <jepler> IOPortTag & x"06" & MuxedQCountSelTag & MuxedQCountSel0Pin, -- I/O 34
[01:45:14] <jepler> yes, if I read my patch right 6 is the number that makes sense there
[01:46:22] <pcw_home> Yes so only if the second 7I48 is used is the pin forced to be output with alternate source
[01:52:22] <cradek> I have the 7i48 on P2 but nothing wired to it. hm2_5i20.0.gpio.000 - 010.in are reading true/false randomly (should they even show up?)
[01:52:22] <cradek> also 034
[01:53:50] <pcw_home> Yes that may be (the muxed encoder inputs will look like bit hash if not read synchonously)
[01:54:33] <pcw_home> 34 should be 50% so about = high/low
[01:54:43] <cradek> oh ok
[01:55:16] <cradek> should the driver hide those gpios that don't make sense to use as gpio?
[01:56:00] <cradek> ok machine is running (except for the output that was on 034)
[01:56:05] <cradek> I will try putting an encoder on the 7i48
[01:57:39] <pcw_home> Good question, theres also a possible bug waiting to happen if people think they can read encoder pins on GPIOS
[01:57:40] <pcw_home> (ou can still read the A/B/I levels through the encoder hardware however)
[01:58:15] <pcw_home> ou --> you
[02:14:02] <cradek> yay - encoder 0 counts
[02:17:22] <cradek> index works
[02:28:53] <cradek> pcw_home: documentation bug: 7i48 manual says default is ttl encoder input ("left"), but mine came all set to rs422/right
[02:33:58] <pcw_home> OK thanks I'll fix docs
[02:36:30] <jepler> cradek: fixed mux select pin firmware:
http://emergent.unpy.net/files/sandbox/hostmot2-fixed-7i48.tar.gz
[02:38:54] <cradek> wow that was fast
[02:40:39] <cradek> trying now
[02:43:07] <cradek> yep that gives me my 034 output back
[02:43:07] <cradek> slick
[02:44:14] <jepler> and with a larger number of encoders selected, does it take the second mux select at the right time?
[02:44:18] <jepler> (num_encoders=7, I guess)
[02:44:41] <cradek> and 048 does show up as gpio.in, so it works like the other IM fw
[02:45:09] <cradek> so you want me to try num_encoders=6 and num_encoders=7 and see if it happens at 7 but not 6?
[02:45:21] <jepler> right, I think so
[02:45:35] <cradek> one minute
[02:47:05] <cradek> yes
[02:47:19] <cradek> num_encoders=6 my config still loads and works
[02:47:26] <cradek> =7 gives me touchy.hal:34: parameter or pin 'hm2_5i20.0.gpio.034.is_output' not found
[02:48:35] <jepler> so that means the change is right, right?
[02:48:41] <cradek> yes I think so
[02:49:52] <cradek> I had to mess with your patch somewhat because it conflicted with 3pwm changes. should I push it to master?
[02:50:03] <cradek> (also removed debug output)
[02:50:07] <jepler> yes, if you are happy with it at this point
[02:50:08] <jepler> thank you
[02:50:24] <cradek> I can't find any problem with it.
[02:50:43] <cradek> however I've only hooked up an encoder 0
[02:55:14] <jepler> I think it stands a decent chance of being right, and an even better chance of being close
[02:55:17] <CIA-2> EMC: 03cradek 07master * rda0d5aa5563d 10/src/hal/drivers/mesa-hostmot2/ (hostmot2.c hostmot2.h pins.c): Support for multiplexed encoders (7i48)
[02:56:31] <cradek> thanks for your help
[02:57:01] <cradek> will a new hostmot2-firmware-5i20 package magically appear now?
[03:00:14] <cradek> guess not - I don't have anything related to firmwares in sources.list
[03:01:26] <jepler> firmwares are in 'base'
[03:01:46] <jepler> but I won't go through the effort of publishing new packages tonight
[03:02:06] <cradek> all I have is buildmaster on this machine
[03:02:16] <cradek> yeah - it's not urgent
[03:03:40] <jepler> if you want to get hostmot2 updates you should add hardy or lucid 'base' to your sources
[03:05:05] <cradek> "deb
http://www.linuxcnc.org/emc2 lucid base emc2.4" ?
[03:05:56] <jepler> yes, or leave off 2.4 if you always want buildbot packages to take precedence over linuxcnc ones
[03:06:02] <jepler> (leave off 'emc2.4')
[03:06:15] <cradek> gotcah
[03:06:16] <cradek> ha
[03:11:56] <jepler> 'night
[03:13:02] <cradek> goodnight, thanks again
[16:46:26] <skunkworks> did I mention how cool comps are?
http://pastebin.ca/1913905
[16:47:39] <jepler> I'm excited you're getting the hang of them
[16:48:02] <Jymmm> "comp" being exactly what?
[16:48:30] <Jymmm> compensation?
[16:48:39] <skunkworks> an easy way to make hal componants.
[16:48:53] <Jymmm> Ah, components. Gotcha.
[16:50:24] <skunkworks> jepler: yes - playing around I can see the light at the end of the tunnel :)
[17:51:44] <jepler> * jepler just wonders what the names like "sssol"
[17:51:49] <jepler> "so, so, so out of luck"?
[17:52:58] <skunkworks> heh - I named the pins the same as the solinoid pins. ss solinoid
[17:54:12] <skunkworks> k solinoid, sa solinoid and so on
[17:55:23] <skunkworks> I am using raw encoder counts for testing. I want the spindle to rotate so many rotations before it decides that it is shifted.
[17:55:55] <skunkworks> so - I say rotate 'this' many encoder counts for now.
[18:01:16] <skunkworks> it is mainly shifting into the first gear after enabling the components. There really is no feedback to say that it is in gear. When we get the encoder mounted on the spindle for rigid tapping - then we can compare the ratio between spindle motor and spindle to see if the gear shift was successful
[18:02:41] <skunkworks> so - inital shift will be so many rotations. Any shift after that I think I will use 'so many rotations' + the pressure transistion as the gears shift. That should be pretty accurite.
[18:05:22] <skunkworks> for now
[18:18:39] <cradek> http://mpm1.com:8080/machines/CNCcontrols/fanuc10/FILE0059.JPG
[18:19:03] <cradek> the control on the enshu that died: soon to be emc2/touchy
[18:19:33] <skunkworks> Cool - that was a well used machine. wow
[18:19:48] <cradek> yes I think they use(d) it constantly
[18:27:07] <skunkworks> is that 4 axis?
[18:27:39] <cradek> the control must support it, but I don't think they have a rotary on it
[18:28:10] <skunkworks> the jog toggles are interesting
[18:28:19] <skunkworks> if that is what I see on the right side
[18:28:28] <cradek> yes
[18:28:42] <cradek> I did a similar thing on my panel
[18:29:20] <cradek> http://timeguy.com/cradek-files/emc/jr.jpg
[18:29:34] <cradek> you can just barely see the three toggles in this photo
[18:29:47] <cradek> X is left-right, Z is up-down and Y is diagonal
[18:30:44] <skunkworks> neat
[18:31:05] <skunkworks> how did the 6 axis daughter board go?
[18:31:47] <cradek> it works now, needed a firmware change and driver change
[18:32:16] <cradek> have to physically mount it and wire my jogwheel to it before jr is working again
[18:32:16] <cradek> then I'll try generating the Y tach signal.
[18:33:19] <skunkworks> how are you going to do that? are you going to use one encoder counter for position and one for velocity?
[18:34:04] <cradek> the first thing I'll try is just feeding the encoder velocity right out an extra dac
[18:34:13] <cradek> scaled so rapids are near 10v
[18:34:22] <cradek> then adjust the amp tach gain accordingly
[18:34:35] <skunkworks> oh - ok - duh - you need to run the velocity back to your amps.
[18:34:44] <cradek> yes
[18:35:43] <skunkworks> ok - that makes sense now. I thought you where going to try to do some sort of dual loop thing in emc.
[18:35:50] <skunkworks> cradek: did you see
http://electronicsam.com/images/KandT/conversion/servo/belts.jpeg
[18:36:25] <cradek> neat! when will it move?
[18:36:39] <skunkworks> soon :)
[18:37:19] <cradek> yay
[18:38:20] <skunkworks> we still need to mount the y servo - but that is direct coupled - so just drilling holes in the right places. :)
[18:38:31] <skunkworks> but we should be able to start tuning x and z soon.
[18:40:43] <cradek> slick
[18:41:03] <cradek> what are you using for feedback? not the scales for now I assume?
[18:47:30] <skunkworks> encoders. (and tachs)
[18:48:09] <cradek> on the motors?
[18:49:33] <skunkworks> yes
[18:52:51] <skunkworks> the tachs (when cleaned up) look very good.
http://electronicsam.com/images/KandT/conversion/servo/tach.JPG
[18:53:01] <skunkworks> the output 90v at 1200rpm
[18:53:29] <skunkworks> *they
[19:31:21] <skunkworks> cradek: are we taking bets on how long it will take to convert? 6 days?
[19:31:26] <skunkworks> 3 days?
[19:43:17] <skunkworks> 2 days and an all nighter?
[20:28:08] <alex_joni> heh
[20:30:40] <cradek> just the thought of that makes me tired.
[20:30:42] <alex_joni> http://pastebin.ca/1914040
[20:32:09] <cradek> ?
[20:33:10] <alex_joni> that was an automatic email that a post has been made to a thread
[20:33:24] <alex_joni> "Do not answer to this e-mail notification as it is a generated e-mail."
[20:35:47] <cradek> it's from the Forum Forum
[20:36:24] <alex_joni> THE Forum Forum
[20:40:12] <alex_joni> http://www.linuxcnc.org/images/fbfiles/images/test.jpg
[20:40:32] <alex_joni> cradek: alternative GUI for junior
[20:42:00] <cradek> yes I especially like the 5x7 dot matrix font. the high resolution high quality anti-aliased fonts I have now are too hard to read.
[20:42:23] <alex_joni> anti-aliased is not retro enough :D
[20:43:09] <cradek> the fake-retro candy lozenge UI look and feel is like cilantro - people love it or hate it.
[20:44:29] <cradek> I bet no cyan 5x7 LED displays exist in the real world - those should be red. that's my real complaint :-)
[20:45:03] <jepler> it'd be best if I didn't get drawn into discussing this.
[20:45:36] <jepler> it's nice that emc has programmable interfaces that don't force developers into a specific widget toolkit.
[20:45:36] <cradek> jepler: you agree, right? they should be red, right?
[20:48:09] <cradek> http://milo.com/leapfrog-clickstart-my-first-computer
[20:48:29] <skunkworks> rewind?
[20:50:02] <jepler> hint?
[20:50:55] <skunkworks> that gui has a rewind button
[20:51:04] <jepler> and the leapfrog has a hint button
[20:51:08] <skunkworks> heh
[20:51:13] <skunkworks> got it
[20:51:36] <cradek> I wish my computer had a hint button
[20:51:48] <skunkworks> I wish life had a hint button
[20:55:07] <alex_joni> and a rewind button
[20:55:39] <JT-Work> I wish my edge finder had a "hey stupid you forgot the minus sign" flashing light
[20:56:42] <skunkworks> is it a 2 piece edge finder now?
[20:57:00] <cradek> JT-Work: all my edge probing routines print a message like "spind center is now at X-0.2"
[20:57:00] <cradek> spindle, even
[20:57:11] <cradek> that way I can't (as easily) mess it up or confuse the sign
[20:57:37] <JT-Work> this was on the Anilam :/
[20:57:38] <cradek> but for a regular edge finder I don't know how you'd do that...
[20:58:22] <JT-Work> yea a std mechanical edge finder and if I had gone fishing this morning I'd be ahead instead of behind LOL
[20:58:47] <cradek> arg.
[20:59:03] <JT-Work> I do have a real purdy paper weight now to add to the collection :)
[21:14:44] <gtom_> need some help implementing a "goto" in emc
[21:19:49] <jepler> beyond knowing that flow control is implemented mostly in interp_o_word.cc I don't have any specific advice about doing that
[21:20:29] <alex_joni> gtom_: in regular programming any goto case can be rewritten as an if/loop
[21:21:25] <gtom_> what i mean is a goto function in the gcode, i wrote the code and it works except...
[21:21:53] <gtom_> o words and user defined functions have some problems
[21:23:23] <gtom_> i am unsing the preview interpreter to calculate the machine state & position for
[21:23:41] <gtom_> a particular line of code.
[21:24:25] <gtom_> This allows me to stop emc at a certain position and to "reentry" in the code
[21:26:12] <gtom_> the problem is if the m101 function is executed the motion controler does not stop at this position
[21:28:00] <gtom_> example: some lines o gcode -> m110 sends a command to my gui to perform homing
[21:28:38] <gtom_> my gui pauses the interpreter, stores the task motion line
[21:29:10] <gtom_> and finally sends a stop
[21:30:09] <gtom_> switch to mode manual, perform a home, calculate the last position in the preview interpreter
[21:31:17] <gtom_> change to mdi mode, set the machine in the state given by the preview interpreter sneding mdi commands and finally restart the program at the last known position.
[21:33:42] <gtom_> how is the last move before a M1xxx command handled ???
[21:35:27] <gtom_> Is it possible to have an excact stop on a M1xx command ???
