Back
[00:03:38] <theorb> theorb is now known as theorbtwo
[00:45:47] <juri_> hey, i'm building my own mill from scrap, i was wondering if i should put in switches to detect when each axis reaches its limit. make sense?
[00:46:11] <atmega> limit switches are good.
[00:46:12] <andypugh> Yes.
[00:46:31] <andypugh> You need a home switch anyway, life gets tedious without them.
[01:34:30] <skunkworks> would I have a ton of trouble getting sim running on mavric?
[01:34:44] <skunkworks> Maverick
[01:53:27] <emcrules> Skunkworks have a few min?
[01:54:20] <skunkworks> I am here at the moment - whats up?
[01:54:31] <skunkworks> what's up?
[01:54:53] <emcrules> Tryuing to figure out a issue i have with my servo setup
[01:55:37] <skunkworks> what is your hardware and such?
[01:55:55] <emcrules> Jogs fine and moves fine under manual and MDI no following errors and compares well with my accurite DRO
[01:56:22] <emcrules> 7143 with servos tourque control
[01:57:12] <emcrules> motor is geared to screw with 3:1 timing belt and pulleys
[01:57:43] <emcrules> problem is the motor may start to drift when standing still
[01:58:00] <emcrules> very slowly
[01:59:03] <emcrules> icing on the cake is that EMC's DRO or mesa hal pins do not indicate that it's happening
[01:59:04] <skunkworks> sounds like noise is getting into the encoder signals.
[01:59:57] <skunkworks> if noise gets into the encoder lines - the dro will stay the same - but the axis will slowly move.
[02:00:11] <emcrules> I know just cant figure out why it's not reading on the the AXIS DRO
[02:00:34] <emcrules> Is there a filter i can adjust to highlight the issue
[02:00:58] <skunkworks> are you using a servo interface card - like the 7i33?
[02:01:05] <emcrules> yes
[02:01:41] <skunkworks> what are your encoders? are they differential or single ended? how long are the cables/ what cables?
[02:01:51] <emcrules> Diff
[02:01:57] <skunkworks> really? yikes
[02:02:06] <skunkworks> what kinda cables are you using?
[02:02:22] <emcrules> Cables are sheilded from the drive to the 7133
[02:02:34] <skunkworks> twisted pair?
[02:02:47] <skunkworks> where are they grounded?
[02:03:37] <emcrules> grounded in the enclosure that holds the 7133. and yes twisted
[02:03:42] <skunkworks> hmm
[02:04:02] <skunkworks> do you have the 7i33 setup for diff?
[02:04:15] <emcrules> yes
[02:06:03] <emcrules> it's not bad now but if i grab onto the screw pully and twist it back and fourth the motor will start to drift in one direction
[02:06:24] <emcrules> allways in the same direction
[02:06:32] <skunkworks> odd
[02:07:01] <emcrules> .0005" at a time
[02:07:30] <emcrules> I can see the encoder counts change on the drive but not on the 7143
[02:08:20] <skunkworks> does the encoder signal go to the drive and the 7i33?
[02:09:07] <emcrules> yes encoder connects to drive and then the drive has output terminals that i connected to the 7133
[02:10:00] <skunkworks> what kind of drive?
[02:10:31] <emcrules> teco
[02:12:41] <skunkworks> sounds like drive config issue or a grounding issue between the drive and emc? maybe?
[02:16:05] <emcrules> Yeah i dont know what to think right now i have two drives to switch back and fourth from and they both behave the same way the only common thing is the wiring from the drive to the 7133
[02:17:43] <pcw_home> Does the drive encoder output exactly mimic the encoder or does it go through processing (for example: can you set different encoder output resolutions)
[02:21:06] <emcrules> yes i can scale the encoder if i wish but i have set it for what it is (in the drive)
[02:21:28] <pcw_home> A scope or even a LED+resistor across the A,'A and B,'B lines from the encoder and the same lines to the 7I33 should help trace where the counts are lost
[02:22:14] <emcrules> By scope you mean a real one and not HAL scope right?
[02:22:30] <pcw_home> I suspect the drive is not forwarding its encoder information correctly
[02:22:31] <pcw_home> (yes real)
[02:24:04] <emcrules> I just dont understand why im not loosing counts durring motion or when im e-stopped
[02:26:21] <pcw_home> Deadzone bug in their encoder output?
[02:28:22] <skunkworks> emcrules: can you setup the drive without encoder input?
[02:29:11] <emcrules> not sure will have to read the manual some more
[02:30:02] <pcw_home> Since its a slow creep, you could monitor the A.B encoder lines with HALScope (you need to find which GPIO bits they are on)
[02:30:03] <pcw_home> and see what they do (if you see no change in the DRO I expect they are doing nothing)
[02:31:15] <emcrules> The one thing i did notive in hal meter was that the encoder velo did change when this happend but the counts did not
[02:33:01] <pcw_home> Well if the velocity changes there must be some counts
[02:34:52] <emcrules> Thats what i was thinking at the time. I was wondering if ther was some deadband setting or filter that caused emc or the 7143 to ignore them
[02:35:39] <pcw_home> Theres a deadband for the PID but not the DRO
[02:36:26] <emcrules> I have it set currently to .000002
[02:37:29] <pcw_home> Probably have to look at what the drive is supplying as quadrature, HALscope should help here at least at slow speeds
[02:40:51] <cradek> I've seen an encoder lose counts in just one direction before. it was a grounding problem on the encoder wires
[02:41:26] <cradek> if you messed with the screw you could feel it jump - if you looked at the raw encoder counts, it would jump 4 counts at once
[02:42:00] <cradek> brb
[02:48:28] <emcrules> if i leave it alone it bounces between -43619 to -43620 and the if i twits the screw it will jump to -43624 and the back to -43620 or -43619 if i keep doing this i can turn my screw constanly in one direction while the DRO always reads the same
[02:50:19] <pcw_home> I've seen noise generate false counts as well but in this situation the drive sees real counts that the 7I33/7I43 doesn't
[02:50:20] <pcw_home> thats what leads me to believe that the drive is not forwarding the encoder info correctly
[02:51:18] <pcw_home> what bounces, the display on your drive?
[02:51:57] <emcrules> no 7i43 raw encoder counts in hal meter
[02:52:24] <emcrules> ithe drive count operate as expected
[02:56:54] <pcw_home> I guess I would verify that the RS-422 connections are correct (2 LEDS will work here)
[02:56:55] <pcw_home> and then check the quadrature with HALScope
[03:06:22] <emcrules> will do. God this is anoying!!!!
[03:40:49] <atmega> anyone made an MPG out of cheap rotary encoders? (like
http://www.seeedstudio.com/depot/rotary-encoder-with-switch-p-667.html?cPath=119_121 )
[04:04:44] <cradek> I think it's been done
[04:04:57] <cradek> these are usually very low cycles per rev (like 16)
[04:05:12] <cradek> they are mechanical so they can have a noisy signal and probably wear out relatively fast
[04:13:23] <atmega> yeah, I hooked one up to a uC and it was incredibly noisy
[04:15:02] <cradek> you can work around it with RC filters etc (and quadrature is somewhat forgiving)
[04:15:18] <cradek> but -- real optical jogwheels don't cost that much, and how many will you really need?
[04:15:34] <atmega> more like completely unusable than just noisy. I don't think I ever got it anywhere near reliable with software debouncing
[04:15:50] <cradek> cost of crappy encoder + cost of two pizzas = cost of real jog wheel
[04:15:54] <atmega> just 1 that I can think of, but I have some already
[04:16:01] <elmo401> cradek: my thoughts as well... the 'real' ones are not all that expensive. why bother with cheap stuff like that?
[04:16:06] <atmega> yeah, or jsut do the joypad
[04:16:29] <cradek> well - I've successfully used those for uC projects with no filtering
[04:16:50] <cradek> poll the inputs (don't generate interrupts for god's sake) and do correct quadrature decoding
[04:16:58] <cradek> it works fine
[04:17:52] <atmega> I'll try that... with interrupts, I could sometimes get 1 per detent, but sometimes -10 to 50
[04:18:22] <cradek> yeah don't do any edge sensing on those noisy edges
[04:19:40] <atmega> I tried stealing one of my son's xbox joypads, but they seem to only use the USB for charging
[07:50:32] <psha> mhaberler: here?
[07:50:44] <mhaberler> yes, tovarich
[07:50:58] <psha> while andy is not here and won't be angry about discussion on user channel :)
[07:51:22] <mhaberler> yeah, he can always bitch when reading the log ;-)
[07:51:25] <psha> as a workaround for 'on_pin_change' you may create togglebutton, set it not active and add handler to toggled singal
[07:51:46] <psha> i was thinking about adding GObject wrappers to HAL
[07:52:01] <psha> so it'll be possible to add signals to them
[07:52:11] <mhaberler> yess!
[07:53:59] <mhaberler> I see the workaround working; however, that implies any halpin of interest actually connects to a particular hal widget
[07:54:18] <mhaberler> now what the hell is a GObject ;-)
[07:55:35] <mhaberler> just joking; reading gobject doc..
[07:55:50] <psha> goobject is base of Gtk
[07:56:04] <psha> it's some type of pure-C classes
[07:56:13] <psha> pretty verbose but working
[07:56:26] <psha> every GLib based program more or less uses gobjects
[07:59:56] <mhaberler> psha: gobject docs.. holy cow, this isnt for the faint-hearted
[08:01:09] <psha> for hal gobjects we don't need even 1/1000 of glib power :)
[08:01:38] <mhaberler> I guess what I'm going to start with is an HalObserver class which gets me a callback on pin change with new and old value; that could be replaced with your mechanism once done
[08:02:10] <psha> hang for a while, i'll see if it's possible to add signals in pure python, not in bindings
[08:03:55] <psha> yes, it's possible
[08:04:52] <mhaberler> psha: I'd love to understand what you just said ;-)
[08:18:41] <psha> mhaberler: done
[08:18:50] <mhaberler> ?
[08:19:13] <psha> i'll push gladevcp-glib branch in a minute
[08:29:19] <psha> mhaberler: branch gladevcp-glib
[08:29:33] <psha> it's just scetch
[08:29:41] <mhaberler> looking..
[08:29:54] <psha> code is quite dirty now but i think as first stage it's ok
[08:32:52] <Bonny> Psha hello... Just one question. Why I can attach HAL_led on ubuntu 10.04 but doesn't work on hardy.
[08:33:10] <psha> some errors in console?
[08:33:31] <Bonny> I think yes. I just power up hardy to pass that to you.
[08:34:31] <Bonny> and DRO works on 10.04 but not on hardy :( too
[08:41:23] <Bonn1> psha
http://pastebin.com/GWKr1Trw
[08:42:40] <psha> that's bad...
[08:43:18] <Bonn1> http://pastebin.com/afHw8hXK
[08:43:24] <Bonn1> ... config file..
[08:43:44] <Bonn1> if I remove few lines of LED then works
[08:43:57] <psha> issue is same as in camview-emc a while ago -- old gtk.gdk.Color object has no *_float values...
[08:44:29] <Bonn1> cure?
[08:46:30] <psha> possible :)
[08:46:44] <Bonny> I hope :D
[08:47:28] <Bonny> the next (DRO) seems to be more problematic.
[08:56:15] <psha> Bonny: you have to set colors in glade
[09:07:54] <psha> Bonn1: first, set ON color for Led
[09:08:09] <psha> gtk from hard don't know how to translate color names to values
[09:11:03] <Bonn1> http://pastebin.com/Y6R5eUhV
[09:11:40] <Bonn1> http://pastebin.com/JybkM32U
[09:11:49] <Bonn1> error and config file.
[09:12:01] <psha> and pull fixes from this branch
[09:12:10] <psha> git://psha.org.ru/psha/emc2.git gladevcp-led-hardy
[09:13:11] <mhaberler> psha: fighting with git here...
[09:13:13] <mhaberler> I understand that gices me a value-changed handler on a widget
[09:13:15] <mhaberler> what I'm unclear: how do I monitor a pin which isnt connected to a widget? ok, invisible widget is a possibility
[09:14:04] <psha> mhaberler: if you wrap pin into GPin it will be updated automaticaly
[09:14:47] <psha> value-changed is not on the widget, it's on GPin
[09:15:05] <psha> which is small wrapper around Pin object
[09:15:20] <mhaberler> figuring...
[09:19:44] <psha> Bonn1: working?
[09:28:15] <Bonn1> yes
[09:28:30] <Bonn1> I had phone so thiss took little longer
[09:31:43] <psha> good, i'll merge it to main gladevcp branch
[09:32:28] <psha> maybe you'll check Bar widget too?
[09:36:16] <psha> hm, no, it won't :)
[09:36:25] <psha> too many backporting...
[09:40:50] <mhaberler> psha: any idea why stock .gitignore has 'lib' ignored :-/ ?
[09:41:39] <psha> yes, historicaly that was place like 'bin' where stuff was moved during compilation :)
[09:41:59] <psha> but cmorley choose lib/ as place to start gladevcp
[09:41:59] <Bonn1> http://imagebin.ca/view/pUM04out.html
[09:42:05] <Bonn1> 4 psha
[09:42:08] <mhaberler> guess that needs to go..
[09:42:17] <psha> mhaberler: maybe...
[09:42:43] <psha> Bonn1: nice :)
[09:42:49] <Bonn1> psha It works.. I just put some gadgets and check.
[09:43:16] <psha> it'll be in master on next merge
[09:43:31] <Bonn1> not to many backorting?
[09:43:39] <Bonn1> p
[09:43:42] <Bonn1> :D
[09:43:46] <psha> not progressbar :) but HAL Bar
[09:43:57] <Bonn1> ???
[09:44:24] <psha> http://www.linuxcnc.org/component/option,com_kunena/Itemid,20/func,view/catid,22/id,4656/limit,6/limitstart,12/lang,english/
[09:44:46] <Bonny> there are not other bar at all
[09:45:42] <Bonny> hmm seems that I need to update something on 10.04 too
[09:45:56] <psha> it won't work on hardy :(
[09:46:12] <psha> same issue as with Led but in larger scale
[09:46:24] <Bonny> Ok I don't need it at this time :)
[09:46:38] <Bonny> But what we can do with DRO?
[09:46:51] <Bonny> I very like to have it one.
[09:47:05] <Bonny> .. on hardy
[09:47:27] <psha> i'll take a look on one now...
[09:48:31] <psha> i have ~10-15 minutes for it so if i'll get what's wrong fast it'll be fixed :)
[09:49:28] <Bonn1> how I can help?
[09:50:18] <Bonn1> when I install camunits-plugins-emc on 10.04 the dro came up but not such package for hardy
[09:50:22] <psha> hm there is no camunits-plugins-emc at all :)
[09:50:34] <psha> i think i've forgot to build it :)
[09:51:10] <Bonny> how to reforgot that ? :D
[09:53:08] <psha> i'm asking build system to build it but with no success till
[09:53:43] <Bonn1> Can help?
[09:53:59] <psha> think no :)
[09:54:22] <psha> nobody can help me with my own build system :) since i'm only author of it :)
[09:54:26] <Bonn1> Then just to send you good wish to you have success.
[09:54:51] <psha> :)
[09:54:55] <Bonn1> hopefully that helps :D
[09:55:41] <psha> Bonn1: you have 2.3?
[09:55:50] <psha> or 2.4?
[09:56:05] <psha> on hardy?
[09:56:33] <Bonn1> 2.5.0~pre
[09:57:04] <psha> heh :) i don't believe that there is binary compatiblity between 2.3 and 2.5
[09:57:10] <psha> so it's better to compile it by hand
[09:57:42] <psha> instructions are simple
[09:57:51] <Bonn1> I need custom type of stepgen and I belive is it only on 2.5.0
[09:58:07] <psha> http://psha.org.ru/cgit/psha/emc-camunits
[09:58:11] <psha> you need this repo
[09:58:17] <psha> emc2
[09:58:42] <psha> full list of build deps are here
[09:58:52] <psha> http://psha.org.ru/cgit/psha/emc-camunits/tree/debian/control#n4
[09:59:01] <psha> 'Build-Depends' line
[09:59:20] <psha> libcamunits-gtk6-dev is not needed though
[09:59:46] <Bonn1> sorry psha but I don't know what to do with all that...
[10:00:19] <psha> apt-get install debhelper cdbs libcamunits6-dev libglib2.0-dev libglut3-dev
[10:00:38] <psha> theese libs are needed to compile halio plugin
[10:01:13] <psha> then run 'make' and place halio.so in /usr/lib/camunits
[10:01:16] <Bonn1> ok that's more understandble for me.. Just need to add SUDO
[10:01:21] <psha> yes
[10:01:37] <psha> i always strip it
[10:02:46] <Bonn1> hmm make doesn't work.. where to execute?
[10:03:10] <Bonn1> slavko@emc2:~$ make
[10:03:10] <Bonn1> make: *** No targets specified and no makefile found. Stop.
[10:03:11] <Bonn1> slavko@emc2:~$
[10:04:25] <Bonn1> http://pastebin.com/k0r3THQs
[10:05:01] <mhaberler> psha: I declare stupidity on value-changed.. how do I use it?
[10:10:12] <psha> pin = GPin(comp.new_pin('pin-name', ...))
[10:10:20] <psha> pin.connect('value-changed', handler)
[10:10:29] <mhaberler> ok...
[10:10:31] <psha> just like ordinar widget
[10:11:41] <psha> you have to do it when you are creating pins
[10:12:07] <mhaberler> before hal_ready I guess
[10:13:05] <mhaberler> halcomp.ready() I mean
[10:17:19] <psha> mhaberler: yes, before
[10:17:31] <psha> after it is not possible to create pins
[10:17:32] <mhaberler> ok, get it.. almost there..
[10:19:35] <psha> update thread will be fixed later
[10:25:14] <mhaberler> have it working thanks. I guess this will cover it.
[10:28:52] <mhaberler> so my idea would be to detect 'hal' function in foo.py and call it after widgets are setup (and their hal pins) and before halcomp.ready so user may add pin and handler. Makes sense?
[10:30:30] <psha> yes
[10:30:43] <psha> not hal i think but somethink with 'init' in it's name
[10:30:50] <psha> something
[10:31:19] <mhaberler> yep
[10:32:17] <mhaberler> need to pass at least halcomp to it
[10:33:28] <psha> sure
[10:33:38] <psha> halcom and builder/glade object
[10:33:48] <psha> no need in passing it's type
[10:33:48] <mhaberler> yep
[10:34:02] <psha> if you want you awlays may deside with isinstance(obj, gtk.Builder)
[10:34:10] <psha> decide
[10:34:35] <mhaberler> ok
[10:35:49] <psha> be back later
[10:36:06] <mhaberler> cu, busy anyway in packaging your stuff...
[10:37:16] <Bonn1> for all. How to correct add oneshot module?!?
[10:37:27] <Bonn1> loadrt oneshot names=forOn
[10:37:45] <Bonn1> addf forOn base-thread that not work
[11:27:57] <jthornton> does it give you an error?
[11:47:36] <mhaberler> psha: looks like it starts to become useful! - see my repo gladevcp-halpinhooks
[11:49:15] <psha[work]> mhaberler: spinbutton.connect('value-changed', spinbutton_changed)
[11:49:22] <psha[work]> this connects you to spinbutton signal
[11:49:24] <psha[work]> not gpin
[11:49:39] <mhaberler> aja.
[11:49:52] <psha[work]> mhaberler: 50 comp['hal_led2'] = not comp['hal_led2']
[11:50:19] <psha[work]> this will stop working when checks for in/out pins will be enabled in hal module :)
[11:50:39] <psha[work]> hal_led2 is 'input' pin, you are not pertmitted to change its value
[11:50:58] <psha[work]> but now theese checks are skipped :)
[11:51:01] <mhaberler> uh..
[11:51:02] <mhaberler> trying to build toolchanger gldaevcp panel now, see if that works
[11:51:46] <psha[work]> 'true' way is to connect this pin to some out pin
[11:51:56] <psha[work]> but for testing purposes it's ok :)
[11:52:07] <mhaberler> yep.. just trying my way around parameter land
[11:53:29] <psha[work]> also think besides value-changed some additional signals will be useful
[11:53:48] <psha[work]> i think that value-up/value-down will be nice
[11:57:24] <Bonn1> psha I didn't have succes with DRO. so here is my attempt. (not finished / good)
http://imagebin.ca/view/FcJx3hsE.html
[11:58:15] <Bonn1> and hal file
http://pastebin.com/5f1kCabH
[12:00:14] <Bonn1> Seems that I grab wrong pin as I got wrong coordinate reading. If G43 ia active then that difference should be substitudet from value in DRO tab. What pin DRO grab?!? ... And sadly label can handle just s32 so I got not fractions.
[12:00:35] <Bonn1> any idea for inprowment?
[12:03:07] <psha[work]> label may handle s32/float/u32
[12:03:22] <psha[work]> change 'pin type' property in glade
[12:03:48] <mhaberler> I saw that, will experiment
[12:04:16] <psha[work]> there is tooltip explaining what 1/2/3 means
[12:04:23] <psha[work]> i've left that untouched
[12:04:51] <psha[work]> for absolute/relative axis position - inspect halui.axis* pins
[12:04:54] <psha[work]> there is something useful
[12:05:33] <psha[work]> halui.axis.0.pos-relative
[12:05:36] <psha[work]> check this
[12:06:22] <mhaberler> will do. This looks very promising!
[12:06:22] <psha[work]> btw what was wrong with halio.so?
[12:06:53] <Bonn1> I use halui.axis.0.pos-relative
[12:07:44] <psha[work]> i see nw
[12:07:45] <psha[work]> now
[12:07:53] <psha[work]> and it don't respect G5*?
[12:08:09] <Bonny> no.
[12:08:36] <Bonny> wel no with G43!
[12:08:44] <Bonny> G43 not G5*
[12:08:44] <psha[work]> *(halui_data->axis_pos_relative[0]) = emcStatus->motion.traj.actualPosition.tran.x - emcStatus->task.g5x_offset.tran.x - emcStatus->task.g92_offset.tran.x;
[12:08:55] <psha[work]> i don't know what is G43 :)
[12:09:02] <Bonny> tool offset
[12:09:37] <psha[work]> with this question you'd better go to somebody more confident :)
[12:10:11] <psha[work]> btw what is on the screenshot? 'flower' like?
[12:10:35] <Bonny> But probably you can help me when now I goot to many decimals... Probably text template (%s) should be changet
[12:10:58] <psha[work]> yes
[12:11:02] <psha[work]> %.3f
[12:11:15] <psha[work]> will limit it to 3 frac digits after
[12:11:18] <Bonny> On picture is just cuttout of gear as I need to make new gear for my laminator.
[12:11:27] <psha[work]> %.03f will show zeres for missing digits
[12:11:34] <Bonny> Can I insert X= in front of that?
[12:11:37] <psha[work]> yes
[12:11:42] <psha[work]> its arbitrary string
[12:11:53] <Bonny> Wil test..
[12:12:27] <psha[work]> only requirment that python expression 'template_string % value' have to be correct
[12:12:56] <psha[work]> you may run 'ipython' and try to give it different strings
[12:19:22] <mhaberler> curious - why would I use a HAL Table over a GtkTable? just to be able to activated/deactivate all widgets in it?
[12:20:55] <psha[work]> yes
[12:21:22] <mhaberler> aha, that explains why so much of my attempts were greyed out ;-)
[12:24:00] <psha[work]> you are not first who was wondering about this :)
[12:24:08] <Bonn1> My reading seems to be out for halui.axis.0.pos-relative value..
[12:24:47] <Bonn1> can be that added directly within hal or I need to add ADD component?
[12:26:42] <psha[work]> i think add comp is needed
[12:30:16] <psha[work]> * psha[work] looks at own nick
[12:30:26] <psha[work]> it seem that i'm at work!
[12:41:50] <SteveStallings> SteveStallings is now known as steves_logging
[13:00:50] <Bonny> psha available?
[13:03:51] <psha[work]> partial :)
[13:04:27] <Bonny> only to inform that on hardy the croshair works only in XOR mode.
[13:04:51] <Bonny> ... color pickup and rdawing with that color doesn't work.
[13:05:05] <psha[work]> heh, again _float values :)
[13:05:23] <psha[work]> i'll fix it in the evening
[13:05:31] <Bonny> the poorMan DRO works now with correct offsets.
[13:06:54] <psha[work]> cool
[13:07:09] <psha[work]> btw what was problems with halio.so?
[13:07:14] <psha[work]> it refuses to build?
[13:07:15] <Bonny> and here (crosshair) I have idea to have different aperture (ie circle, square, track with angle)
[13:07:49] <Bonny> I downloaded what you say but then can't do make as I get error
[13:08:08] <Bonny> I probably use wrong commandline :(
[13:08:13] <psha[work]> make
[13:08:13] <psha[work]> :)
[13:08:17] <psha[work]> that's all you need
[13:08:20] <Bonny> in what dir?!
[13:08:33] <psha[work]> in cloned emc-camunits repository
[13:13:40] <Bonn1> psha I executed apt-get install debhelper cdbs libcamunits6-dev libglib2.0-dev libglut3-dev
[13:13:50] <Bonn1> and where now to do make?@?
[13:15:13] <psha[work]> git clone git://psha.org.ru/psha/emc-camunits
[13:17:57] <Bonn1> http://pastebin.com/5ijF5ZYp
[13:20:39] <psha[work]> -Ipath-to-emc-headers to CFLAGS
[13:20:53] <psha[work]> -Lpath-to-emc-libs to LDFLAGS
[13:21:11] <psha[work]> you are compiling against RIP environment
[13:21:16] <Bonn1> ? is that commandline ?!?
[13:21:17] <psha[work]> so need theese paths
[13:22:22] <psha[work]> just edit Makefile
[13:22:40] <psha[work]> on line 4 add another -I flag with path to emc headers
[13:23:02] <psha[work]> on line 14 add -L flags with path to libs
[13:23:37] <psha[work]> something -I$(EMC2_HOME)/include on line 4
[13:24:22] <Bonn1> I feel so stupid... Where that libraries are? (what paths?)
[13:24:26] <psha[work]> and -L$(EMC2_HOME)/lib on 14
[13:28:29] <Bonny> to dumb! Aborting....
[13:30:29] <psha[work]> heh, wait a bit, i'll add that to makefile
[13:32:31] <psha[work]> git pull
[13:33:50] <Bonn1> http://pastebin.com/8uiaZs5z
[13:35:39] <psha[work]> you have not sourced emc-environment
[13:37:05] <Bonn1> http://pastebin.com/UN3yBAp2
[13:38:46] <psha[work]> what's gcc version?
[13:39:08] <Bonn1> how to ask?
[13:39:22] <psha[work]> not needed
[13:39:34] <psha[work]> try replacing ULAPI with RTAPI in makefile
[13:40:59] <Bonn1> seems pretty same
[13:41:12] <psha[work]> i'll check this in the evening
[13:41:19] <psha[work]> i have no emc2 sources here
[13:41:53] <Bonn1> http://pastebin.com/ktXURmwg
[13:41:56] <Bonn1> ok...
[13:42:03] <Bonn1> do the job. LD
[13:42:06] <Bonn1> :D
[13:42:16] <Bonn1> I had some work too.
[13:42:21] <Bonn1> see ya
[13:45:02] <psha[work]> :)
[13:47:11] <pcw_home> emcrules: Is it possible that you have set HostMot2s quadrature counter into up/down mode? that would cause this kind of behavior
[14:50:17] <mhaberler> psha: toolchanger Axis tab in repo. Not using all capabilities yet, unelegant but working
[14:53:16] <psha[work]> mhaberler: i'll take a look when return home
[14:53:58] <mhaberler> sure. by then I gess I will have the restarting TC which permits jogging during tc - needs to talk to emc
[16:17:37] <ries_> ries_ is now known as ries
[17:11:26] <Bonny> psha
http://tinyurl.com/36o69ap
[17:11:45] <Bonny> ... it's related to you :-)
[17:14:14] <psha> Bonny: forum?
[17:14:24] <psha> i'm getting email notifications :)
[17:14:25] <Bonny> yes latest 3 posts
[17:14:30] <psha> looks cool
[17:14:50] <Bonny> I realy want that slider somewhere outside.
[17:15:10] <Bonny> for selecting aperture is okay to be burried.
[17:15:50] <Bonny> Just compare image sizes on forum when slider are oppened and when not.
[17:16:21] <Bonny> It's self explainable why I want slider outside :D
[17:21:33] <psha> that's tru
[17:21:36] <psha> eating too much space
[17:22:02] <psha> maybe it's better to raise window with extra controls, not in tabs?
[17:22:07] <Bonny> But I think can't be done with HAL sliders...
[17:22:19] <psha> no
[17:22:22] <psha> i've tried ;)
[17:22:35] <psha> it's too complicated to correctly connect pins
[17:23:03] <psha> problem is same as in gladevcp
[17:23:22] <Bonny> Maybe vertical sliders (left or right of image)
[17:23:38] <Bonny> In most cases there ase some free space left.
[17:24:43] <Bonny> But two slider's in space where (current) my DRO is the best I think. Maybe only lost one text line.
[17:29:45] <psha> maybe i'll look again into pins 2 controls...
[17:31:34] <Bonny> I have something like
http://imagebin.org/125327 in mind
[17:39:26] <Bonny> psha I must go now.
[17:40:30] <psha> ии
[17:40:31] <psha> bb
[17:40:38] <psha> hi andy
[17:50:12] <andypugh> Hi psha
[17:50:37] <andypugh> Is it wierd coding in the wrong alphabet?
[17:50:53] <psha> yea, missed that russian layout was selected
[17:51:15] <andypugh> It must be like using APL would be for me.
[17:51:27] <archivist_emc> or perl :)
[17:51:46] <andypugh> Perl at least uses latin characters
[17:52:50] <mhaberler> all greek for me!
[17:53:50] <psha> andypugh: if perl program is using latin chars then it's either by mistake or this prog was not written by perl programmer
[17:54:31] <andypugh> I might be confusing perl with python.
[17:58:39] <andypugh> The perl examples I can see on Wikipedia seem to be written in the latin alphabet. What am I missing?
[18:01:30] <andypugh> Whereas this is the Game of Life written in APL:
http://upload.wikimedia.org/wikipedia/en/f/ff/LifeInApl.gif
[18:53:36] <psha> andypugh: for me perl is using too many non-alphanumeric chars. it's not rare when line consists only of $_*~=... chars
[20:17:53] <alex_joni> any UK'ers around?
[20:18:12] <alex_joni> http://www.reghardware.com/2010/11/29/compo_ipad_cases_nov_2010/
[20:19:40] <archivist_attic> Im an apple free zone :)
[20:37:17] <andypugh> I'm in theUK and a dedicated Apple Fanboi :-)
[21:33:21] <jepler-> jepler- is now known as jepler
[21:51:32] <andypugh> There is a very interesting question on the forum. A chap is finding that his parallel port gives a lower voltage with Linux/EMC than with Win2k and Mach3. To the extent that his charge-pump circuit won't energise.
[21:52:07] <andypugh> He is quite clear that it is all the same hardware throughout, only the software is different, and he doesn't sound like an idiot. Any ideas?
[21:58:10] <cradek> my first idea is that even non-idiots are mistaken sometimes
[21:58:22] <cradek> it seems pretty hard to believe
[21:59:19] <cradek> I'm no parport expert, but I don't think software can affect whether pullups are enabled, etc.
[22:01:06] <archivist> different charge pump rate
[22:01:32] <cradek> yes the rate could of course be different
[22:01:37] <andypugh> He's measuring voltages, trying pull-ups, seems to have a scope and is checking waveforms (and the frequencies are the same on the scope)
[22:01:39] <SWPadnos> different port setup - EPP may have different drive strength than SPP
[22:02:05] <SWPadnos> and a different output type as well, since EPP is bidirectional (on the data lines)
[22:02:09] <archivist> andypugh, mark space different too it rate same
[22:02:40] <andypugh> His quote is "with Windows2000 and Mach3 the Charge Pump on pin 14 is a rather gittery but functional 0.3 to 5V wave form at about 10kHz BUT with the same PC and same BIOS settings and interface hardware the parallel port wave form is a perfect 10kh (no noticeable jitter at all) but 0.5V to 3.6V and so the charge pump circuit does not quite run.
[22:02:40] <andypugh> "
[22:03:30] <archivist> what swp said about drive strength and mode
[22:03:33] <andypugh> So, he is impressed by the EMC2 signal quality and step smoothness, but having to frig his charge-pump
[22:04:18] <andypugh> Glad to hear my suggestion of trying different modes in the BIOS wasn't entirely daft.
[22:04:47] <SWPadnos> Linux or EMC may set the port to EPP mode (regardless of the BIOS settings)
[22:05:17] <andypugh> Can the driver over-rule the BIOS?
[22:05:17] <celeron55> basically anything might set it to anything
[22:05:32] <celeron55> in addition, bioses can be buggy
[22:05:36] <celeron55> etc
[22:05:43] <JT-Hardinge> is there a way in Linux to tell what the port is set to?
[22:09:26] <SWPadnos> I'm thinking that emc sets EPP mode whenever possible, at least after the D510MO issues recently discussed
[22:10:31] <JT-Hardinge> are those issues with the D510MO resolved?
[22:11:01] <SWPadnos> I believe so, by always turning on EPP, regardless of whether Linux/BIOS report the port as capable of it :)
[22:11:12] <JT-Hardinge> I'm building a backup for the Discovery with one... and dang they are small
[22:11:29] <SWPadnos> yeah, mini-ITX is a nice little platform
[22:13:37] <JT-Hardinge> I got a case just for it and it holds the motherboard, a 5 1/4 drive and a 3 1/2 drive and not much else...
[22:14:43] <andypugh> Floppy drives?
[22:17:35] <JT-Hardinge> dvd and harddrive
[22:17:50] <JT-Hardinge> 3 1/2 internal drive
[22:21:02] <JT-Hardinge> from wikipedia about different parallel port modes "All modes use TTL voltage logic levels,"
[22:21:54] <andypugh> They are all meant to, but feeble voltages are quite common. It is almost like manufacturers don't take the p-port seriously any more.
[22:22:43] <andypugh> Sorry, that sounded pompous. "From what I have been reading on the internet recently, it appears that feeble voltages are quite common"
[23:14:49] <frallzor> lo kids
[23:16:45] <andypugh> Hi
[23:16:45] <the_wench> hello andypugh, you have a question?
[23:17:12] <andypugh> Yes, why do you pose as a woman when one has never yet been sighted on this forum?
[23:19:40] <frallzor> a giiiiirl here?!
[23:20:49] <andypugh> Well, there was that Isreali a year or so ago, making a servo with a felt-tip en and card for the encoder. (and it worked)
[23:39:05] <emcrules> JT thanks for the help yesterday I found my problem and fixed it
[23:55:37] <JT-Hardinge> cool
