Back
[06:06:02] <Jymmm> Jymmm is now known as Red70sShow
[06:06:19] <Red70sShow> Red70sShow is now known as Jymmm
[13:00:20] <cradek> psha: good morning - gladevcp won't insert itself into touchy - I get x protocol errors instead. 'xterm -into' works fine with touchy so I think the problem is in gladevcp.
[13:00:37] <cradek> my stdout/stderr:
http://pastebin.ca/1970361
[13:41:39] <ries_> ries_ is now known as ries
[14:46:47] <skunkKandT> How do I know what bit file to use to run the 6 axis 7i48?
[14:51:02] <skunkKandT> do I use SV12IM_2X7I48_72.BIT instead?
[14:51:12] <skunkKandT> for one?
[14:59:22] <jepler> skunkworks: even if you have just one 7i48, you'd still use the 2x7i48 file
[14:59:37] <jepler> you'll just enable fewer encoders and pwms
[15:02:48] <skunkworks> jepler: hmm - the 7i48 is the 6 axis daughter board.
[15:03:08] <skunkworks> I have one 5i20 with the 7i33 and the other is going to have a 7i48
[15:03:44] <skunkworks> *the other 5i20
[15:08:25] <skunkKandT> if I do CONFIG="firmware=hm2/5i20/SVST8_4.BIT num_encoders=4 num_pwmgens=4 num_stepgens=0, firmware=SV12IM_2X7I48_72.BIT num_encoders=4 num_pwmgens=4 num_stepgens=0"
[15:08:34] <skunkKandT> emc never starts or errors
[15:09:51] <skunkKandT> is it because I need atleast 6 encoders and 6 pwmgens?
[15:11:36] <skunkKandT> * skunkKandT tries
[15:12:13] <skunkKandT> nope - CONFIG="firmware=hm2/5i20/SVST8_4.BIT num_encoders=4 num_pwmgens=4 num_stepgens=0, firmware=hm2/5i20/SV12IM_2X7I48_72.BIT num_encoders=6 num_pwmgens=6 num_stepgens=0"
[15:12:19] <cradek> skunkKandT: loadrt hm2_pci config="firmware=hm2/5i20/SV12IM_2X7I48_72.BIT num_encoders=6 num_pwmgens=6 num_stepgens=0 enable_raw,firmware=hm2/5i20/SVST8_4.BIT num_encoders=4 num_pwmgens=4 num_stepgens=0
[15:12:20] <skunkKandT> doesn't load emc - or error
[15:12:26] <cradek> "
[15:12:29] <cradek> this is mine
[15:13:47] <skunkKandT> I am using trunk as of a few weeks ago
[15:15:27] <jepler> no messages on the terminal? no messages in dmesg?
[15:16:20] <skunkKandT> hold on - I have to reboot
[15:20:42] <skunkKandT> http://pastebin.ca/1971001
[15:24:03] <skunkKandT> I swapped the bit files order also - same deal
[15:24:31] <skunkKandT> (in the config line in the ini file)
[15:24:53] <skunkKandT> I am not seeing anything.
[15:25:22] <skunkKandT> (I don't have to reboot - the normal config line still loads.)
[15:27:17] <psha> cradek: maybe i've broken something while moveing modules
[15:28:31] <skunkKandT> why are there muxed index masks on pin 34,48,49,50?
[15:30:06] <psha> i'll finish adding gobject properties to hal_led and fix this
[15:31:35] <skunkKandT> psha: my issue?
[15:34:11] <psha> no, cradek's :)
[15:34:18] <skunkworks> heh - ok :)]
[15:40:03] <skunkKandT> ok - if I unlink all the pins that are muxed index masks - (34,48,49,50) emc will load
[15:42:14] <skunkKandT> Is the bit file I have wrong - maybe?
[15:49:56] <cradek> the index mask pins should also be usable as gpio
[15:50:12] <cradek> are they not? that's a bug if.
[15:51:31] <cradek> yeah seems like those pins should also say IOPort
[15:53:32] <cradek> er, I'm wrong, on hm2/5i20/SVST8_4IM2.BIT they don't say IOPort
[15:53:41] <cradek> are you trying to use them as gpio output or input?
[15:53:51] <cradek> seems like they can work as input, but probably not output
[15:54:09] <skunkKandT> ah - that would make sense
[15:54:28] <cradek> more specifically I bet 34 is output only, 48 49 50 are input only
[15:54:49] <cradek> so you may have to rewire a bit :-/
[15:55:05] <skunkKandT> hm2_5i20.1.gpio.047.invert_output
[15:55:05] <skunkKandT> 14 bit RW FALSE hm2_5i20.1.gpio.047.is_opendrain
[15:55:06] <skunkKandT> 14 bit RW FALSE hm2_5i20.1.gpio.047.is_output
[15:55:07] <skunkKandT> 14 bit RW TRUE hm2_5i20.1.gpio.051.invert_output
[15:55:09] <skunkKandT> 14 bit RW TRUE hm2_5i20.1.gpio.051.is_opendrain
[15:55:10] <skunkKandT> 14 bit RW TRUE hm2_5i20.1.gpio.051.is_output
[15:55:25] <skunkKandT> skips over.
[15:55:26] <cradek> yep
[15:55:39] <cradek> those have to be ins, so they can (optionally) be used for index mask
[15:55:48] <cradek> likewise I bet 34 is out only
[15:56:35] <cradek> hmmmm, I have no idea how you'd mask index for the encoder you want. maybe that should be removed from the bitfile if it's unusable anyway
[15:57:58] <skunkKandT> so I could use those pins then?
[15:58:10] <cradek> yes if index mask was removed from the bitfile
[15:58:14] <jepler> I can whip up a bitfile with those index-mask-related pins removed..
[15:58:21] <skunkKandT> I am suprisingly running out of pins.. :)
[15:58:31] <cradek> there will still be that one output-only
[15:58:51] <cradek> jepler: am I missing something, or is it impossible to use it anyway?
[15:59:55] <skunkKandT> heh
[15:59:57] <cradek> amazing
[16:00:04] <skunkKandT> Hi pete
[16:00:25] <pcw_home> Hi skunkKandT
[16:00:37] <jepler> hm, recovering pin 34 looks harder
[16:01:07] <pcw_home> More wrong is pin 34 that should have been fixed
[16:01:21] <jepler> and/or it's a driver issue
[16:01:40] <pcw_home> Maybe just an old bitfile issue
[16:02:20] <pcw_home> (the second select pin should be for channel 6)
[16:02:34] <jepler> aha, pcw's right. I fixed that but haven't released the fix
[16:02:43] <jepler> so the bug is still in the hostmot2-firmware-0.7 package from linuxcnc
[16:02:57] <jepler> but it'll be fixed in this firmware I'm about to make without the index mask too
[16:04:11] <skunkKandT> so.. - I will be able to use all the pins as gpio? or just the 3 outputs?
[16:05:52] <jepler> skunkKandT: I think it'll fix the issue with all 4 of the pins
[16:06:00] <skunkworks> you guys are awesome!
[16:06:17] <cradek> ain't that the truth
[16:06:37] <pcw_home> Theres actually no reason that special inputs could not be used as GPIO (other than confusing the user)
[16:07:02] <jepler> as for whether IM makes sense, couldn't you build an external mux from the same signal that muxes everything else?
[16:07:16] <jepler> I don't see why IM wouldn't work, but it does seem like it'll need something more sophisticated than wires
[16:07:42] <cradek> I see what you mean
[16:08:00] <cradek> wonder if anyone but me needs IM
[16:08:25] <pcw_home> the Index mask on the 7I48 config is not muxed (it can be thats the MIM option)
[16:09:44] <cradek> but it says hm2/hm2_5i20.1: IO Pin 048 (P4-01): Muxed Encoder #0, pin Muxed IndexMask (Input)
[16:09:56] <jepler> hmmm in that case there's a driver-side problem -- skunkKandT wanted num_encoders=6 but only got 3 IM pins
[16:10:02] <cradek> is that detected wrong?
[16:10:38] <jepler> Number of occupied Slices: 2,350 out of 2,352 99%
[16:11:59] <pcw_home> Maybe, Not sure whats in Skunkworsk bitfile,the bitfile on our website has 12 inon muxed index masks
[16:14:21] <jepler> skunkKandT:
http://emergent.unpy.net/files/sandbox/5i20_SV12_2X7I48.zip
[16:15:48] <skunkKandT> jepler - drop them in the lib/frimware/hm2/5i20
[16:15:52] <skunkKandT> ?
[16:16:10] <jepler> skunkKandT: yes and change the firmware name
[16:16:17] <jepler> pcw_home: I think the bug is somewhere in the neighborhood of this driver code:
[16:16:18] <jepler> // muxed encoder gets the sel pins
[16:16:21] <jepler> hm2_pins_allocate_all(hm2, HM2_GTAG_MUXED_ENCODER_SEL, hm2->encoder.num_instances);
[16:16:24] <jepler> // and about half as many I/Os as you'd expect
[16:16:26] <jepler> hm2_pins_allocate_all(hm2, HM2_GTAG_MUXED_ENCODER, (hm2->encoder.num_instances+1)/2);
[16:17:26] <jepler> for the muxed encoder index function it needs to allocate all num_instances pins
[16:17:47] <pcw_home> Yes the would have to be patched for the IM but left the same for MIM
[16:19:29] <pcw_home> On the other hand only wierdos need IM and MIM is not even supported in any hardware
[16:20:12] <jepler> how do you recognize IM vs MIM in the idrom?
[16:20:29] <cradek> I resemble that remark
[16:20:41] <pcw_home> different module ID I think
[16:21:12] <pcw_home> Or perhaps different pin I'd have to look.
[16:23:10] <jepler> but either way, the existing driver will balk at it
[16:23:33] <jepler> as opposed to me having to worry that the change I'm contemplating will be breaking a user with a working MIM configuration
[16:24:38] <pcw_home> Yes fix IM and worry about MIM when and if its ever needed
[16:28:44] <skunkKandT> emc loads with the new bit file :)
[16:28:57] <skunkKandT> yay!
[16:29:06] <skunkKandT> (with all the pins hooked up and such)
[16:29:13] <jepler> skunkKandT: good news
[16:32:18] <pcw_home> Probably best to ignore the MIM stuff for now its not even supported fully in the firmware yet
[16:32:19] <pcw_home> (both muxed Index mask and muxed probe are supported in the hardware but they need new pin #s and the logic then hooks them up is missing)
[16:32:41] <pcw_home> (logic that)
[16:33:02] <skunkKandT> boy - I have to remember all things I have done - well - I guess so far it is the fix for the bit pins and then the firmware.
[16:33:36] <skunkKandT> jepler: did you push the changes you made to head?
[16:33:57] <jepler> skunkKandT: hostmot2 firmwares are in a separate git repository from emc2
[16:34:14] <jepler> anybody want to try my untested 7i48 index pin fix? (that is in emc2)
http://emergent.unpy.net/files/sandbox/0001-hm2-7i48-register-the-proper-number-of-index-mask-pi.patch
[16:34:33] <skunkKandT> I mean the fix for boolean issue with the mesa card
[16:35:44] <jepler> ummm I think so
[16:36:35] <jepler> skunkKandT: mmmmmaybe not
[16:37:50] <CIA-112> EMC: 03jepler 07master * r5ebc6a475028 10/src/hal/drivers/mesa-hostmot2/ioport.c: hostmot2: handle a 'bit' pin with a value other than 0 or 1
[16:38:12] <jepler> actually that should be on v2.4_branch
[16:39:16] <psha> why emc2-sim installs only compiled python scripts?
[16:39:27] <psha> is it's feature? :)
[16:39:28] <jepler> and actually it was already, but v2.4_branch hasn't been merged to master lately
[16:39:35] <jepler> psha: because we're all too tired to make the packaging right
[16:39:42] <skunkKandT> jepler: thankyou
[16:39:57] <jepler> (to use python-support or whatever they've changed it to this week)
[16:40:09] <pcw_home> skunkKandT, tried to fit the resolver firmware in a 5I20 for your accupins but no luck, too much RAM/ROM
[16:41:09] <psha> :))
[16:41:14] <skunkKandT> aww - pcw_home thanks for trying
[16:41:30] <pcw_home> 217% full
[16:41:31] <jepler> skunkKandT: you'll just have to buy one of those beefier fpgas
[16:41:48] <skunkKandT> so - if I had the 400kgate array?
[16:42:11] <skunkKandT> (5i22)
[16:42:48] <pcw_home> Fits easily, I can even fit the Resmod and a 8 channel sserial in a 400K part (5I23 or 7I43)
[16:44:02] <skunkKandT> so - did we think that it would work for the 4 coil heads?
[16:44:16] <skunkKandT> (2 coils centertapped)
[16:44:41] <pcw_home> I might be able to squeeze it ti fit a 5I20 but I would need to get rid of the sine lookup table and do some less RAM wasteful way of doing the DAQ
[16:45:15] <psha> cradek: gladevcp embedding was working and then breaks on same config?
[16:45:20] <pcw_home> I think I would be tempted to try running it backwards as a resolver first
[16:45:25] <skunkKandT> ah
[16:45:52] <psha> cradek: or you've changed glade file for embeded panel?
[16:46:40] <CIA-112> EMC: 03jepler 07master * r0b98210f6738 10/docs/man/man9/ (hm2_pci.9 hostmot2.9): better 3x20 info in hostmot2 and hm2_pci manpages
[16:46:41] <CIA-112> EMC: 03jepler 07master * r6dfb6c15e5f6 10/src/emc/usr_intf/pncconf/pncconf.py: fix following error when inverting servo motor direction
[16:46:43] <CIA-112> EMC: 03jepler 07master * r21f7c966f13d 10/src/emc/usr_intf/pncconf/pncconf.py: fix inversion of encoder on servo configs
[16:46:44] <CIA-112> EMC: 03jepler 07master * rd3e4927e768e 10/src/emc/usr_intf/pncconf/pncconf.py: remove spaces from setp commands so tcl calibration program works
[16:46:45] <CIA-112> EMC: 03jepler 07master * r290bf1737b22 10/src/hal/drivers/mesa-hostmot2/ioport.c: hostmot2: handle a 'bit' pin with a value other than 0 or 1
[16:46:46] <CIA-112> EMC: 03jepler 07master * ra427ac719b4e 10/src/emc/usr_intf/touchy/emc_interface.py: touchy: fix three-digit active gcodes being displayed wrong
[16:46:48] <CIA-112> EMC: 03jepler 07master * rafdcdd2e1172 10/src/emc/usr_intf/pncconf/pncconf.glade: raise max values on spinboxes for metric machines
[16:46:52] <CIA-112> EMC: 03jepler 07master * rb5bb7beec1b3 10/ (VERSION debian/changelog): release v2.4.5
[16:48:41] <pcw_home> Theres also a new waveform gen module in HostMot2. With a 2 phase version of the generator and a
[16:48:43] <pcw_home> special counter you might be able to make it work the original way
[16:48:44] <pcw_home> (this would be small enough to fit in a 5I20)
[16:49:05] <CIA-112> EMC: 03jepler 07master * rb2f01c3f2730 10/src/emc/usr_intf/pncconf/pncconf.py: fix external jogging buttons option on lathe configs
[16:49:06] <CIA-112> EMC: 03jepler 07master * r928bfb34b6f4 10/ (6 files in 4 dirs): Merge remote branch 'origin/v2.4_branch'
[16:49:39] <skunkKandT> pcw_home: very cool
[16:50:43] <pcw_home> ( you would just need a couple of zero crossing comparators for the front end, and perhaps a power op amp to drive the coils)
[16:51:13] <cradek> psha: completely new glade generated yesterday
[16:52:00] <psha> gladevcp this.glade shows it correctly?
[16:52:02] <psha> without embeding?
[16:52:38] <cradek> yes
[16:52:55] <cradek> when I try the embed, it comes up but in its own window, with every control disabled (greyed)
[16:53:05] <cradek> accompanied by those error messages in the pastebin
[16:53:13] <psha> yes i've seen
[16:53:40] <psha> may you add some debug prints in gladevcp? at least window.window.xid is important
[16:53:48] <psha> in embedding part
[16:55:20] <psha> or may you send glade file to me?
[16:55:30] <psha> i'll test it localy
[16:55:42] <cradek> I can send it
[16:55:47] <psha> psha@psha.org.ru
[16:55:53] <psha> or url as you wish
[16:56:28] <cradek> http://timeguy.com/cradek-files/emc/lathepanel.glade
[16:56:38] <psha> thx
[16:56:57] <psha> it's gray for me without embedding...
[16:57:01] <psha> it's correct?
[16:57:35] <cradek> hmm, it should not be gray
[16:57:38] <cradek> wonder what I did wrong
[16:57:52] <psha> BadWindow
[16:57:57] <psha> i'll debug it now
[16:58:03] <cradek> but I agree - it is grey here too
[17:02:38] <psha> hal tables are controlled by hal pin
[17:02:45] <psha> if it's 0 then table will be disabled
[17:02:59] <cradek> oh ok
[17:03:11] <cradek> so that's not the problem at all?
[17:03:32] <psha> suppose so
[17:03:42] <psha> i think it's not related to badwindow bug
[17:04:09] <psha> if you replace HAL_Table with GtkTable buttons are active
[17:05:17] <psha> and i've found what caused badwindow
[17:05:22] <psha> but don't understand why
[17:05:33] <psha> it tries to embed child frame
[17:05:39] <psha> not top-level one
[18:29:03] <psha> cradek: i've found workardound for this issue...
[18:30:34] <psha> as a side effect gladevcp panels in axis are resizing correctly :)
[18:40:35] <psha> cradek: may you check last commit in gladevcp-modules branch
[18:59:47] <cradek> sweet!
[19:01:09] <psha> working?
[19:01:33] <psha> i'm also refactored makepins so it takes widgets from glade/gtkbuilder
[19:01:44] <psha> thus no direct xml parsing is needed
[19:05:32] <cradek> yes works for me
[19:06:01] <cradek> nifty
[19:06:07] <cradek> should I push this merge?
[19:07:09] <psha> not yet
[19:07:39] <psha> there is one more change pending
[19:07:53] <cradek> ok
[19:11:29] <psha> try last changes
[19:11:48] <psha> i've checked both with gtkbuilder/libglade files and both are working
[19:13:01] <cradek> works for me
[19:15:07] <psha> i think it's now in pretty good state and may be merged
[19:15:31] <cradek> label of float and format %4.1f works, thanks for doing that
[19:15:40] <psha> there is one more question
[19:15:51] <psha> now widgets are imported as gladevcp.hal_pythonplugin
[19:16:01] <psha> .hal_pythonplugin part may be safely discarded
[19:16:11] <psha> so it will be simple gladevcp
[19:16:19] <psha> like gtk, vte, etc...
[19:16:46] <psha> at this point i don't see any hidden issues in this name shortening
[19:17:13] <psha> only one is that all glade files generated with old catalogs will complain about 'unable to find gladevcp.hal_pythonplugin'
[19:17:22] <cradek> if you are asking my opinion, I have none - I don't know about those issues at all
[19:18:29] <psha> it's 'thinking aloud'
[19:18:33] <psha> always helps me a lot
[19:19:23] <cradek> this part definitely looks good to me
[19:22:16] <psha> so i'll better break names this time then when everybody is used to old ones
[19:25:53] <psha> take a look at last change
[19:26:02] <psha> it breaks names a bit
[19:26:59] <psha> old panels work fine but before editing them with glade you must fix module name in first lines of file
[19:27:12] <psha> but makes them a bit more sane
[19:27:17] <psha> i mean names
[19:27:21] <cradek> ok
[19:27:42] <cradek> early is always better than later if you need to break old stuff to improve sanity
[19:27:43] <psha> since there are only two people with new names in panels it's not issue :)
[19:27:58] <cradek> heh ok
[19:29:21] <cradek> ok to push this merge now?
[19:29:35] <psha> yes
[19:30:01] <psha> i'll ask cmorley to take a look on master
[19:33:44] <CIA-112> EMC: 03cradek 07master * r65b1d57c819c 10/lib/python/gladevcp/ (__init__.py hal_python.xml): gladevcp: Fix glade plugin module path
[19:33:46] <CIA-112> EMC: 03cradek 07master * r861ccaa82d2f 10/lib/python/ (gladevcp/makepins.py gladevcp_makepins.py): gladevcp: Move gladevcp_makepins inside gladevcp
[19:33:49] <CIA-112> EMC: 03cradek 07master * r37bfb1ed0b13 10/lib/python/gladevcp/ (hal_widgets.py makepins.py): gladevcp: Add text and zones for progress bar
[19:33:50] <CIA-112> EMC: 03cradek 07master * rf7c7fddbde2c 10/ (5 files in 4 dirs): gladevcp: Move catalog and pixmap to share
[19:33:50] <CIA-112> EMC: 03cradek 07master * rb1b5ad5ea6be 10/ (5 files in 4 dirs): gladevcp: Revert "gladevcp: Move catalog and pixmap to share"
[19:33:51] <CIA-112> EMC: 03cradek 07master * rd4c28a09d014 10/lib/python/gladevcp/ (hal_widgets.py makepins.py): gladevcp: Add properties and text format to label
[19:33:54] <CIA-112> EMC: 03cradek 07master * r4da69cca13b1 10/lib/python/gladevcp/ (led.py makepins.py): gladevcp: Added gobject props to HAL_LED
[19:33:54] <CIA-112> EMC: 03cradek 07master * r790618a79307 10/src/hal/user_comps/gladevcp.py: gladevcp: Improve reparenting
[19:33:56] <CIA-112> EMC: 03cradek 07master * rfeff1052669c 10/lib/python/gladevcp/makepins.py: gladevcp: Take list of widgets from builder
[19:33:57] <CIA-112> EMC: 03cradek 07master * rdee7f21fb0f8 10/src/Makefile: gladevcp: Install catalog and widget files
[19:33:58] <CIA-112> EMC: 03cradek 07master * rc7802b95528d 10/lib/python/gladevcp/READ_ME: gladevcp: Update readme with current state
[19:33:59] <CIA-112> EMC: 03cradek 07master * r9e0393d6020b 10/lib/python/gladevcp/ (4 files): gladevcp: Shorten import path
[19:34:00] <CIA-112> EMC: 03cradek 07master * r2f15954e116d 10/lib/python/gladevcp/led.py: gladevcp: Fix LED colors initalization
[19:34:01] <CIA-112> EMC: 03cradek 07master * r8e8c9e19a1ec 10/ (12 files in 5 dirs): Merge branch 'gladevcp-modules' of git://grid.pp.ru/psha/emc2
[19:34:05] <CIA-112> EMC: 03cradek 07master * rbdd70803bd17 10/lib/python/gladevcp/makepins.py: gladevcp: Drop read_widget from makepins
[19:37:34] <micges> wow
[19:45:28] <psha> i think i need to drop announce in dev list
[19:46:23] <psha> jepler: how are creating such pretty logs with diffstat as in
http://thread.gmane.org/gmane.linux.distributions.emc.devel/3591
[19:49:23] <jepler> psha: git request-pull
[19:50:02] <psha> thanks
[21:22:53] <andypugh> This sserial (8i20) setup is becoming a bit tortured.
[21:23:56] <andypugh> I am wondering if a userspace program that writes to the registers in raw mode might not be easier.
[21:26:17] <andypugh> Though I really would like to report out a few parameters at least, so do need to solve this.
[21:41:47] <pcw_home> Yes I think a pass-through mode using raw-read raw-write (or just routines that do the same thing) would be a good way for users to access setup params
[21:41:49] <pcw_home> maybe a "setup" pin to put it into the setup mode
[21:46:20] <andypugh> I currently have "sserial_setup" as a config modparam. The board then starts up in 802 mode, and doesn't put the "Do It" command into the TRAM.
[21:48:35] <andypugh> However, it does still put current and angle values in the register. I think I might have found part of the problem, setup_mode needs to just not register any TRAM.
[23:39:03] <skunkKandT> so.. in classic ladder - if you set the output of a coil in 2 different locations.. It seems you cannot depend on the contact with the same name to work consistantly
[23:50:27] <skunkKandT> ok - so you can't have 2 outputs named the same in 2 different areas...
[23:51:19] <skunkKandT> heh - I have to take ladder 101 I guess
[23:51:37] <andypugh> <meaningless comment to show someone with no knowledge of the matter is at least listening>
[23:56:31] <skunkKandT> heh