Back
[00:02:35] <jmkasunich> if you need to run another port, or two ports, before I figure it out, edit line 67 of hal_ppmc.c and run make
[00:02:45] <jmkasunich> right now it says { 0x0378, 0, 0}
[00:03:07] <jmkasunich> if you want ports at 0xbf00 and 0x278, do { 0xbf00, 0x0278, 0 }
[00:03:13] <jmkasunich> you can do up to three ports
[00:03:14] <rayh> okay. will do.
[00:03:31] <jmkasunich> dinner time
[00:03:32] <rayh> Got it.
[00:03:45] <rayh> Gotta find another good db25 cable.
[00:04:19] <jmkasunich> ha, figured it out
[00:04:50] <jmkasunich> sudo bin/halcmd loadrt hal_ppmc port_addr=0xbf00,0x278
[00:05:03] <jmkasunich> you can enter 1 to three values, comma separated
[00:05:07] <jmkasunich> and it does understand hex
[00:05:20] <jmkasunich> * jmkasunich eats chili
[01:02:57] <rayh> okay jmkasunich I'm seeing the pins of both boards at the same time
[01:04:02] <rayh> rayh is now known as rayh-away
[01:04:48] <jmkasunich> good!
[01:05:06] <jmkasunich> thanks for that test
[01:10:42] <Jacky^> G night guys
[01:10:49] <jmkasunich> night
[01:10:53] <Jacky^> Jacky^ is now known as Jacky^afk
[01:31:00] <CIA-5> 03jmkasunich * 10emc2/src/hal/components/stepgen.c:
[01:31:00] <CIA-5> Updated comments inside stepgen.c to document the change from cfg=<string> to
[01:31:00] <CIA-5> step_type=num[,num] for selecting step types. Note: the actual change to the
[01:31:00] <CIA-5> code was by yabo sukz, and is a significant improvement, thanks yabo
[01:36:21] <CIA-5> 03jmkasunich * 10emc2/src/hal/components/freqgen.c: Applied the 'step_type=num[,num]' method of configuration to freqgen. It was originally applied to stepgen by yabo sukz, since stepgen and freqgen are very similar they should be configured the same way.
[01:37:30] <CIA-5> 03jmkasunich * 10emc2/scripts/hal_demo: modified hal_demo to use the new freqgen configuration method
[01:38:37] <jmkasunich> been meaning to do that for a while
[01:38:55] <cradek> does this get rid of the problematic ="1 1 1" thing?
[01:39:06] <jmkasunich> yes, at least for stepgen and freqgen
[01:39:16] <jmkasunich> parport still uses a string method
[01:39:21] <cradek> cool; those quotes are a curse
[01:39:28] <jmkasunich> cfg="0x378 in 0x278 out"
[01:39:50] <jmkasunich> that one probably could be changed to use two arrays, one for port addr, and another for dir
[01:40:03] <cradek> in=0x378n;out=0x278
[01:40:07] <jmkasunich> port_addr=0x378,0x278 port_dir=i,o
[01:40:10] <cradek> or ,
[01:40:26] <cradek> grr
[01:40:31] <cradek> in=0x378,out=0x278
[01:40:36] <cradek> there, I typed it right
[01:40:42] <jmkasunich> not yet ;-)
[01:40:58] <cradek> well I give up then
[01:41:03] <jmkasunich> in=0x0378 out=0x278,0bf00
[01:41:20] <cradek> I think you have to avoid the space
[01:41:27] <jmkasunich> the syntax is varname=value[,morevalues]
[01:41:36] <jmkasunich> in and out are two separate vars buth arrays
[01:41:36] <cradek> oh, ok
[01:41:40] <cradek> (I know nothing about this)
[01:41:43] <jmkasunich> both arrays
[01:41:51] <jmkasunich> MODULE_PARM
[01:41:58] <jmkasunich> part of the kernel
[01:42:12] <jmkasunich> I didn't know that MODULE_PARM could handle arrays until yabo's changes
[01:42:26] <cradek> he seems smart
[01:42:31] <cradek> I hope he comes back to talk to you tomorrow
[01:42:43] <cradek> I told him you were the guy to talk to!
[01:42:51] <jmkasunich> I saw that in the log
[01:43:04] <cradek> (he only stayed for a minute)
[01:43:12] <jmkasunich> ;-)
[01:43:18] <rayh-away> rayh-away is now known as rayh
[01:43:46] <jmkasunich> hey ray!
[01:45:53] <rayh> Was I given to understand that you could loop a single parport to more than one PPMC?
[01:46:05] <jmkasunich> in theory
[01:46:23] <jmkasunich> you need to set the dip switches on the board so the two boards have different addys
[01:46:36] <rayh> Right.
[01:46:54] <jmkasunich> and there might be electrical issues, if the cable between the two boards is long there might be ringing or noise on the signals
[01:47:18] <jmkasunich> the "bus" concept was oritinally applied to the PPMC boardset, where the "cable" was actually a backplane
[01:47:31] <rayh> Yes and a kludged wye would sure cause trouble.
[01:48:06] <rayh> JonE has my set of ppmc cards right now. When they get back I'll test.
[01:48:08] <jmkasunich> my USC has a P9, 26 pin (2x13) header that looks like it is connected to the parport conn
[01:48:21] <anonimasu> evening
[01:48:37] <jmkasunich> I suspect that a pair of stacked USC boards could be connected using P9
[01:48:53] <rayh> Right. neither of mine are populated.
[01:49:11] <jmkasunich> he sent me a schematic, but P9 doesn't appear on it, so I'm not sure it is connected to the parport
[01:49:27] <jmkasunich> wouldn't take to long to trace it out though
[01:49:41] <cradek> sounds like you need some db25 idp connectors and ribbon cable
[01:49:47] <rayh> eh someday maybe.
[01:49:48] <cradek> if they just hook up "in parallel"
[01:49:49] <jmkasunich> that would work too
[01:51:09] <jmkasunich> I think Jon told me he designed them to be able to work that way, but I'm not sure he ever test them that way
[01:55:11] <rayh> Jon set up some standard io, I presume that we can set this up as we please using HAL and CL?
[01:55:28] <jmkasunich> except for dig in 15 and dig out 7
[01:55:38] <jmkasunich> he has some screwy estop logic on those
[01:55:56] <jmkasunich> unless dig in 15 is energized, none of the outputs will come on
[01:56:10] <jmkasunich> unless dig out 7 is commanded on, none of the output will come on
[01:56:31] <jmkasunich> and dig in 15 will always read OFF unless dig out 7 is commanded on
[01:56:59] <SWP_Away> SWP_Away is now known as SWPadnos_
[01:59:51] <rayh> Okay. I'll keep that arrangement in mind.
[02:00:26] <jmkasunich> he also indicated to me that the estop logic for two boards on the same cable is cross-connected
[02:00:31] <SWPadnos_> by the way - in case you didn't notice, the step / PWM outputs also remain off when output 7 isn't on
[02:00:48] <jmkasunich> I dunno if that means both din15 need to be on before any dout can be on, but I suspect so
[02:01:09] <jmkasunich> SWP: haven't gotten that far yet, but thanks for the warning
[02:01:39] <SWPadnos_> hm - that 's a tough one - the out7 -> in15 is an estop interlock. I'm not sure how much of a window there is for turning on multiple out7's
[02:02:44] <jmkasunich> can always drive in15 with your physical estop chain, so it is on whenever the buttons aren't pressed
[02:02:55] <jmkasunich> then run out7 to your main power contactor or whatever
[02:03:06] <SWPadnos_> true
[02:03:25] <jmkasunich> I don't think he intended out7 to be wired back to in15
[02:03:52] <SWPadnos_> actually, I'm not sure - when he sent mine, he put a jumper in between SSR7 out and in15
[02:04:02] <SWPadnos_> I believe it is meant to be wired together
[02:04:27] <jmkasunich> hmmm
[02:05:09] <jmkasunich> * jmkasunich isn't gonna use it that way ;-)
[02:05:24] <jmkasunich> (I wonder if he did that to get some kind of latching?)
[02:05:28] <SWPadnos_> you may have no choice ;)
[02:05:48] <SWPadnos_> I'm realizing that pins 14 and 15 are both involved with estop
[02:05:51] <jmkasunich> I have 15 tied active here, and everything else works
[02:05:59] <jmkasunich> 14? how?
[02:06:20] <SWPadnos_> ok - it may just be that the outputs will be disabled unless both the input and enable are on
[02:06:25] <SWPadnos_> pin 14, not input 14
[02:06:42] <SWPadnos_> I'm looking at the sample wiring pdf file
[02:07:18] <jmkasunich> well that probably assumes emc1 software, so you might be seeing emc logic, rather than hardwired logic
[02:07:25] <SWPadnos_> could well be
[02:07:31] <jmkasunich> the behavior I described with 15 and 7 is hardware
[02:07:37] <SWPadnos_> I should look at the actual board, I guess ;)
[02:07:42] <SWPadnos_> yep
[02:07:52] <jmkasunich> with that handy new driver ;-)
[02:07:58] <SWPadnos_> indeed
[02:08:11] <jmkasunich> gotta focus on digio right now, thats all that works....
[02:08:14] <SWPadnos_> Do you have plans for the 8-pin connector (P8, I think - the spindle output)?
[02:08:42] <jmkasunich> not yet, but we could extent the driver to make that an aux out, say a hal_u8 pin
[02:08:48] <SWPadnos_> I was thinking of writing the pulse speed / PWM duty cycle calculation functions
[02:09:15] <jmkasunich> any help on the driver would be muchly appreciated
[02:09:16] <SWPadnos_> yeah - I'd make it byte - if people want bits, they can split it with another component
[02:09:29] <SWPadnos_> OK - I was going to change the way the ini parameters work
[02:09:40] <SWPadnos_> since there's nobody who knows how they work now
[02:09:42] <jmkasunich> I'm putting in that inb/outb caching arrangement we discussed, gonna commit that then move on to encoders
[02:09:47] <jmkasunich> which ones?
[02:09:49] <SWPadnos_> ok - cool
[02:10:33] <jmkasunich> that reminds me, gotta call Jon and ask him something...
[02:10:43] <SWPadnos_> the relationship between pulses / sec and "max output" is kinda gray
[02:11:13] <jmkasunich> I was thinking about making the scaling of the HAL pin be Hz
[02:11:28] <SWPadnos_> itshould probably be calculated from MAX_VELOCITY and OUTPUT_SCALE for each axis
[02:11:38] <jmkasunich> or make it like freqgen, with user configurable scaling from a float
[02:12:09] <rayh> This should run in servo thread rather than base??
[02:12:13] <jmkasunich> right
[02:12:23] <SWPadnos_> sort of - I would like a number that is the highest step frequency allowed
[02:12:26] <rayh> thanks
[02:12:27] <jmkasunich> base is only needed when you are making step pulses in SW, or counting encoder in SW
[02:12:53] <SWPadnos_> there is still a BASE_PERIOD though, right? (it should just be the same as the servo period)
[02:12:55] <jmkasunich> I wish we had a generic way to do expressions with ini vars
[02:13:05] <SWPadnos_> that would be a valuable addition
[02:13:22] <jmkasunich> [AXIS_0]MAX_VELOCITY*[AXIS_)]OUTPUT_SCALE
[02:13:40] <rayh> I got the same jumpers here.
[02:13:45] <jmkasunich> yeah, there is still a base period
[02:14:07] <jmkasunich> but really, a system with no functs running on that thread could drop the thread completely
[02:14:54] <jmkasunich> maybe I should modify motmod so that if BASE_PERIOD in the ini is zero, it skips creating the base thread
[02:15:04] <SWPadnos_> isn't the SERVO_PERIOD calculated as a multiple of BASE_PERIOD?
[02:15:58] <SWPadnos_> well - how do ini defaults work? I know that for Windows, you provide a default value, and that's what you get back if the item isn't found.
[02:16:10] <SWPadnos_> does base_period default to 0, or something else?
[02:16:17] <jmkasunich> src/emc/motion/motion.c line 917, init_threads()
[02:16:33] <jmkasunich> and MODULE_PARM(base_period), etc, further up in the same file
[02:17:03] <jmkasunich> ha, I already have code to create base only if its faster than servo
[02:17:26] <SWPadnos_> lucky^Hsmart you ;)
[02:17:28] <jmkasunich> damn I'm good ;-P
[02:18:23] <jmkasunich> the defaults are set near the MODULE_PARM macros
[02:18:49] <SWPadnos_> yep - and it is set to 0 - good job
[02:31:22] <jmkasunich> just talked to JonE
[02:31:30] <jmkasunich> P9 is intended for daisychaining
[02:31:43] <jmkasunich> but you can not simply parallel the boards
[02:31:57] <jmkasunich> you run your parport cable to the DB25 on the first board
[02:32:43] <jmkasunich> then you use a 26 pin header - ribbon cable - DB25 pin conn to go from P9 on the first board to the DB25 on the second board
[02:33:16] <SWPadnos_> ah - something like the standard motherboard -> parallel connector cables
[02:33:49] <jmkasunich> apparently the ACK signal isn't tri-state, so ACK from additional boards must be gated with ACK from the first board, and used to drive the cable to the PC
[02:33:55] <jmkasunich> yes
[02:34:16] <jmkasunich> ideally just a little longer than the board, so it can go under the board to the next one
[02:34:37] <SWPadnos_> you can't stack them anyway
[02:34:43] <jmkasunich> he's tested it that way with his diagnostic program, but never had a EMC driver that would to that before
[02:34:43] <SWPadnos_> not too close at any rate
[02:34:46] <jmkasunich> right
[02:39:02] <rayh> I've got 14,15 jumpered to EG. I don't see a true but the green light named estop ok is lit.
[02:39:25] <SWPadnos_> have you set output 7 (8) on?
[02:39:33] <rayh> commanded out7 high but get no red light.
[02:39:52] <SWPadnos_> do you have a resistor or SSR installed?
[02:40:19] <jmkasunich> the LED doesn't work unless there is an SSR or load resistor installed
[02:40:19] <rayh> Yes the pico dc ssr is in there.
[02:40:44] <jmkasunich> read_all and write_all are in a thread, and the thread is running?
[02:41:32] <rayh> uh perhaps that's the problem. would that be hal_ppmc_read_all
[02:42:01] <jmkasunich> do halcmd show threads
[02:42:05] <jmkasunich> then halcmd show functs
[02:42:24] <jmkasunich> under functs should be something like ppmc.0.read_all and ppmc.0.write all
[02:42:33] <jmkasunich> they should also be listed under a thread
[02:42:54] <jmkasunich> if not, do addf ppmc.0.read-all <threadname>
[02:43:08] <jmkasunich> <threadname> would be servo-thread if you are running with EMC
[02:43:15] <rayh> that's what I'm looking for.
[02:43:24] <jmkasunich> I was just testing, so my thread name was different
[02:44:59] <rayh> thanks.
[02:45:09] <SWPadnos_> so - I'm looking at the scaling parameters for motenc and stg, and they seem to be different (in fact, motenc looks like it doesn't make use of the scale parameter at all)
[02:45:35] <jmkasunich> consistency isn't a strong point right now
[02:46:14] <SWPadnos_> I'll take a look at stepgen
[02:46:31] <rayh> HAL: ERROR: function 'ppmc.0.read-all' not found
[02:47:12] <SWPadnos_> what does 'halcmd show funct' tell you?
[02:47:21] <SWPadnos_> functs
[02:47:40] <rayh> tells me it's not running. it's my .hal file that failed.
[02:47:59] <rayh> Yes I know I can start it all manually.
[02:48:00] <jmkasunich> show funct will show you the proper name of the funct
[02:48:10] <jmkasunich> maybe I did read_all instead of read-all...
[02:48:30] <jmkasunich> duh
[02:48:34] <jmkasunich> just plain read
[02:48:37] <jmkasunich> ppmc.0.read
[02:49:04] <jmkasunich> the internal (C) function name is read_all, but that isn't relavent to HAL
[02:49:35] <jmkasunich> so your addf line should say addf ppmc.0.read servo-thread
[02:50:13] <jmkasunich> are you still running two boards on two parports?
[02:50:25] <jmkasunich> if so, you also need to addf ppmc.1.read to read the second port
[02:51:49] <rayh> okay I'll try that
[02:52:33] <rayh> Got em in there now.
[02:52:45] <jmkasunich> and you also have to have the write function(s) installed, to be able to set dout 7
[02:55:01] <rayh> Yes two boards on two ports but just working on the ppmc.0
[02:55:08] <jmkasunich> ok
[02:55:17] <rayh> no red led yet.
[02:55:52] <rayh> 14,15 still show false
[02:56:02] <jmkasunich> 15 will, until you get the red
[02:56:07] <jmkasunich> you have green, right?
[02:56:23] <rayh> right.
[02:56:36] <jmkasunich> on mine, 0 thru 14 would show true at that point if I jumpered them to EG
[02:56:44] <rayh> wait 15 is pulled low with a jumper.
[02:56:58] <jmkasunich> 15 to EG, right?
[02:57:04] <rayh> yes
[02:57:30] <jmkasunich> ok, get another jumper,and go 4 to EG
[02:57:54] <jmkasunich> din.04.in should go true
[02:58:06] <jmkasunich> btw, what is din.04.in-not?
[02:58:26] <jmkasunich> if the in's and the in-not's are both false, that means the read functoion isn't running
[02:59:17] <rayh> it did go true and both read and write are shown in servo-thread
[02:59:35] <jmkasunich> 04 went true?
[02:59:41] <jmkasunich> so inputs are working
[03:00:03] <jmkasunich> problem must be outputs
[03:00:11] <jmkasunich> how are you telling out7 to turn on?
[03:00:15] <jmkasunich> I did this:
[03:00:18] <jmkasunich> newsig test bit
[03:00:38] <jmkasunich> linksp test ppmc.0.dout.07.out
[03:00:44] <jmkasunich> sets test 1
[03:01:08] <SWPadnos_> out of curiosity, have you tried univstepdiags?
[03:02:36] <rayh> no I've not tried it.
[03:02:56] <SWPadnos_> you may want to do that - it may be that your board won't light that LED for some reason
[03:03:04] <rayh> That's what I did only named a bit different.
[03:03:24] <SWPadnos_> I'd use ./univstepdiags diocontinuous
[03:03:47] <SWPadnos_> that'll give you ssr7 on, plus a shifting bit through the other 7 ouputs
[03:06:09] <rayh> how do I get univstepdiags
[03:06:24] <SWPadnos_> I think it's on Jon's site - lemme find a URL
[03:06:37] <SWPadnos_> http://pico-systems.com/codes/univstepdiags.tgz
[03:06:57] <SWPadnos_> instructions here
http://pico-systems.com/codes/univstepdiag.html
[03:07:09] <jmkasunich> that will verify that port and board are OK, narrows things down
[03:07:19] <SWPadnos_> always a good plan
[03:12:09] <SWPadnos_> are you just using hal_demo to load the RT core, then using halcmd for testing
[03:12:10] <SWPadnos_> ?
[03:12:26] <jmkasunich> hal_demo?
[03:12:35] <jmkasunich> I usually use scripts/realtime start
[03:12:39] <SWPadnos_> ah
[03:12:53] <jmkasunich> but ray might be using emc.run
[03:12:55] <SWPadnos_> how do you add or delete threads?
[03:13:05] <jmkasunich> not pretty
[03:13:07] <jmkasunich> can't delete
[03:13:14] <SWPadnos_> ok - just add then :)
[03:13:19] <jmkasunich> add by using the threads component
[03:13:41] <SWPadnos_> hm - I'll havea look at some .hal files
[03:13:42] <jmkasunich> sudo bin/halcmd loadrt threads name1=<threadname> period1=<period>
[03:14:07] <jmkasunich> you can have name2, period2, and name3, period3, so up to three threads at once
[03:14:21] <jmkasunich> once threads are created, the exist until hal shuts down
[03:14:26] <SWPadnos_> ok
[03:14:27] <jmkasunich> so you can remove threads comp
[03:14:32] <jmkasunich> bin/halcmd unloadrt threads
[03:14:38] <jmkasunich> and load it again if you need more
[03:14:48] <SWPadnos_> ok - I was wondering about that
[03:14:49] <jmkasunich> note that threads must be created fastest first
[03:15:05] <SWPadnos_> ok
[03:15:06] <jmkasunich> because fastest is highest priority
[03:15:07] <jmkasunich> I
[03:15:21] <jmkasunich> I'd have to check code to see how strongly that is enforcec
[03:15:31] <jmkasunich> enforced
[03:16:11] <jmkasunich> its in hal_lib.c if you really wanna know
[03:16:20] <SWPadnos_> period in sec, usec, or nsec?
[03:16:21] <jmkasunich> hal_thread_new() or somethign like that
[03:16:23] <jmkasunich> nsec
[03:16:38] <SWPadnos_> on the command line?
[03:16:47] <jmkasunich> yes
[03:16:50] <SWPadnos_> ok - thanks
[03:16:53] <jmkasunich> huh?
[03:17:00] <jmkasunich> what did you mean about the cmd line
[03:17:04] <SWPadnos_> heh
[03:17:27] <jmkasunich> period in nsec is an arg to threads component
[03:17:37] <SWPadnos_> halcmd loadrt threads name1=<threadname> period1=<period in nsec>
[03:17:41] <jmkasunich> hal_thread_new() is the API function in hal_lib.c that implements it
[03:17:44] <jmkasunich> yes
[03:17:46] <SWPadnos_> ok
[03:18:15] <jmkasunich> I want to add a newthread cmd to halcmd
[03:59:05] <dmwaters> {global notice} Hi all! in an hour and 10 minutes, we've got some major upgrades to 3 of our main boxes. If everything goes right, it won't take more then 15 minutes. If things go wrong, well, it could take a little longer.:) 2 main rotation servers, and a hub will be impacted by these upgrades, as well as www.freenode.net and services. I will try to make this as quick as possible. Thank you for your patience, and thank you for using freenode
[04:38:43] <CIA-5> 03paul_c * 10emc2-auto/wiki/ (4 files in 3 dirs): "Auto update wiki from a cron job. Sun Nov 27 05:30:01 GMT 2005 "
[04:40:08] <CIA-5> 03jmkasunich * 10emc2/src/hal/drivers/hal_ppmc.c: revised ppmc driver to do block reads and writes on the EPP port to take full advantage of the auto-increment address function and minimize slow inb and outb operations
[04:41:12] <dmwaters> {global notice} This is a reminder that in about 25 minutes, 3 main servers will be rebooted for upgrades. This will not take long. Thank you for your patience, and thank you for using freenode!
[04:49:41] <dmwaters> {global notice} FYI, those of you who are using join throttling may want to disable it briefly durring the server upgrades in order to avoid people landing in overflow channels durring the upgrades.
[05:06:22] <CIA-5> 03jmkasunich * 10emc2/src/hal/drivers/hal_ppmc.c: need an include to get kmalloc for kernels older than 2.6
[19:32:32] <cradek> HAL:27: ERROR: parameter 'parport.0.pin-01-invert' not found
[19:32:44] <jmkasunich> bin/halcmd show param
[19:32:50] <alex_joni> cradek: bin/halcmd show param
[19:32:52] <jmkasunich> I probably spelled it wrong
[19:33:07] <alex_joni> jmkasunich: don't think so ;)
[19:33:14] <petev> cradek: you will need to add the param settings to you .hal too
[19:33:18] <alex_joni> ahh.. you meant the pin
[19:33:22] <cradek> hmm, can't run emc with an error in the file
[19:33:28] <cradek> can't run halcmd without emc
[19:33:41] <alex_joni> cradek: sudo scripts/realtime start
[19:33:42] <SWPadnos_> it's decimals, not dashes
[19:33:44] <jmkasunich> sudo scripts/realtime start
[19:34:01] <SWPadnos_> ppmc.0.dout.03.invert
[19:34:04] <alex_joni> sudo /sbin/insmod rtlib/parport.ko
[19:34:12] <jmkasunich> then sudo bin/halcmd -f <your hal file>
[19:34:21] <alex_joni> jmkasunich: stop echoing me ;-)
[19:34:29] <jmkasunich> :-P
[19:34:34] <jmkasunich> my way is better
[19:34:43] <alex_joni> how so?
[19:34:56] <jmkasunich> uses his file
[19:34:59] <alex_joni> mine is quicker
[19:35:17] <alex_joni> he can see what params there are, add them to his file, then he only need to rmmod one (parport)
[19:35:20] <alex_joni> then try emc ;)
[19:35:25] <jmkasunich> ok, that works too
[19:35:43] <jmkasunich> yet another way: ;-)
[19:35:49] <jmkasunich> do the reatime start
[19:36:02] <jmkasunich> then sudo bin/halcmd loadrt hal_parport
[19:36:13] <jmkasunich> do the list command
[19:36:24] <jmkasunich> then sudo bin/halcmd unloadrt all
[19:36:36] <jmkasunich> sudo scripts/realtime stop
[19:36:54] <jmkasunich> I like to use loadrt instead of insmod
[19:37:08] <alex_joni> yeah.. it figures out all there's needed
[19:38:49] <cradek> cool, the IO is right now
[19:38:59] <cradek> except when I exited emc2, my choppers did not disable
[19:39:23] <cradek> that seems wrong...
[19:39:36] <cradek> they do disable when I start emc2
[19:40:25] <jmkasunich> they disable when you start the program, right?
[19:40:33] <jmkasunich> enable when you do machine on (F2)?
[19:40:36] <cradek> yes
[19:40:40] <jmkasunich> disable when you do machine off?
[19:40:44] <cradek> yes
[19:40:48] <jmkasunich> remain off if you exit
[19:40:50] <cradek> yes
[19:40:57] <jmkasunich> but if you exit with them on, they stay on...
[19:41:01] <cradek> yes
[19:41:22] <jmkasunich> * jmkasunich probably has to take a look at the run script
[19:41:41] <jmkasunich> you stop emc by killing the GUI
[19:41:46] <cradek> yes
[19:42:06] <jmkasunich> the news from the GUI must reach the motion module, and it must turn off its output, and that must propogate to the parport driver
[19:42:26] <jmkasunich> before the run script gets around to stopping the RT threads with a halcmd stop
[19:42:33] <alex_joni> jmkasunich: how about driving all pins low during unload_module()
[19:42:36] <SWPadnos_> each HAL component can have a cleanup function as well - that can fix things like this in some cases
[19:42:46] <SWPadnos_> low is often "active"
[19:42:51] <petev> true
[19:42:51] <alex_joni> SWPadnos_: each module has
[19:42:58] <jmkasunich> yeah, the modules can't make assumptions
[19:43:08] <SWPadnos_> in this case, they can
[19:43:08] <alex_joni> SWPadnos_: low is how the parport is when you reboot the PC
[19:43:18] <SWPadnos_> not necessarily
[19:43:23] <alex_joni> SWPadnos_: based on invert?
[19:43:30] <SWPadnos_> you could do that
[19:43:48] <alex_joni> I would fancy that.. just have the value of invert in the pins
[19:44:17] <SWPadnos_> with the PPMC, and probably most of the other servo controller cards, there is a bgllobal "enable" signal. it makes sense to turn that off on unlosd
[19:44:19] <jmkasunich> better to have a working system do an orderly shutdown, than to start killing the drivers and have them force their outputs to some state that they (with no knowledge of the overall system) think is best
[19:44:21] <alex_joni> so any inverted pins are on 1, the others on 0
[19:44:35] <jmkasunich> hi paul
[19:45:12] <SWPadnos_> hi there
[19:45:20] <cradek> hello
[19:45:21] <petev> nice alex
[19:45:31] <billie_bunter> billie_bunter is now known as alex_joni
[19:45:33] <alex_joni> lol
[19:45:43] <cradek> snort
[19:46:32] <jmkasunich> well, we done it now...
[19:46:47] <cradek> so now I'm copying over cycle times, maxvel, maxaccels from my old ini
[19:52:06] <cradek> ok, I copied over my numbers, but whenever I try to jog I immediately get a joint following error
[19:52:36] <alex_joni> cradek: very different numbers than stock config?
[19:52:44] <alex_joni> maybe base_period is a bit high?
[19:52:48] <alex_joni> can't keep up?
[19:52:53] <cradek> scales a little higher, accels a little higher, velocities a little lower
[19:53:04] <cradek> it doesn't move even one step
[19:53:15] <alex_joni> that's odd..
[19:53:40] <alex_joni> * alex_joni would think of only one thing..
[19:53:50] <cradek> is OUTPUT_SCALE really supposed to be 1?
[19:53:58] <alex_joni> I think so..
[19:54:07] <jmkasunich> only one scale is used for a stepper config
[19:54:15] <SWPadnos_> is this with a USC board?
[19:54:16] <alex_joni> OUTPUT_SCALE is not used in emc2 afaik
[19:54:22] <cradek> ok
[19:54:25] <SWPadnos_> no - nevermind
[19:54:28] <cradek> no, step/dir on parport only
[19:54:39] <SWPadnos_> (duh - we're still writing the encoder and output parts ;) )
[19:54:41] <alex_joni> cradek: what I would imagine is that the stepgen's aren't enabled
[19:55:02] <alex_joni> maybe the hal file is wrong somehow?
[19:55:02] <jmkasunich> alex: didn't you add those wires to the stock configs?
[19:55:11] <alex_joni> jmkasunich: I did
[19:55:16] <jmkasunich> cradek: you are using a recent checkout, right>?
[19:55:25] <cradek> maybe an hour ago
[19:55:33] <jmkasunich> recent enough ;-)
[19:55:47] <jmkasunich> the HAL section of your ini invokes core_stepper.hal?
[19:56:04] <cradek> yes
[19:56:05] <alex_joni> jmkasunich, cradek: the only thing I might imagine is if cradek took those lines and connected them to parport to enable his drives
[19:56:26] <cradek> +newsig chopper_enable bit
[19:56:26] <cradek> +setp parport.0.pin-01-out-invert 1
[19:56:26] <cradek> +linksp chopper_enable axis.0.amp-enable-out
[19:56:26] <cradek> +linksp chopper_enable parport.0.pin-01-out
[19:56:26] <cradek> +
[19:56:34] <cradek> +setp parport.0.pin-14-out-invert 1
[19:56:34] <cradek> # connect it to a physical pin
[19:56:34] <cradek> -linksp spindle_on parport.0.pin-09-out
[19:56:34] <cradek> -
[19:56:34] <cradek> +linksp spindle_on parport.0.pin-14-out
[19:56:35] <jmkasunich> and you added your commands to connect the enable to core-stepper.hal
[19:56:43] <cradek> these are my only cnages to standard_pinout
[19:57:04] <jmkasunich> ok, you did it in standard_pinout.hal
[19:57:07] <jmkasunich> thats fine
[19:57:08] <cradek> right
[19:57:19] <cradek> ok
[19:57:23] <alex_joni> so axis.0.amp-enable-out now goes to 2 pins (parport something, and stepgen.x.enable)
[19:57:50] <SWPadnos_> no - from motion amp enable to parport, not to stepgen.x.enable
[19:57:54] <jmkasunich> oh, I know what happened
[19:58:03] <alpha> sup?
[19:58:04] <alex_joni> SWPadnos_: not in what he pasted,
[19:58:08] <SWPadnos_> right
[19:58:10] <jmkasunich> alex already had a signal connected to axis.0.enable
[19:58:15] <alex_joni> jmkasunich: 2 sigs connected to the same pin
[19:58:32] <jmkasunich> and when cradek connected chopper_enable, it unconnected the other one
[19:58:45] <cradek> let's use /estop then
[19:58:54] <jmkasunich> not neccessary
[19:58:58] <petev> cradek: just use the sig name that was there
[19:59:03] <alex_joni> cradek: use Xen
[19:59:03] <jmkasunich> delete your newsig chopper_enable
[19:59:07] <alex_joni> that's the signame
[19:59:09] <jmkasunich> yes
[19:59:20] <alex_joni> and linksp Xen parport.0.pin-01-out
[19:59:27] <jmkasunich> Xen was already connected, so the newsig was unneccessary
[19:59:55] <alex_joni> jmkasunich: does the unconnecting print a BIG warning message?
[20:00:01] <alex_joni> maybe it should
[20:00:09] <jmkasunich> good point
[20:00:40] <jmkasunich> or just refuse, and force you to do an unlinkp first
[20:00:43] <alex_joni> or say that the pin already has a sig connected to it, and you need to use --force to unconnect the previous one
[20:00:54] <alex_joni> jmkasunich: we think almost alike tonight ;)
[20:01:25] <cradek> ok, great, that fixed it
[20:01:38] <cradek> accel is a lot higher than emc1
[20:01:41] <alex_joni> cradek: thanks for pointing us a 'bug' out ;)
[20:01:42] <jmkasunich> another thing... intro to emc2 should tell folks to start the standard config, then open a shell, and do halcmd show >default_config
[20:01:43] <cradek> maybe I wasn't getting what I asked for
[20:02:01] <alex_joni> cradek: the stepgen works a lot better than emc1
[20:02:04] <alex_joni> so I've heard :D
[20:02:05] <jmkasunich> they can read default_config and see what is connected and how, then decide what changes to make
[20:02:24] <alex_joni> jmkasunich: or they should just use halgui & not mess with files they don't know
[20:02:25] <alex_joni> :D
[20:02:36] <jmkasunich> once we have that, yes
[20:02:46] <alex_joni> my hopes just went up 724,5% now that cradek uses emc2
[20:02:55] <jmkasunich> s/uses/tries/
[20:03:00] <alex_joni> yeah ;)
[20:03:12] <alex_joni> cradek: that was a very subtle hint
[20:03:17] <cradek> cool, it works and sounds nice and smooth
[20:03:22] <alex_joni> ;-)
[20:03:32] <cradek> had to reduce my accel to 50 to get reliable starts
[20:03:40] <alex_joni> halgui beeing programmed in python (*;-)*)
[20:04:09] <jmkasunich> 50 = 50 inches/sec^2
[20:04:09] <alex_joni> cradek: any other issues from the switch?
[20:04:12] <cradek> multi-axis jogs work right with axis
[20:04:23] <alex_joni> cradek: it does too with tkemc :P
[20:04:45] <alex_joni> jmkasunich: he isn't running emc2 for 2 minutes, and he already has AXIS on it :P
[20:04:51] <cradek> can you push left, up, pagedown at the same time, and release them separately?
[20:05:27] <alex_joni> cradek: yes
[20:05:44] <tomp> does emc2 have something like a step response test for servos ( to evaluate accel)?
[20:05:46] <cradek> should machine-off stop the spindle? it doesn't
[20:05:48] <alex_joni> but only since my fix..
[20:06:08] <alex_joni> cradek: good point.. should it?
[20:06:25] <cradek> no idea
[20:06:31] <cradek> I always used estop before, and it does
[20:06:40] <alex_joni> ok.. so estop does
[20:06:46] <cradek> yes, it still does
[20:06:57] <cradek> I defer on the proper behavior of machine-on/off
[20:07:05] <alex_joni> ok.. so do I
[20:07:09] <cradek> (except I'm sure it should turn off on exit)
[20:07:25] <alex_joni> that's more likely to be included in the runlevels jmk was talking about
[20:07:40] <alex_joni> right john?
[20:07:59] <alex_joni> cradek: what's your first impression of emc2?
[20:08:09] <alex_joni> as a programmer/user/developer
[20:12:16] <cradek> first impressions:
[20:12:35] <cradek> hal is powerful but obscure
[20:12:45] <cradek> I'm glad I don't have to dink with PID to make my steppers work
[20:14:50] <jmkasunich> just looking at the shutdown code in emc.run
[20:15:20] <alex_joni> jmkasunich: it basicly sends some kill's around
[20:15:21] <alex_joni> iirc
[20:15:25] <jmkasunich> first it kills the GUI (if not already dead, on a normal shutdown it will be dead)
[20:15:30] <jmkasunich> then it sleeps one second
[20:15:39] <jmkasunich> then it kills task
[20:15:46] <jmkasunich> then it does halcmd stop
[20:15:55] <jmkasunich> which kills all realtime execution
[20:16:04] <jmkasunich> then it begins unloading realtime modules
[20:16:20] <jmkasunich> that one second should be when EMC does an orderly shutdown
[20:17:20] <alex_joni> just because there's no connection to GUI?
[20:17:24] <alex_joni> that's dull
[20:17:31] <alex_joni> task would have no idea about that
[20:17:36] <SWPadnos_> perhaps a machine-specific "shutdown.hal" should be in there somewhere
[20:17:40] <alex_joni> and there might be another GUI started somewhere else
[20:17:58] <jmkasunich> shutdown should come from EMC code, not buried in hal
[20:18:10] <SWPadnos_> before realtime and HAL modules are unloaded, if it exists, then bin/halcmd -f shutdown.hal
[20:18:25] <SWPadnos_> that gives an integrator the ability to set things as they like on exit
[20:18:39] <jmkasunich> today, the run script invokes a single display, and when that display exits, it begins cleanup
[20:18:59] <SWPadnos_> (it would mostly consist of 'sets' commands, I'd bet)
[20:19:00] <jmkasunich> that is the master display process, you can later open (and close) others, but that one determines when emc shuts down
[20:19:16] <jmkasunich> I think the old emc.run worked the same
[20:19:20] <SWPadnos_> yep
[20:19:21] <alex_joni> jmkasunich: I know, was just pointing things out
[20:19:24] <petev> yeah, but I like the idea of a guarnteed ordly shutdown in RT
[20:19:34] <jmkasunich> everything emc.run starts runs in the background, except the display
[20:19:37] <alex_joni> maybe task should trap the kill signal
[20:19:41] <SWPadnos_> orderly != corrent for the machine
[20:19:43] <alex_joni> and do some stuff accordingly
[20:19:45] <SWPadnos_> correct
[20:19:49] <petev> alex: it does
[20:20:00] <alex_joni> then emc.run should wait 1 sec, and the others get shut down
[20:20:03] <petev> traps kill and term
[20:20:16] <jmkasunich> but what does it do when it sees kill or term?
[20:20:21] <alex_joni> petev: OK, then .. didn't catch that in jmk's description
[20:20:26] <jmkasunich> it should send a command to the RT part
[20:20:30] <petev> runs emc shutdown code
[20:20:31] <alex_joni> jmkasunich: it should send out the _ABORT and other stuff
[20:20:44] <jmkasunich> perhaps ABORT, followed by MACHINE_OFF and maybe even ESTOP
[20:20:57] <alex_joni> all the HALT NML messages
[20:20:59] <alex_joni> to IO & co
[20:21:02] <jmkasunich> yes
[20:21:09] <SWPadnos_> perhaps anything in a shutdown script ;)
[20:21:21] <petev> look at emctask_quit
[20:21:31] <jmkasunich> where? emctaskmain?
[20:21:40] <petev> taskmain.cc
[20:21:47] <petev> it set's the done flag
[20:21:55] <petev> then exits main loop with cleanup
[20:22:01] <alex_joni> EMC_AXIS_HALT , EMC_TRAJ_ABORT, EMC_TRAJ_HALT, EMC_MOTION_ABORT, EMC_MOTION_HALT, EMC_TASK_ABORT, EMC_TASK_HALT, EMC_TOOL_ABORT, EMC_TOOL_HALT, etc
[20:22:37] <petev> emctask_shutdown is the cleanup part
[20:23:16] <jmkasunich> emcMotionHalt should shut down the motion system
[20:23:26] <jmkasunich> I wonder if the run script just isn't waiting long enough
[20:23:39] <petev> but how do you know task gets to run this?
[20:23:41] <jmkasunich> cradek: can you run an experiment?
[20:23:48] <petev> maybe the script should wait for task to die
[20:23:59] <cradek> jmkasunich: running a program right now
[20:24:10] <petev> if task is stuck waiting for a buffer or something, what happens?
[20:24:15] <jmkasunich> when you get a chance, add "sleep 1" at line 291 of emc.run
[20:24:23] <jmkasunich> and see if you get a more orderly shutdown
[20:24:41] <alex_joni> petev: nothing right away
[20:25:13] <alex_joni> petev: but after a while (a few months), and 5 or 6 of these strange calls & quits, probably you'll witness some very hard to track segfault ;-)
[20:25:16] <petev> yeah, so HAL may be stopped too soon
[20:25:37] <petev> for sure on my machine ;-)
[20:25:42] <alex_joni> but I must admit I like the shutdown.hal idea SWP? had
[20:25:48] <petev> me too
[20:25:58] <alex_joni> jmkasunich: how about you?
[20:26:03] <jmkasunich> although it seems like KilltaskWithTimeout in the run script does already wait for the task to dissappear
[20:26:10] <SWPadnos_> following the Ray mantra of separating machine logic from the core program
[20:26:10] <cradek> jmkasunich: that makes no change
[20:26:26] <jmkasunich> ok, so much for that theory
[20:26:57] <jmkasunich> I'm not thrilled with the shutdown.hal idea
[20:27:25] <jmkasunich> IMO, axis.0.enable should turn off before the machine shuts down
[20:27:26] <alex_joni> jmkasunich: maybe it should also call emcAxisDeactivate() not only the emcAxisHalt()
[20:27:37] <alex_joni> as that's how it's done now
[20:27:38] <jmkasunich> maybe
[20:27:41] <petev> I don't care how it's implemented, but there should be an orderly shutdown in RT that is not user dependant
[20:27:48] <SWPadnos_> I would see that being used to set certain signals to known values before shutdown, and not much else
[20:27:48] <alex_joni> /me reads that in int emcMotionHalt()
[20:28:04] <jmkasunich> I don't know the details, but the motion module needs to shut down clean...
[20:28:22] <jmkasunich> if somebody wants more custom shutdown actions after that, then shutdown.hal is an option
[20:28:30] <alex_joni> agreed
[20:28:32] <SWPadnos_> the trouble is that the definition of "clean" can change from machine to machine
[20:28:35] <jmkasunich> but as a bandaid for a busted internal shutdown of emc, NO
[20:28:45] <alex_joni> ideally the standard .hal file would be empty imho
[20:29:05] <SWPadnos_> but yes - in cases where there's an "obvious" functionality (like enables, estop, etc), those should be dactivated at cleanup time
[20:29:09] <alex_joni> but it could provide already-in-place hooks for strange machines
[20:29:42] <alex_joni> cradek: can you try a small change to taskintf.cc ?
[20:29:49] <jmkasunich> note that it a signal is being driven (for example by motmod), a "sets" in shutdown.hal is NOT going to have much effect, if any
[20:29:56] <alex_joni> * alex_joni can hardly test the parport
[20:30:14] <alex_joni> unlinkp first? then sets
[20:30:29] <jmkasunich> if neccessary
[20:30:45] <alex_joni> I would unlinkp the parport pins, then build a true and a false sig
[20:30:47] <jmkasunich> but better for motmod to drive axis.0.enable off itself
[20:30:51] <alex_joni> and connect them accordingly
[20:31:04] <alex_joni> yes, we are talking about screwy machines here
[20:31:13] <jmkasunich> cradek's isn't screwy
[20:31:16] <jmkasunich> fix that first
[20:31:20] <alex_joni> sure.. I want that
[20:31:27] <SWPadnos_> and machines that are part of larger machines
[20:31:33] <alex_joni> but it's hard for me to test.. no voltmeter around today
[20:31:34] <jmkasunich> sorry
[20:31:49] <alex_joni> * alex_joni is hoping for some cooperation from cradek ;)
[20:32:04] <jmkasunich> halscope on axis.0.enable?
[20:32:16] <cradek> working on an axis bug... just a couple minutes
[20:32:20] <alex_joni> after shutdown?
[20:32:22] <jmkasunich> of course, the run script will shut down halscope too :-(
[20:32:46] <alex_joni> I could start realtime again, and run only parport and look at the value
[20:33:01] <SWPadnos_> with axis, how do you turn the limits display on/off?
[20:33:22] <alex_joni> jmkasunich: ok, you convinced me..
[20:33:24] <SWPadnos_> (of course, I may have a version without that feature)
[20:33:32] <alex_joni> fired up the devel box
[20:33:33] <cradek> SWPadnos_: on the edit menu
[20:33:38] <cradek> they default to on
[20:33:40] <alex_joni> SWPadnos_: they should turn on by default
[20:33:42] <jmkasunich> line 291 in emc.run, you could put something in there that requires user input, then exits
[20:33:45] <SWPadnos_> ok - I may need a later version
[20:33:51] <alex_joni> if not, then you have an older version
[20:34:00] <jmkasunich> that would stop the script after task is killed, but before the RT is stopped and cleaned up
[20:35:19] <alex_joni> I don't think there's a need for that
[20:35:27] <jmkasunich> not for real, just for testing
[20:35:42] <jmkasunich> so you could use a scope to examin hal stuff during shutdown
[20:36:39] <jmkasunich> you could just start a halmeter at line 291, that way it will stop until you close the meter
[20:37:23] <alex_joni> ok :)
[20:38:28] <SWPadnos_> hm - I guess I needa newer axis without all the log crap ;)
[20:39:30] <cradek> SWPadnos_: I just checked in a fix for log
[20:39:46] <SWPadnos_> ok - cvs will be my new friend
[20:40:29] <cradek> http://unpy.net/cgi-bin/viewcvs.cgi/axis/extensions/emcmodule.cc.diff?r1=1.12;r2=1.13
[20:40:59] <alex_joni> jmkasunich: is there a pause command?
[20:41:09] <alex_joni> or smthg to wait on user intervention?
[20:41:15] <cradek> read
[20:41:31] <alex_joni> thx
[20:41:33] <tomp> If I want an mcode to end with something like an MFIN...
[20:41:36] <tomp> then I need to post an EMC_TASK_PLAN_PAUSE, run my code and issue EMC_TASK_PLAN_RESUME (yes?)
[20:41:38] <SWPadnos_> thanks
[20:46:30] <SWPadnos_> hm - turning off extents does Bad Things on my machine
[20:46:56] <SWPadnos_> the plot will no longer update, and a string of errors pop up in the terminal
[20:47:18] <cradek> what kind of errors?
[20:47:41] <SWPadnos_> Exception in Tkinter callback
[20:47:43] <SWPadnos_> Traceback (most recent call last):
[20:47:45] <SWPadnos_> File "/usr/lib/python2.3/lib-tk/Tkinter.py", line 1345, in __call__
[20:47:47] <SWPadnos_> return self.func(*args)
[20:47:49] <SWPadnos_> File "/usr/lib/python2.3/lib-tk/Tkinter.py", line 456, in callit
[20:47:51] <SWPadnos_> func(*args)
[20:47:52] <SWPadnos_> File "/Project/emc2/bin/axis", line 372, in actual_tkRedraw
[20:47:53] <SWPadnos_> self.tkRedraw_perspective()
[20:47:55] <SWPadnos_> File "/Project/emc2/bin/axis", line 315, in tkRedraw_perspective
[20:47:56] <SWPadnos_> 0., 1., 0.)
[20:47:58] <SWPadnos_> error: (1283, 'stack overflow')
[20:47:59] <SWPadnos_> Exception in Tkinter callback
[20:48:01] <SWPadnos_> Traceback (most recent call last):
[20:48:02] <SWPadnos_> File "/usr/lib/python2.3/lib-tk/Tkinter.py", line 1345, in __call__
[20:48:04] <SWPadnos_> return self.func(*args)
[20:48:05] <SWPadnos_> File "/usr/lib/python2.3/lib-tk/Tkinter.py", line 456, in callit
[20:48:07] <SWPadnos_> func(*args)
[20:48:08] <cradek> ugh
[20:48:09] <SWPadnos_> File "/Project/emc2/bin/axis", line 372, in actual_tkRedraw
[20:48:10] <SWPadnos_> self.tkRedraw_perspective()
[20:48:11] <cradek> ok ok
[20:48:12] <SWPadnos_> File "/Project/emc2/bin/axis", line 319, in tkRedraw_perspective
[20:48:13] <SWPadnos_> self.redraw(self)
[20:48:14] <SWPadnos_> File "/Project/emc2/bin/axis", line 1684, in redraw
[20:48:16] <SWPadnos_> cone_scale = max(g.max_extents[x] - g.min_extents[x],
[20:48:18] <SWPadnos_> UnboundLocalError: local variable 'x' referenced before assignment
[20:48:20] <SWPadnos_> I got one when I did the change, then a zillion when I tried to pan / zoom
[20:48:50] <cradek> I think the real error might be the first one
[20:48:58] <SWPadnos_> I'm re-running it now
[20:49:27] <SWPadnos_> OK - before loading anything, I can change it at will
[20:49:49] <alex_joni> oh-oh
[20:49:50] <alex_joni> :D
[20:49:53] <cradek> let me try it here... I think I've killed a different bug
[20:50:09] <SWPadnos_> Exception in Tkinter callback
[20:50:11] <SWPadnos_> Traceback (most recent call last):
[20:50:13] <SWPadnos_> File "/usr/lib/python2.3/lib-tk/Tkinter.py", line 1345, in __call__
[20:50:15] <SWPadnos_> return self.func(*args)
[20:50:17] <SWPadnos_> File "/usr/lib/python2.3/lib-tk/Tkinter.py", line 456, in callit
[20:50:18] <SWPadnos_> func(*args)
[20:50:20] <SWPadnos_> File "/Project/emc2/bin/axis", line 374, in actual_tkRedraw
[20:50:21] <SWPadnos_> self.tkRedraw_ortho()
[20:50:23] <SWPadnos_> File "/Project/emc2/bin/axis", line 355, in tkRedraw_ortho
[20:50:24] <SWPadnos_> self.redraw(self)
[20:50:26] <SWPadnos_> File "/Project/emc2/bin/axis", line 1684, in redraw
[20:50:27] <SWPadnos_> cone_scale = max(g.max_extents[x] - g.min_extents[x],
[20:50:29] <SWPadnos_> UnboundLocalError: local variable 'x' referenced before assignment
[20:50:30] <SWPadnos_> Exception in Tkinter callback
[20:50:32] <SWPadnos_> Traceback (most recent call last):
[20:50:33] <SWPadnos_> File "/usr/lib/python2.3/lib-tk/Tkinter.py", line 1345, in __call__
[20:50:35] <SWPadnos_> return self.func(*args)
[20:50:36] <SWPadnos_> File "/usr/lib/python2.3/lib-tk/Tkinter.py", line 456, in callit
[20:50:38] <SWPadnos_> func(*args)
[20:50:40] <SWPadnos_> File "/Project/emc2/bin/axis", line 374, in actual_tkRedraw
[20:50:41] <SWPadnos_> self.tkRedraw_ortho()
[20:50:43] <SWPadnos_> File "/Project/emc2/bin/axis", line 355, in tkRedraw_ortho
[20:50:44] <SWPadnos_> self.redraw(self)
[20:50:46] <SWPadnos_> File "/Project/emc2/bin/axis", line 1684, in redraw
[20:50:47] <SWPadnos_> cone_scale = max(g.max_extents[x] - g.min_extents[x],
[20:50:49] <cradek> ok, I get it too
[20:50:49] <SWPadnos_> UnboundLocalError: local variable 'x' referenced before assignment
[20:50:52] <SWPadnos_> those are what I get when I change the menu option, and without trying to move the plot
[20:51:21] <SWPadnos_> If I don't try to pan, I can turn extents back on (which gives me two erros again), but it still works
[20:51:46] <cradek> diff -u -u -r1.85 axis.py
[20:51:46] <cradek> --- axis.py 27 Nov 2005 21:39:50 -0000 1.85
[20:51:46] <cradek> +++ axis.py 27 Nov 2005 21:44:10 -0000
[20:51:46] <cradek> @@ -1680,6 +1680,7 @@
[20:51:46] <cradek> if live_plotter.running.get() and live_plotter.data and vars.show_tool.get():
[20:51:49] <cradek> if program is not None:
[20:51:52] <cradek> g = self.g
[20:51:54] <cradek> + x,y,z = 0,1,2
[20:51:57] <cradek> cone_scale = max(g.max_extents[x] - g.min_extents[x],
[20:51:59] <cradek> g.max_extents[y] - g.min_extents[y],
[20:52:02] <cradek> g.max_extents[z] - g.min_extents[z],
[20:52:06] <cradek> add this patch
[20:52:15] <SWPadnos_> no - actually, I can do everything as long as extents are on
[20:53:02] <SWPadnos_> ok - do I need to reinstall afterwards?
[20:53:03] <cradek> yes, I see the bug here too, add that patch there
[20:53:19] <cradek> if you patch bin/axis in-place, no
[20:53:29] <SWPadnos_> ok - so bin/axis is anis.py
[20:53:31] <SWPadnos_> axis
[20:53:34] <cradek> yes
[20:56:16] <SWPadnos_> rotation seems to be backwards now, but otherwise it's fixed
[20:56:53] <SWPadnos_> also, the scale snaps to something weird (and small) when I middle-click to drag and rotate
[20:57:13] <cradek> if you are in an ortho view and middle click to rotate, it snaps to perspective
[20:57:19] <cradek> it's a feature
[20:57:26] <jmkasunich> ;-)
[20:57:37] <SWPadnos_> well - it seems to do it on mouse-down, rather than mouse-up (sometimes)
[20:57:43] <cradek> I agree the scale could be preserved better, but it's hard
[20:57:58] <cradek> it's intended to do it as soon as you nav with the mouse
[20:58:02] <SWPadnos_> so if I want to drag, it snaps to perspective, then I can drag
[20:58:07] <cradek> right
[20:58:11] <cradek> unless you're alread in perspective
[20:59:07] <cradek> next you're going to tell me it crashes if you hit HOME
[20:59:10] <SWPadnos_> ok - you're right, it snaps to the other zoom when I start the move
[20:59:18] <SWPadnos_> cool - lemme try that ;)
[20:59:34] <SWPadnos_> how do you do measurements?
[21:00:32] <cradek> what do you mean?
[21:01:06] <SWPadnos_> the web page sais that there are "drafting-style measurements"
[21:01:16] <cradek> um, of the program extents
[21:01:34] <SWPadnos_> ok - it looked like there were a lot of CAD-like markers in the screenshot ;)
[21:09:26] <CIA-5> 03alex_joni * 10emc2/src/emc/task/taskintf.cc: added a call to emcTrajDisable() before emcTrajHalt(), this way the amps get disabled before shutdown
[21:09:44] <cradek> alex_joni: testing your change...
[21:10:07] <alex_joni> cradek: I am very gratefull
[21:10:30] <cradek> works!
[21:10:52] <cradek> SWPadnos_: home bug is fixed too
[21:11:09] <SWPadnos_> it didn't crash for me :(
[21:11:19] <SWPadnos_> or did I hit pg-up by accident??
[21:11:25] <cradek> * cradek shrugs
[21:11:48] <SWPadnos_> should the machine be on for home to crash axis?
[21:11:50] <alex_joni> cradek: yay
[21:12:12] <cradek> SWPadnos_: probably, I don't think home does anything if the machine isn't on
[21:12:28] <SWPadnos_> one little quirk - the progress meter starts off, and then resets after getting 1/4 - 1/3 of the way
[21:12:56] <cradek> that's another feature
[21:13:00] <cradek> there are two stages to loading
[21:13:08] <SWPadnos_> heh
[21:13:15] <cradek> the first one gets a bouncing bar because we don't know how long it will take
[21:13:18] <cradek> the second one gets a real progress bar
[21:13:29] <SWPadnos_> OK - home does cause the plot to freeze
[21:13:33] <cradek> yeah
[21:13:34] <cradek> it's fixed
[21:13:41] <SWPadnos_> yep - I was going to mention that it looked like the type changed
[21:13:45] <SWPadnos_> ok
[21:13:53] <SWPadnos_> is it a one-liner like the othres?
[21:14:11] <cradek> no, it's several files
[21:14:19] <cradek> requires recompile
[21:14:22] <SWPadnos_> ok
[21:14:35] <cradek> is the emc2 interpreter one of the new ones?
[21:14:48] <SWPadnos_> not in HEAD
[21:15:07] <jmkasunich> the lerman interp is in a branch
[21:15:17] <jmkasunich> I'm not sure what the critera for merging it should be
[21:15:27] <jmkasunich> probably if nobody is gonna scream about it, we should merge it
[21:15:43] <jmkasunich> a decision for the new board
[21:15:44] <cradek> axis won't display relative coordinates
[21:15:51] <jmkasunich> * jmkasunich ducks responsibility
[21:15:52] <cradek> when I have an offset in place
[21:16:10] <cradek> show machine position / show relative position does nothing
[21:17:13] <cradek> oh, the offsets aren't working at all
[21:18:28] <cradek> yeah, coord systems in general are broken
[21:18:31] <cradek> try this
[21:18:37] <cradek> g0x1
[21:18:39] <cradek> g10l2p1x1
[21:18:41] <cradek> g0x0
[21:18:45] <cradek> [last jog should not move]
[21:19:27] <cradek> oh, I see
[21:19:37] <cradek> it comes up with G55 by default, not G54 like emc1!
[21:21:21] <cradek> once I issue G54 once, it all works
[21:22:51] <SWPadnos_> isn't there supposed to be some "startup_codes" ini setting?
[21:22:58] <cradek> yes, there is one
[21:22:59] <alex_joni> there is
[21:23:15] <SWPadnos_> I don't see it in any of the stock .inis
[21:25:20] <cradek> ok, hitting ESC doesn't turn off the spindle either and I _know_ that should
[21:25:47] <cradek> also when emc aborts (like when a programmed line would exceed limits) the spindle does not stop
[21:25:51] <cradek> surely it should stop then too
[21:25:57] <alex_joni> cradek: ok, I'll look at that now
[21:26:17] <alex_joni> can you tell me what gets issued on Esc?
[21:26:21] <alex_joni> some ABORT it should be
[21:26:33] <cradek> EMC_TASK_ABORT
[21:27:24] <alex_joni> ok, thanks, saved me some searching ;)
[21:30:34] <jmkasunich> * jmkasunich 's brain spins
[21:30:50] <SWPadnos_> watching too much Exorcist?
[21:31:00] <jmkasunich> I can't multitask between interp and task level stuff (here), motion stuff (alex) and the PPMC driver code
[21:31:10] <alex_joni> no.. watching some nice code :)
[21:31:16] <alex_joni> jmkasunich: same spinning over here
[21:31:18] <cradek> and I'm fixing more gui bugs
[21:31:23] <alex_joni> but I'm looking at iocontrol too
[21:31:24] <alex_joni> :)
[21:31:34] <alex_joni> cradek: what if esc gives you an estop?
[21:31:35] <SWPadnos_> and I'm just looking for good example code to copy ;)
[21:31:38] <alex_joni> would that be bad?
[21:31:42] <alex_joni> or any abort :D
[21:31:47] <jmkasunich> F1 gives estop
[21:31:53] <jmkasunich> that's a bit radical for ESC
[21:31:53] <cradek> it has never worked that way
[21:32:00] <alex_joni> I was kidding
[21:32:10] <alex_joni> as a quick fix I put the default HAL values on ABORT
[21:32:15] <jmkasunich> abort stops tool motion, I dunno if it should stop spindle
[21:32:15] <alex_joni> and that includes estop :)
[21:32:33] <jmkasunich> it should not assert estop
[21:32:42] <alex_joni> I KNOW
[21:32:53] <cradek> alex_joni: IT SHOULD NOT ESTOP!!!1!1
[21:32:55] <alex_joni> changing that now.. go back to your other 3 things ;)
[21:32:58] <jmkasunich> ok, sorry
[21:33:14] <cradek> jmkasunich: in emc1 abort definitely stops the spindle
[21:33:22] <alex_joni> stop screaming at me ;) it's night, dark and I'm easily scared
[21:33:25] <cradek> so does exceeding a limit
[21:33:37] <jmkasunich> ok
[21:34:12] <jmkasunich> alex_joni: BOO!!!
[21:34:33] <jmkasunich> or should that be YAH BOO!
[21:34:42] <alex_joni> ROFL
[21:36:32] <SWPadnos_> that sucks
[21:36:33] <alex_joni> cradek: should it stop lube & co aswell?
[21:36:46] <cradek> don't care, I don't have those :-)
[21:36:50] <jmkasunich> no
[21:37:09] <alex_joni> hrmm.. no?
[21:37:11] <SWPadnos_> I would think that coolant should stop
[21:37:19] <SWPadnos_> if the spindle stops
[21:37:21] <alex_joni> see... again the runlevel thingies ;)
[21:37:34] <alex_joni> just hack it up as you like it..
[21:37:40] <alex_joni> not as "we" code it
[21:37:42] <SWPadnos_> yeah - see my previous pseudo-rants about stop modes
[21:41:41] <alex_joni> cradek: I changed it, but I don't like it
[21:41:52] <alex_joni> we need to come up with a better way to do this
[21:42:05] <alex_joni> maybe classicladder is an answer.. not sure
[21:42:17] <cradek> * cradek hides
[21:42:29] <cradek> I don't want to have to figure that out for my basic machine
[21:42:31] <cradek> that would be silly
[21:42:32] <jmkasunich> I hesitate to impose CL on people with entry level machines
[21:42:34] <alex_joni> it needs to be customizeable..
[21:42:47] <cradek> it needs to have reasonable default behavior AND be customizable
[21:42:57] <SWPadnos_> run spindle enable through an AND block, along with some output from task ("running" or the like)
[21:42:59] <alex_joni> cradek: probably you'll have to run CL without knowing that
[21:43:02] <jmkasunich> CL rocks if you want to do lots of custom stuff tho
[21:43:20] <alex_joni> with some basic config that emulates the emc1
[21:43:37] <jmkasunich> alex has a point
[21:43:38] <alex_joni> and others (not me) who want something else, can come up with their own ladder
[21:43:59] <jmkasunich> we could ship default configs that run ladder, hal, and all that, and joe ordinary never has to look at it
[21:44:07] <alex_joni> jmkasunich: maybe integrate your runlevels into this
[21:44:20] <jmkasunich> but if he wants to customize, the standard configs are his starting point
[21:44:28] <alex_joni> iocontrol exports some runlevel pins, which get to the appropiate ladders
[21:44:34] <alex_joni> right
[21:44:50] <jmkasunich> * jmkasunich needs to shut up and focus on USC driver, I promised people I'd have something this weekend
[21:44:59] <alex_joni> but who's joe ordinary? (some new relative of aunt tillie?)
[21:45:03] <jmkasunich> yeah
[21:45:04] <alex_joni> I liked her better :D
[21:45:21] <SWPadnos_> tillie got too much computer experience ;)
[21:45:22] <jmkasunich> how about joe sixpack?
[21:45:25] <alex_joni> ok.. we'll discuss this with the new board :)
[21:45:33] <alex_joni> hmmm.. sounds .. competent
[21:45:48] <jmkasunich> ?
[21:46:11] <jmkasunich> we'll have a new board in 90 minutes ;-)
[21:47:33] <alex_joni> sixpack == competent
[21:47:39] <jmkasunich> nah
[21:47:50] <alex_joni> more than tillie ;)
[21:47:51] <SWPadnos_> sixpack == drunk all the time (on beer)
[21:47:51] <CIA-5> 03alex_joni * 10emc2/src/emc/iotask/ioControl.cc: changed the behaviour on ABORT, now all pins (spindle, lube, coolant, etc) get reset to a default value. this should be at some point configurable by the user, so maybe a CL extension with this in it is needed.
[21:48:03] <alex_joni> SWPadnos_: I know ;)
[21:48:03] <jmkasunich> joe sixpack is a hillbilly with a beer belly and a sixpack of cheap beer in cans
[21:48:07] <SWPadnos_> joe sixguns would be competent, though ;)
[21:48:08] <alex_joni> cradek: can you test that?
[21:48:13] <cradek> sure
[21:48:23] <cradek> are override limits supposed to work? If I turn it on, I still can't jog into my limit
[21:48:28] <alex_joni> cradek: thanks, that makes it more fon..
[21:48:42] <alex_joni> override limits should work before homing
[21:49:02] <alex_joni> if you are already homed it shouldn't allow you to go into a limit
[21:49:05] <alex_joni> I think...
[21:49:05] <cradek> but there are no limits before homing ...?
[21:49:15] <jmkasunich> no soft limits
[21:49:19] <cradek> I can jog anywhere before homing
[21:49:20] <alex_joni> how can there be? emc doesn't know where you are...
[21:49:21] <jmkasunich> because the machine doesn't know where it is
[21:49:23] <cradek> oh, this is about the switches
[21:49:27] <alex_joni> right
[21:49:32] <cradek> ok, this overrides the limit SWITCHES
[21:50:16] <jmkasunich> you have switches on your machine?
[21:50:20] <cradek> no
[21:50:23] <jmkasunich> ok
[21:50:31] <cradek> I home by eyeball and then trust the soft limits
[21:50:38] <alex_joni> right
[21:50:44] <cradek> it seems to work great
[21:50:48] <jmkasunich> normal for a small machine
[21:50:53] <jmkasunich> switches are overkill
[21:51:01] <alex_joni> cradek: can I shutdown my develbox?
[21:51:07] <SWPadnos_> I like to think of them as underkill ;)
[21:51:12] <alex_joni> or do you have any last-minute requests?
[21:51:14] <cradek> what am I testing now? It's built
[21:51:36] <alex_joni> requests, bugs, etc.
[21:51:49] <cradek> um, the spindle doesn't turn on now
[21:51:51] <alex_joni> cradek: run it, and push Esc
[21:52:07] <cradek> ugh
[21:52:17] <cradek> the first time I ran the program, the spindle didn't turn on, I shit you not
[21:52:19] <alex_joni> it should stop the spindle
[21:52:19] <alex_joni> it doesn't turn on??
[21:52:21] <cradek> the second time, it did
[21:52:27] <alex_joni> damn.. strange
[21:52:38] <cradek> now ESC does turn off the spindle
[21:52:41] <alex_joni> open a halmeter and look at iocontrol.0.spindle-on
[21:52:52] <cradek> checking to see if I can reproduce it...
[21:54:00] <cradek> no, can't reproduce
[21:54:11] <alex_joni> but I could.. I think
[21:54:22] <alex_joni> started 3D_Chips
[21:54:27] <alex_joni> and the spindle was off..
[21:55:25] <cradek> that is not good!!
[21:56:27] <alex_joni> I also noticed some strange behaviour with the tool
[21:56:36] <alex_joni> T1M6 didn't cause it to load a new tool
[21:57:21] <alex_joni> but in MDI it works ok
[21:57:31] <alex_joni> darn.. too tired to hunt it down
[21:57:38] <alex_joni> can you submit a bug tracker?
[21:57:47] <alex_joni> I'll look at it later today
[21:57:58] <cradek> saying that once the spindle didn't come on? everyone will laugh at me
[21:58:19] <alex_joni> saying that I was able to reproduce it :)
[21:58:36] <alex_joni> it happens all the time here
[21:58:44] <alex_joni> if you shutdown emc, and run again
[21:59:27] <alex_joni> hrmm.. maybe I should only mess with spindle not with tool too..
[21:59:33] <alex_joni> hang on, I'll commit another version
[21:59:53] <cradek> oh do you think your change broke it?
[22:00:21] <alex_joni> I think so..
[22:00:31] <alex_joni> try to commit before my change
[22:00:35] <alex_joni> to checkout
[22:00:43] <alex_joni> darn.. told you I was tired :)
[22:00:52] <cradek> go to bed! we'll deal with it later
[22:00:59] <cradek> this isn't an emergency or anything
[22:01:04] <SWPadnos_> yeah - it's like 27:00 there ;)
[22:01:10] <alex_joni> I don't like leaving buggy code around
[22:01:18] <alex_joni> SWPadnos_: it did overflow :)
[22:01:20] <cradek> just revert your change then
[22:01:24] <alex_joni> 25
[22:01:39] <alex_joni> 25:54 ;)
[22:01:49] <SWPadnos_> heh
[22:02:21] <cradek> jmkasunich: I am occasionally hearing glitches during jogs
[22:02:41] <cradek> jmkasunich: if it was anyone else, I'd blame a bogus realtime setup (bios settings, etc)
[22:03:05] <cradek> jmkasunich: but this is a venerable emc machine so I'm worried there's a bug in emc2
[22:06:32] <jmkasunich> hmm
[22:06:44] <jmkasunich> (sorry, was away a bit)
[22:06:55] <cradek> testing...
[22:06:58] <alex_joni> cradek: don't think it's my change.. an older version does the same I think
[22:07:51] <SWPadnos_> the version of emc2 that I have (from earlier today) turns on the spindle when I run 3d_chips for the first time
[22:08:07] <cradek> jmkasunich: I can actually stall on a long jog if I move the mouse!
[22:08:22] <cradek> jmkasunich: I know that sounds like a machine problem, but emc1 is fine
[22:09:20] <jmkasunich> what is your PERIOD?
[22:09:29] <cradek> same on both: .000024
[22:09:48] <jmkasunich> change the emc2 PERIOD to .000040 and see what happens
[22:10:39] <cradek> you are talking about BASE_PERIOD right?
[22:10:47] <jmkasunich> yeah
[22:11:04] <cradek> I also changed other CYCLE_TIMEs etc.
[22:11:55] <cradek> that does seem to fix it! why???
[22:12:19] <alex_joni> not enough time to complete the stuff it needed to do..
[22:12:21] <jmkasunich> emc2 isn't quite as optimized for speed as emc1 was, may have been running out of time under certain conditionds
[22:12:42] <cradek> I thought that would cause a lockup, not a glitch
[22:12:47] <jmkasunich> I like to think emc2 is optimized for readability, but that might be too generous
[22:12:53] <jmkasunich> nope, just a glitch
[22:13:13] <cradek> I'm not sure 40 is fast enough for my 8000 scale
[22:13:15] <alex_joni> cradek: rtai RT stuff is pretty protected against lockup
[22:13:30] <cradek> alex_joni: not using it here...
[22:13:45] <alex_joni> I thankfully seen that while sorking on a driver
[22:13:45] <alex_joni> s/sorking/working/
[22:13:45] <alex_joni> you're runnign RTLinux?
[22:13:50] <cradek> yes
[22:13:53] <alex_joni> can't type anymore..
[22:14:05] <alex_joni> nice.. one of the few RTLinux emc2 users I know..
[22:14:14] <cradek> maybe the only
[22:14:18] <alex_joni> I know some older BDI is RTLinux based
[22:14:30] <jepler> it was up to bdi live rc46
[22:14:31] <alex_joni> at least one compile_farm slot is like that
[22:14:34] <jepler> then paul threw it all away
[22:14:43] <cradek> hi jeff
[22:14:48] <alex_joni> yup.. it's too commercial for my taste too
[22:14:52] <alex_joni> hi jeff
[22:15:02] <cradek> but at least I can figure out how to build a kernel with it...
[22:16:23] <alex_joni> night Martin
[22:16:27] <alex_joni> this is crazy..
[22:16:40] <alex_joni> EMC_TOOL_ABORT gets sent during AUTO periodically
[22:16:47] <alex_joni> a few times per second
[22:17:06] <cradek> ouch
[22:17:28] <skunkworks> update on the jogging issue. I have set up 2 diffent machines with bdi 4.3 and emc2 - they both act the same in jog.
http://sourceforge.net/tracker/index.php?func=detail&aid=1367192&group_id=6744&atid=106744
[22:18:47] <skunkworks> I can on the 500 mhz pentium 2 run the z axis (input scale of 20000) will run at 75 ipm in mdi or auto. The thing just screams ;)
[22:19:05] <cradek> hmm, I got a joint following error - I wonder if PERIOD is too slow now.
[22:19:06] <skunkworks> pentium III
[22:19:44] <skunkworks> my period is set to .00002 which someone here did a calc and said 75 is the maximum at that period
[22:20:05] <cradek> totally depends on your output scale
[22:20:11] <skunkworks> steppers
[22:20:16] <skunkworks> both the same
[22:21:26] <SWPadnos_> yes - 75 IPM is the max with 20 uS BASE_PERIOD and 20000 steps/inch
[22:21:54] <jmkasunich> skunkworks, try 30uS base period
[22:22:18] <cradek> my machine seems ok at .000032
[22:22:19] <jmkasunich> that means fewer steps/sec of course (probably 50ipm instead of 75)
[22:22:25] <jmkasunich> but see if it behaves better
[22:22:40] <skunkworks> I started out with the default period. Still had the following errors in jog
[22:22:43] <SWPadnos_> you can get around 590 IPM on the other axes (from the step rate anyway)
[22:22:53] <skunkworks> what was it .00005?
[22:23:22] <cradek> 45 minutes left for voting...
[22:23:24] <jmkasunich> SWP: huh?
[22:23:29] <skunkworks> right - the machine seems to run 300 ipm on those axises - have not tried any higher
[22:23:36] <jmkasunich> 20uS = 50K interrupts/sec
[22:23:41] <jmkasunich> = 25K max steps/sec
[22:24:08] <jmkasunich> divided by 20K steps/inch = 1.25 in/sec
[22:24:12] <jmkasunich> = 75 ipm
[22:24:29] <SWPadnos_> he's got 2540 steps/inch on X + Y
[22:24:36] <SWPadnos_> and 20k on Z
[22:24:38] <jmkasunich> oh
[22:24:49] <SWPadnos_> hence 75 IPM and 590-ish IPM
[22:24:54] <skunkworks> right
[22:24:58] <jmkasunich> my head is spinning again, I can't switch topics so fast
[22:25:03] <skunkworks> sorry
[22:25:07] <SWPadnos_> sorry about that
[22:25:35] <cradek> well thanks everyone, this has been very productive
[22:25:51] <jmkasunich> I will need to load and run with your ini files to see what is happening
[22:26:03] <alex_joni> cradek: should work as promised now
[22:26:25] <jmkasunich> cradek: agreed... several bugs found and stomped, all in all a good day
[22:26:26] <skunkworks> just thought I would add that the jogging issue is the same between 2 differnt systems. one amd 700mhz and an pentium III 500. (pentium runs better)
[22:26:54] <cradek> alex_joni: I will update again then
[22:26:56] <cradek> alex_joni: thanks again
[22:27:04] <alex_joni> * alex_joni is fighting with cvs
[22:27:09] <jmkasunich> and also the same with differnet base periods, so unlikely to be a difference in CPU capabilities
[22:27:26] <jmkasunich> I need to look at the stepgen behavior with halscope
[22:27:30] <jmkasunich> but can't right now
[22:27:36] <jmkasunich> buried in other work
[22:28:28] <alex_joni> wth does sticky tag mean?
[22:28:43] <cradek> I think it means you have to use cvs up -A
[22:28:50] <jmkasunich> it means that particular checkout is "stuck" to a particular revision
[22:28:58] <jmkasunich> what he said...
[22:29:07] <cradek> you were previously working on a branch
[22:29:13] <cradek> or something
[22:29:16] <cradek> I got that recently too
[22:29:24] <alex_joni> no I checked out an older revision
[22:29:30] <cradek> yeah
[22:29:32] <cradek> use cvs up -A
[22:29:32] <jmkasunich> two choices, keep the current checkout (if you want to continue to work on the branch) and get a new checkout for head
[22:29:48] <jmkasunich> or just do cvs up -A which will move your current checkout to head
[22:29:51] <skunkworks> One question - as you guys are fixing things I can do the -cd ~/emc2/src [then] ./configure [then] make clean [then] make
[22:30:11] <cradek> skunkworks: yes
[22:30:18] <cradek> skunkworks: you have to get the changes from cvs first of course
[22:30:24] <skunkworks> to update - or do I have to do the cvs -d:pserver first
[22:30:28] <jmkasunich> cvs up -dP
[22:30:32] <jmkasunich> then cd src, etc, etc
[22:30:33] <skunkworks> ok thanks
[22:30:41] <CIA-5> 03alex_joni * 10emc2/src/emc/iotask/ioControl.cc: reverted the previous change, tried a different approach. this still needs to be user-setable
[22:30:46] <alex_joni> finally ;)
[22:30:50] <cradek> aha
[22:30:55] <jmkasunich> you don't need the -d:pserver etc stuff, that is the first time only
[22:30:56] <alex_joni> hope it's got the changes I meant in there
[22:31:14] <alex_joni> cradek: you'll never figure out what the problem was
[22:31:21] <cradek> with diff I bet I could
[22:31:29] <alex_joni> * alex_joni wants to scream when I see something like that
[22:31:33] <alex_joni> it was LUBE
[22:31:42] <alex_joni> some weird logic included in task
[22:31:49] <alex_joni> that checks that lube is working
[22:32:12] <alex_joni> I think.. didn't follow that very much
[22:32:17] <jmkasunich> machine logic in task = bad programmers! go to bed early without dinner!
[22:32:27] <alex_joni> jmkasunich: RIGHT
[22:32:31] <cradek> mmm dinner
[22:32:37] <alex_joni> [01:25] <cradek> mmm dinner
[22:32:43] <cradek> alex_joni: at first glance it does seem to work
[22:32:47] <jmkasunich> breakfast
[22:32:49] <cradek> alex_joni: but I couldn't reproduce the problem for some reason
[22:32:54] <alex_joni> I could
[22:32:56] <cradek> 17:25 here
[22:33:02] <cradek> ok, then I trust you if you say it's fixed
[22:33:04] <alex_joni> yeah.. tea time:)
[22:33:30] <alex_joni> it's hacked to work, not really fixed
[22:33:39] <alex_joni> fixed would mean it works the way it should
[22:33:43] <alex_joni> userconfigurable
[22:33:54] <alex_joni> but that's pretty away I think
[22:33:55] <cradek> it's all about sensible defaults
[22:34:04] <alex_joni> it would mean to rip task apart ;)
[22:34:11] <cradek> go to bed, you're not thinking clearly
[22:34:21] <alex_joni> of course I am
[22:34:42] <alex_joni> it's in these late hours when my common-sense is switched off
[22:34:46] <cradek> I was kidding
[22:34:54] <cradek> thanks for fixing these problems
[22:34:55] <alex_joni> now I don't think about what that would involve ;)
[22:35:09] <alex_joni> cradek: I know you were, I was kidding too
[22:35:18] <alex_joni> no problem ;) thanks for pointing them out
[22:35:45] <cradek> it's scary but maybe I'll try cutting something with this setup...
[22:35:57] <alex_joni> but the more I look at these parts of emc, the more I think it needs to get rewritten
[22:36:10] <jmkasunich> cut something soft
[22:36:13] <alex_joni> and that's even scarier
[22:38:16] <skunkworks> thanks for everyones hard work. For not being a linux person - I sure could get used to emc2.
[22:39:05] <cradek> skunkworks: did you vote yet?
[22:39:06] <jmkasunich> if you are getting emc2 from cvs and compiling it, you are on the way to becoming a linux person
[22:39:12] <cradek> that's the truth
[22:39:28] <jmkasunich> (resistance is futile, you will be assimilated)
[22:39:52] <cradek> but it's such a pleasant assimilation
[22:40:05] <skunkworks> I was just folling the directions on the wiki page. It is almost greek other than the cd command ;)
[22:42:05] <skunkworks> just a vauge understanding of what is going on.
[22:44:03] <cradek> I'm going for a while
[22:44:15] <SWPadnos_> see ya
[22:44:17] <cradek> thanks again all
[22:44:25] <SWPadnos_> no - thank you
[22:44:49] <jmkasunich> yeah, we need testing with axis
[22:44:57] <jmkasunich> face it, we need testing
[22:45:18] <SWPadnos_> 2 or 3 axis bugs fixed this eve - not bad
[22:58:11] <CIA-5> 03jmkasunich * 10emc2/src/hal/drivers/hal_ppmc.c: stepgen HAL pin export code added, realtime part not done yet. committing to coordinate with SWP.
[23:04:03] <skunkworks> what - what am I voting for?
[23:04:29] <cradek> assuming you were on the mailing list a week ago, the emc board of directors
[23:04:43] <cradek> but the vote closes in 2.5 minutes
[23:05:47] <skunkworks> nope just signed up - don't know enough about what is going on here to vote. thanks
[23:06:04] <SWPadnos_> stumping for votes, eh cradek ;)
[23:06:29] <cradek> who me?
[23:06:40] <cradek> nah, but I wish everyone who cares would vote
[23:06:56] <jmkasunich> maybe everyone who cares did vote
[23:07:00] <jmkasunich> sad thought tat
[23:07:02] <jmkasunich> that
[23:07:08] <SWPadnos_> yes
[23:07:12] <cradek> I have no idea how many voted last year
[23:07:17] <cradek> I know I did
[23:07:32] <SWPadnos_> well - it looks like there's one more vote this year than last year (that could be me)
[23:08:09] <skunkworks> Next time
[23:08:49] <skunkworks> unless you guys kick me out for being annoying.
[23:09:03] <SWPadnos_> wecan do that if you like ;)
[23:09:19] <SWPadnos_> but you haven't gotten annoying yet
[23:09:31] <cradek> I'm still here, so it's obvious that's not the way it works
[23:09:46] <SWPadnos_> oh yeah
[23:10:08] <jmkasunich> hi thalx
[23:12:44] <thalx> Greetings
[23:17:35] <wb9mjn> Hi All, has anybody done PROBE'g with a servo EMC system ?
[23:17:53] <jmkasunich> have never done probing at all :-(
[23:18:20] <wb9mjn> The probe input is on the RT I/O parallel port...
[23:18:35] <wb9mjn> Which is not used on the servo systems....
[23:18:54] <jmkasunich> oh, emc1...
[23:19:07] <jmkasunich> on emc2, the probe input can be routed to any I/O
[23:19:11] <wb9mjn> I m more interested in using the probe function for tool setting, actually...
[23:19:35] <jmkasunich> ooohhh, clever... auto tool length compensation
[23:21:22] <wb9mjn> A company sells a tool probe which can be converted to a tool setting probe...
[23:22:05] <wb9mjn> Put that in the 0,0 corner, and have it check tool heights...
[23:22:53] <wb9mjn> Would be handy....
[23:24:25] <wb9mjn> Another way would be a spring loaded piston, that has two contacts. One grounds when pressed, and the other grounds when the piston reaches
[23:24:34] <wb9mjn> full upward travel....
[23:25:20] <wb9mjn> Could tool set by a medium speed downward movement unto the first contact opens, then a very slow upward movement till the second grounds....
[23:25:47] <SWPadnos_> you'd be better off with a very precise optical proximity sensor - no mechanical wear to reduce accuracy
[23:26:03] <wb9mjn> That way, arbitrary length tools could be quickly gauged....
[23:26:06] <jmkasunich> gonna be hard to detect to 0.0001 optically
[23:26:39] <SWPadnos_> not too easy mechanically either ;)
[23:26:41] <wb9mjn> If the tools vary by 3 or 4 inches in length, could take quite a while to gauge a tool...
[23:26:54] <wb9mjn> automatically....
[23:27:12] <jmkasunich> imagine a cylinder, open top, with a small lip on the inside of the top
[23:27:20] <SWPadnos_> you can do it if you have an electrically insulated pad, and move very slowly onto it (making contact through the machine)
[23:27:37] <jmkasunich> the lower edge of the lip is precisely parallel to the table and at a known height
[23:28:13] <jmkasunich> inside the cylinder, a very flat disk, pressed up against the lip by a spring that is barely stiff enough to hold it up
[23:28:28] <jmkasunich> tool comes down, makes electrical contact with the disk
[23:28:38] <jmkasunich> the disk is free to move down to avoid crashing the tool
[23:28:50] <jmkasunich> then you move back up slowly
[23:28:55] <jmkasunich> until contact breaks
[23:28:57] <wb9mjn> The advantage of optical methods is that small tools could be gauged without rising breakage (like .0201 drill bits)...
[23:29:54] <wb9mjn> Yep, that s what I was thinking jmk... ...
[23:29:58] <jmkasunich> yeah, there are always tradeoffs
[23:30:40] <wb9mjn> An optical system might work by doepler....
[23:31:37] <wb9mjn> Any detected doepler indicates the beam has been intersected....this could be very accurate....
[23:31:45] <jtr> A disk might tilt with a single-point cutter.
[23:31:51] <jmkasunich> but how wide is the beam
[23:32:01] <wb9mjn> Not if the disk is a piston in a cylinder....
[23:32:04] <wb9mjn> Not by much....
[23:32:06] <jmkasunich> tilt doesn't matter - you are detecting first contact between disk and tool
[23:32:07] <jtr> agreed
[23:32:21] <jmkasunich> it doesn't tilt until after you hit it
[23:33:00] <tomp> i'm used to using voltage drop, 10V at 50ma, when it goes away, you touched ( I work slow )
[23:33:16] <jtr> yup - I was thinking of the fast advance, slow retract method.
[23:33:22] <wb9mjn> The doepler method does not require a micro-colimated beam, as soon as the edge of the beam is touched, there is reflected out of phase light, and
[23:33:30] <tomp> its real cheap and accurate if you can go slow
[23:33:45] <wb9mjn> by mixing back at the source, a very small amplitude of light, out of phase, can be detected....
[23:34:01] <jmkasunich> but you have to know where the edge of the beam is
[23:34:13] <jmkasunich> so it must be of a known size, and sharp-edged
[23:34:24] <tomp> 2 micron repeatability on many machines
[23:34:33] <tomp> 1 on some
[23:34:38] <SWPadnos_> you know where the beam is, just like you'd know where your contact disk is
[23:34:41] <jmkasunich> agreed tom, electrical is very accurate
[23:35:07] <jmkasunich> whens the last time you saw a beam of light that went from full power to dark over 0.0001 inch?
[23:35:23] <jmkasunich> the intensity drops slowly as you move away from the center
[23:35:28] <jmkasunich> the edge isn't sharp at all
[23:35:36] <jmkasunich> even a laser
[23:35:52] <SWPadnos_> with a mask over the detector, you get better edge definition
[23:36:10] <jmkasunich> mask detector and emitter
[23:36:22] <jmkasunich> and your accuracy is still no better than mask slot width
[23:36:24] <SWPadnos_> also, using detection techniques other than on/off, you can see very slight changes in beam intensity
[23:36:39] <jmkasunich> which is a tradeoff with brighness, aka signal strength
[23:36:53] <wb9mjn> You guys are thinking intensity...I m talking phase....much more sensative...
[23:36:57] <SWPadnos_> change detection
[23:37:11] <SWPadnos_> phase is harder, and you're not guaranteed to get a phase change
[23:37:23] <jmkasunich> is the beam parallel to the tool, or perpendicular?
[23:37:34] <SWPadnos_> different tool diameters will have differnet amounts of phase change
[23:37:39] <jmkasunich> yes
[23:38:02] <jmkasunich> and if the beam is parallel, then beam diameter and edge of beam sharpness are crucial
[23:38:11] <jmkasunich> oops, scratch that
[23:38:22] <jmkasunich> and if the beam is perpendicular, then beam diameter and edge of beam sharpness are crucial
[23:38:31] <SWPadnos_> I'm thinking of making a version of my digital camera that has a nice 1:1 or better lens, and allows you to make pixel-size measurements from the image
[23:38:31] <wb9mjn> No tool is perfectly smooth...and one could even rotate the tool....
[23:38:45] <wb9mjn> We are talking light wavelengths here..
[23:39:12] <SWPadnos_> if you rotate the tool, you lose all doppler and phase info, becuase the tool is moving (though you might be able to measure tooth travel speed ;) )
[23:39:16] <jmkasunich> if the beam is perpendicular to the tool, the light waves are parallel, they tell you nothing about length
[23:39:27] <wb9mjn> And look for harmonics of rotatio to make it easier...
[23:39:47] <wb9mjn> Making it too complicated SWP, just need to detect when something is there....
[23:40:00] <jmkasunich> geez... just use tomp's $20 method... power supply, resistor, optocoupler to pass it to the computer
[23:40:18] <SWPadnos_> too easy ;)
[23:40:38] <wb9mjn> If the beam is perpedicular, and the tool was perfecly smooth cylinder, and the beam infinately small in diamter, there would be no
[23:40:40] <wb9mjn> detection....
[23:40:49] <SWPadnos_> throw in an RFdetector with programmable gain, and you can get a really accurate detector
[23:40:58] <wb9mjn> Tools and lasers are neither....
[23:41:19] <SWPadnos_> but only for overall intensity, not phase
[23:41:20] <wb9mjn> So, you will hear the detector growl whenever anything is in the beam ....
[23:41:30] <jmkasunich> but how far into the beam...
[23:41:39] <wb9mjn> And if you spin the tool, you will here it sing....
[23:42:00] <jmkasunich> but the beam edges are fuzzy
[23:42:01] <wb9mjn> Probably with the -30 dB contour would be sufficient...
[23:42:19] <jmkasunich> so when it starts to growl, you don't know exactly how far into the beam it is
[23:42:28] <jmkasunich> certainly not a the center
[23:43:22] <wb9mjn> The only trick to it is setting the -30 dB contour at a specified height....
[23:43:46] <jmkasunich> thats what I've been getting at all along
[23:43:54] <SWPadnos_> it will change depending on the tool diameter, unless all tools are larger than the beam
[23:44:00] <wb9mjn> Which could be done with a guage pin in the spindle....
[23:44:11] <SWPadnos_> even then, itwill change with different tool shapes (like V cutters or ball-nose)
[23:44:29] <jmkasunich> so you are actually using the optical thing as a secondary standard
[23:44:45] <jmkasunich> calibratet it with some other method (guage pin for example)
[23:45:15] <wb9mjn> Easy to do,,,just put the gauge pin in the collet loose, and push down to a specified height....then pull back and do a beam detection...done...
[23:46:21] <tomp> Agie, Makino, Mitsubishi, Ingersoll, Ona, Dieter, Charmilles all use voltage drop. It's proven accurate cheap.
[23:46:26] <wb9mjn> Could use that same method to calibrate the piston method....
[23:46:37] <jmkasunich> the detection point will still vary with tool end geometry
[23:47:40] <wb9mjn> Not sure jmk.... ...
[23:48:11] <jmkasunich> imagine a ball end mill, turned such that the beam hits the back of the cutting edge
[23:48:19] <wb9mjn> Think the disturbance will be so sensative, that it wont matter for setting to .0001 ...
[23:48:27] <jmkasunich> most deflected light bounces downward, not toward the detector
[23:49:00] <jmkasunich> then try a regular endmill, the relief is shiny and reflects right back at the detector
[23:49:00] <tomp> nite all
[23:49:47] <jmkasunich> and don't forget that drop of oil or coolant hanging on the bottom of the tool ;-)
[23:50:09] <wb9mjn> You are thinking too macro, not nano....at light wavelengths only a telescopic mirror polish will reflect in phase off axis...These are not stealth tools here,,hi...
[23:50:49] <wb9mjn> nite tomp...thanks for the info on professional methods...
[23:50:54] <jmkasunich> liquid surfaces (like oil) will
[23:51:14] <jmkasunich> oh well, not worth arguing about - to each his own
[23:51:24] <wb9mjn> Not unless they are of uniform thickness....
[23:51:48] <wb9mjn> Probably gone as far as can without experimentation....
[23:52:10] <wb9mjn> But...favor the piston for first work anyway...
[23:53:11] <jmkasunich> the real issue isn't the detector anyway, one way or another you can reduce the signal to a contact closure, whether it is tool touching metal, or $10,000 laser box generating an output
[23:53:21] <jmkasunich> the issue is what to do with that contact closure
[23:53:32] <jmkasunich> how to get it into emc and modify the tool table
[23:54:56] <wb9mjn> Well...could do that manually initially...and a switch...down switch to piston movement switch, up switch to tool tool touch switch and use PROBE function...
[23:55:10] <lerman> That's what the interpreter is for. Also, the testing, looping, subroutine ability facilitates doing stuff like that.
[23:55:16] <wb9mjn> That then gives you a number...which you manually enter into the tool table...
[23:56:02] <wb9mjn> Which brings me back to the subroutine updates to the interpretter, which I need to do yet...how do I get started ?
[23:56:18] <lerman> emc1 or emc2?
[23:56:28] <wb9mjn> Or it could be a script....
[23:56:31] <wb9mjn> EMC1 ...
[23:56:50] <lerman> The changes are in the current main line sources.
[23:57:14] <wb9mjn> I m using RC_46....do you know which files I need to switch ?
[23:58:08] <lerman> I don't really, but at least most of the rs274ngc_new directory.
[23:58:29] <wb9mjn> Ok...