psha: you're probably right
so i'll move it and push everything to gladevcp-modules branch
hey, I think it worked
downside is that gladevcp will be placed in two different places in source....
a lot of stuff is like that...
I confirm that GLADE_CATALOG_PATH works
check gladevcp-modules branch
i've moved them and updated emc-environment.in file
i'm updating READ_ME file too
gitk FETCH_HEAD master
i've updated readme to reflect current state
instead of the link warning in the readme, can we (you :-) just fix the package and make install rules?
seems like it wouldn't need any special warnings then
working on it :)
fwiw, rip works for me, with your latest changes
psha: why do we need special hal hbox and table?
don't know... i've not digged that far
hm, is there no widget for a plain numeric readout?
cradek: they may be enabled/disabled via hal pins
<number halpin="spindle-actual" font="('Courier',12)" format=" 4.0f"/>
like gtk.Entry but only for digits?
not entry - readout only
HAL_Label may be easily fixed this way
oh it has "label pin type" - maybe it already does this?
self[obj].set_text("%s"% str ( self.hal[obj] ) )
only simple '%s'
but if it's enought - then it is
I don't understand what that would do - there is no hal string type
everything may be converted to string in python :)
it's either u32 or float
but way how it's defined is not great...
i'm fixing it...
[17:18:24] <cradek> http://timeguy.com/cradek-files/emc/lathepanel.png
this is a replacement for the axis pyvcp panel currently on my lathe
... after I plug in your new label widget in those two holes
horrors.... , is pyvcp dying a slow death now ?
cradek: check last commit
awallin: for me gladevcp is far better options since i'm only confident with gtk when some guis are needed
is touchy in gtk?
ok, so touchy+gladevcp and axis+pyvcp
gtk + gtk, tk + tk
other mixtures looks horrible
cradek: i think i have to revert f7c7fddbde2c2315da96515b4b3aa904fef32f6b and leave xml and png files in lib/python/gladevcp...
files in share are hard to find and there is no serious 'pros' of this move
in run-in-place mode there is no difference what dir to set in GLADE_CATALOG_PATH
in installed - no difference from whare install files to /usr/share/glade3
cradek: i've reverted it and updated makefile so it installs in correct place
i've also updated hal_label
it seem that it's time for some documentatation :)
psha, maybe find some time to fix rtai+emc install in debian too ;)
it was very hard for me to force myself to use ubuntu instead of debain :)
i hope i'll have small amount of time theese evenings (sat/sun) so i may give it a try...
on sun is birtday of my daughter so i won't have enought time :)
i don't force myself at all, i'll stay on debian :)
i'm a bit tired of packaging so i was hoping that at least here i'll use stock debs :)
but - why not?
it seem that there are some debian users here
so if we'll roll good quality packages they will be usefull
i looked on ubuntu-cnc at 'rtai-config*' file and guess what ? it isn't provided by any package ..
if you promise to punch me regulary i'll setup repo/buildsys for testing
* qq- punch pasha
and now i'm going to sleep :-P
but tomorrow i'll setup repo at least...
after my raid will sync
* qq- sing easy sleep to psha
The 8i20 has a whole lot of settings stored in nvram. There is a Windows application to change them. PCW seemed not too fond of the idea of exposing them in the main driver for fear of wearing out the nvram. The idea was to create a secondary driver that exports all the parameters where they could be tweaked inside halrun or a comp or maybe something similar to stepconf.
However, as parameters are only really written inside the HAL file at startup, and it is easy to only write values that have changed, I am wondering if this makes any sense?
I am considering simply creating parameters for all of them, though that will end up being an awful lot of pins.
could you do something fancy that if you pass a flag with the loadrt line - it activates the parameters - otherwise it doesn;t? (talking out of my a$$)
Yes, that would be doable.
And is probably the easiest way, on reflection.
Then you could start the driver from halrun.
wow - that doesn't happen very often,
can it be a regular userland program?
I don't know
I assume so, but you would need to duplicate so much of the hostmot2 driver to get the interface to the FPGA registers that I am not sure it would make sense
wonder how much of the windows app could be reused
maybe just strip anything gui and parse the command line instead
probably would have to replace a few getperm type things
I _think_ that it communicates with the individual serial modules via the serial port, not through the FPGA card. I might be wrong.
now just wait for pcw to pop in and set you straight :)
Reading the manual, it does work through the serial port, and is in fact not windows but command-line
oh hey, that is probably pretty darn easy to port then, unless it's written in microsoft word macros or some other crazy windowsy thing
Indeed, but then you have to dismantle the equipment, move a jumper and plug into the serial port.
how often do you want to do this reprogramming? what does it do?
On the plus side, I could stop writing the driver now if that was acceptable.
Sets parameters like max current, PID gains, brake voltage thresholds etc
It will be something you do during initial machine setup, then never touch.
hm, gladevcp doesn't go into touchy for me, it pops up a separate window instead, with everything disabled in it
oh, x protocol errors (bad window)
fwiw, my output: http://pastebin.ca/1970361
Is it likely that this chap haas achieved what he thinks he has achieved?
[23:33:20] <andypugh> http://www.linuxcnc.org/component/option,com_kunena/Itemid,20/func,view/catid,24/id,4800/lang,english/#4804
emc configs/sim/touchy.ini < or so, wouldn't it worked too ?