#emc | Logs for 2007-11-15

[00:18:58] <alex_joni> skinnypuppy34: not yet
[00:43:17] <LawrenceG> alex_joni: looks nice... refers to linuxcnc gcode page, so code should work with emc... too bad its windows :{
[02:15:33] <toastydeath> bo jangles
[02:39:48] <jlmjvm> jepler:was the homing routine changed in 2.2.1?
[02:43:53] <jlmjvm> used to be able to watch the axis gui during homing,it would feed at search vel,hit switch,rev and feed off at latch vel,then rapid to home offset
[02:45:55] <jlmjvm> now it just instantly moves back to origin on the axis gui before you can trigger the switch
[02:46:39] <jlmjvm> even tried my old Xswitches in the custom.hal,but no difference
[02:55:25] <jepler> jlmjvm: if you mean homing doesn't work in your stepconf-generated file, you've probably hit another stepconf bug. there were intentional changes in the homing sequence (http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?UPDATING#Homing_changes) but they won't affect many users and I don't think they'd cause the behavior you're seeing.
[02:56:09] <jlmjvm> i was just reading that,i dont think thats it either
[02:56:35] <jlmjvm> almost looks like the simulator gui homing out
[02:56:46] <jepler> I'll see if I can spot any obvious problems tomorrow .. but I don't have a stepper machine with home switches to actually test on :-P
[02:59:42] <jlmjvm> k,ill just ghost this configuration,and reload 2.1.7 for now,was going to install this in a machine tomorrow
[03:00:51] <jlmjvm> before even with no machine hooked up the gui moved at the search speed,now it just instantly moves like your running the stepper sim
[03:04:18] <tomp2> gEDA netlist to .hal using python http://pastebin.ca/774221
[03:39:04] <stustev> what's going on tonite?
[03:40:30] <stustev> seems mighty quiet
[03:42:17] <jepler> jlmjvm: just copy your old config to the machine with 2.2, then do the few small tweaks to get it working just like in 2.1.7!
[03:43:00] <jepler> (excuse my shouting)
[03:43:36] <stustev> good evening Jeff - thank you for the work on the latest release - it looks GOOD!
[03:44:22] <jepler> stustev: thanks, I'm glad it's working for someone :-P
[03:44:40] <jepler> jlmjvm has been trying out stepconf, but unfortunately it's turning up a lot of bugs ..
[03:45:11] <jlmjvm> thats what i was in the process of doing,was wondering if it would work like that
[03:45:15] <stustev> I haven't tried any stepper configs, only servo
[03:45:46] <jepler> old stepper configs are 99% compatible, but stepconf generates a completely new configuration file from scratch..
[03:45:46] <stustev> I wish I was at a point I could help you with it. I am not there yet.
[03:47:34] <jlmjvm> fixing to put my old config in and give it a whirl
[03:48:29] <stustev> I will be in and out of here. If I don't answer right away I'll be back
[03:48:36] <jepler> I'm done for the night
[03:48:45] <jepler> I promise to look into the stepconf homing thing tomorrow
[03:53:17] <jlmjvm> dude,that appears to be working
[03:53:47] <jlmjvm> im so glad i saved that config
[03:55:47] <jlmjvm> thanks again
[04:43:47] <cradek> stustev: did you see the kins I stuck in the 5axis sample config?
[04:45:35] <stustev> when did you stick it in there?
[04:45:54] <cradek> earlier today I think
[04:46:10] <stustev> I will update and look
[04:46:11] <stustev> bbl
[05:04:38] <stustev> cradek: absolutely perfect WOW
[05:05:28] <stustev> It took me so long because I had changed the JOINT0 and JOINT1 in the 5axisgui.py and in the bin directory
[05:05:43] <stustev> The motion looked funny until I changed them back
[05:06:16] <cradek> like you kept saying, the kins are very simple
[05:06:31] <cradek> changing tool length doesn't work yet of course
[05:06:31] <stustev> does this do 5 axis tool length compensation?
[05:06:35] <cradek> nope
[05:06:48] <cradek> the kins don't (currently) have access to the tool length.
[05:07:07] <stustev> the kins are very simple but I can't read the C/C++ code very well
[05:07:11] <cradek> also, there's a problem with what happens when you change lengths. I need to think about it some more.
[05:08:17] <cradek> yeah I bet not being familiar with the language is a big stumbling block even though you know full well what you want it to do
[05:08:25] <stustev> sometimes the operator/programmer will change the length to blend two cuts. the tool length will change a very small amount
[05:09:11] <stustev> yeah - I imagine it is something like being paralyzed. You know what you want to say or do but you cannot move
[05:09:18] <stustev> or speak
[05:09:32] <cradek> yikes
[05:09:56] <stustev> that's how I feel when I enter this arena
[05:10:26] <stustev> How much work is it to allow the kins access to the tool length?
[05:10:44] <cradek> I'm not sure
[05:11:20] <stustev> did you see my post about EMC waiting for the gui file to get ready?
[05:11:23] <cradek> I think I could finish tool comp in a hacked up emc tree, but for getting it cleanly into the distribution I'm not so sure what it would take.
[05:11:51] <cradek> I think alex answered that question - maybe it's something about the call to hal_ready()
[05:12:22] <stustev> On another note - the machine looks EXACTLY like a machine would look when built in vericut
[05:12:59] <stustev> Is there any way to import STL files into the python script?
[05:13:11] <stustev> My requests just don't stop do they?
[05:13:32] <stustev> bbl
[05:13:36] <cradek> stl files (at least the ascii type) are pretty easy to read. it could be done.
[05:14:09] <cradek> but, it would only be for dog-and-pony, so I'm not too interested in that
[05:18:58] <stustev> I agree - what there is now is more than sufficient to allow someone to check how the machine moves
[05:22:21] <stustev> thank you, thank you, thank you - I will study the kins file to learn what I can
[05:23:27] <cradek> you're welcome -- the key was understanding what was supposed to happen - thanks for helping with that.
[05:24:24] <stustev> now how do I pass information from the ini file into the kins? this would allow the geometric compensation
[05:25:21] <cradek> your kins module could have hal parameters and pins. you would probably have to use that.
[05:25:37] <cradek> the hal file could set them with values from the ini if that's where you want to put them.
[05:26:25] <cradek> ack, it's late again, goodnight
[05:27:03] <stustev> give me an example of how to do it - good night and thanks again
[07:56:06] <Jymmm> SWPadnos: Ping
[07:58:25] <alex_jon1> pong
[08:06:04] <Jymmm> forgot your name huh?
[08:06:15] <alex_jon1> alex_jon1 is now known as alex_joni
[08:06:19] <alex_joni> better now?
[08:06:42] <Jymmm> I was referring to your pong
[08:07:19] <alex_joni> yeah, well.. you should know better :)
[08:07:23] <alex_joni> he's long asleep
[08:07:36] <Jymmm> bum
[08:09:03] <Jymmm> oh man.... working on my LCPI cert, had to take a break from CCNA, was kicking my butt.
[11:36:09] <SZTAKI> hi
[11:36:37] <SZTAKI> I need help
[11:47:01] <alex_joni> hi SZTAKI
[11:49:07] <alex_joni> SZTAKI: es mi a baj ?
[11:49:21] <SZTAKI> do u know if it's possible to use a new HAL (the "comp") tool for creating new components under EMC 2.0.1
[11:49:33] <alex_joni> 2.0.1 ??
[11:49:37] <SZTAKI> aha
[11:49:37] <alex_joni> that is quite old
[11:49:46] <alex_joni> any reason not to upgrade?
[11:50:15] <SZTAKI> working fine :)
[11:50:59] <alex_joni> I don't see comp in emc 2.0.1
[11:51:09] <SZTAKI> I know
[11:51:36] <SZTAKI> which ver. uses comp?
[11:52:07] <alex_joni> it was in 2.1.0 already
[11:52:28] <alex_joni> http://cvs.linuxcnc.org/cvs/emc2/src/hal/utils/comp.g?graph=1
[11:52:36] <SZTAKI> thx
[11:53:05] <SZTAKI> any idea to get support for robot arm components?
[11:53:24] <alex_joni> for 2.0.1 you would have to install emc2 from source (run-in-place), then compile the component
[11:53:27] <alex_joni> and install it manually
[11:53:34] <alex_joni> what kind of components?
[11:53:58] <SZTAKI> direct and inverse kinematics
[11:55:20] <alex_joni> what kind of support?
[11:55:58] <alex_joni> SZTAKI: would it be easier if we do this in magyar? (I have a collegue nearby who speaks hungarian)
[11:56:03] <SZTAKI> source and description
[11:56:25] <SZTAKI> ok
[11:57:56] <SZTAKI> inverz és direkt geometriai feladat megoldását szolgáló HAL komponensek kellenének
[12:01:33] <kjdro> hello all
[12:01:39] <alex_joni> 13:55 < SZTAKI> inverz és direkt geometriai feladat megoldását szolgáló HAL
[12:01:39] <alex_joni> komponensek kellenének
[12:02:24] <alex_joni> SZTAKI: in emc2.1.x there's kins for a puma typed robot
[12:02:44] <SZTAKI> az nem jó
[12:03:04] <alex_joni> why?
[12:03:10] <SZTAKI> de, mégis jó
[12:03:55] <SZTAKI> tehát, ha fölteszem a 2.1.x-et, akkor tartalmazza a komponenseket?
[12:04:11] <SZTAKI> +az
[12:04:14] <alex_joni> yup
[12:04:21] <SZTAKI> köszi
[12:04:25] <alex_joni> but.. the puma typed kins are not for a generic RRRRRR
[12:04:41] <alex_joni> if you need a generic RRRRRR robot, then maybe different kins is what you need
[12:04:59] <SZTAKI> we need 5 R
[12:05:04] <SZTAKI> RRRRR
[12:05:23] <alex_joni> SZTAKI: here's the theory for a puma 560: http://www.bridgeport.edu/sed/risc/html/proj/damir/theory.html
[12:05:57] <alex_joni> the code is in emc2: http://cvs.linuxcnc.org/cvs/emc2/src/emc/kinematics/pumakins.c?graph=1
[12:06:10] <alex_joni> (sorry.. I think I was wrong, it's only in emc2.2.x)
[12:06:17] <SZTAKI> ok
[12:07:00] <alex_joni> if you install emc2.1 or emc2.2
[12:08:15] <alex_joni> you might need to update your configuration
[12:08:26] <alex_joni> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?UPDATING <- information for updating the docs
[12:08:49] <SZTAKI> thx!
[12:10:25] <alex_joni> SZTAKI: if you need further info, I'll be around
[12:11:28] <SZTAKI> 1 more question
[12:12:08] <SZTAKI> EMC 2.2.1 still works with Debian Linux 2.6.15 + RTAI
[12:12:09] <SZTAKI> ?
[12:12:47] <alex_joni> yes
[12:13:45] <SZTAKI> thx
[12:14:03] <alex_joni> yw
[12:16:41] <SZTAKI> bye
[12:54:07] <jlmjvm> alex_joni:im having some homing difficulties with the stepconf generated file in 2.2.1
[12:55:04] <alex_joni> jlmjvm: what kind?
[12:55:09] <alex_joni> * alex_joni can try to help...
[12:56:21] <jlmjvm> it doesnt move at the search vel like it did in 2.1.7,just seems to instantly rapid to origin
[12:56:40] <jlmjvm> on the gui,not hooked to actual machine yet
[12:57:20] <jlmjvm> btw,the charge pump works in 2.2
[12:58:48] <jlmjvm> do you need me to pastebin my file?
[13:02:51] <alex_joni> what did you set up?
[13:03:18] <jlmjvm> ?
[13:04:48] <alex_joni> there are quite a number of different homing types
[13:05:07] <jlmjvm> let me paste my file
[13:08:23] <jlmjvm> http://pastebin.ca/774956
[13:13:31] <alex_joni> yup, there is no homing type set up
[13:14:14] <jlmjvm> oh really,thats how it worked in 2.1.7
[13:14:24] <jlmjvm> where do you set it up at?
[13:18:41] <alex_joni> you need to edit the ini I think, I don't think stepconf supports different homing types
[13:18:48] <alex_joni> http://www.linuxcnc.org/docview/html//config_ini_homing.html
[13:25:02] <jlmjvm> im using homing type 1 in my ini i thought
[13:25:43] <jlmjvm> these are the same numbers i used in 2.1.7 that work
[13:31:56] <alex_joni> jlmjvm: as I said, I don't think stepconf knows about Homing types, so you would have to do it like you did for 2.1.7
[13:32:12] <alex_joni> stepconf is intended for close to trivial setups, for inexperienced users
[13:32:48] <alex_joni> hmm.. I might be wrong though
[13:33:04] <alex_joni> I see that you can enter Home Search velocity, and Home Latch direction
[13:33:13] <jepler> yes it's "supposed" to handle homing, but I probably have a bug
[13:33:17] <alex_joni> jlmjvm: you'd better wait for jepler
[13:33:29] <alex_joni> jepler: hi jeff
[13:33:34] <jepler> too bad I don't have a stepper machine with limit/home switches
[13:33:45] <alex_joni> I don't see a place where you can enter latch velocity
[13:34:10] <jlmjvm> morning jepler
[13:34:59] <jlmjvm> you can see what im talkin bout without a machine
[13:37:23] <jepler> is the problem simply that stepconf writes SEARCH_VEL = 0.050000
[13:37:27] <jepler> instead of HOME_SEARCH_VEL ?
[13:37:37] <jlmjvm> lemmee see
[13:38:28] <jepler> same for LATCH_VEL
[13:40:12] <jlmjvm> yep same for latch,appears to be working
[13:40:14] <jlmjvm> yahoo
[13:40:28] <jlmjvm> yeah
[13:40:59] <jepler> well that was simpler than I had feared
[13:41:20] <jlmjvm> too cool
[13:41:57] <jepler> great, that'll be another bug fixed in the next version
[13:42:02] <jepler> your help with this has been very valuable.
[13:42:18] <jlmjvm> i was up till 1:30 working on the old config to run in 2.2,got everything but the cp
[13:42:44] <jlmjvm> thanks,was trying not to be a bother
[13:43:33] <jlmjvm> jlmjvm slowly working his way to the beta tester spot,lol
[13:45:33] <jlmjvm> alex and jepler,thanks for the help
[13:45:48] <alex_joni> np
[16:58:08] <alSMT> is there a trick to saving classiladder files?
[16:59:04] <alex_joni> alSMT: what emc2 version?
[16:59:13] <alSMT> 2,21
[16:59:25] <alex_joni> hmm.. it should work just like that
[16:59:33] <alex_joni> any errors you're getting?
[17:00:12] <alSMT> i get output.cpl but only a small file
[17:00:41] <alSMT> save it as a .cpl
[17:00:46] <alex_joni> did you use save? or save as?
[17:00:49] <alSMT> clp
[17:01:06] <alSMT> save as
[17:01:21] <alex_joni> how small is small?
[17:01:33] <alex_joni> I tried the demo_step_cl sample config
[17:01:45] <alex_joni> and I can save as in my home dir, it's about 4kB
[17:02:23] <alSMT> 6.8 kb
[17:03:04] <alex_joni> and when you open it the next time.. it's missing some rungs?
[17:03:13] <alex_joni> or how did you figure out it was too small?
[17:03:27] <alex_joni> (btw, 6.8kB sounds like an ok value)
[17:03:33] <alSMT> no the info is down the page farther
[17:03:56] <alSMT> sorry i'll give it another go
[17:04:08] <alex_joni> np
[18:41:11] <buckie555> I'm experiencing some strange behaviour when placing a limit cmoponent onto the output of a pid component
[18:41:27] <alex_joni> buckie555: go on
[18:41:51] <alex_joni> btw.. pid has a max_output param (or similar name..)
[18:42:04] <buckie555> Yes but I need to be able to change it on the fly
[18:42:10] <buckie555> this is for my atc
[18:42:18] <buckie555> The situation is this
[18:42:53] <buckie555> I need to be able to command movement from within the hal during a toolchange operation to retract up from the toolchange height to give clearance whilst my drum totates
[18:43:22] <buckie555> so to do so I hijack the output from the motion planner and apply an offset into the pid component
[18:43:29] <buckie555> all well and good
[18:43:30] <alex_joni> right
[18:43:42] <alex_joni> you also need to apply the offset to the feedback
[18:43:49] <alex_joni> else you get a ferror
[18:43:53] <buckie555> however since it imparts an abrupt change it causes a violent overshoot
[18:44:03] <buckie555> yes I've also hijacked the feedback
[18:44:12] <alex_joni> ok.. guess you used a mux there
[18:44:21] <buckie555> so I tried using a limit component on the output of the pid
[18:44:31] <buckie555> mux - spot on
[18:44:36] <alex_joni> I'd put the limit before the pid somehow
[18:44:52] <buckie555> and the system appears to become very overdamped
[18:45:39] <alex_joni> I would try this:
[18:45:48] <buckie555> strangely, if I limit the output on the 5i20 dac using it's parameter I get exactly what I'm trying to achieve so I know it must be possible
[18:46:09] <alex_joni> take the motion command pos, and put an add component
[18:46:23] <buckie555> Introducing the limit block has the effect even if I leave the min and max unassigned so it's effectively doing nothing
[18:46:45] <alex_joni> maybe it's causing delay
[18:46:54] <alex_joni> did you add it in the right order in the thread?
[18:47:12] <alex_joni> the addf call I mean
[18:47:22] <buckie555> I believe so. I've got it before anything else
[18:47:41] <alex_joni> if you put the addf at the beginning of the thread it will take the value from the last iteration of pid calcs
[18:48:00] <alex_joni> so the new pid calcs will only command changes in the next thread iteration
[18:48:09] <buckie555> Oh Ok, so it needs to be in the order of the chain
[18:48:27] <alex_joni> seems like an extra cycle to me.. it would lead to 'softness' or 'overdamping' I guess
[18:48:34] <buckie555> that may well explain it as it would alter the pid loop sampling time
[18:49:37] <buckie555> What you were suggesting regarding adding to the ouput of the motion command pos would still intrtoduce a step change I believe
[18:49:55] <alex_joni> buckie555: unless the second component is a wind-up component
[18:50:14] <alex_joni> something that goes from 0 to target with a certain vel
[18:50:21] <buckie555> and then I'd obviously need to add an offset to the feedback from the encoder so the motion planner doesn't think there's a huge following error
[18:50:23] <alex_joni> think RC
[18:50:41] <alex_joni> the same offset goes to both (motion cmd and feedback)
[18:51:15] <buckie555> RC - Is it possible to simulate a ramp with the current component set - I didn't see anything that stood out
[18:51:52] <alex_joni> maybe step signal from a sets or setp, then some filter
[18:52:05] <buckie555> the good news is the whole of the rest of the toolchange logic worked perfectly, it's just the overshooting to the toolchange and tool retract heights that I need to fix
[18:52:09] <alex_joni> or a simple comp that does what you need
[18:53:35] <buckie555> I'm sure I know the answer to this but just to be certain - there isn't a way to change a component's parameter on the fly is there?
[18:53:50] <alex_joni> only using setp
[18:54:14] <alex_joni> jepler wrote a component not long ago, that exports a pin, and setp's a certain parameter based on the pin input
[18:54:14] <buckie555> yes but I can execute a setp based on a logic condition in the hal?
[18:54:27] <alex_joni> it's not quite real-time, but it's close to what you need
[18:54:33] <buckie555> sorry can should have been can't
[18:55:32] <buckie555> so does that mean that I can call a setp if a certain condition exists
[18:55:59] <alex_joni> hang on, trying to find that component
[18:57:22] <alex_joni> btw.. there's a component called offset
[18:57:43] <alex_joni> which adds an offset to a value, and substracts the same one from a feedback
[18:57:52] <alex_joni> just what you need for offseting the motion command
[18:58:42] <buckie555> just seen it - yes that would be cleaner than the mux2
[18:58:58] <buckie555> so now it's just being able to limit the step change
[18:59:52] <jepler> I may have missed it in the scrollbac, but did you consider limit3 to turn the step change in position into a trapezoidal-velocity-profile movement?
[19:00:39] <alex_joni> sounds like what I was looking for..
[19:00:50] <buckie555> ah that might work and just switch it in and out as required
[19:00:55] <alex_joni> buckie555: use offset for the adding/sutracting
[19:01:03] <alex_joni> on the step you put a limit3
[19:01:12] <alex_joni> and the output from offset goes to pid
[19:01:24] <jepler> this is the parameter-setting component that alex_joni alluded to earlier, but I don't know that it is applicable to the task you face: http://emergent.unpy.net/files/sandbox/paramsetter
[19:01:24] <alex_joni> jepler: what was the pin <-> param thingie again?
[19:01:55] <alex_joni> jepler: ok, thanks
[19:02:42] <buckie555> well with that i could just limit the 5i20 dacs output during toolchanging
[19:03:27] <buckie555> but I think the cleaner solution would be the limit3
[19:03:50] <buckie555> I appreciate the ideas guys - it gives me a lot more options to try
[19:04:32] <buckie555> I was gradually backing stuff out and when it still oscillated with the limit in place but no values set I was really scratching my head
[19:05:13] <buckie555> actually I also saw some other strange behaviour which I think is unconnected:
[19:05:39] <buckie555> FYI I'd just upgraded from 2.1.7 to 2.2.1 on this machine - I've never seen this before on 2.1.7
[19:05:50] <buckie555> Homing on my x and y works as expected.
[19:06:13] <buckie555> On my z homing sometimes works ok but sometimes goes a little crazy.
[19:06:41] <buckie555> I'm set up to home off the limit switch and then back off until it sees the encoder pulse
[19:08:01] <buckie555> What appears to happen is sometimes it sees the limit, backs off and sees the index pulse then a fraction of a second later the axis jumps past the limit. I end up having to use a manual override to bring it back up but it hasn't lost the home position
[19:08:54] <buckie555> I noticed some chat in the latest release about the necessity for limit switch to stay switched past the contact point until it baks off and the index pulse is seen.
[19:09:10] <buckie555> I'm wondering whether I've got a dirty switch
[19:09:58] <jepler> I *think* the limit switch only has to stay closed until the axis can decelerate after hitting it at HOME_SEARCH_VEL, but I'm not sure
[19:11:35] <jepler> if you can capture it in halscope, a graph with motor-pos-cmd, motor-pos-fb, home-sw-in and index-enable might help shed light on just what is happening
[19:11:49] <jepler> maybe make halscope trigger on the rising edge of index-enable or the falling edge of home-sw-in?
[19:11:58] <jepler> do you home to an index pulse on all axes?
[19:12:42] <alex_joni> it might be that on this axis the index pulse happens slightly later while travelling towards the switch
[19:13:04] <alex_joni> buckie555: I'd check couplings & co, if they are really tightened
[19:13:31] <alex_joni> maybe it slipped lately, and now it's slightly further away than it was while you used 2.1.7
[19:13:52] <jepler> alex_joni: I'm not sure how that leads to this kind of behavior, though
[19:15:07] <alex_joni> maybe the index pulse comes very late on the switch, close before it travels behind the switch
[19:16:02] <alSMT> http://pastebin.com/m43d0a0da could someone load this into classicladder and tell me if this logic is not going to work for me
[19:18:27] <alex_joni> alSMT: can you describe in words what you are trying to do?
[19:18:55] <jepler> LOAD /net/filesrv1/sd3a/users/jepler/Desktop/m43d0a0da.txt -3
[19:19:06] <jepler> I don't know if it's because of pastebin.com's handling of the file, but it doesn't load in my classicladder
[19:19:14] <alex_joni> jepler: it loads here
[19:19:19] <alSMT> spindle rev run a timer for 1 sec before rev
[19:19:42] <alex_joni> alSMT: can you tell what each input/output is?
[19:19:48] <alex_joni> I only get B0, B1, etc
[19:19:54] <jepler> hmph, it loads when I give it a .clp extension
[19:19:56] <alex_joni> because I don't have your hal connections
[19:20:02] <alex_joni> jepler: yup.. same here
[19:20:44] <alSMT> I0 spindle brake I1 sp fwd I2 sp rev Q0 brake out Q1 fwd Q2 rev
[19:22:11] <alSMT> the pins apear linked from halshow but I get now output
[19:22:33] <alex_joni> did you push run on classicladder?
[19:23:15] <alSMT> I did but didn't seem to do anything
[19:23:36] <alSMT> what does run do?
[19:23:46] <alex_joni> starts the ladder
[19:24:02] <alex_joni> if you don't get blue lines it means it's not doing anything
[19:24:09] <jepler> also, do you have the classicladder_rt component loaded and its function added to a thread with 'addf'?
[19:24:52] <alSMT> yes I beleive so
[19:25:04] <alex_joni> I only get Q0 out
[19:25:23] <alSMT> thats what I got
[19:25:39] <alex_joni> something is fishy in the logic..
[19:26:15] <alex_joni> alSMT: maybe you can tell me what you wanted to do (with B0..B5)
[19:27:18] <alSMT> I'm using the timer r output to engage brake for 1 sec and the spindle fwd outputtimer d
[19:27:28] <alex_joni> I think you got D and R backwards
[19:27:58] <alSMT> that would be to easy
[19:28:10] <alex_joni> when I activate I1, it turns B2 on for 1 second, then turns B1 on
[19:28:19] <alex_joni> B1 commands the brake.. and it stays like that
[19:32:21] <buckie555> sorry, had to dissappear for a few minutes - regarding the suggestions for the strange limit switch behaviour I'll endeavour to capture a halscope trace and go from there
[19:33:02] <alex_joni> alSMT: also the %B5 seems backward
[19:33:16] <alex_joni> I put a -| |- there and it seems to work ok now
[19:33:36] <alex_joni> alSMT: on %B2 --- %b5 --- %Q1
[19:33:48] <alex_joni> and %B4 --- %B5 --- %Q2
[19:34:31] <alSMT> n open
[19:34:35] <alex_joni> yes
[19:34:52] <alSMT> i'm editing now
[19:35:40] <alSMT> did you mean the contact or the coil?
[19:36:22] <alex_joni> remind me which one is which :D
[19:36:30] <alex_joni> I mean the one in the middle of the 2 lines
[19:37:01] <alSMT> ok
[19:39:11] <Hugomatic> Hi guys. I'm torn between using gcode with loops (o words) and writing python programs that 'print' gcode. I'd like to know if those o words are specific to emc or if they are supported by all gcode machines?
[19:39:34] <alex_joni> Hugomatic: there are similar codes for all kind of machines
[19:39:35] <cradek> virtually no gcode is supported by all gcode machines
[19:39:52] <alex_joni> but the O-codes you saw described in the EMC manual are specific for EMC
[19:39:53] <cradek> all machines are different except perhaps G0 and G1
[19:39:54] <jepler> python. hands down.
[19:40:07] <alex_joni> I hardly think there are other machines that would understand them
[19:40:29] <cradek> I take that back. some machines do G0 differently.
[19:40:58] <Hugomatic> thanks guys... I'm going to stick with python generators for now. :-)
[19:41:26] <cradek> G1 is pretty universal!
[19:41:29] <alex_joni> Hugomatic: anything usefull for the big crowd?
[19:43:53] <Hugomatic> Well, I have this simple class that holds values (a gloryfied dictionary). It displays the UI when you load the python program, and it supplies the values for my templates. It can theoretically also parse cmd line arguments (instead of showing the UI).
[19:46:35] <Hugomatic> When I 'play' a python file in EMC, every gcode print line correspond to a program state. I'd like to be able to see the program state when the user clicks on a 3D line.
[19:47:41] <alex_joni> if you click on a 3D line it highlights the appropiate g-code line
[19:47:50] <alex_joni> so maybe adding a comment to that line helps?
[19:48:41] <Hugomatic> I'd like the entire stack trace and program state (lots of info)... the comment could point to that info in a separate file.
[19:49:21] <Hugomatic> Or I can simply launch a debugger that will halt when that same line number is written...
[19:51:47] <alSMT> Alex_joni: thanks its a go , maybe someone would post a link to Mark's http://membres.lycos.fr/mavati/classicladder/ from the emc's doc's there is some timer info that I found and he has the R on top and D on the bottom didn't realy notice it myself ,Thanks again
[19:52:19] <alex_joni> alSMT: I thought we have a link to classicladder
[19:52:29] <Hugomatic> Outputting o words added considerable problems to my scheme. I'll let you know if I think anything useful comes out of this. Thanks for the info.
[19:53:32] <alex_joni> alSMT: not in the html/pdf docs, I'll fix that.. thanks for reporting
[19:54:09] <jepler> why would you necessarily output o-words?
[19:54:14] <alSMT> ok I was looking
[19:54:27] <jepler> you can just skip the use of any feature of emc's gcode that you find troublesome or don't find useful...
[19:55:44] <Hugomatic> jepler: My Sherline mill is weak, so I often have to cut the same pattern in layers. Switching from plastic to alu, I need to change the cut and feed, and I don't want to change the code in more than one place.
[19:56:17] <Hugomatic> o words seemed like the 'proper' way to do this
[19:56:24] <jepler> while no more portable than O-words, you can just use #-parameters to do this.
[19:56:31] <jepler> e.g., #1=13 (feed rate for plunges)
[19:56:35] <jepler> at the top of the file, then
[19:56:46] <jepler> F#1 (set feed rate from parameter)
[19:57:00] <jepler> each time you want to use the plunge feed rate
[19:57:28] <Hugomatic> jepler: sure, but I still need some for or while loop to do each pass, don't I?
[19:57:38] <jepler> if you're cutting down in multiple passes, and the depth-per-pass changes, then yes you can't do that with a simple parameter
[19:57:52] <Hugomatic> thanks
[19:58:05] <jepler> but if you're generating it with a python program, you can output the right number of passes depending on what is entered in the gui, and still skip the O-words..
[19:59:49] <Hugomatic> Exactly. and my output is simpler (one line for one 3D segment)... I just need easy debugging of the initial python from the 3D view.
[20:07:07] <alex_joni> * alex_joni goes to bed
[20:07:10] <alex_joni> good night all
[20:07:13] <jepler> see you alex_joni
[20:10:05] <Hugomatic> I noticed there's a "show distance to go" but no "show total time". Is there a problem computing the time to execute a program (at 100% feed override)
[20:10:26] <jepler> "distance to go" only applies to the current primitive movement anyway
[20:10:42] <jepler> there is an estimate of program time in File > Properties but the quality of the estimate is not great
[20:10:52] <Hugomatic> great nes, thanks
[20:23:06] <jepler> (the time estimate doesn't account for the machine having velocity and acceleration limits)
[20:24:03] <JymmmEMC> SWPadnos: ping
[20:54:37] <skunkworks> barum: Hi :)
[22:09:41] <jlmjvm> jepler:everything was looking good in the machine today!
[22:10:58] <jlmjvm> whats this about msi motherboards and latency i keep seeing in the users group?
[22:12:10] <jlmjvm> the last 2 mills i did had msi motherboards,one with a usc,one a campbell breakout board
[22:20:51] <skunkworks> jlmjvm: what user group?
[22:22:31] <jlmjvm> the emc-users that i get in my email
[22:24:38] <skunkworks> ah
[22:24:39] <skunkworks> ok
[22:28:03] <jlmjvm> ive had no problems at all with the 2 msi boards ive used,both were new,1 socket 754,1 socket am2,both had via chipset and agp slot
[22:31:04] <jlmjvm> however my asrock socket 754 board has latency issues,it has nvidia chipset
[22:32:00] <jlmjvm> when its normal i get about 4000,when abnormal 145000
[22:33:43] <jlmjvm> the am2 msi board with the slowest sempron you could get was getting 10000