Back
[01:20:03] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[02:11:40] <SWPadnos> is it possible to have cvsweb list the file size on the drectory info page?
[02:12:34] <jepler> I'm not sure if it's easy to compute it for an arbitrary revision
[02:13:43] <jepler> I'm not sure if it's easy to compute it for an arbitrary revision
[02:13:48] <jepler> just finding the latest log message is easy by comparison
[02:16:35] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[02:23:52] <SWPadnos> ah, ok
[02:24:30] <SWPadnos> right - is is the original version that's retained, plus diffs, or is it the current version plus diffs?
[02:24:34] <SWPadnos> is it ... ?
[02:24:42] <jepler> the current version plus diffs, I think
[02:24:53] <SWPadnos> oh, then ls (file) would do it :)
[02:24:53] <jepler> but I'm not sure if "current" means HEAD or if it means "the last checked-in version"
[02:24:57] <SWPadnos> right
[02:25:06] <jepler> well, no "working file" is retained
[02:25:10] <SWPadnos> for "version-X" it's a harder problem
[02:25:26] <jepler> but every revision but one is stored as "the other version, with these edits applied"
[02:25:42] <SWPadnos> right
[02:25:56] <SWPadnos> ok - nevermind
[02:26:24] <SWPadnos> I thought of it because I wasn't positive the .pin file was a large binary file until I actually downloaded it :)
[02:26:58] <jmkasunich> I take it you don't have a local CVS checkout
[02:27:10] <SWPadnos> not on this laptop (WIN2k)
[02:27:32] <SWPadnos> I'm not sure I ever figured out how to make TortoiseCVS actually use ssh
[02:27:38] <SWPadnos> if it even works
[02:28:14] <SWPadnos> I may install Edgy on the other hard disk, and hope the wifi drivers work
[19:45:48] <Lerneaen_Hydra_> Lerneaen_Hydra_ is now known as Lerneaen_Hydra
[20:39:29] <Jymmmmmm> Jymmmmmm is now known as Jymmmmmmmmmm
[20:40:29] <Jymmmmmmmmmm> Jymmmmmmmmmm is now known as Jymmm
[20:42:10] <Jymmm> Jymmm is now known as Jymm
[20:42:09] <Jymm> Jymm is now known as Jymmm
[21:20:00] <jepler> this is something I'd rather not try to bite off for 2.1
[21:20:27] <alex_joni> jepler: I agree getting this right might take a while
[21:20:30] <jepler> we need to branch soon, and then get back to experimental stuff in HEAD
[21:20:43] <alex_joni> sounds like a good idea to me
[21:20:44] <cradek> jmk is right that we've already done some of the work for the various override overrides
[21:21:25] <jepler> I guess I don't know exactly what you came up with
[21:21:49] <cradek> a bitmap of override overrides that goes along with each motion
[21:22:07] <jepler> ah
[21:22:10] <cradek> then TP just makes the bitmap available to the rest of motion during the move
[21:23:06] <jepler> I don't know how many outputs people will want -- the space required might be prohibitive.
[21:23:16] <cradek> yeah especially if DACs are involved.
[21:23:17] <alex_joni> jepler: I don't think more than a bunch is needed
[21:23:41] <alex_joni> if they need then I bet they can trigger them using CL
[21:24:22] <jepler> 1000 TP entries, 100 outputs at 4 bytes each, is only 400k
[21:24:24] <jepler> that's "nothing"
[21:24:44] <jepler> and 100 is way way overkill
[21:24:58] <alex_joni> yeah, I was thinking more like 10
[21:25:10] <alex_joni> * alex_joni looks how many he added last time
[21:25:52] <jepler> and all realtime has to do is put those values on the corresponding HAL pins
[21:26:08] <jepler> 40-400 bytes per 10ms is also "nothing"
[21:26:32] <jepler> but still -- I don't want to move the goalposts. I want to branch 2.1.
[21:26:40] <alex_joni> seems I came up with 4 dio's last time
[21:27:47] <alex_joni> hmm.. something is borked here
[21:27:58] <alex_joni> juve@ubuntu:~/emc2/src$ ../scripts/emc
[21:27:58] <alex_joni> EMC2 - pre-2.1 CVS HEAD
[21:27:58] <alex_joni> ../scripts/emc: line 197: @WISH@: command not found
[21:28:01] <jepler> it wouldn't be hard to make them a compile-time constant, easy to increase if we want to
[21:28:17] <alex_joni> it's already a compile-time constant
[21:28:17] <jepler> alex_joni: either I screwed something up, or you didn't run 'make' after you updated
[21:28:30] <jepler> @WISH@ is a recent addition of mine
[21:28:39] <alex_joni> EMCMOT_MAX_DIO in mot_priv.h
[21:28:56] <jepler> good
[21:28:57] <alex_joni> jepler: yeah, I've seen the commit message.. but I ran make again, ran config.status again, ran configure again
[21:29:39] <alex_joni> my configure.in doesn't show anything related to WISH
[21:29:48] <jepler> I must have missed a related check-in then?
[21:30:18] <alex_joni> sounds like configure.in and configure are foobared
[21:30:30] <alex_joni> maybe you commited from scripts/ ?
[21:31:21] <jepler> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/configure.in.diff?r1=1.112;r2=1.113;f=h
[21:31:33] <jepler> hi ray
[21:31:39] <rayh> question about ubuntu6.06
[21:31:59] <rayh> How do I see the locations of parports, both mobo and add in cards?
[21:32:08] <rayh> Hi jeff
[21:32:08] <alex_joni> lspci ?
[21:32:24] <rayh> I tried that but did not see any 378
[21:32:27] <alex_joni> there's a page in the wiki regarding addon parport cards
[21:32:41] <alex_joni> cat /proc/ioports ?
[21:32:45] <jepler> You can see the ones that the linux kernel detects by temporarily loading the kernel's parport driver
[21:32:51] <jepler> something like: modprobe -i parport_pc
[21:33:07] <jepler> we turn off the kernel parport driver specifically so it doesn't do anything with parallel ports.
[21:33:46] <rayh> Okay.
[21:34:22] <jepler> when I did that, my kernel logged these messages:
[21:34:24] <jepler> [696650.421700] parport: PnPBIOS parport detected.
[21:34:22] <jepler> [696650.421756] parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE]
[21:34:22] <jepler> [696650.514701] lp0: using parport0 (interrupt-driven).
[21:35:18] <rayh> Okay I've got that module loaded. Okay.
[21:35:27] <rayh> I see what it did with dmesg
[21:35:52] <alex_joni> rayh: addon cards should show up in lspci -v
[21:35:53] <rayh> Will parport_pc find all of em.
[21:36:05] <rayh> Okay.
[21:36:09] <rayh> Hey thanks guys.
[21:36:11] <alex_joni> no, usually the onboard I think
[21:36:28] <rayh> I didn't see any parports with lspci
[21:36:30] <jepler> after you've looked at those messages, you won't be able to load emc's hal_parport until the linux parport module is removed
[21:36:40] <jepler> on my system I had to issue: sudo rmmod lp parport_pc
[21:36:40] <rayh> either before or after the modprobe
[21:36:46] <alex_joni> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?NetMos
[21:36:50] <rayh> okay.
[21:37:11] <jepler> also, if your system printed this, then you probably need to use emc's "probe_parport": parport: PnPBIOS parport detected.
[21:37:31] <jepler> (item 4 on
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?TroubleShooting)
[21:37:49] <rayh> How do I use "probe_parport"
[21:37:58] <rayh> is that a script
[21:38:00] <jepler> Some users have reported that in EMC 2.0.1, EMC appears to start, but no signals ever appear on the parallel port (the motors don't turn).
[21:38:03] <jepler> To fix this problem, upgrade to EMC 2.0.3 or newer. Then, add the command
[21:38:05] <jepler> loadrt probe_parport
[21:38:08] <jepler> before the line loading hal_parport in your hal file.
[21:38:38] <jepler> does your system have a PCI add-in parport card?
[21:38:39] <rayh> MattS loaded this. I believe it is a 2.0.3 or 2.0.4
[21:38:48] <rayh> Not my system.
[21:38:55] <rayh> I'm phone servicing a distant computer.
[21:39:04] <jepler> oh
[21:39:16] <cradek> sorry to hear that :-)
[21:39:18] <jepler> with voice or with modem?
[21:39:27] <rayh> All this parport is doing is aux IO
[21:39:30] <rayh> the motion and all is stg
[21:39:38] <rayh> voice
[21:40:14] <jepler> kinda hard to pastebin the lspci then
[21:41:55] <rayh> Right.
[21:42:09] <rayh> I was doing a comparison with my emc-live box here.
[21:42:26] <rayh> and lspci does not show any parport even though I've got one at 378
[21:42:39] <rayh> the modprobe and dmesg does show it.
[21:43:03] <jepler> the "legacy" ports usually don't show up in lspci -- they're ISA devices, effectively.
[21:43:09] <cradek> 0378-037a : parport0
[21:43:09] <cradek> 037b-037f : parport0
[21:43:18] <cradek> I get this in /proc/ioports
[21:43:34] <jepler> cradek: you must have the linux kernel parport driver loaded, then
[21:43:42] <cradek> oh, probably - sorry
[21:43:45] <rayh> I didn't find anything there either
[21:43:55] <cradek> never mind me
[21:44:24] <alex_joni> lspci only shows the pci addon cards, like the netmos
[21:44:40] <alex_joni> and it _doesn't_ identify them as parport related
[21:44:47] <rayh> shoot. Now I can't remove parport_pc. Says it's used by 1
[21:45:01] <alex_joni> sudo rmmod parport
[21:45:05] <alex_joni> sudo rmmod parport_pc
[21:45:06] <rayh> okay. I think I can find the stuff.
[21:45:12] <rayh> busy is the answer
[21:45:19] <alex_joni> and lsmod to see what's using it
[21:45:43] <rayh> It just says 1 is but not other kernel modules
[21:46:48] <rayh> ah got it.
[21:47:03] <rayh> lp and several others were using it.
[21:47:18] <rayh> I think I can handle the call when it comes in.
[21:47:21] <rayh> thanks a bunch guys.
[21:47:34] <alex_joni> no sweat.. that's what we are payd for :)
[21:47:36] <jepler> I also had to remove "lp"
[21:48:53] <alex_joni> jepler: figured out the missing configure bits?
[21:48:56] <alex_joni> or is it just me?
[21:48:56] <cradek> haha
[21:49:09] <jepler> alex_joni: 15:31:27 <jepler>
http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/configure.in.diff?r1=1.112;r2=1.113;f=h
[21:49:16] <jepler> I checked in the configure stuff
[21:49:23] <jepler> I mean, already
[21:49:30] <alex_joni> odd
[21:50:09] <alex_joni> was that a couple of minutes ago?
[21:50:16] <alex_joni> CIA is silent as usually
[21:50:51] <alex_joni> oh darn..
[21:50:54] <jepler> no it was longer ago than that
[21:51:14] <alex_joni> I checked out the new_cl_branch, and forgot I did that on my working copy :)
[21:51:26] <jepler> obn
[21:51:25] <jepler> oh
[21:51:38] <alex_joni> and I checked this before but only in emc2/ not in emc2/src
[21:51:46] <jepler> yeah, new_cl_branch is probably broken now
[21:53:04] <cradek> is there a reason not to merge that?
[22:00:13] <jepler> yes -- I haven't had positive feedback from anybody
[22:00:31] <jepler> I had hoped for some
[22:00:34] <alex_joni> jepler: I ran it .. and it works
[22:00:36] <alex_joni> :P
[22:00:45] <cradek> it worked for me
[22:00:56] <alex_joni> but I can say the same about the old one, not seeing much of a difference
[22:01:01] <cradek> nobody else will try it until it's merged
[22:01:09] <alex_joni> cradek: bet we can ask Dallur
[22:01:24] <alex_joni> I know he is the one that complained about missing parts from CL
[22:01:35] <cradek> did ray try it? I'd think he would be interested and able to test it
[22:02:37] <rayh> i
[22:02:54] <rayh> ve not tested new cl
[22:03:01] <cradek> oops, sorry to talk about you like you're not here ray, I forgot
[22:17:48] <jepler> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?SynchronizedOutputs
[22:19:21] <alex_joni> jepler: you don't want to put them into parameters
[22:19:25] <alex_joni> imho
[22:20:01] <jepler> alex_joni: that's not my favorite idea either, but I felt it deserved a mention anyway
[22:20:20] <cradek> should the analogs go from 0 to 1 (or -1 to 1) with scaling in HAL?
[22:20:24] <alex_joni> it somehow feels that it brings trouble
[22:21:19] <cradek> if I have g1x1; M200 P1 Q1; M200 P1 Q0; g1x2 how do you synchronize/not stop?
[22:21:41] <jepler> cradek: I don't see a reason to restrict the range.
[22:22:48] <jepler> cradek: I hadn't considered the "double modification" case; add a note to the wiki about it if you like
[22:22:55] <cradek> ok I guess I agree, I didn't see at first how scaling would work, but I think the answer is don't worry about it
[22:23:24] <jepler> in my imagined implementatio, the behavior would never output the value 1, not even for a short time.
[22:24:05] <jepler> if you want it to appear for some time, then put in a programmed pause
[22:24:14] <cradek> there's a problem with tying it to the upcoming motion too: M200P1Q1; G4P.5; M200P1Q0 is perfectly reasonable
[22:24:40] <jepler> in that case, the state of P1 should be visible when the pause starts
[22:25:14] <jepler> that probably wasn't clear from what I wrote, that's the "special handling of g4 etc"
[22:25:39] <cradek> ok I see
[22:26:23] <jepler> so userspace could detect that P1 was set without an intervening motion, and insert a "smallest possible pause"
[22:26:33] <jepler> in your original case (no G4)
[22:26:42] <jepler> you'd typically get 10ms
[22:27:30] <cradek> it seems like we need an uncomfortable combination of queue-emptying and motion-attachment implementations
[22:27:46] <jepler> I think we should just move pause and dwell into motion, not task
[22:27:55] <jepler> it's causing more and more problems
[22:27:56] <cradek> I was just thinking that
[22:28:14] <cradek> but probing
[22:28:26] <jepler> yeah -- it doesn't fix probing, optional stop, block delete
[22:28:39] <jepler> and the hypothetical "read input", however that will work
[22:29:05] <cradek> I'm starting to be with ray on "read input" being a bad idea
[22:29:17] <jepler> if that's true, then "probe" is a bad idea
[22:29:28] <cradek> yes, that's right
[22:30:13] <cradek> by "that's right" I mean I see the connection, not that I'm sure of whether they are (both) bad
[22:30:33] <jepler> I'll stick by "we should move dwell and pause into motion"
[22:30:58] <alex_joni> jepler: sounds more and more like 2.3 to me
[22:31:13] <cradek> it would be nice to not have to empty the queue when we dwell. that sucks.
[22:31:35] <alex_joni> * alex_joni thinks task needs some really good cleanup
[22:31:47] <alex_joni> it needs to get more generic and more simple
[22:31:49] <cradek> task needs some really good throwing out and starting over
[22:31:52] <jepler> I'll just rewrite task in python this weekend
[22:32:01] <alex_joni> eek
[22:32:02] <jepler> see you guys later, it's time to drive home
[22:32:07] <cradek> me too
[22:32:09] <alex_joni> time for bed here
[22:32:15] <cradek> goodnight
[22:32:19] <alex_joni> good night
[22:38:23] <rayh> parport report -- I found two parports.
[22:38:39] <rayh> Had to use modprobe because lspci didn't show anything
[22:38:55] <rayh> One at 0x378
[22:39:00] <rayh> One at 0x278
[22:39:25] <rayh> The 278 is the one spec'd in the xxx_io.hal file
[22:39:53] <rayh> in the dmesg it is referred to as parport1
[22:40:07] <rayh> would that make any difference to HAL
[22:40:25] <rayh> It should still be referred to as parport.0.whatever?
[23:25:17] <cradek> if line("'> 0 && line("'<= line("$") |
[23:34:20] <jmkasunich> hi guys
[23:34:41] <jmkasunich> only here for a few minutes - wish I could have participated in the sync outputs discussion
[23:35:12] <jmkasunich> my thoughts on it were to do the RT part exactly as we did the overrides
[23:35:27] <cradek> hi
[23:35:35] <jmkasunich> when the command to set some pin to some value is sent, it sets a variable to that value
[23:35:47] <jmkasunich> that variable does not directly drive the output
[23:36:04] <jmkasunich> it is copied into the queue on the next line/arc command
[23:36:19] <jmkasunich> and when it comes back out of the queue it is written to the outout
[23:36:20] <jmkasunich> output
[23:36:22] <cradek> yes I agree that's part of the solution
[23:36:22] <jmkasunich> hi
[23:36:49] <cradek> but imagine a program that's dwell/set/dwell/set etc (no motion)
[23:37:39] <jmkasunich> just like the override stuff - if the queue is empty, the "pending" values get copied directly to the "active" values
[23:38:38] <cradek> true
[23:38:51] <cradek> maybe it's not actually very hard
[23:38:58] <cradek> did you see jepler's pre-spec?
[23:38:59] <jmkasunich> I was thinking of a struct outputs { array of float; array of bit }
[23:39:05] <jmkasunich> yes
[23:39:21] <jmkasunich> add one of those structs to each queue entry, and have two as part of the emcmot status struct
[23:39:27] <jmkasunich> "pending" and "active"
[23:39:49] <jmkasunich> and treat them _exactly_ the way we treat the enables in the tc
[23:40:07] <jmkasunich> time to go...
[23:40:11] <cradek> ok bye :-)
[23:40:13] <jmkasunich> I might be back around 10pm est
[23:40:21] <cradek> ok
[23:42:25] <cradek> rayh: about your earlier question I think if there's one loadrt parport, you'll get just parport.0 - it doesn't matter what the linux driver calls it