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