Back
[01:08:04] <KimK_afk> KimK_afk is now known as KimK
[03:17:27] <CIA-1> EMC: 03jepler 07v2_2_branch * 10emc2/src/hal/drivers/hal_m5i20.c: this is an error
[03:17:44] <CIA-1> EMC: 03jepler 07TRUNK * 10emc2/src/hal/drivers/hal_m5i20.c: this is an error
[04:48:32] <KimK> KimK is now known as KimK_brb
[04:59:29] <KimK_brb> KimK_brb is now known as KimK
[17:57:48] <cradek> seb_kuzminsky: is there an advantage to the non-IM firmware? It seems like we would not need it since IM doesn't interfere with anything if you don't enable it.
[19:31:56] <seb_kuzminsky> cradek: I think you're right, the IM firmware is better for everything we currently do
[19:32:35] <seb_kuzminsky> the non-IM firmwares have 6 output pins per stepgen instance, to support 'table-driven step output'
[19:33:18] <seb_kuzminsky> but the driver doesnt support that yet, only 2-pin steppers (step/dir, up/down, and quadrature)
[19:33:20] <jmkasunich> is there any reason why table driven stepgens are associated with non-IM encoders? or just coincidence?
[19:33:28] <seb_kuzminsky> pin count
[19:33:38] <jmkasunich> oh, IM encoders need more pins
[19:33:43] <seb_kuzminsky> the IM firmwares needed some more pins... right
[19:33:49] <seb_kuzminsky> so the steppers shrunk
[19:34:07] <seb_kuzminsky> peter's been meaning to put out a bunch more firmwares with 2-pin steppers, but hasnt gotten to it yet
[19:34:21] <seb_kuzminsky> i think your cli-based firmware build system will take care of that neatly :-)
[19:34:49] <jmkasunich> if we (including peter) get the infrastructure straightned out, then I don't think peter will have to generate so many firmwares
[19:34:55] <jmkasunich> we can do it instead
[19:34:59] <seb_kuzminsky> agreed
[19:35:18] <seb_kuzminsky> i'll teach the buildbot how to do it, and we'll autogenerate all the bitfiles whenever any of the vhdl changes
[19:35:34] <jmkasunich> right now, pins can only be traded off between "functions" like stepgen, and GPIO, right?
[19:36:03] <seb_kuzminsky> the pin decriptor can hold any two "module function tags", but in practice one of them is always ioport
[19:36:08] <jmkasunich> it would be nice if you could trade pins between say a stepgen and a pwmgen, since a motor is likely controlled by one or the other
[19:36:18] <seb_kuzminsky> that *would* be cool
[19:36:56] <seb_kuzminsky> on gate-heavy fpgas you could have a single firmware with lots of modules, and a mux to select which module gets the io pins
[19:37:13] <jmkasunich> yeah
[19:37:22] <seb_kuzminsky> we'd seriously want some better way to configure the driver then ... ;-)
[19:39:19] <CIA-1> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/TODO: thanks to KimK for testing 5i22-1.5, and suggestions from PCW on stepgen improvements
[19:39:24] <seb_kuzminsky> jmkasunich: thanks for helping KimK get going yesterday :-)
[19:39:38] <jmkasunich> you're welcome
[19:39:55] <jmkasunich> there really wasn't much to do, once I followed peters advice and used the ted config
[19:40:19] <jmkasunich> global search/replace 7i43 -> 5i22, and a couple minor tweaks
[19:40:30] <seb_kuzminsky> that's what i like to hear :-)
[19:40:35] <jmkasunich> IMO we need to do some serious housecleaning of the sample configs
[19:41:02] <jmkasunich> if there is a preferred sample config for HM2, the user shouldn't have to guess which one it is
[19:41:02] <seb_kuzminsky> i switch back and forth between 7i43 and 5i20 in my testing, simply by changing an environment variable that gets subbed into all the HAL names
[19:41:22] <seb_kuzminsky> well, the one with hm2 in then name seems like a good first guess ;-)
[19:41:28] <seb_kuzminsky> hm2-servo and hm2-stepper
[19:41:39] <jmkasunich> if you are a guy with a 5i20, hm2 doesn't pop to mind, 5i20 does
[19:41:47] <seb_kuzminsky> the confusion imo is that there are like 3 or 4 drivers for the 5i20
[19:42:37] <jmkasunich> right
[19:43:05] <seb_kuzminsky> i'm planning to purge my old 7i43 drivers next week or so, but i dont think we're ready to get rid of m5i20 just yet
[19:43:07] <jmkasunich> the 5i2x stuff needs to go away (there was never a sample config for that, and it never really worked, so nobody should be using it)
[19:44:07] <seb_kuzminsky> that would leave us with just m5i20 and hm2, which sounds like a good place to be
[19:44:14] <jmkasunich> yeah
[19:44:29] <jmkasunich> it is very tempting to elimiate m5i20 for 2.3.0, but we'll have to discuss that
[19:45:04] <seb_kuzminsky> the hm2 configs are nearly card-agnostic... we could duplicate hm2-servo to hm2-servo-{7i43,5i2{0,2,3},4i6{5,8}}, but that seems kind of crowded and redundant
[19:45:53] <seb_kuzminsky> i think we're not well set up for doing env var substitution in the sample configs, though i did do that in the "hostmot2" pseudo-config that i've been using
[19:46:06] <jmkasunich> hmm
[19:46:17] <jmkasunich> we are set up to substitute from the inifile
[19:46:21] <seb_kuzminsky> which reminds me, i should remove the "hostmot2" config now that there's a real one
[19:46:34] <jmkasunich> and there is nothing to prevent us from adding new sections or vars to the ini
[19:46:47] <jmkasunich> in the [HAL] section, we could add a var MESA_BOARD
[19:47:24] <jmkasunich> then in hm2-servo.hal, do hm2-[HAL]MESA_BOARD.0.encoder.whatever
[19:47:34] <jmkasunich> not sure I have that syntax exactly right
[19:47:36] <seb_kuzminsky> there are three vars needed: HM2_DRIVER (hm2_7i43 or hm2_pci), HM2_BOARD (hm2_5i20, hm2_5i22, etc) and HM2_CONFIG (to pick the right firmware, mostly)
[19:47:38] <jmkasunich> also not sure how much I like it
[19:48:21] <seb_kuzminsky> that's from configs/hostmot2/hm2.hal
[19:48:21] <jmkasunich> to be honest, an individual user will be best served with simple HAL flies that do very little subsitution
[19:48:39] <seb_kuzminsky> yes that's true
[19:48:46] <jmkasunich> ie. already customised (or customized one time by an editor) for his board
[19:48:48] <seb_kuzminsky> and soemthing obvious, like the board-name in the config-name...
[19:49:03] <jmkasunich> that way the lines in the hal file correspond directly to commands that he could type in halcmd to test them
[19:49:31] <seb_kuzminsky> well, if he's got his env set up, then he *can* just type them in halcmd ;-)
[19:49:38] <jmkasunich> heh, what we need is something like stepconf "hm2conf"
[19:50:05] <seb_kuzminsky> that's a good idea
[19:50:31] <jmkasunich> it would read hm2-servo.hal and .ini (or something similar, perhaps with a .in extension, and substitution tags
[19:50:56] <jmkasunich> prompt for board, number of axes, etc, and generate files ready for further manual tweaking
[19:51:22] <seb_kuzminsky> or select daughter-boards from a pull-down menu (7i30 on P2, etc)
[19:51:27] <jmkasunich> yeah
[19:52:04] <jmkasunich> that kind of thing is sort of where I wanted to go with m5i2x, but 1) I bit off more than I could chew, and 2) peter kept inventing new boards
[19:52:09] <seb_kuzminsky> i went to add this to the todo file, and discovered it's already there, second from the top ;-)
[19:52:25] <seb_kuzminsky> "slow down, peter!"
[20:10:48] <tomaw> [Global Notice] Hi all, one of our hubs just disappeared taking services with it. We're looking in to the cause now.
[20:20:21] <tomaw> [Global Notice] Hi all. The connectivity problems seem to be resolved and services are back online. Sorry for the disturbance and thank you for using freenode.
[23:08:59] <cradek> seb_kuzminsky:
http://timeguy.com/cradek-files/emc/dt
[23:09:35] <cradek> seb_kuzminsky: I got a bunch of scary messages but the encoder still seems to be working
[23:09:41] <cradek> it was just sitting still when it did this
[23:13:17] <cradek> I had homed and then turned the spindle on and off a few times, then took a break and came back to find the messages
[23:14:23] <cradek> fwiw, it is still running, I have not exited emc
[23:35:27] <cradek> oh, I see it's mentioned in TODO already