Back
[00:11:10] <tomp> a linear encoder parallel to the stage has to have a better built machine than a rotary encoder on the screw... in this sense, it has more sources of mechanical error between it and the stage. Either can be effective, neither knows where the tool tip is by firsthand knowledge
[00:14:21] <fenn> why do you say that?
[00:15:48] <tomp> its a stack up of the number of sources. the linear has more elements in its chain
[00:15:58] <anonimasu> hm..
[00:16:32] <anonimasu> tomp: linear encoders makes a damn big diff when you need close tolerances..
[00:17:12] <anonimasu> :)
[00:17:20] <anonimasu> though it depends on screws and stuff also..
[00:17:24] <tomp> the linear has to contend with 'crabbing', and the machine that uses it must be capable of the close tolerance (that was the point)
[00:17:34] <anonimasu> crabbing?
[00:18:23] <tomp> the table might lean a bit on reversal,, rotate a tiny bit around Z on a std 3axis cartesian
[00:18:50] <anonimasu> tomp: that's like assuming every machine out there is crap..
[00:19:07] <anonimasu> it's a gross assumption..
[00:19:21] <tomp> no its assuming all machines have some limitation
[00:19:32] <tomp> and some advantage
[00:20:06] <tomp> imo
[00:24:11] <anonimasu> im very random..
[00:24:31] <anonimasu> night
[00:24:35] <tomp> nite
[00:25:02] <fenn> tomp: easy, just need six encoders then :D
[00:25:23] <fenn> while you're at it, make it a hexapod :DD
[00:26:10] <tomp> yeh i wonder about how the puma's work (6dof robots) no wonnder high precision robot can hit a 4 thou cube at 1 meter ( thats as good as it gets )
[00:27:03] <tomp> what i'd like to see is measuring where the tool is , not where the holders & frames are
[00:40:05] <fenn> well how you gonna do that?
[00:40:15] <fenn> i mean, the tool's a chunk of metal right?
[00:40:23] <fenn> anything else has to be attached to it somehow
[00:54:47] <robin_sz> tomp, you need to play with a 6 axis bot to understand them .. emc isn;t really ever going to match a proper robot controller
[00:55:19] <fenn> what language are robots usually programmed in?
[00:55:38] <robin_sz> depends ... often manufacturer specific
[00:55:45] <robin_sz> ARLA, RPAID, PDL2
[00:55:51] <robin_sz> RAPID sorry
[00:56:07] <robin_sz> let me give you an example of typical motion on a 6 axis bot
[00:56:26] <robin_sz> they usually have a 3 basic movement modes
[00:56:37] <robin_sz> well, coordinate systems ...
[00:56:42] <robin_sz> the first is joint
[00:56:56] <robin_sz> each joint is moved independently
[00:57:18] <robin_sz> XYZABC ... ok?
[00:57:50] <robin_sz> the second is 'base'
[00:58:18] <robin_sz> imagine a 3 axis grid XYZ, with 0,0,0 under the base of the robot
[00:58:24] <erDiZz> for "the table might lean a bit on reversal" there might be a correction value, a number of additional step for the steppers to make when an opposite movement starts
[00:58:43] <erDiZz> does emc have such an option
[00:58:43] <erDiZz> ?
[00:58:53] <tomp> robin_sz: following
[00:59:18] <tomp> erDiZz: dont know of one, backlash is a bit like that
[00:59:21] <robin_sz> X+ moves the TCP (tool centre point) along X .. often moving all 6 axes to do that
[00:59:34] <fenn> there isnt much in the way of multi-axis compensation, but it could be easily added with hal or custom kinematics
[00:59:59] <robin_sz> Z+ moves it vertically up ... again all 6 axes together
[01:00:32] <robin_sz> A,B and C rotate the tool about hte X,Y and Z axes OK?
[01:00:51] <tomp> k 'base' sounds like 'tooltip', joint is low level
[01:00:58] <robin_sz> right
[01:01:04] <robin_sz> no, ...
[01:01:08] <robin_sz> not quite
[01:01:17] <fenn> base is where the end-effector plugs into right?
[01:01:22] <robin_sz> no
[01:01:26] <erDiZz> tomp, yes, according to the wiki, 'backlash' seems to be what I meant
[01:01:28] <robin_sz> base is the robot floor plate
[01:01:39] <fenn> ok that was my first guess :_
[01:01:52] <fenn> * fenn wipes his drool off
[01:01:53] <robin_sz> just like a big CNC mill
[01:02:09] <robin_sz> and finally there is "tool" ...
[01:02:32] <robin_sz> imagine the same grid but centred onthe tool mount (lke what fenn said)
[01:02:50] <robin_sz> so Z+ allways does a tool plung motion
[01:03:01] <robin_sz> wherever it might be ...
[01:03:03] <fenn> so you can program movements for base? or its just a coordinate offset?
[01:03:18] <fenn> like what if you have two robots mounted on a gantry
[01:03:21] <robin_sz> you can arbitarily swap between any coordinate system at any time
[01:03:31] <tomp> erDiZz: backlash is 'like' it not exactly intended for this purpose, only for single plane
[01:04:14] <erDiZz> tomp, do you mean that "backlash" cannot be specified for each axis separately?
[01:04:31] <tomp> robin_sz: i like the idea the Z is the tool axis always, on Heidenhains with planar tilt, i told operators that it was like skateboarding... down is where your feet are :)
[01:04:47] <robin_sz> so basically, you have two "high level" modes there and a low level joints mode
[01:04:49] <robin_sz> tomp, yeah
[01:04:58] <robin_sz> tomp, they all have their uses
[01:05:43] <robin_sz> so, the more advanced bots support the two high level modes in cartesian, cylinrical and polar coardinates too
[01:06:08] <robin_sz> and there is almost always a "user" cooardinate system too, definaeabel as you like
[01:06:39] <tomp> erDiZz: i dont have deep understanding of emc's implementation, but i think it does not have the ability to correct for y in terms of x (yet ), only x in terms of x
[01:07:05] <erDiZz> I see
[01:07:34] <tomp> robin_sz: can emc grow into that capability ( anything stopping it in its basic thinking )?
[01:08:21] <erDiZz> tomp, and how to describe correction for "y in terms of x"? By an arbitrary formula provided by an operator?
[01:08:59] <fenn> yup
[01:09:12] <tomp> erDiZz: i would use a look up table of data returned by a good inspection ( laser interferometer & retroreflector )
[01:09:35] <erDiZz> ah
[01:09:39] <fenn> you would need to store data for previous state so you know if you're changing direction (i think)
[01:09:41] <tomp> erDiZz: because it may not be expressed well by a function
[01:09:55] <fenn> look at how backlash comp does it i guess
[01:13:00] <tomp> fenn: maybe you could measure a table per direction, and use the appropriate one ( you'd switch back and forth when executing a circle ) oh yeah, thats why ballbar tests are good, one of the basic emc ngc files
[01:13:56] <tomp> wow emc doesnt even give those out anymore, when did that happen?
[01:14:54] <erDiZz> tomp, "x by x" and "x by y" seem not to interfere ideologically: one can do "x by x" first, and then "x by y"
[01:15:05] <tomp> (its becuz "will all the people who use ballbars please stand up" :)
[01:16:16] <erDiZz> and if it is done sequentially in this manner, then it is at least evident how to interpret a single x-y look up table
[01:16:16] <tomp> erDiZz, yes i dont think they are exclusive
[01:16:44] <tomp> //interfere
[01:18:32] <robin_sz> tomp, well, gcode is out for a start I think :)
[01:19:30] <robin_sz> robot languages are more flexible ... PDL2 for example is very PASCAL like
[01:19:45] <robin_sz> loops, conditionals, variables, arrays ...
[01:20:04] <robin_sz> so, thats the interpreter jukned then :)
[01:20:10] <tomp> argh! := pascal choke
[01:20:25] <robin_sz> the rest is basically the kinematics
[01:20:40] <erDiZz> robin_sz, doesn't one need feedback to for correction
[01:20:39] <erDiZz> ?
[01:20:52] <robin_sz> erDiZz, hwo do you mean?
[01:21:16] <erDiZz> that "x by x" thing is done using feedback from an encoder, as I understand
[01:21:20] <robin_sz> there is obviously motion feedback, encoders on each axis motor
[01:21:35] <erDiZz> robin_sz, yes, and how do you get that feedback to the interpreter? :)
[01:21:37] <robin_sz> so 6 channels of that to give JOINT position
[01:22:55] <robin_sz> the software trasnlates those joint positions to XYZABC
[01:23:16] <robin_sz> because it knows the length of each arm and the pivot points etc
[01:23:31] <robin_sz> offsets and the like
[01:23:32] <erDiZz> that's all fine, but the correction has to be done at the lowest level, in real-time mode
[01:23:44] <robin_sz> I wish I understood you
[01:23:53] <erDiZz> ah well
[01:23:59] <robin_sz> correction? for what?
[01:24:03] <tomp> interpreter doesnt get feedback? control gets feedback
[01:24:11] <robin_sz> exactly
[01:24:14] <erDiZz> yes
[01:24:38] <tomp> whatyouwant - whatyougot = error
[01:24:44] <robin_sz> the intepreter does not get feedback or do correction of anyting
[01:25:03] <robin_sz> thats all doen in the servo loops, fed by the trajectory planner
[01:25:29] <erDiZz> robin_sz, what you say means that gcode is _not_ involved
[01:25:34] <robin_sz> correct
[01:25:37] <erDiZz> that's what I was just saying
[01:26:23] <robin_sz> you *could* controla 6 axis bot with gcode ... but it would be limited and clumsy
[01:26:36] <erDiZz> agree
[01:26:50] <robin_sz> but in terms of feedback its exactly the same as a mill or router
[01:27:06] <robin_sz> the inerpreter is not involved in the feedback loop
[01:28:02] <robin_sz> the key to it is the forward and reverse kinematics
[01:28:16] <robin_sz> and for bots that usually means a lot of matrix algebra
[01:28:44] <tomp> i see from the commit messages that some puma and a scara simulator is being worked on
[01:28:46] <erDiZz> if only the interpreter was involved, it would be a loooong loop, but it would be a damn flexible one...
[01:29:03] <robin_sz> ?
[01:29:11] <robin_sz> mmm .. no
[01:29:14] <erDiZz> robin_sz, you could program anything then
[01:29:26] <robin_sz> you seem confused, sorry.
[01:29:34] <erDiZz> np
[01:29:51] <robin_sz> the feedback is not anything you need to worry about or kow about when programming anyting
[01:29:56] <robin_sz> moves wise.
[01:30:54] <robin_sz> being able to "get into" the feedback loop from your gcode (or other) progrma woudl not give any real benefit
[01:30:53] <tomp> i wanted to use pumas for sink edm , esp for turbine parts that usually required a 4 to 6 axis workholder ( 6dof vice ), but they were repeatable enough for crude cuts wher the tool was simply replaced. it wouldnt 'fit'
[01:31:19] <jepler> tomp: the scara simulator can run g-code nicely already.
http://axis.unpy.net/files/01170693566/scara.png
[01:31:35] <tomp> wow (drool)
[01:32:06] <erDiZz> robin_sz, I see. messed up a bit, I've only imagined some rich programmable control logics
[01:32:06] <tomp> oops, the crayon got bent :)
[01:32:24] <erDiZz> ...that's not related to gcode of course
[01:32:45] <tomp> jepler: why does the tool look skewed
[01:32:50] <robin_sz> erDiZz, remember, the feedback is a PID loop to make the physical motor follow the planned trajectory ...
[01:32:55] <jepler> tomp: the tool is actually another joint
[01:33:16] <jepler> tomp: I think it can be rotated around the Z axis
[01:34:23] <tomp> k i thought scaras were only planar (chip die placement... ), thats more usefull... we got a use for polar gcodes now :)
[01:35:07] <jepler> unfortunately I think there's a bug in the inverse kinematics for that joint :(
[01:35:16] <jepler> but XYZ works nice
[01:35:39] <tomp> temporary bug ;)
[01:35:45] <robin_sz> I can only begin to wonder about the forward/reverse kinematics on a 6 axis industrial bot
[01:36:10] <robin_sz> in "joint" mode, yeah easy ... in tool mode?
[01:36:25] <robin_sz> and being able to flip between them?
[01:36:28] <robin_sz> * robin_sz shudders
[01:36:44] <tomp> i used to imagine teaching a 6DOF was a matter of pulling and pushing it like a mule :)
[01:36:51] <robin_sz> heh
[01:36:56] <jepler> tomp: at the same time?
[01:36:58] <tomp> the recording where the joints were
[01:37:13] <robin_sz> nah, all done from a teach pendant
[01:37:43] <robin_sz> 12 buttons for +- on each axis,
[01:37:54] <robin_sz> swap modes joint, base, tool, user
[01:37:55] <tomp> jepler: it was an imagination where i had only read about it, one of those illusions where i try to understand how something might work
[01:38:30] <robin_sz> imagine you are in tool mode ...
[01:38:54] <robin_sz> the X arrow onthe front of the tool faceplate is pointing up, left at 45 degrees when you stand in front of it
[01:38:55] <tomp> skateboard
[01:39:31] <robin_sz> you press "X+" and it moves up and left, staying on the tool-face plane
[01:39:35] <robin_sz> OK?
[01:39:53] <robin_sz> now rotat the tool Z axis, X points up and right ...
[01:40:04] <robin_sz> pressing X+ moves the tool up and right ...
[01:40:16] <robin_sz> the whole coordinate system rotated on the tool face plate
[01:42:01] <robin_sz> and then theres the whol ething of 3D restricted areas, virtual work area limits balh blah blah .. theres really a lot to a robot controller thats very specialised
[01:42:03] <robin_sz> anyway
[01:42:05] <robin_sz> bedtime
[01:42:23] <tomp> i think you said the coordinate system moves with the tool, is from the tool's viewpoint
[01:42:29] <tomp> thanks
[01:42:38] <tomp> nite
[01:43:00] <jepler> see you robin_sz
[01:47:20] <tomp> if i understood that, then x+ is like my right hand. Wherever I am , x+ is to my right. If i turn around or stand on my head or lean, x+ is to my right hand
[01:50:49] <tomp> jepler: i did bin/halcmd loadrt pci_8255 i didnt get any pins, but did get 4 functions. do i supply an address?
[01:51:44] <Jymmmm> ok, I'm off to work... back in 90 minutes or so
[01:55:13] <jepler> tomp: yes, io=0xHHHH
[01:55:21] <jepler> you can find it in lspci
[01:55:25] <tomp> thanks
[01:55:28] <jepler> I'm not sure what it was on my system, which isn't booted right now
[01:55:50] <tomp> do i do direction?
[01:57:27] <jepler> I think that the default (0) creates all input pins
[01:57:39] <tomp> k
[01:57:41] <jepler> other values up to 4095 create different combinations of inputs and outputs
[01:58:25] <tomp> oooh, will study the source
[02:00:33] <tomp> oooh lotsa pins now bin/halcmd loadrt pci_8255 io=0xd400
[02:02:30] <tomp> tomp screws din rails to top of desktop box for all the io breakout boards
[02:32:46] <Twingy> hi
[02:37:24] <crepincdotcom_> * crepincdotcom_ is happy :-)
[02:37:32] <jepler> hi Twingy
[02:37:43] <jepler> crepincdotcom_: what's up?
[02:37:44] <crepincdotcom_> the guys in the CNC lab at school gave me my own section of the lab and offered me a job....
[02:37:52] <jepler> oh cool
[02:37:56] <crepincdotcom_> plus told me I could use any of their bits with my mill
[02:38:01] <crepincdotcom_> so yeah, thats good
[02:38:31] <crepincdotcom_> heh cant remember if I told you this, but ThinkNTinker called me yesterday
[02:38:51] <jepler> if you said that I missed it
[02:39:09] <crepincdotcom_> I placed an order, they called an hour later to say that they had googled me, found the mill I made, and determined that one of the bits I ordered would break due to the runout in my mill. they suggested 2 others that were cheaper and would work better
[02:39:16] <crepincdotcom_> THEN they 2-dayed it all to me :-)
[02:39:19] <jepler> ah
[02:39:27] <jepler> neat
[02:39:42] <crepincdotcom_> yah
[02:39:51] <tomp> great, who was that?
[02:39:59] <crepincdotcom_> John at thinkntinker
[02:40:17] <jepler> http://thinktink.com/
[02:42:38] <crepincdotcom_> how are things on your end jepler
[02:43:09] <jepler> crepincdotcom_: pretty good
[02:43:18] <crepincdotcom_> good good
[02:43:40] <jepler> crepincdotcom_: did you see the image I posted earlier?
http://axis.unpy.net/01170693566 this is what's on my mind lately
[02:44:12] <crepincdotcom_> whoa
[02:44:21] <crepincdotcom_> have you built such a thing, or just simulated?
[02:44:24] <jepler> just simulated
[02:44:29] <jepler> and jmkasunich has done most of the work, to tell the truth
[02:44:29] <crepincdotcom_> thats wicked cool
[02:45:09] <jepler> thanks
[02:45:20] <crepincdotcom_> you guys really are amazing at what you do
[02:45:38] <crepincdotcom_> i was just thinking yesterday how great Axis is... and now it supports that stuff too!
[02:46:12] <jepler> you're making me blush.
[02:46:20] <crepincdotcom_> lol, im not kidding though
[02:46:44] <jepler> thanks
[02:46:57] <tomp> pretty sci-fi stuff, good work ( tomp pictures the machine tool workbench where users created thier own monster machines )
[02:48:17] <jepler> yeah -- we just need a way to turn the 'vismach' description into a series of instructions to build the machine, and feed that to an existing mill
[02:48:24] <jepler> ooh I should patent that
[02:48:58] <crepincdotcom_> sounds like a good idea
[02:49:05] <crepincdotcom_> * crepincdotcom_ signes vitual NDA
[02:49:10] <ejholmgren> * ejholmgren slaps jepler with a trout
[02:49:28] <crepincdotcom_> lol
[02:49:35] <tomp> so the description is in the vismatch file? ( i gotta get back to the 8255 pin direction code ... )
[02:49:39] <crepincdotcom_> * crepincdotcom_ uses the puma to slap jepler with a trout
[02:49:47] <jmkasunich> we need a vismach model for the stepper_xyza machine now
[02:50:04] <jmkasunich> tomp: not quite
[02:50:07] <jepler> I did a lousy 3-axis mill already
[02:50:16] <jepler> it doesn't look as good as your machines
[02:50:18] <jmkasunich> vismach.py provides the primitives and such
[02:50:27] <jmkasunich> the machine description is in another python file
[02:50:45] <crepincdotcom_> jepler: it doesnt look as good as whose machine, and why is it lousey? (pics?)
[02:51:38] <jepler> hm and it doesn't run with jmk's latest changes to vismach.py
[02:51:57] <jmkasunich> tomp: here is the machine description for the scara:
http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/emc/usr_intf/axis/scripts/scaragui.py?rev=1.5
[02:52:14] <jmkasunich> jepler: that won't be hard to fix - about 4-5 lines
[02:52:41] <jmkasunich> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/emc/usr_intf/axis/scripts/scaragui.py.diff?r1=1.4;r2=1.5
[02:52:53] <jmkasunich> add two capture objects, one in tool space, one in work space
[02:52:59] <jmkasunich> and change the call to main
[02:53:02] <jepler> jmkasunich: i fear it will be a bit more work than that, i wrote it in the xml format I was toying with as an alternative to the python format
[02:53:09] <jmkasunich> oh
[02:53:48] <jepler> http://pastebin.ca/341930
[02:53:52] <jmkasunich> funny, 4 days ago I thought we should have some file format for the machine descriptions, and cradek said I should just hard code it
[02:54:02] <jmkasunich> now I'm 100% convinced thats the way to go
[02:54:14] <jepler> great, forget I ever mentioned XML
[02:54:19] <tomp> jmkasunich: and you just started using python ... sheesh
[02:54:20] <jepler> though I'm glad I learned python's xml library a bit better
[02:54:48] <jmkasunich> nice thing about using python - you can do math
[02:54:55] <jepler> yep
[02:54:59] <jmkasunich> for the puma everything is hardcoded
[02:55:16] <jmkasunich> but for the scara, you set 6 values, and it builds the robot to match them
[02:55:23] <jmkasunich> lots of simple arithimetic
[02:55:41] <jmkasunich> arm_dia = arm_lengty / 5.0, that kind of thing
[02:56:25] <jepler> yeah -- if you choose a full-featured language as your configuration format, you get a whole language without having to design it
[03:00:42] <jmkasunich> tomp: I've been cheating on the py
[03:00:49] <tomp> what python library had box & cylinder? i just noticed it was 3D
[03:00:57] <tomp> you pyCheater you
[03:01:08] <jmkasunich> jepler did the hard stuff, actually building the machine model is basically a lot of repetitions of the same basic code
[03:01:34] <jepler> tomp: to render the cylinder, it uses the "glu" library, function gluCylinder()
[03:02:13] <jmkasunich> open GL does the grunt work, jeff did an interface that lets py call it, and vismach itself has some convenience calls that call jeff's code but make it more user friendly
[03:02:44] <jmkasunich> (for instance, the open gl sphere is always at the origin, and you have to translate it separately, the vismach sphere lets you specify the location and does the translate for you
[03:05:09] <tomp> i'm not familiar with the spheres, but i get one coord set is centered at the robot base, and will need to look & play to grok the others (oh the vismach sphere does rev kins for you sort of )
[03:06:25] <jmkasunich> for example, looking at
http://axis.unpy.net/files/01170693566/scara.png
[03:06:40] <tomp> yah
[03:06:53] <jmkasunich> the inner arm consists of a vertical cylinder, a box, a horizontal cylinder, another couple of boxes, and another vertical cylinder
[03:07:17] <tomp> k
[03:07:19] <jmkasunich> vismach has calls to let you create cylinders, spheres, and boxes
[03:07:31] <jmkasunich> cylinders can be parallel to x, y, or z
[03:07:44] <jmkasunich> you can also apply rotations and/or translations to anything
[03:08:03] <jmkasunich> so you make the outer joint part (two boxes and a cylinder) then translate it to the end of the arm
[03:08:06] <jmkasunich> make the main tube
[03:08:13] <jmkasunich> make the inner joint part (box and cylinder)
[03:08:39] <jmkasunich> then you apply a variable rotation to the whole thing, which is controlled by hal
[03:08:52] <tomp> yah ( i'm following )
[03:09:17] <jmkasunich> the outer arm is built first, has its own variable rotation, and then it is attached to the inner one
[03:09:29] <jmkasunich> so the inner arm's rotation affects both pieces
[03:10:08] <tomp> re controlled by hal you mean this isnt just a model, it'd work? , it's a 'reflection'
[03:11:48] <jmkasunich> it is a simulated machine, controlled by hal pins
[03:12:05] <jmkasunich> disconnect the PID loop or stepgen, and connect the simulator
[03:12:48] <tomp> i think i meant (:)) if you had a real machine, it could be a 'monitor' of what the real machine was doing
[03:13:02] <jmkasunich> if I had a real scara robot, I could measure its critical dimensions (lengths of arms, etc) and enter them into the model, and I'd get something that behaves exactly like the real thing
[03:13:09] <jmkasunich> except that if you crash it, nothing happens
[03:13:13] <tomp> wicked!
[03:13:19] <jmkasunich> the tool can run right thru the floor or arm or...
[03:15:02] <tomp> today robin_sz had questions about the suitability of gcode to 'drive' a robot. do you see that you'd use gcode to command the scrara ( robin was thinking puma like )
[03:16:21] <CIA-8> 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/scaragui.py: allow geometry settings to come from the commandline
[03:23:01] <jepler> goodnight gus
[03:23:04] <jepler> guys
[03:23:12] <tomp> nite
[03:32:29] <Twingy> * Twingy heads to bed
[03:32:49] <tomp> nite Twingy
[03:32:57] <Twingy> tomorrow will fix your problem
[03:33:14] <tomp> k, thanks, get some rest
[03:33:30] <Twingy> 7 hours of mentoring wears you down :)
[03:33:46] <Twingy> esp. high school kids, night
[03:34:04] <tomp> bhudda will reward you
[04:08:21] <tomp> ok, i got the direction sussed for the 8255, it has 3 chips, each has 3 ports, but 1 port an be nibbled (used as 2 separate 4 bit chunks), so there's 4 chunks per chip, port A,B, Chi Clo, and each chunk can be all inputs or outputs.
[04:09:51] <tomp> by weighting the chunks, A=8 B=4 Chi=2 and Clo=1, you can state the direction of one chip by binary 1111 to 0000 ( 1 means output )
[04:11:45] <tomp> and for 3 chips, thats 3 sets of 4bits, so the value ranges from 4095 to 0 for allout to all in
[04:17:58] <tomp> this makes the call to install the pci_8255 bin/halcmd loadrt pci_8255 io=0xd400 dir=1911 io is the address returned by lspci -v and the 1911 make chip 3 portA in chip 2 port A in, chip 1 port A in ( and all other ports and half ports are outputs becuz 1911 is hex777 )
[04:19:46] <tomp> enuf for now, nite all
[08:33:36] <Dallur> morning
[09:08:52] <tray> Hello, anyone able to help a noobie.
[09:09:24] <tray> I've got an optoisolator connected to my parallel port,
[09:09:57] <tray> Using Pin2 as the supply, and pin25 as the gnd. An led to indicate the operation of the isolator.
[09:10:27] <tray> Can I force this led on & off using the HAL config. in axis?
[10:26:56] <charolastra> hi
[10:31:12] <Dallur> hello
[12:20:35] <cradek_> cradek_ is now known as cradek
[13:05:27] <tomp> jepler: could you paste/post an xml example of the table widget please ? not clear on the calling format. Whats the flexible/uniform rows/columns? as it looks like you can have all 4 in 1 layout. i do see it's an interface to the grid manager. thanks
[13:19:34] <jepler> good morning
[13:19:39] <jepler> here's a simple table example:
http://pastebin.ca/344005
[13:19:53] <tomp> jepler: thanks
[13:22:26] <jepler> if you change the <table> line to <table flexible_rows="[2]">
[13:22:34] <jepler> you'll see that the middle row expands when you resize the window
[13:22:41] <tomp> ah
[13:23:29] <jepler> flexible_rows corresponds to the Tk row/column weight flag, except that with flexible_rows you can only give a weight of 1
[13:25:25] <tomp> ok, i'll use that as reference to the tcltk books i have, not really a tcikler myself, tho i heard about weight
[13:25:33] <jepler> if you change the <table> line to read <table uniform_cols="abb"> then columns 2 and 3 will have the same width
[13:25:52] <jepler> all of the uniform_ and flexible_ can be used together, though all the combinations don't necessarily make sense
[13:27:07] <tomp> btw: last night i got this format for pci_8255 bin/loadrt pci_8255 io=0xd400 dir=1911 seemed to work ( 1911 is hex 777 )
[13:28:18] <tomp> jepler thanks, off to dentist
[13:35:32] <CIA-8> 03alex_joni 07TRUNK * 10emc2/configs/scara/scara.ini: fix TRAJ accel's
[13:50:57] <jepler> skunkworks: you should have used this technology for your servo amp board:
http://www.makezine.com/blog/archive/2007/02/how_to_make_a_p_12.html
[13:52:28] <skunkworks> yeck.. at least use resist and acid...
[14:05:08] <A-L-P-H-A_> skunkworks, laser toner + acid work great too
[14:07:25] <a-l-p-h-a> hehe.. forgot about hydrairc
[14:25:32] <fenn_gohan> why is this happening? /usr/local/share/emc2/bin/emc_module_helper: Permission denied
[14:26:38] <fenn_gohan> heh a quick google finds me asking the same question a couple months ago
[14:26:47] <alex_joni> hmm.. is the permission denied a problem with executing the file?
[14:26:52] <alex_joni> or with the insmod?
[14:27:38] <fenn_gohan> it does chmod 4750 on emc_module_helper
[14:27:55] <fenn_gohan> so its no readable by normal users
[14:28:43] <fenn_gohan> -rwsr-x--- 1 root staff
[14:29:00] <fenn_gohan> * fenn_gohan wonders where group "staff" came from
[14:29:18] <fenn_gohan> maybe i should just remove that file and start with a fresh copy
[14:30:31] <fenn_gohan> hmm same result
[14:31:02] <alex_joni> maybe you should add your user to staff :P
[15:00:27] <maddash> realtime delays
[15:04:26] <fenn_gohan> i'm getting some errors from axis that i think might be related to the recent mdi changes
[15:05:19] <jepler> fenn_gohan: what's the error?
[15:05:34] <fenn_gohan> http://pastebin.ca/344082
[15:06:50] <fenn_gohan> http://pastebin.ca/344084
[15:07:36] <fenn_gohan> it does it whether installed or run in place
[15:08:22] <alex_joni> import xml.dom.ext
[15:08:27] <alex_joni> seems your missing a python package
[15:08:49] <alex_joni> fenn_gohan: what system is this?
[15:08:52] <alex_joni> debian?
[15:08:56] <fenn_gohan> yes
[15:09:19] <alex_joni> python2.4-xml
[15:10:03] <jepler> looks like you changed where files are installed. I don't think the installer would normally create "/usr/local/share/emc2/lib/python/vcpparse.py"
[15:11:32] <fenn_gohan> aha i have some crap left over in my PATH
[15:13:41] <fenn_gohan> ok lathe works, still get the draw_lines error in sim/axis
[15:14:00] <fenn_gohan> thanks alex
[15:14:09] <jepler> is it possible you have another copy of minigl.so somewhere that doesn't match the version of emc you're trying to run?
[15:15:03] <fenn_gohan> /usr/lib/python2.4/site-packages/minigl.so
[15:15:03] <fenn_gohan> /usr/local/share/emc2/lib/python/minigl.so
[15:15:38] <jepler> I would expect the installer to create the one in site-packages
[15:17:08] <fenn_gohan> they have the same md5
[15:17:50] <jepler> hm
[15:18:05] <jepler> lathe probably works because it doesn't load splash gcode
[15:18:11] <jepler> I bet it won't load a file for preview
[15:18:26] <jepler> but I don't understand this error you're seeing
[15:19:22] <fenn_gohan> right, that's what i thought (and it dies when i load a file)
[15:20:45] <alex_joni> my ARM9 quest is successfull :)
[15:21:03] <jepler> fenn_gohan: no other files named minigl.so on your system?
[15:21:13] <alex_joni> 2.6.15.7 + busybox + uclibc + .. booting of an S3C2410 :)
[15:21:56] <fenn_gohan> (when loading a 3D_chips.ngc in lathe mode)
http://pastebin.ca/344115
[15:22:05] <jepler> if you didn't have this change I suspect you'd get that error:
http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/emc/usr_intf/axis/extensions/minigl.c.diff?r1=1.5;r2=1.6;f=h
[15:22:06] <fenn_gohan> alex_joni: gratz.. did you use buildroot?
[15:22:41] <alex_joni> fenn_gohan: yeah, and a vanilla 2.6.15.7 (with minor hacking)
[15:23:17] <alex_joni> http://www.youtube.com/watch?v=-DWF9XrjACs
[15:24:50] <jepler> in fact I get that error by reversing that change
[15:24:57] <jepler> File "/usr/src/emc2/bin/axis", line 1499, in draw_lines
[15:24:58] <jepler> return draw_lines(lines, for_selection)
[15:24:58] <jepler> TypeError: function takes exactly 3 arguments (4 given)
[15:25:52] <fenn_gohan> ok.. minigl.c has that change, how do i verify that /usr/lib/pytho.../minigl.so is the same code?
[15:27:46] <jepler> $ strings /usr/src/emc2/lib/python/minigl.so | grep 'i.ddd..ddd..O'
[15:27:46] <jepler> i(ddd)(ddd)|O
[15:28:04] <fenn_gohan> btw does this mean we'll get colored lines that show off the feedrate in pretty colors? :D
[15:28:06] <jepler> or make sure the minigl.so from your build tree (emc2/lib/python/minigl.so) matches the installed one
[15:28:44] <jepler> no, feeds are still shown in white, but there's a milling-time estimate in File > Properties...
[15:31:29] <fenn_gohan> ok it's not there of course
[15:31:46] <jepler> is there an emc2/lib/python/minigl.so in your build tree?
[15:32:33] <jepler> from src: $ touch emc/usr_intf/axis/extensions/minigl.c; make ../lib/python/minigl.so
[15:32:36] <jepler> Depending emc/usr_intf/axis/extensions/minigl.c
[15:32:40] <jepler> Compiling emc/usr_intf/axis/extensions/minigl.c
[15:32:41] <jepler> Linking python module minigl.so
[15:33:43] <jepler> if you do the same, does it rebuild minigl.so?
[15:34:00] <fenn_gohan> yes, and now its different
[15:34:16] <fenn_gohan> why didnt it recompile minigl.so after i did a make clean earlier?
[15:35:19] <jepler> I dunno, I'll do a make clean and see if it rebuilds or not
[15:36:24] <jepler> $ make clean; make ../lib/python/minigl.so
[15:36:29] <jepler> ...
[15:36:30] <jepler> Compiling emc/usr_intf/axis/extensions/minigl.c
[15:36:30] <jepler> Linking python module minigl.so
[15:37:51] <fenn_gohan> well now it works
[15:38:32] <fenn_gohan> * fenn_gohan makes a note to buy more gremlin snacks at the grocery store
[15:38:53] <jepler> yeah -- I'm pleased to hear it works now but I'd love to know what went wrong
[15:39:27] <jepler> is the X protocol error gone now too?
[15:40:41] <fenn_gohan> yeah
[15:41:01] <jepler> * jepler declares victory.
[15:41:26] <fenn_gohan> * fenn_gohan highfives jepler
[16:10:51] <a-l-p-h-a> anyone ever burn a DVD over a network connection/samba? Is that a dumb idea?
[16:14:12] <charolastra> i'd say deffinitly
[16:15:53] <a-l-p-h-a> damn it... 22mB/sec > 100mbit ethernet.
[16:15:58] <a-l-p-h-a> 16x dvd.
[16:15:57] <fenn_gohan> do it over wireless in an emulator just to be sure
[16:16:04] <charolastra> hehehe
[16:16:58] <a-l-p-h-a> this blows... well... options options.
[16:19:09] <a-l-p-h-a> Do I have to login first before I can VNC into a session? Or can I start a session via VNC?
[16:19:26] <a-l-p-h-a> I know I can ssh over... but not what I want. want a GUI to drag and drop files to burn.
[16:20:25] <charolastra> VNC is a server-client thing; just start the server there
[16:22:28] <fenn_gohan> fish://server
[16:23:16] <a-l-p-h-a> charolastra, it's a headless machine, so I dunno how to start if I can.
[16:35:56] <Vq^> a-l-p-h-a: you could use vnc with xdmcp
[16:40:47] <jepler> a-l-p-h-a: typically you manually start your vnc session with a command like 'vncserver :1'
[16:48:30] <a-l-p-h-a> I got tightvncserver up and running.
[16:48:38] <a-l-p-h-a> but when I vnc in... all I get is gnome-terminal.
[16:48:40] <a-l-p-h-a> no desktop.
[16:49:03] <a-l-p-h-a> I can start other apps... but a desktop would be nice...
[16:54:19] <crepincdotcom_> :-(
[16:54:25] <crepincdotcom_> * crepincdotcom_ *cries*
[16:54:37] <crepincdotcom_> I just fryed the Y-axis motor on my mill :-(
[16:56:02] <a-l-p-h-a> crepincdotcom, shitty.
[16:56:06] <a-l-p-h-a> how'd you do that?
[16:56:16] <crepincdotcom_> nothing I did, just bad motors
[16:56:22] <crepincdotcom_> theyre Cannon scanner motors I salavaged
[16:56:33] <crepincdotcom_> just not meant for this I guess :-(
[17:06:09] <crepincdotcom_> oh phew its not the motor
[17:06:14] <crepincdotcom_> looks like a drive transistor
[18:45:20] <maddash> a-l-p-h-a: can you ssh?
[18:48:17] <alex_joni> is that in python?
[18:52:46] <maddash> is there some page on the wiki that lists most (if not all) possible causes of realtime delays when running EMC2?
[18:53:11] <cradek> yes
[18:54:11] <alex_joni> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?TroubleShooting#Unexpected_realtime_delay_check_dmesg_for_details
[18:54:55] <cradek> fwiw, searching for "realtime delay" gave that one result
[18:55:20] <maddash> bah, i searched "delay"
[18:55:29] <crepincdotcom_> I have a stepper that just vibrates when I step it. I'm half stepping, and it moves 3 motions in one direction then skips back. I've tested the controller and it works on other motors. However, there is still the proper resistance between the coils on the stepper so none of them are blown out.... anyone have any ideas?
[18:55:54] <cradek> stepper is wired wrong?
[18:55:55] <fenn> accel too high?
[18:56:19] <fenn> noise on the lines?
[18:56:21] <cradek> yeah does this one have more mass on it?
[18:56:32] <crepincdotcom_> cradek: the wiring didnt change. It was motoring along and suddenly the Y-axis stopped moving so I investigated
[18:57:03] <crepincdotcom_> I put a vise on the mill, however I had it moving around earlier no problem. even at lowest speed (==highest torque) it just vibrates
[18:57:11] <cradek> does the motor work on another driver?
[18:57:17] <crepincdotcom_> I brought the accels down too
[18:57:19] <crepincdotcom_> cradek: no
[18:57:44] <cradek> is it free if you turn it by hand?
[18:58:12] <fenn> what kind of drive is it?
[18:58:11] <crepincdotcom_> well it certainly takes some torque to turn it, but not more so than usual that I can tell
[18:58:14] <crepincdotcom_> unipolar
[18:58:21] <fenn> homemade?
[18:58:33] <crepincdotcom_> L297 --> ground side switching with TIP102's
[18:58:33] <crepincdotcom_> fenn: yes
[18:58:45] <crepincdotcom_> that channel is verified to work with other motors on the system
[18:59:04] <crepincdotcom_> I guess I'll take it off and see what happens at no load :-/
[18:59:07] <fenn> measure the y axis sense resistor and see if its the same as others?
[18:59:26] <crepincdotcom_> i dont know why it would changes since it worked before, but good point. i will.
[18:59:28] <fenn> you might have damaged the motor (too much current demagnetizes a permanent magnet)
[18:59:37] <crepincdotcom_> hmmm perhaps
[18:59:40] <cradek> did it overheat or anything?
[18:59:46] <crepincdotcom_> it did get quite hot
[18:59:52] <cradek> eek
[19:00:04] <crepincdotcom_> but the coils didnt melt, since theres still connectivity between the wires
[19:00:10] <fenn> l297 doesnt have a sleep mode does it?
[19:00:15] <cradek> it may have shorted turns, which you would not notice when measuring resistance
[19:00:16] <crepincdotcom_> yes it does
[19:00:19] <crepincdotcom_> I havent enabled it though
[19:00:25] <crepincdotcom_> cradek: oh
[19:00:48] <crepincdotcom_> I think the problem stems from the fact that when the motors arent turning, theyre sitting there with one coil fully energized
[19:00:52] <cradek> until it's melted into one big lump of copper, the resistance will stay about the same
[19:00:56] <crepincdotcom_> since I don't disable the driver when its not moving
[19:01:01] <crepincdotcom_> cradek: oh
[19:01:27] <cradek> crepincdotcom_: that's only a problem if your steady-state current is too high right?
[19:01:39] <cradek> I mean it's normal to have one or two coils on...
[19:01:46] <crepincdotcom_> theoretically, but I dont know what "too high" is
[19:01:57] <crepincdotcom_> i mean they do get wicked hot
[19:01:59] <fenn> yeah hard to tell with a random scrappy motor
[19:02:09] <cradek> if they're real hot, it's too high
[19:02:12] <crepincdotcom_> drat
[19:02:34] <cradek> heh "scrappy"
[19:02:34] <crepincdotcom_> well since i need a matched pair if I'm going to get new ones, what do you guys think of these?
[19:02:38] <crepincdotcom_> http://cgi.ebay.com/3-stepper-motors-4-cnc-mill-lathe-emco-taig-sherline_W0QQitemZ160083110399QQihZ006QQcategoryZ78196QQrdZ1QQcmdZViewItem
[19:02:41] <crepincdotcom_> heh mine certainly are scrappy
[19:03:57] <cradek> you should probably shoot for something lower voltage
[19:04:16] <skunkworks> Dynamically balanced rotor for 100+ ipm on a 20tpi lead screw
[19:04:18] <maddash> would ssh-ing cause RTD's?
[19:04:19] <skunkworks> yah
[19:04:30] <maddash> skunkworks: was that for me?
[19:04:40] <fenn> maddash: ssh shouldnt cause any problems
[19:04:45] <skunkworks> maddash: no - sorry
[19:04:46] <cradek> maddash: shouldn't if your machine works right
[19:04:53] <fenn> maddash: go into the bios and start turning off "features"
[19:05:15] <maddash> ok, i just got two slightly different responses...
[19:05:28] <maddash> cradek: could you define how the machine would "work wrong"?
[19:05:54] <maddash> fenn: yes, I'm assuming that I've turned off the usual suspects (acpi, smi, etc)
[19:05:58] <cradek> maddash: mostly it would be hardware or BIOS settings that break realtime
[19:06:45] <skunkworks> onboard video - I have had usb equipment and chipsets cause it also.
[19:06:51] <maddash> cradek: so i basically asked if activity in the network hardware would break the cpu's concentration...
[19:07:26] <crepincdotcom_> cradek: I took off the vise, turns out that extra mass passes the threshold for friction in the Y plane. so the motor works.... but I can't use my vise
[19:07:27] <fenn> some mobo's with wake on lan have problems?
[19:07:53] <fenn> crepincdotcom: swap x and y
[19:07:56] <fenn> i bet your motor's busted
[19:08:02] <crepincdotcom_> really?
[19:08:04] <crepincdotcom_> ok
[19:08:08] <maddash> skunkworks: you've had RTD's? how bad do they get?
[19:08:19] <crepincdotcom_> fenn: they do run very hot, I guess I should look into that
[19:08:37] <fenn> er.. swap the motors i mean
[19:08:48] <cradek> maddash: it's possible I suppose, maybe try a different network card
[19:09:47] <skunkworks> maddash: how bad? I don't want any. If I am getting them - I tweek things until no more RTD.
[19:10:11] <maddash> cradek: so should i avoid that motherboards w/network hardware were built into it?
[19:10:26] <fenn> no, just dont use the onboard ethernet
[19:10:33] <fenn> (if its causing problems)
[19:10:33] <cradek> it seems the more built-in stuff a MB has, the worse it works
[19:10:42] <cradek> but yeah, often you can just turn that stuff and put in cards
[19:10:49] <maddash> ah, ok.
[19:11:22] <cradek> err turn that stuff OFF
[19:11:30] <cradek> in the BIOS, I mean
[19:11:57] <skunkworks> maddash: do you have onboard video? Did I ask that yesterday?
[19:12:39] <maddash> skunkworks: yes. no.
[19:12:43] <skunkworks> ouch
[19:12:55] <robin_sz> onboard video ...
[19:12:55] <skunkworks> that is probably the main problem. Shared memory
[19:13:09] <maddash> skunkworks: why? the wiki states that vid cards cause RTD's.
[19:13:08] <robin_sz> or as we prefer to call it: the kiss of death to RT applciations
[19:13:36] <skunkworks> ?
[19:14:01] <skunkworks> wiki says what? ;)
[19:14:45] <robin_sz> RTDs?
[19:15:04] <robin_sz> rectally transimitted diseases?
[19:15:13] <skunkworks> Many onboard video chips cause bad realtime performance. The ones that use some of the system RAM for video are the worst. If you have realtime problems with a system using onboard video, the first thing to do is disable it and plug in a video card. The closed-source NVidia driver is known to break realtime, so if you have an NVidia card you should try the "nv" or "vesa" drivers.
[19:15:40] <skunkworks> real time delays. :)
[19:26:25] <maddash> skunkworks: it's an intel 950
[19:26:33] <maddash> skunkworks: it's reasonably fast
[19:27:53] <alex_joni> maddash: the intel boards have an issue with RT called SMI
[19:28:00] <alex_joni> as it's written on that page :)
[19:28:26] <alex_joni> maddash: did you run the latency test?
[19:29:47] <maddash> alex_joni: no. ididn't think i had an intel chipset.
[19:30:10] <alex_joni> if you have an i950 then I bet you do
[19:30:19] <maddash> yeah, i just chked.
[19:30:40] <alex_joni> maddash: I built a new RTAI package which fixes that SMI problem
[19:30:45] <alex_joni> I can help you set it up
[19:30:45] <maddash> maybe i'm better off using an onboard g-code interpreter
[19:31:04] <alex_joni> onboard g-code interpreter?
[19:31:45] <maddash> alex_joni: your code takes advantage of the regularity of smi?
[19:32:08] <alex_joni> not my code.. I simply packaged a small fix to the RTAI smi kernel module
[19:32:18] <alex_joni> it basicly disables SMI
[19:32:37] <alex_joni> so while you run RT code, you won't be affected by USB disks or other things which cause SMI interrupts
[19:32:44] <alex_joni> they still work afaik
[19:32:58] <skunkworks> alex_joni: they do on my portable.
[19:33:09] <alex_joni> skunkworks: do what?
[19:33:30] <skunkworks> usb drives still work while emc2 is running
[19:33:48] <alex_joni> yeah, but don't cause RT latency errors.. right?
[19:33:53] <skunkworks> exactly
[19:34:04] <maddash> "onboard g-code interpreter" - for some more money, i could get a board that stores a gcode file in NAND and interprets it via hardware
[19:34:19] <alex_joni> where from?
[19:34:20] <erDiZz> the nVidia driver "breaks realtime" by issuing "wbinvd" CPU instructions, which are very expensive. I had a successful experiment, where wbinvd execution was delayed till the completion of next realtime-timer tick, so that it worked without delays at about 1Khz frequency (but at higher frequencies the problems were back)
[19:34:29] <erDiZz> (just for your information)
[19:34:46] <alex_joni> erDiZz: how did you delay it?
[19:34:59] <maddash> alex_joni: there's a few floating on the web. chk out smc-machines 's MC443G board.
[19:35:32] <erDiZz> alex_joni, I was delaying the return to the whole kernel by busy-looping till the next real-time timer interrupt was processed
[19:36:07] <erDiZz> wbinvd happens on creating of a new OpenGL context and on switching from the console to X mostly
[19:36:28] <alex_joni> I see.. so it shouldn't happen very often ?
[19:36:36] <erDiZz> yes, that's pretty rare
[19:36:45] <alex_joni> how do you detect it?
[19:38:16] <erDiZz> there's a scrrenshot at my blog. let me find it...
[19:38:31] <alex_joni> I think I saw that one
[19:38:39] <alex_joni> is it the one with SMB transfers in the background?
[19:39:06] <erDiZz> no, that was later
[19:39:13] <erDiZz> but the tool is the same
[19:39:26] <alex_joni> ok
[19:39:31] <erDiZz> alex_joni,
http://gcode.blogspot.com/2006/06/performance-in-action.html
[19:40:17] <erDiZz> I had a conversation with a man who was investigating on this problem too. There's a link to that discussion
[19:44:14] <maddash> what's "gauntlet"?
[19:44:16] <erDiZz> and that "cache pre-fill" idea in the blog record didn't work, wbinvd stabilized at about 700.000 CPU cycles (if I remember the number correctly) on my Pentium D 820 (2.8 Ghz), which is still a lot
[19:44:41] <erDiZz> maddash, that a neat weapon from quake 3 :)
[19:45:06] <maddash> erDiZz: very funny. I meant "pf.gauntlet"
[19:45:27] <erDiZz> maddash, pf.gauntlet is a GUI that displays those graphs
[19:45:34] <erDiZz> it can be found in MyNC CVS
[19:46:22] <erDiZz> but I didn't invest much time in it. I used it only twice since that time, and thus only was hacking on it twice
[19:46:34] <maddash> why do you name your nc code files .iso?
[19:46:51] <skunkworks> russia - wow - do you know... :)
[19:46:55] <erDiZz> skunkworks, right
[19:47:06] <erDiZz> I received them as .iso, so they are :)
[19:47:26] <erDiZz> and everybody calls them [is'oshki] here :)
[19:47:40] <alex_joni> omg, 700000 cycles?
[19:47:52] <erDiZz> alex_joni, yep
[19:48:28] <erDiZz> so on a 2.8 Ghz machine one should expect invevitable problems at 2.8 Khz
[19:48:55] <erDiZz> (I've approximated 700.000 to one million)
[19:49:28] <alex_joni> that's crazy
[19:49:33] <erDiZz> ...because without those "cache pre-fills" it can take slightly more that 700.000
[19:49:46] <erDiZz> alex_joni, yep :( that's what that instruction does
[19:50:12] <erDiZz> my numbers are experimental, and I've measured it on a single machine only
[19:50:13] <alex_joni> seems that's 486+
[19:50:31] <erDiZz> alex_joni, what do you mean?
[19:50:43] <erDiZz> the instruction?
[19:50:43] <alex_joni> the wbinvd
[19:50:47] <alex_joni> yeah
[19:51:21] <erDiZz> Linux just doesn't happen to need it, fortunately
[19:51:25] <erDiZz> but
[19:51:33] <erDiZz> it _does_ wbinvd when setting MSRs
[19:51:45] <erDiZz> as is required by Intel system developer's guide
[19:52:01] <erDiZz> em
[19:52:02] <erDiZz> not MSRs
[19:52:04] <erDiZz> MTRRS only
[19:52:14] <erDiZz> memory-type range registers
[19:52:46] <alex_joni> erDiZz: TMI for me at this hour :D
[19:53:02] <erDiZz> :)
[19:53:50] <alex_joni> erDiZz: I'm recovering from the last 4 days spent at getting 2.6.15.7 to run on an ARM9 board
[19:54:16] <maddash> alex_joni: how'd that work out?
[19:54:35] <alex_joni> maddash: it worked ..
[19:54:44] <alex_joni> still not everything yet..
[19:54:49] <erDiZz> and why 2.6.15.7? a patch for that version?
[19:55:03] <maddash> alex_joni: why did you try?
[19:55:06] <alex_joni> erDiZz: I had a patched 2.4.18 I think
[19:55:15] <alex_joni> but that was too old for some other things
[19:55:33] <alex_joni> I just grabbed the latest 2.6.15 (I feel comfortable with it), don't ask me why
[19:58:43] <erDiZz> ...I had a patch for 2.6.15.6 for a long time.. until I updated it for 2.6.19
[19:58:48] <maddash> you realize that emc doesn't run on arm, rah?
[19:58:49] <erDiZz> * erDiZz back to the documentation stuff
[19:59:54] <maddash> brb
[20:07:26] <pier> emc runs now smoothly as always :) it was apm.... I forgot to remove it from kernel when compiling
[20:08:20] <pier> no longer complaining about rt delay and rtai test gives no overrun..
[20:09:36] <skunkworks> Great job!
[20:11:30] <pier> thanks skunkworks but it's thanks to your advice on linuxcnc
[20:12:03] <pier> I re-read the page and remembered about not removing apm
[20:32:09] <pier> is the link to EMC2_Code_Notes.pdf broken?
[20:32:47] <alex_joni> pier: which one?
[20:33:17] <pier> the one
http://www.linuxcnc.org/docs/EMC2_Code_Notes.pdf
[20:34:03] <alex_joni> pier: it's called
http://www.linuxcnc.org/docs/EMC2_Developer_Manual.pdf
[20:34:32] <pier> thanks alex
[20:34:41] <alex_joni> pier: where did you get that link?
[20:35:01] <pier> on the web page
http://www.linuxcnc.org/index.php?option=com_content&task=view&id=5&Itemid=5&lang=en
[20:36:52] <pier> wow freshly backed! Looks like latex' been used (reminds me of my thesis in the early 90thies)
[21:18:52] <alex_joni> pier: fixed that link, thanks for pointing it out
[21:19:59] <alex_joni> pier: v2.1 Documentation is here:
http://www.linuxcnc.org/docs/2.1/
[21:21:21] <pier> thanks
[21:22:59] <alex_joni> np
[21:23:56] <pier> alex_joni: did you translate the page into Italian? It is a good translation...
[21:24:49] <pier> if a hand for that purpose is needed I'd be glad to be of any help
[21:25:28] <alex_joni> pier: not me, although I can read most of it..
[21:25:37] <alex_joni> it was another guy from italy (on the mailing list)
[21:25:51] <alex_joni> pier: feel free to email me any translations which aren't done yet
[21:26:02] <alex_joni> and I'll update them some day *blush*
[21:26:18] <pier> ok the wiki links I imagine?
[21:26:38] <alex_joni> wiki should probably stay unstranslated
[21:26:49] <alex_joni> but news, and other stuff is still not translated
[21:27:05] <pier> ok then
[21:27:36] <alex_joni> I think I might have gotten a tranlation for basic install
[21:27:50] <alex_joni> but had no time to put it up, it's not the most pleasant thing to do
[21:28:21] <alex_joni> I have it, and I'll do it now.. ok?
[21:28:30] <alex_joni> I mean, can you check afterwards?
[21:28:52] <pier> np at all...
[21:29:40] <pier> if you'd pass some links on to me I'll se to them asap
[21:29:49] <pier> in any case
[21:30:39] <pier> better you gurus sweat over the real thing ;)
[21:32:45] <alex_joni> gurus? where?
[21:33:14] <pier> hehe
[21:38:46] <alex_joni> http://www.linuxcnc.org/index.php?option=com_content&task=view&id=21&Itemid=4&lang=it
[21:39:52] <pier> ok
[21:41:06] <alex_joni> anyone knows why I would get "no such device" when trying to mount /dev/sda1 ?
[21:41:28] <alex_joni> fdisk shows /dev/sda1 as FAT16 (type 6), and recognizes it ok
[21:41:42] <alex_joni> the /dev/sda and /dev/sda* have all been created
[21:42:07] <SWPadnos> read permissions?
[21:42:33] <alex_joni> running as root?
[21:42:42] <SWPadnos> err - no, that wouldn't be it :)
[21:42:53] <alex_joni> I do get some error in syslog saying it can't read partition table
[21:43:07] <alex_joni> or something like that .. but fdisk reads it just fine
[21:48:13] <lerneaen_hydra> random question: when in an ssh session, is everything encrypted?
[21:48:23] <cradek> yes
[21:48:23] <SWPadnos> ljh*&Cjkh dlkh llsiu*&hhl
[21:48:33] <SWPadnos> (that was encryptedspeak for "yes" :) )
[21:48:34] <alex_joni> SWPadnos: I can read that just fine
[21:48:38] <SWPadnos> heh
[21:48:48] <lerneaen_hydra> and the encryption is regarded as "safe", today, right?
[21:48:50] <alex_joni> maybe because I'm in a similar ssh session ?
[21:48:54] <alex_joni> lerneaen_hydra: mostly safe
[21:49:02] <pier> alex_joni: looks perfect to me....
[21:49:05] <alex_joni> pier: good
[21:49:11] <SWPadnos> next time, I'll use a triple-DES + SHA-3 cipher
[21:49:13] <lerneaen_hydra> at least good enough to stop someone only curious
[21:49:21] <alex_joni> lerneaen_hydra: it can be broken with a man-in-the-middle attack :D
[21:49:32] <alex_joni> but then those probably need some DNS hacking
[21:49:44] <alex_joni> lerneaen_hydra: sure.. this is not a trivial thing to do..
[21:49:51] <alex_joni> they need to be really motivated
[21:50:18] <lerneaen_hydra> hmm by that you mean that you think you connect to your host, but in fact you connect to the mitm, which in turn send the data through him?
[21:50:30] <lerneaen_hydra> but once the connection is established it's really safe?
[21:52:08] <cradek> it keeps host keys so the MITM would have to be there every time you connect, including the first
[21:52:19] <cradek> you could transfer (or check) your host keys some other way to be sure there's no MITM
[21:52:52] <pier> night all
[21:53:27] <maddash> alex_joni: have you got it mounted?
[21:54:46] <lerneaen_hydra> cradek; what's to stop the mitm from copying/passing through the host keys?
[21:56:12] <cradek> lerneaen_hydra: um I guess I don't know
[21:56:17] <alex_joni> maddash: no..
[21:57:09] <alex_joni> maddash: but I shut that board down for tonight..
[21:57:31] <lerneaen_hydra> 'night everyone
[21:57:35] <alex_joni> night LH
[22:02:50] <alex_joni> good night all
[22:03:41] <erDiZz> night
[22:13:43] <maddash> hmm, anyone here familiar with objectarx?
[22:20:50] <twice2> help a noob?
http://paste.getlinuxhelp.org/120014
[22:22:18] <cradek> laptop?
[22:22:22] <jepler> twice2: look for a script in the guest machine to reinstall the vmware tools
[22:22:37] <cradek> oh, ethernet inside vmware
[22:22:53] <jepler> because you installed a new kernel when you installed emc2, the vmware network card driver probably needs to be compiled for the new kernel.
[22:23:13] <twice2> that's what i was afraid of
[22:23:45] <jepler> there is a standard ethernet card type that works inside a vmware machine, bu t I don't know what it is offhand
[22:23:48] <SWPadnos> VMWare doesn't provide drivers for the realtime kernel you need to run a CNC, so a compile is inevitable
[22:23:59] <SWPadnos> it should be an AMD PCNet2000 or similar
[22:24:01] <cradek> you may have to re-run vmware-config.pl after changing kernels
[22:24:22] <cradek> (I thought vmware didn't run at all without its modules)
[22:24:51] <cradek> oh, ignore me, good grief
[22:24:52] <twice2> i'll try it
[22:24:55] <jepler> cradek: ubuntu is the guest, I think
[22:24:58] <cradek> I misunderstood the question
[22:24:58] <cradek> yeah
[22:25:04] <SWPadnos> it's fine without the guest software being installed, but you get things like seamless mouse motion between host/guest when they're installed
[22:25:49] <maddash> maddash is now known as sudo_maddash
[22:27:54] <alex_joni> good night all
[22:32:44] <lerman> I would like to make a minor change to the file 'scripts/emc' to export the environment variable EMC2_NCFILES_DIR. Where should the change be made?
[22:33:56] <lerman> A comment in the script says: "Values that come from configure". I assume that means the values are created automagically. I need to know where the "source" is for that.
[22:34:33] <cradek> emc.in
[22:34:34] <SWPadnos> ultimately, I think the source is configure.in in the src/ dir
[22:34:49] <SWPadnos> is NCFIULES_DIR already generated by configure?
[22:34:56] <SWPadnos> -I
[22:34:56] <SWPadnos> err -U
[22:35:29] <SWPadnos> duh - nevermind me. time for some brain food in my diet :)
[22:35:41] <twice2> ah man, i can't even find gcc :/
[22:36:24] <lerman> Generated by someone. If you look at 'script/emc' you will see a bunch of env variables defined. Some are exported. I need for this one to be exported.
[22:38:14] <lerman> I suspect that in configure.in, I just need to add " ; export EMC2_NCFILES_DIR" at the ends of the two lines that say EMC2_NCFILES_DIR=...
[22:40:37] <cradek> emc is generated from emc.in by configure
[22:41:42] <lerman> Thanks. cradek.
[22:42:13] <cradek> configure just substitutes strings for the @VAR@ things in emc.in
[22:50:50] <jepler> lerman: i don't believe the EMC2_NCFILES_DIR should be used. we should get rid of it. The location to search for g-code files is specified in the .ini as [DISPLAY]PROGRAM_PREFIX
[22:51:17] <jepler> a user can change the .ini file (for instance, to have a different directory for lathe .ngc files than for mill .ngc files) but not the EMC2_NCFILES_DIR
[22:53:18] <lerman> Someone suggested that we use NCFILES, but what you are saying makes sense. How is the .ini file read? Or, more specifically, how can I access that variable from the interp. [please, tell me it is easy.]
[22:53:56] <jepler> rs274ngc_pre.cc: if (NULL != (inistring = inifile.find("PARAMETER_FILE", "RS274NGC"))) {
[22:54:06] <jepler> you should be able to do something like this ^^^
[23:03:23] <lerman> jepler: thanks.
[23:39:47] <twice2> does the install include the Magma source or do i get that somewhere else?
[23:41:06] <jepler> to rebuild the vmware tools you presuambly need the linux-headers-2.6.15-magma package
[23:41:26] <jepler> the source is in the linux-source-2.6.15-magma package if you want/need it
[23:43:40] <twice2> jepler: yeah, to rebuild the vmware tools i just need the header package then?
[23:44:02] <jepler> twice2: yes, the linux-headers package is enough to build new kernel modules
[23:44:29] <twice2> cool, so like how to get that then?
[23:44:45] <jepler> sudo apt-get install <packagename>
[23:45:08] <twice2> gudancer :)
[23:45:49] <jepler> if you were using standard ubuntu, there's a graphical package manager in one of the menus, but I think you mentioned using xubuntu
[23:46:19] <jepler> bbl, dinnertime
[23:46:37] <twice2> synpatic, but it doesn't show any emc packages
[23:46:56] <twice2> thanks man, i'm jazzed
[23:51:28] <CIA-8> 03flo-h 07v2_1_branch * 10emc2/src/po/de.po: updated translation for EMC2.1
[23:58:43] <CIA-8> 03flo-h 07v2_1_branch * 10emc2/src/po/de.msg: updated for EMC2.1
