Back
[00:03:08] <jepler> BUS=="scsi", SYSFS{model}=="USB CF Reader", SYMLINK="cf%n"
[00:03:23] <jepler> finally, my card reader will appear with a consistent name
[00:03:32] <jepler> /dev/cf1 and /media/cf1
[00:04:02] <cradek> I get the feeling udev would be cool if only it were documented somewhere
[00:04:07] <jepler> there's a manpage
[00:04:10] <jepler> but it's not written in english
[00:04:33] <cradek> by my count there are no less than 18 manpages
[00:05:05] <jepler> I also got the usb-serial converter I user primarily to program my ARM microcontroller board to appear with a consistent name:
[00:05:09] <jepler> BUS=="usb", KERNEL=="ttyUSB*", SYSFS{idProduct}=="2303", \
[00:05:11] <jepler> SYMLINK+="ttyARM"
[00:05:16] <cradek> cool
[00:05:28] <jepler> (no, I have no idea why it's SYMLINK+= in one case and SYMLINK= in the other; I wrote them months apart)
[00:13:34] <robin_sz> meep??
[00:15:21] <robin_sz> jepler, I prefer the way Windows allocates devices myself ...
[00:15:36] <robin_sz> $n = rand(10)
[00:15:57] <robin_sz> $newDevice= "comm$n";
[00:16:00] <robin_sz> seemingly
[00:16:34] <robin_sz> my usb serial adaptor just appears wherever the hell it please in Windows ... pick a comm port, any commport
[00:19:10] <jepler> yeah I've had trouble with that, the small amount I've tried to use USB devices on windows
[00:19:14] <jepler> then I swore off windows
[03:06:02] <jepler> that took a bit longer than I expected, but service to cvs.linuxcnc.org should now be restored...
[03:21:00] <jepler> and now .. goodnight
[03:49:41] <A-L-P-H-A> do we have svn?
[08:26:00] <Lerneaen_Hydra> Lerneaen_Hydra is now known as Lerneaen_Hydra_s
[08:26:04] <Lerneaen_Hydra_s> hmm
[08:26:14] <Lerneaen_Hydra_s> Lerneaen_Hydra_s is now known as LH_school
[08:26:19] <LH_school> thats better
[08:27:32] <LH_school> 'lo all
[08:27:38] <LH_school> if there's anyone here now that is
[08:51:42] <LH_school> apparently not
[09:08:33] <alex_joni> I am
[09:09:29] <LH_school> ooh
[09:09:31] <LH_school> Hi alex
[09:10:02] <LH_school> you wouldn't know any reason why "Connection to irc://efnet/ (irc://irc.prison.net/) refused. Reconnecting in 15 seconds." happens when I try to connect to efnet?
[09:10:17] <LH_school> I connected to it just fine a moment ago, and then I got a forced disconnect
[09:10:38] <LH_school> in the middle of a conversation too, on top of that
[09:10:43] <alex_joni> might be that your ip is banned
[09:11:02] <alex_joni> especially if it's a university IP.. that's very likely
[09:12:59] <LH_school> hmm, probablu
[09:13:01] <LH_school> probably
[09:13:23] <LH_school> strange that I connected to it just now though
[09:19:26] <LH_school> hmm
[09:20:08] <LH_school> I just talked to someone else and efnet wasn't acsessable for him either
[09:20:17] <LH_school> alex_joni: could you test efnet?
[09:46:19] <A-L-P-H-A> hey girls.
[09:46:25] <A-L-P-H-A> I'm on efnet righ tnow
[09:46:30] <A-L-P-H-A> irc.efnet.org
[09:46:52] <A-L-P-H-A> LH cause you host name is wrong.
[09:47:07] <A-L-P-H-A> oh wait... irc.prison.net that's right
[09:47:26] <LH_school> that's right
[09:47:31] <A-L-P-H-A> try irc.arcti.ca
[09:47:36] <LH_school> ah!, ok
[09:48:09] <A-L-P-H-A> irc.choopa.net as well
[09:48:24] <LH_school> what's the generic connect command?
[09:48:31] <LH_school> * LH_school is IRC new
[09:48:39] <LH_school> err, engrish yes!
[09:48:44] <LH_school> * LH_school is new to IRC
[09:49:16] <A-L-P-H-A> lh, generic would be connecting to the main rotation serve, which spits you to another server... for efnet... tha twould be irc.efnet.org
[09:49:27] <LH_school> yeah that's what I though
[09:49:31] <LH_school> thought
[10:53:02] <danex> Hello All
[11:27:45] <A-L-P-H-A> know what i just realized, that a line following robot is super easy... two sensors set to the width of the line... say just outside of the line... to either outside edges.
[11:27:57] <A-L-P-H-A> if the line curves, it'll set off one sensor, and not the other.
[11:28:13] <A-L-P-H-A> thus telling the opposite wheel to move a little faster...
[11:28:21] <A-L-P-H-A> or that same wheel a little slow.er
[11:28:51] <A-L-P-H-A> now, the issue is when it has a intersection... that would be a little more tricky.
[11:28:59] <A-L-P-H-A> anyone on ideas of that?
[11:29:03] <A-L-P-H-A> say a figure 8.
[11:29:37] <alex_joni> A-L-P-H-A: if you have some max deviation, then it's safe
[11:29:50] <alex_joni> or maybe if both sensors are set, keep going as you were going
[11:30:12] <A-L-P-H-A> hmm... I'm actually thinking to keep it INSIDE the line, as long as it was a thick lin
[11:30:13] <A-L-P-H-A> line
[11:30:26] <A-L-P-H-A> that way, as long as it doesn't sense white/light color, you're gold.
[11:30:28] <alex_joni> then I suspect you won't have a problem
[11:30:34] <alex_joni> but usually it's the other way around
[11:30:39] <alex_joni> outside sensors..
[11:30:56] <A-L-P-H-A> yeah...
[11:31:02] <A-L-P-H-A> i've never made one, just postulating.
[11:31:10] <A-L-P-H-A> I don't know what you mean by max deviation.
[11:31:45] <A-L-P-H-A> say I draw a line with a sharpie... that's gonna cause some issues... unless I record what was the last say 1 to 2 seconds worth of data.
[11:31:45] <alex_joni> how fast to make one wheel go faster
[11:32:18] <A-L-P-H-A> if I had like 4 sensors, that's make sense too... or maybe even three. with one on the track, and the other two off.
[11:32:39] <A-L-P-H-A> so ABC... if BC are white, spin left wheel faster... if AB spind right wheel faster.
[11:33:23] <A-L-P-H-A> ABC are on white, stop. if ABC are black, keep moving (you're at a T or a cross)
[11:33:28] <A-L-P-H-A> T would indicate stop...
[11:33:39] <A-L-P-H-A> just a fun little toy to build... that is if I had sensors.
[11:36:53] <A-L-P-H-A> guess it could also be made with one sensor... albeit really in effecient...
[11:37:29] <A-L-P-H-A> if it's off, move one wheel, if back on, keep going... so it was zigzag over the line, so it kept finding that line.
[11:53:19] <A-L-P-H-A> alex_joni, what atmel do you use now these days?
[11:57:39] <alex_joni> atmega128 lately
[12:05:56] <A-L-P-H-A> alex_joni, checking
[12:09:15] <A-L-P-H-A> hmm.
[12:10:03] <A-L-P-H-A> not bad...
[12:10:25] <A-L-P-H-A> although it's still approx $10/pc cdn
[12:13:11] <alex_joni> it's quite a big chip
[12:13:15] <alex_joni> with lots of stuff in it
[12:13:24] <alex_joni> if you want cheap/simple there are lots others
[12:13:27] <A-L-P-H-A> yeah... I was looking at the speks
[12:13:32] <alex_joni> I normally use it with OS and Network
[12:15:20] <A-L-P-H-A> can it do ethernet as well?
[12:15:43] <A-L-P-H-A> or usb itself? without external support?
[12:15:52] <A-L-P-H-A> (except the drivers I guess)
[12:16:37] <A-L-P-H-A> it'd be awesome, if I could set a password on the chip... and broadcast itself to a network, and have it communicate via ssh, or telnet.
[12:17:19] <alex_joni> I use it for eth all the time
[12:17:22] <alex_joni> webserver on it
[12:17:28] <alex_joni> no ssh though
[12:17:33] <A-L-P-H-A> https?
[12:17:46] <alex_joni> it can do telnet, but for passing a COM along
[12:17:47] <A-L-P-H-A> well, I guess it's not so bad, if it's going through an internal network with a switch
[12:17:51] <alex_joni> right
[12:17:58] <alex_joni> www.ethernut.de
[12:18:06] <alex_joni> check stuff about NutOS
[12:18:11] <alex_joni> and NutNet
[12:18:30] <A-L-P-H-A> wow. that'd be soo cool.
[12:18:32] <alex_joni> the last hardware they have is quite extreme
[12:18:41] <A-L-P-H-A> i've got so many devices I would love to automate...
[12:18:45] <alex_joni> 8 MBytes Flash and 256 kBytes linear SRAM, MMC/SD-Card Socket, three programmable PLLs etc. Due to the 32-Bit AT91R40008 CPU (ARM7TDMI) running at 73.728 MHz, it is mainly targeted at performance intensive processing like real-time coding and decoding applications. A DM9000E controller is used for the 100 MBit Ethernet Interface
[12:19:14] <A-L-P-H-A> oh... so this isn'twith the the atmega128 persay.
[12:19:18] <A-L-P-H-A> cause that only has like 128K.
[12:19:18] <alex_joni> I have some custom version of the Ethernut 1
[12:19:31] <alex_joni> that's with AtMega128
[12:20:05] <A-L-P-H-A> cost of ethernut 1?
[12:21:11] <alex_joni> about 50$ if you build it yourself
[12:21:53] <A-L-P-H-A> not to bad.
[12:23:22] <A-L-P-H-A> tiny board... 10cm by 8cm
[12:26:29] <A-L-P-H-A> alex_joni, where can I buy one already made?
[12:27:44] <alex_joni> www.ethernut.de
[12:28:21] <A-L-P-H-A> doesn't show me anything for sale
[12:28:41] <alex_joni> do you want 1.3 or 3 ?
[12:28:48] <A-L-P-H-A> probably 1.3
[12:29:14] <alex_joni> http://www.egnite.de/en/store.php?700001&&sid=30f1ae2534ccd5ffca83283ca41ef371&
[12:29:33] <A-L-P-H-A> oh WOW... 95
[12:29:41] <A-L-P-H-A> fark that for now then.
[12:29:49] <A-L-P-H-A> that's like $150+ CDN.
[12:31:11] <alex_joni> the 3.0 is 145E
[12:31:22] <alex_joni> although it's nice ;)
[12:31:32] <A-L-P-H-A> what's the euro key in linux? in win32, it's alt-0128
[12:31:41] <alex_joni> but.. like I said.. they give out schematics.. so you can always build your own
[12:31:45] <alex_joni> not sure :)
[12:31:46] <A-L-P-H-A> true
[12:31:55] <alex_joni> the medianut is nice
[12:31:56] <A-L-P-H-A> your kb doesn't have a euro key?
[12:31:58] <alex_joni> mp3-decode and all
[12:32:06] <alex_joni> it's alt-gr+E
[12:32:18] <alex_joni> but I'm in doze right now (at work)
[12:32:39] <A-L-P-H-A> what's GR?
[12:33:05] <alex_joni> there's a second alt on the right, on german keyboards
[12:33:14] <alex_joni> I think it comes from Alt-graphic or similar
[12:33:21] <A-L-P-H-A> oh
[12:33:29] <A-L-P-H-A> us kb's don't have that
[12:33:37] <A-L-P-H-A> hence why the extended ascii codes
[12:33:55] <A-L-P-H-A> alt-248 is the other useful one... degree symbol °
[12:34:24] <alex_joni> A-L-P-H-A: how about this one?
http://www.olimex.com/dev/sam7-ex256.html
[12:34:36] <alex_joni> I have that at Shift-^ = °
[12:35:00] <alex_joni> SAM7-EX256 development board with AT91SAM7X256, LCD, Audio, CAN, USB, Ethernet 10/100 USD $115.95
[12:35:08] <A-L-P-H-A> I don't have a ^ symbol directly... to get ^, i have to use shift-6 = ^
[12:35:10] <alex_joni> sounds like a good deal
[12:35:40] <A-L-P-H-A> these aren't bad.
[12:35:57] <A-L-P-H-A> however, a WRT-54GL is like $50, and includes a wifi.
[12:36:09] <A-L-P-H-A> however, no serial, or other mechanisms of output.
[12:36:45] <A-L-P-H-A> I guess I could canablize for the LEDs to toggle stuff... but there's no method to log data.
[12:36:52] <A-L-P-H-A> I'm talking a linksys router.
[12:37:00] <A-L-P-H-A> WRT-54GL = the linux router from linksys.
[12:37:06] <alex_joni> I know what a WRT-54GL is
[12:37:11] <alex_joni> :P
[12:37:12] <A-L-P-H-A> alex_joni, sorry. :)
[12:37:20] <alex_joni> np
[12:37:21] <A-L-P-H-A> I'm not sure what Europe has.
[12:37:54] <alex_joni> it did sounds like a router
[12:38:01] <alex_joni> and I remember seeing some people hacking them
[12:38:09] <alex_joni> so I assumed it's that :)
[12:38:23] <alex_joni> 54G sounds like 802.1g (54Mbit) ;)
[12:38:39] <A-L-P-H-A> yeah. the L is linux.
[12:38:46] <alex_joni> WRT = wireless router
[12:38:52] <A-L-P-H-A> there are several revisions of that thing
[12:39:04] <A-L-P-H-A> 6 that I know of... but someone says there's a 7 out now too.
[12:39:13] <A-L-P-H-A> 1-6 are reflashable.
[12:39:25] <alex_joni> unless you screw it up iirc
[12:39:29] <alex_joni> then they are lost :D
[12:39:30] <A-L-P-H-A> 2 was the one people could make into a mini computer... with two serial ports, and MMC/SD reader.
[12:39:43] <A-L-P-H-A> they could be reflashed, if you jtag them
[12:39:50] <alex_joni> oh.. really?
[12:39:55] <alex_joni> what chipset inside?
[12:40:01] <alex_joni> arm something iirc
[12:40:06] <A-L-P-H-A> sec
[12:40:56] <A-L-P-H-A> doesn't say
[12:41:45] <A-L-P-H-A> BCM3302 V0.8
[12:41:48] <A-L-P-H-A> here we go.
[12:42:11] <A-L-P-H-A> someone said there are some serial mods to it
[12:43:03] <alex_joni> guess you know openwrt
[12:43:20] <A-L-P-H-A> I actually use dd-wrt
[12:43:23] <A-L-P-H-A> not openwrt
[12:43:31] <A-L-P-H-A> same shit different pile.
[12:44:31] <alex_joni> ok.. just that it came up in google :)
[12:58:08] <A-L-P-H-A> there are two serial ports. :D
[13:57:29] <gpettit> Hi jmkasunich
[14:08:16] <gpettit> thanks jmkasunich for the streamer component, that should work well to stream the trajectories.
[14:49:38] <jmkasunich> hi gpettit
[14:49:51] <gpettit> hi
[14:50:04] <jmkasunich> interesting application
[14:50:49] <gpettit> it is a bit different
[14:51:16] <jmkasunich> is this a flight simulator or something?
[14:51:33] <jmkasunich> (I'm guessing something else, since the motions are predefined)
[14:52:18] <jmkasunich> camera positioning for movie special effects shots? ;-)
[14:52:25] <gpettit> kind of a flight simulator, it will be used to simulate flight, but only to test an instrument
[14:52:51] <jmkasunich> like artificial horizon, or some other gyro?
[14:53:10] <gpettit> to tell you the truth, I have no idea what the instrument will be
[14:53:16] <jmkasunich> ;-)
[14:53:31] <jmkasunich> "nobody tells me nuttin, I just work here"
[14:53:41] <gpettit> u got it
[14:54:11] <gpettit> I just see it as an opportunity to play with some cool stuff
[14:54:19] <jmkasunich> thats always fun
[14:55:03] <jmkasunich> what kind of kins are involved? hexapod/stewart platform (like the big flight simulators)? or more like a robot arm with the instrument on the end?
[14:56:11] <gpettit> It is a hexapod, so the kinematics to go from cartesian to joint space (inverse) is relatively straight forward.
[14:56:48] <jmkasunich> unless the position feedback is absolute, homing is going to be complex
[14:57:43] <gpettit> What I have done in the past is home each individual actuator
[14:58:06] <gpettit> once each actuator found its position, we were good to go
[14:58:09] <jmkasunich> can that be done without getting the platform into an indeterminate state?
[14:58:31] <jmkasunich> I thought with a hexapod you couldn't move just one actuator at a time
[14:59:35] <gpettit> you actually can move one actuator at a time. If the hexapod is assembled and you unhook one joint. The platform has one degree of freedom. Usually some arcing path
[15:00:21] <gpettit> Of course if you have keep out zones, then you can not use this method of homing because you have no idea were the platform is going
[15:00:52] <jmkasunich> if you unhook the actuator you intend to move then you can do whatever you want with it?
[15:01:20] <gpettit> I am sorry, the platform has one degree of freedom
[15:02:05] <jmkasunich> ok, I think I get it... its a 6DOF platform with 6 actuators, so each actuator _can_ be run individually
[15:02:23] <jmkasunich> and it has a DOF, but the response to one actuator is _not_ cartesean
[15:02:47] <gpettit> Right -- It doesn't seem right, but it works. Even after working out the mobility equations, I had to see for myself
[15:03:10] <jmkasunich> seems like you need a mode where you can jog individual actuators under operator control
[15:03:20] <jmkasunich> with eyes peeled to make sure you don't hit anything
[15:03:59] <gpettit> Hopefully for this app, nothing will be in the way
[15:04:00] <jmkasunich> then when you get one actuator close to the home switch, with the platform in a safe position, you give the home command and it goes the rest of the way to the switch by itseld
[15:05:08] <jmkasunich> how big is the platform? is this a machine that sits on a tabletop and has a payload of a few kg? or fills a room and the platform _is_ a tabletop (or bigger)?
[15:05:54] <gpettit> It is a small machine that will fit on a table top. In the past though we have built them as large as 10 feet in diameter
[15:06:13] <gpettit> We actually rode the 10 foot one, but it was really really slow
[15:06:21] <jmkasunich> sounds like fun
[15:07:20] <jmkasunich> anyway, getting back to the guts...
[15:07:42] <jmkasunich> homing means you'll need something other than streamer->kins->PID->motors
[15:07:42] <gpettit> Thanks again for all of your help
[15:07:55] <jmkasunich> you're welcome
[15:07:57] <gpettit> one that note
[15:08:32] <gpettit> Do you think I could have some type of user interface that talked to the EMC portion of the controller
[15:08:48] <gpettit> Then when I want to stream, I could switch over to the streamer
[15:09:05] <jmkasunich> its maybe possible
[15:09:07] <jmkasunich> but tricky
[15:09:23] <jmkasunich> because the point where you want to put the switch is inside the controller part
[15:09:36] <jmkasunich> stand by a moment, I want to find the URL of a drawing that will help
[15:10:14] <jmkasunich> http://linuxcnc.org/EMC2_Code_Notes.pdf
[15:10:38] <jmkasunich> page 9, figure 3.1
[15:10:59] <jmkasunich> is the block diagram of one "joint controller"
[15:11:24] <jmkasunich> it gets its commands from the kins, which in turn get their commands from the trajectory planner
[15:11:36] <jmkasunich> the joint controller handles homing and jogging and such
[15:12:09] <jmkasunich> unfortunately, at this point those parts are _not_ separate HAL chunks
[15:12:20] <jmkasunich> you don't want the trajectory planner
[15:13:03] <gpettit> What if I ignored the feedback portion of the controller, and just used it as a position command, sometimes the trajectory planner would be nice
[15:13:13] <gpettit> put the kins in a hal object
[15:13:51] <jmkasunich> not sure I follow
[15:13:59] <gpettit> then use either the position command from the joint controller or the streamer
[15:14:08] <A-L-P-H-A> freak'n hate losing my pocket knife all the time
[15:14:21] <jmkasunich> kins in a hal object, with 6 input pins (cartesean) and 6 output pins (joints), seems attractive at first glance
[15:14:47] <jmkasunich> but when I've looked closer, there always seems to be more complex interaction with the rest than just those 12 pins
[15:15:15] <jmkasunich> I have the disadvantage of no experience with non-trivial kins, and no such hardare to test on
[15:15:48] <gpettit> let me try to sketch a diagram
[15:16:09] <gpettit> This may take a little while
[15:16:27] <jmkasunich> emc also has a disadvantage: although originally designed to support non-trivial kins, and known to work well in the right hands, 95% or more of the user base, and thus most of the testing, is with trivkins machines
[15:16:50] <jmkasunich> the distinction between cartesean coordinates and joint coordinates tends to get muddy
[15:17:20] <jmkasunich> and things sometimes happen that can break non-trivkins without anybody noticing
[15:18:54] <gpettit> by putting the kinematics in a hal object the emc portion could just use the trivial kinematics
[15:20:03] <jmkasunich> but you want to insert your kins between the EMC outputs and the homing code, right?
[15:20:14] <jmkasunich> so the homing code acts on joint coords, not cartesean coords
[15:21:24] <gpettit> yes. I thought if the kins are in a HAL object, you could put some type of switch in front of them and ignore the kins when homing.
[15:21:47] <gpettit> not ignore, but bypass
[15:21:48] <jmkasunich> for "switch", HAL already as a 2 input multiplexer block
[15:21:53] <jmkasunich> so that part is covered
[15:22:01] <jmkasunich> the trick is where in the chain to put the mux
[15:22:19] <jmkasunich> and how to prevent the machine from going nuts when you flip the switch from one mode to another
[15:23:36] <gpettit> Your probably right, it could get messy. Need to think about this one. Still very much in the learning phase
[15:23:37] <jmkasunich> emc(trivkins) -> cartesean positions -> one mux input -> PID
[15:24:02] <jmkasunich> streamer -> cartesean positions -> kins -> joint positions -> other mux input -> PID
[15:24:08] <jmkasunich> thats one possibility
[15:24:31] <jmkasunich> but the idea of the motor positions changing from cartesean to joint when you flip the switch seems worrisome
[15:25:16] <jmkasunich> there is also a HAL block called limit3 - it takes one input (assumed to be a position command)
[15:25:47] <jmkasunich> its output tracks the input exactly, _unless_ that would violate position, velocity, or accel limits (set by hal parameters)
[15:26:18] <jmkasunich> that could go after the mux, to at least limit the nastyness if you flip the switch when the mux inputs are dramatically different
[15:27:09] <jmkasunich> if you look at figure 3.1 again, there is a mode switch in there
[15:27:33] <gpettit> good point. somehow I would need to make sure the positions are the same when the switch is flipped
[15:27:48] <gpettit> I see the switch
[15:28:16] <jmkasunich> when in "free" mode (uncoordinated movement, for jogs, homing, etc) the feedback thru the kins to the coordinated mode planner is used to make the coordinated command match feedback, so no transient when switching to coord mode
[15:28:45] <jmkasunich> when in coord mode, the free mode planner's output is forced to match the output of the cubic interpolator, so no transient when switching to free mode
[15:29:33] <jmkasunich> the value labeled "motor offset" is what is used for homing
[15:30:23] <jmkasunich> when you get the joint to the desired home position, motor offset is reloaded, to make the feedback position be the correct absolute position, regardless of what the motor position is (assuming an incremental encoder, it will be arbitrary)
[15:30:41] <jmkasunich> duh.... I just realise something
[15:30:56] <jmkasunich> don't _step_ the motor-offset
[15:30:58] <jmkasunich> ramp it
[15:31:02] <jmkasunich> that can be your manual control
[15:31:36] <jmkasunich> IOW, the streamer is sending a fixed position (wherever the last file ended)
[15:31:51] <jmkasunich> you ramp motor offset manually to get the joint close to the home switch
[15:32:05] <jmkasunich> then ramp it under program control to touch off on the switch
[15:32:08] <jmkasunich> then freeze it
[15:32:13] <jmkasunich> and you are homed (on that axis)
[15:32:38] <jmkasunich> am I making sense?
[15:33:18] <gpettit> Yes
[15:34:20] <jmkasunich> streamer -> limit3 (just in case) -> one input of summer
[15:34:30] <gpettit> got it
[15:34:39] <jmkasunich> manually controlled value -> other input of summer
[15:34:50] <jmkasunich> "manually" is a simplification
[15:35:18] <jmkasunich> damn, now my brain is going faster than I can put it into words
[15:35:58] <gpettit> In summary, I guess the trick would be to make sure the positions match when switching modes.
[15:36:06] <jmkasunich> yeah
[15:36:15] <jmkasunich> and the trick there might be that "manual" position
[15:36:19] <gpettit> This could be done by ramping to the first position
[15:36:20] <jmkasunich> it doesn't have to be manual
[15:36:33] <jmkasunich> assume you've just turned the machine on
[15:36:38] <jmkasunich> PIDs are _not_ yet enabled
[15:36:45] <jmkasunich> encoders are returning some arbitrary position
[15:36:52] <jmkasunich> streamer is outputting all zeros
[15:37:15] <jmkasunich> you need to get the feedback to match the command before you turn on PID
[15:37:20] <gpettit> first step needs to be load encoder values as current positoin
[15:37:34] <jmkasunich> well, the encoder values are what they are
[15:37:49] <jmkasunich> you'd add an offset to them to make them match current position
[15:37:57] <gpettit> I see
[15:38:08] <gpettit> ok im with you
[15:38:26] <jmkasunich> but if you just turned it on, you don't know current position (unless you require it to be "parked" in a certain spot on shutdown)
[15:38:56] <gpettit> here is what I have done in the past, lets see if I can remember
[15:40:08] <gpettit> machine fires up and you add an offset to zero the encoders, then if you command zero you get no motion. Next the machine hunts for the limit switch
[15:40:48] <gpettit> now you know where you are
[15:41:13] <gpettit> again correct the offset, zero, or load the correct value depending on the hardware
[15:41:14] <jmkasunich> ok, I know how to do the first part ;-)
[15:41:18] <jmkasunich> (in hal)
[15:41:32] <gpettit> cool
[15:41:33] <jmkasunich> you have the raw encoder position, and the current command (probably zero, but doesn't matter)
[15:41:52] <jmkasunich> run them both to a summer, so you get command - feedback
[15:42:06] <jmkasunich> run that to one input of a mux2
[15:42:15] <jmkasunich> tie the other input of the mux2 to its output
[15:42:21] <jmkasunich> (that makes it a track and hold)
[15:42:40] <jmkasunich> the output of the mux2 is now summed with the raw encoder position to get the correctted encoder position
[15:42:54] <jmkasunich> corrected encoder position, and command, go to the PID
[15:43:12] <jmkasunich> with the mux2 in track mode, the corrected encoder _always_ matches the command
[15:43:44] <jmkasunich> when it goes into hold mode, the corrected encoder follows the physical position
[15:43:56] <jmkasunich> so when the PID is disabled, the mux is in track mode
[15:44:06] <jmkasunich> when you enable the PID, the mux is in hold mode
[15:44:19] <jmkasunich> guarantees PID startup with no transient
[15:45:14] <jmkasunich> a pic would be worth a thousand word I bet, wish I had a handy way to draw and post
[15:45:28] <gpettit> I'm sketching, just a minute
[15:48:20] <gpettit> I get it
[15:48:35] <gpettit> You would actually use a different PID when homing
[15:48:47] <gpettit> part of the joint controller, right
[15:49:09] <jmkasunich> I'm thinking of doing it all in HAL right now
[15:49:19] <jmkasunich> replicating a few parts of the joint controller as needed
[15:50:48] <jmkasunich> unless you have a desire to use g-code, or need coordinated motion from point A to point B given only those two points (as opposed to streaming a path from A to B), I think most of EMC just makes life more complicated
[15:51:41] <jmkasunich> I bet a jogwheel would make manual control very nice
[15:52:09] <gpettit> that would be nice
[15:53:30] <jmkasunich> you have no need for feedback kins, right?
[15:53:34] <jmkasunich> just command kins?
[15:53:37] <gpettit> I think I had a stack overflow, let me do some more reading keeping in mind our discussion
[15:53:42] <gpettit> correct
[15:54:16] <gpettit> no feedback kins at this time
[15:54:29] <jmkasunich> in that case, a 12 pin HAL component for kins might work
[15:54:41] <jmkasunich> not sure how you deal with ambiguities though
[15:54:50] <gpettit> have done some playing around with controlling a hexapod in cartesian coords and it has some advantages, but computational intensive
[15:55:26] <gpettit> no singularities over the defined workspace
[15:55:54] <jmkasunich> so there are limits on the cartesean coords, and as long as you obey them you are OK?
[15:56:00] <gpettit> yes
[15:56:36] <jmkasunich> do the limits interact? (ie: if X is 0, A can go +/-50 degrees, but if X is 10, A can only go +/-30 degrees)
[15:59:56] <gpettit> They do, but generally the range to avoid singularities is much larger than the allowable workspace.
[16:00:13] <jmkasunich> good ;-)
[16:00:56] <jmkasunich> I just thought of another hal component to build
[16:00:58] <jmkasunich> a blender
[16:01:21] <gpettit> whats a blender
[16:01:28] <jmkasunich> like a mux, in that when the select input is 0, output = input 0, and when the select input is 1, output = input 1
[16:01:37] <jmkasunich> but the select input is a float, not a bit
[16:02:10] <jepler> isn't this just 'sum2'?
[16:02:12] <jmkasunich> output = input1 * select + input0 * ( 1-select)
[16:02:13] <jepler> "sum2 - 2-input summer, output = in0 * gain0 + in1 * gain1"
[16:02:23] <jepler> I guess the gains are parameters
[16:02:27] <jmkasunich> right
[16:02:35] <jmkasunich> blend ties both gains to a pin
[16:02:44] <jmkasunich> that way you can do smooth transfers
[16:03:06] <gpettit> nice!
[16:03:15] <jmkasunich> two poses, 6 values each, hooked to the inputs of 6 blenders
[16:03:27] <jmkasunich> ramp the select value, and the machine moves from pose 0 to pose 1
[16:04:13] <jmkasunich> jepler: time for you to commit 'comp', I want to write blender today
[16:05:10] <jepler> I can if you want me to
[16:05:27] <jmkasunich> yeah, I know I could download it and do the component outside of CVS, but I'm lazy
[16:06:01] <jmkasunich> it won't break anything will it? if that lib you need is missing, then you just can't do the .comp -> .c step
[16:06:41] <jepler> do you propose to put the generated .c files in?
[16:06:47] <jmkasunich> I wonder if we should have a subdirectory under src/hal/components, to hold .comp files
[16:06:48] <jepler> up to now, python is not required unless you want axis or documentation
[16:07:11] <jmkasunich> hmm
[16:07:42] <jmkasunich> in the ideal world, there would be a directory where you stick a .comp, and (assuming you have the dependencies) when you do make, the .c would be created, _and_ then compiled
[16:07:50] <jmkasunich> with no makefile changes ;-)
[16:07:52] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/blend.comp http://emergent.unpy.net/index.cgi-files/sandbox/blend.c
[16:08:01] <jmkasunich> right john, keep dreaming
[16:08:02] <jepler> oops, missing one _
[16:08:18] <jepler> fixed
[16:08:42] <jmkasunich> what's "open"
[16:08:54] <jepler> if "open" is false, then "select" is constrained to the interval [0,1].
[16:08:58] <jepler> if "open" is true, then it can go outside the interval
[16:09:11] <jmkasunich> oh
[16:09:14] <jmkasunich> freaky
[16:09:21] <jmkasunich> blend and extrapolate!
[16:10:13] <jepler> yeah
[16:10:47] <jmkasunich> I'm liking comp a LOT!
[16:11:05] <jmkasunich> we need to figure out how to integrate it soon
[16:11:16] <jepler> by the way, is the meaning of "direction" for parameters different than for pins?
[16:11:35] <jmkasunich> its pretty fscked is what it is
[16:11:44] <jepler> a "w" pin is written by the component, but a "w" parameter is writable with "setp"?
[16:11:58] <jmkasunich> yeah, thats pretty much it
[16:12:15] <jepler> I suspect that the python halmodule gets that wrong
[16:13:06] <jmkasunich> from hal.h:
[16:13:07] <jmkasunich> HAL_RD vs HAL_WR are inconsistent between pins and parameters.
[16:13:08] <jmkasunich> Someday I hope to fix this, but for now this comment will at
[16:13:08] <jmkasunich> least explain it:
[16:13:08] <jmkasunich>
[16:13:08] <jmkasunich> For pins, a WR pin is an _output_ from the module, and a RD
[16:13:09] <jmkasunich> pin is an input to the module. IOW, the type explains what
[16:13:12] <jmkasunich> the module does to the attached signal.
[16:13:13] <jmkasunich>
[16:13:15] <jmkasunich> For parameters, a WR pin is an input to the module, and RD
[16:13:17] <jmkasunich> pin is an output from the module. IOW, the type explains
[16:13:19] <jmkasunich> what the _user_ can do with the parameter.
[16:13:21] <jmkasunich>
[16:13:23] <jmkasunich> I know, it's messed up, sorry. :-/
[16:13:50] <jepler> I should have read that
[16:13:51] <jmkasunich> maybe we should define some more symbols:
[16:13:53] <A-L-P-H-A> who commited that?
[16:13:57] <jmkasunich> me
[16:13:57] <jepler> sorry. :-/
[16:14:04] <A-L-P-H-A> jmkasunich. :)
[16:14:11] <jmkasunich> HAL_INPUT = HAL_RD
[16:14:16] <jmkasunich> HAL_OUTPUT = HAL_WR
[16:14:24] <jmkasunich> HAL_IO = HAL_RD_WR
[16:14:29] <jmkasunich> and use those for pins
[16:14:36] <jmkasunich> stick with RD and WR for params
[16:15:01] <jmkasunich> could do that right now, it wouldn't break any existing code
[16:15:10] <jmkasunich> and comp can use the input/output names
[16:15:31] <jmkasunich> what do you think?
[16:16:49] <jepler> jmkasunich: I don't think the Python requirement is onerous --- it's part of the base system on fedora, debian, and ubuntu. if we want to include 'yapps2', it's only 45k, but both debian and ubuntu have yapps2 packages available
[16:17:02] <jmkasunich> ok
[16:17:17] <jepler> unlike axis, comp only needs 2.3, so debian sarge is fine
[16:17:39] <jmkasunich> then I'd suggest adding yapps2 to the dependencies list
[16:17:47] <jmkasunich> next step is makefile work
[16:18:03] <jepler> I'll try to do it tonight .. I should be doing my real job right now
[16:18:08] <jmkasunich> heh
[16:18:15] <jepler> you'll have to be around to help me make it go with the pre-kbuild systems, I suspect
[16:18:24] <jmkasunich> what are your thoughts on HAL_INPUT, etc?
[16:18:52] <jmkasunich> I'll be out tonight, but arround tomorrow
[16:19:12] <jepler> OK -- I'll just use the farm, or leave it broken if i can't fix it
[16:19:23] <jmkasunich> if you commit something tonight, I'll try to bash it into shape on the other systems tomorrow
[16:19:48] <jepler> unless there is a warning for using HAL_RD for a pin or HAL_INPUT for a parameter, I'm not sure it helps anything
[16:20:04] <jmkasunich> it makes the code more readable
[16:20:21] <jmkasunich> because input is obviously an input to the component
[16:20:42] <jmkasunich> pin in_1 float in;
[16:21:04] <jepler> I could sure change the words that are used in 'comp' to in, out, and io
[16:21:05] <jmkasunich> instead of pin in_1 float r
[16:21:37] <jmkasunich> have r continue to put HAL_RD in the C, in would put HAL_INPUT in the C
[16:21:46] <jmkasunich> I'll add the typedefs to hal.h now
[16:21:57] <jmkasunich> so handwritten modules will also have the benefit
[16:22:10] <jmkasunich> dunno if I'll go around changing modules right away
[16:22:15] <jmkasunich> maybe
[16:23:19] <jmkasunich> hmm
[16:23:28] <jmkasunich> do enums get typechecked?
[16:23:51] <jmkasunich> typedef enum {
[16:23:51] <jmkasunich> HAL_RD = 16,
[16:23:51] <jmkasunich> HAL_WR = 32,
[16:23:51] <jmkasunich> HAL_RD_WR = (HAL_RD | HAL_WR),
[16:23:51] <jmkasunich> } hal_param_dir_t;
[16:24:27] <jmkasunich> typedef enum {
[16:24:27] <jmkasunich> HAL_IN = 16,
[16:24:27] <jmkasunich> HAL_OUT = 32,
[16:24:27] <jmkasunich> HAL_IO = (HAL_IN | HAL_OUT),
[16:24:27] <jmkasunich> } hal_pin_dir_t;
[16:24:53] <jmkasunich> than change the pin_new functions to expect a hal_pin_dir_t, and the param_new functions to expect a hal_param_dir_t
[16:25:14] <jepler> it doesn't seem like they do
[16:25:15] <jepler> typedef enum e1 { A, B } e1; typedef enum e2 { C, D } e2;
[16:25:15] <jepler> void f(e1 e) { }
[16:25:15] <jepler> void g() { f(C); }
[16:25:24] <jepler> no warnings under 'gcc -Wall'
[16:25:31] <jmkasunich> I was afraid of that
[16:25:44] <jmkasunich> they're not much more than #defines with a pretty wrapper
[16:25:52] <jepler> in C++ they are checked but that's little help
[16:25:57] <jepler> ee.c:6: cannot convert `e2' to `e1' for argument `1' to `void f(e1)'
[16:26:42] <jmkasunich> of course, I could still define them that way, even if they're not checked
[16:26:50] <jmkasunich> I _don't_ think I can do this:
[16:26:57] <jepler> I was thinking that you could have a pair of bits that meant "for parameters", "for pins" or "grandfathered" .. that way you get a runtime warning
[16:27:02] <jmkasunich> typedef enum {
[16:27:09] <jmkasunich> RD = 16,
[16:27:14] <jmkasunich> IN = 16,
[16:27:41] <jepler> actually that seems to be accepted
[16:27:54] <jmkasunich> more proof that they're just #define in disguise
[16:28:13] <jmkasunich> I need to look at the code to see if there are bits free for your suggestion
[16:28:32] <jmkasunich> the fact that they aren't 1 and 2 makes me think they're packed
[16:28:33] <jepler> even if they are just checked at the "boundary" and then stripped
[16:28:41] <bill20r3> jepler, was it you I was talking to about my AVR development board a few days ago?
[16:28:52] <jmkasunich> they are, looks like I pack a three bit type code and the direction bits together
[16:28:56] <jepler> bill20r3: sure could be -- you thought you'd fried a transistor?
[16:29:01] <bill20r3> I got it fixed with a new fet.
[16:29:02] <jepler> bill20r3: what did you ever figure out?
[16:29:11] <bill20r3> thought I'd let you know what it turned out to be.
[16:29:21] <jepler> I'm glad you got it working
[16:29:31] <bill20r3> replaced the smd one with a TO-220 size, it's not pretty, but it works.
[16:29:35] <jepler> I hope you don't let the smoke out again
[16:30:19] <bill20r3> nah, I like to make new mistakes.
[16:31:45] <jepler> bill20r3: I think you told me what your project is with the AVR, but I've forgotten.
[16:32:22] <bill20r3> no real project yet, I'm just learning.
[16:33:11] <jepler> I know the feeling
[16:33:20] <jepler> but soon you'll have a dozen half-finished projects!
[16:34:03] <bill20r3> hell, I've got a dozen half-finished projects *now*.
[16:34:07] <bill20r3> at least.
[17:35:48] <jmkasunich> jepler: are these changes appropriate (and sufficient) for halmodule.cc
http://pastebin.ca/162580
[17:39:49] <A-L-P-H-A> nothing on a TV... everything is either crock hunter, or 9-11.
[17:39:51] <A-L-P-H-A> :/
[17:40:00] <robin_sz> hmmm ...
[17:40:31] <robin_sz> here we have a film about a guy who brings down a big building by firing a crocodile into it
[17:40:47] <A-L-P-H-A> that'd be worth watching
[17:41:04] <A-L-P-H-A> I got a few DVDs I could watch...
[17:41:22] <robin_sz> and anopther one about a terrorist plot that fails wen the guy gets killed by a stingray on his way to do the attack
[17:41:59] <CIA-8> 03jmkasunich 07HEAD * 10emc2/src/emc/iotask/ioControl.cc: changed HAL_RD and HAL_WR to clarify their meanings. The old ones are still supported, at least until I change over all the HAL components to use the new ones.
[17:42:00] <CIA-8> 03jmkasunich 07HEAD * 10emc2/src/hal/ (hal.h hal_lib.c hal_priv.h halmodule.cc): changed HAL_RD and HAL_WR to clarify their meanings. The old ones are still supported, at least until I change over all the HAL components to use the new ones.
[17:42:00] <CIA-8> 03jmkasunich 07HEAD * 10emc2/src/hal/utils/halcmd.c: changed HAL_RD and HAL_WR to clarify their meanings. The old ones are still supported, at least until I change over all the HAL components to use the new ones.
[17:42:02] <CIA-8> 03jmkasunich 07HEAD * 10emc2/src/emc/usr_intf/halui.cc: changed HAL_RD and HAL_WR to clarify their meanings. The old ones are still supported, at least until I change over all the HAL components to use the new ones.
[17:44:00] <CIA-8> 03jmkasunich 07HEAD * 10emc2/src/hal/hal_priv.h: changed HAL_RD and HAL_WR to clarify their meanings. The old ones are still supported, at least until I change over all the HAL components to use the new ones.
[17:45:06] <pier_gar> Hi all
[17:45:19] <A-L-P-H-A> run away... it's pier_gar!!!
[17:45:22] <A-L-P-H-A> quickly!
[17:45:25] <A-L-P-H-A> * A-L-P-H-A hides
[17:45:49] <pier_gar> leave me alone .....
[17:46:16] <pier_gar> just because I always pester you all in the list
[17:46:23] <pier_gar> it's unfair ;)
[17:47:31] <pier_gar> ok I'll go in my corner and stay still and quite :)
[17:49:24] <jepler> jmkasunich: that sure looks plausible
[17:49:44] <jmkasunich> I don't know what python code might invoke halmodule.cc
[17:49:52] <jepler> jmkasunich: axis and hal_manualtoolchange
[17:49:53] <jmkasunich> that might still be using the old names
[17:50:17] <jepler> I'll try to remember to look at that later
[17:50:27] <jmkasunich> I had to convert halui and iocontrol over to the new names because C++ does indeed check the types
[17:50:44] <jmkasunich> I'm working up the energy to change the rest of the modules and drop the old names completely
[17:50:53] <jmkasunich> but I should mow the grass first
[17:51:24] <jmkasunich> if you could change comp to use the new names I'd appreciate it
[17:52:55] <Lerneaen_Hydra> hi people
[19:03:22] <cradek> hi ray!
[19:03:38] <cradek> haven't seen you around these parts for a while
[19:09:14] <rayh> Hi Chris. Been away for a while.
[19:09:48] <cradek> a pleasant trip I hope
[19:10:05] <jmkasunich> greetings ray
[19:10:07] <rayh> It kept me busy
[19:10:29] <rayh> Hi John
[19:10:49] <jmkasunich> heh, printus interruptus
[19:10:56] <jmkasunich> I can
[19:11:17] <rayh> I was really surprised by it.
[19:11:20] <jmkasunich> I can't believe people would be so cheap as to plug and unplug a printer from the parport that runs their machine
[19:11:33] <jmkasunich> whats a parport card cost? $30 tops?
[19:11:36] <rayh> Well we do what we can.
[19:11:40] <cradek> I hope we have all the parport problems solved in emc2.
[19:11:45] <rayh> I've seen a few for $9
[19:12:08] <rayh> Why would it be different?
[19:12:17] <rayh> * rayh is all eyes.
[19:12:25] <cradek> we ask the kernel for exclusive access to the parport and refuse to run without it
[19:12:49] <jmkasunich> thats exactly the point - this user is using the _same_ parport for both
[19:12:50] <cradek> bdi4emc just crosses its fingers while all the printing stuff is also running
[19:12:54] <rayh> Oh. Okay.
[19:13:22] <rayh> Do we see an error message if the EMC can't get exclusive?
[19:13:27] <cradek> rayh: yes
[19:13:33] <rayh> Great.
[19:13:40] <cradek> rayh: it even tells you how to fix it (I think)
[19:13:49] <jmkasunich> that will prevent the unwanted motion
[19:14:00] <cradek> the emc2 ubuntu packages fix it for you
[19:14:03] <jmkasunich> but won't it also make it impossible to swap printer and step motors?
[19:14:22] <jepler> only hal_parport gets "exclusive access". the code hasn't been added for the elson parport boards
[19:14:23] <cradek> yes, and I might argue that's a feature
[19:14:46] <jmkasunich> cradek: I agree
[19:14:57] <rayh> Can the parport modules still be in there?
[19:15:04] <cradek> you could print but you'd have to load the parport_pc kernel module, then unload it before running emc again
[19:15:15] <rayh> Ah okay.
[19:15:24] <jmkasunich> you could have a couple of scripts I guess
[19:15:31] <jmkasunich> mount_printer, and umount_printer
[19:15:32] <jepler> if you have two parallel ports you can configure the linux "parport_pc" driver to only register the one that is to be used with a printer
[19:15:46] <cradek> right, and that would be the best idea
[19:15:46] <jmkasunich> unplug the steppers, plug in the printer, run mount_printer
[19:15:52] <rayh> I can see that.
[19:16:05] <cradek> or a usb printer
[19:16:24] <cradek> I bet many modern printers have both, it's just a matter of using the right cable
[19:16:27] <jmkasunich> right - these days usb printer is the norm
[19:16:31] <rayh> That would have been the easy choice but BDI and Ubuntu don't have the lexmark driver.
[19:16:52] <rayh> I've got a usb to print cable that works great here.
[19:17:04] <cradek> aha I remember that at fest
[19:17:14] <Lerneaen_Hydra> rayh: fast enough for EMC?
[19:17:31] <rayh> No I haven't tried that.
[19:17:32] <cradek> Lerneaen_Hydra: either you are joking or you misunderstand ...
[19:17:37] <Lerneaen_Hydra> then again, 20khz isn't really "fast" by any stretch of the mind
[19:17:40] <Lerneaen_Hydra> heh
[19:17:47] <rayh> It's an ATEN brand.
[19:18:10] <rayh> But we don't have the usb driver either.
[19:18:18] <Lerneaen_Hydra> cradek: how do you mean?
[19:18:59] <cradek> Lerneaen_Hydra: a usb-parallel adapter will work nothing like a parport, and can't possibly be transparent to emc
[19:19:00] <jmkasunich> step/dir out the parport works _only_ because that is one of the few places in the PC where the code can write direclty to hardware and have pins change state immediately
[19:19:09] <jmkasunich> running it thru usb would totally fsck it up
[19:19:57] <Lerneaen_Hydra> yeah, that's sort of what I was thinking. though I can't say I really know lots about the latency/related issues with usb
[19:22:22] <Lerneaen_Hydra> bah. I'm getting tired now.
[19:22:25] <Lerneaen_Hydra> 'night people
[19:22:31] <jepler> chips like ft245 have a mode where you can send a digital waveform which is buffered and clocked out at a set rate. if you don't mind the latency, and can consistently avoid underruns, it seems like you could drive steppers or read quadrature inputs this way. but I'm sure not offering to write it.
[19:22:41] <Lerneaen_Hydra> oh, right
[19:23:01] <Lerneaen_Hydra> that's what I was thinking about, latency from commanded write to the actual pin changing
[19:23:20] <Lerneaen_Hydra> how much latency does parport have in that aspect?
[19:23:27] <jepler> anecdotally, about 1 microsecond
[19:23:50] <jmkasunich> or less
[19:24:14] <Lerneaen_Hydra> so different states are qeued somewhere for base period < 1microsecond?
[19:24:21] <Lerneaen_Hydra> err
[19:24:28] <Lerneaen_Hydra> *smacks head*
[19:24:28] <jepler> that small a base period is basically unattainable
[19:24:32] <Lerneaen_Hydra> yeah
[19:24:37] <Lerneaen_Hydra> that's what I just realised
[19:24:39] <jepler> "mu"
[19:24:57] <Lerneaen_Hydra> here I was thinking 20k picoseconds is 0.2 µS, heh
[19:25:09] <Lerneaen_Hydra> and not 20µs
[19:25:34] <Lerneaen_Hydra> anyway, 'night
[19:25:42] <jepler> actually, I meant 'mu' in this sense:
http://www.angelfire.com/electronic/bodhidharma/mu.html
[19:25:51] <jepler> I didn't realize I meant two things at once
[19:26:53] <Lerneaen_Hydra> haha, nice
[19:27:36] <Lerneaen_Hydra> 'night
[19:27:43] <jepler> goodnight!
[19:28:56] <jepler> anyway .. this hypothetical 'mount_printer' script would read something like: 'sudo modprobe -i parport_pc', and the reverse would just be 'sudo rmmod parport_pc'. sudo would be requried, emc_module_helper will not do anything with parport_pc
[19:29:46] <jepler> to enable just a single printer port for linx use, the user would change the /etc/modprobe.d/emc2 to read something like: options parport_pc io=0xNNN
[19:30:06] <jepler> if you actually do either of these things, please document it somewhere after it's tested and working
[19:30:57] <jepler> (trying to re-rail the earlier conversation here...)
[20:00:24] <robin_sz> meep?
[20:02:40] <robin_sz> picked up that nice big slide today
[20:03:03] <robin_sz> or rather my mad mate picked it up for me ... going to make a nice axis that is.
[20:06:23] <alex_joni> evening gents
[20:06:53] <jepler> *yawn*
[20:07:09] <alex_joni> hey jeff
[20:07:14] <alex_joni> still at work?
[20:09:16] <jepler> yep
[20:09:44] <alex_joni> explains the "yawn"
[20:14:19] <acemi> python emc module can be used with python2.3 without problem, isn't it?
[20:17:21] <jepler> acemi: generally, a ".so" python module can only be used with the same version of python that compiled it.
[20:17:36] <jepler> acemi: at the very least, you get a warning at import time
[20:17:58] <jepler> I don't know of any features I used in the emc module that are not available in python 2.3, but I have not carefully avoided such features
[20:19:35] <acemi> ok jepler, thanks
[20:20:26] <robin_sz> today was a very busy day ...
[20:20:37] <robin_sz> infact, this week is a very busy week!
[20:22:09] <robin_sz> strangely, at the beginning of the week, we had almost no orders ... now we have so much I dont know where we will manage to do it all!
[20:31:27] <alex_joni> that's good to hear
[21:02:49] <roel01> Hi all
[21:04:58] <alex_joni> hello roel01
[21:10:04] <roel01> there is someone who can turbo program pascal
[21:12:59] <alex_joni> I used to
[21:13:13] <alex_joni> 8? years ago..
[21:13:31] <alex_joni> although it was borland pascal :)
[21:14:27] <roel01> got source files for a 16 bit card (pdma)
[21:14:54] <cradek> roel01: try this command to find a more appropriate channel: /msg chanserv list *pascal*
[21:15:56] <alex_joni> roel01: what card is it? and what do you want to do with it?
[21:16:26] <roel01> im trying to build a laser photoplotter
[21:17:04] <alex_joni> got a link to that card?
[21:18:02] <roel01> http://www.acceed.com/product.phtml?ax5016
[21:20:43] <roel01> driver.obj differs a bit from the sourse i got
[21:22:01] <alex_joni> ok, so you basicly have that board
[21:22:07] <alex_joni> and pascal sources for it
[21:22:12] <alex_joni> and want it supported in emc ?
[21:23:04] <roel01> i know some guys in here maybe they could help
[21:23:23] <alex_joni> roel01: we talked in the past :)
[21:23:33] <roel01> i know :)
[21:23:48] <alex_joni> can you mail me the sources.. I'll have a look at them tomorrow
[21:24:08] <alex_joni> but if they are accompanied with some binary part, then there's not much we can do
[21:35:07] <CIA-8> 03jepler 07HEAD * 10emc2/src/emc/usr_intf/axis/scripts/ (axis.py hal_manualtoolchange.py haltest.py): use new HAL_IN HAL_OUT constants
[21:36:06] <alex_joni> roel01: got my email addy?
[21:36:43] <roel01> nope
[21:36:59] <alex_joni> alex.joni AT robcon.ro
[21:37:15] <alex_joni> the board looks fairly old (ISA)
[21:37:26] <alex_joni> I suspect an 8255 on it for the DIO
[21:38:32] <alex_joni> hmmm.. they say they even provide drivers in C ?
[21:39:10] <roel01> jes there are but my source is tp
[21:40:41] <alex_joni> ok, I'll have a look if you send it
[21:41:19] <alex_joni> for now .. I'm off to bed
[21:41:21] <alex_joni> night all
[21:41:32] <roel01> cu alex
[21:53:13] <pier> night!
[22:03:00] <roel01> night all
[22:16:05] <jepler> Jymmm: did you get my message about LIBGL_NO_DRAWARRAYS ?
[22:16:47] <jepler> Jymmm: basically, before trying to start emc2/axis on the ubuntu machine, run this command: export LIBGL_NO_DRAWARRAYS=1
[22:16:53] <jepler> I think it might work then
[22:17:38] <Jymmm> jepler: Yes I did, thank you. Though I probably won't be able to try it out for a few months of longer. I'm having to tear down my setup and hopefully I'll find a place to live that I can setup again.
[22:18:17] <jepler> Jymmm: yeah I saw some of that conversation. I hope things settle down soon
[22:19:13] <Jymmm> jepler: Not looking too good so far. Still no prospects thus far. Not even any without a garage, much less "pet friendly" places.
[22:43:03] <CIA-8> 03jepler 07HEAD * 10emc2/bin/.cvsignore: add "comp", a program for writing HAL boilerplate
[22:43:06] <CIA-8> 03jepler 07HEAD * 10emc2/debian/ (control control.in): add "comp", a program for writing HAL boilerplate
[22:43:08] <CIA-8> 03jepler 07HEAD * 10emc2/src/emc/usr_intf/axis/scripts/ (comp.g .cvsignore): add "comp", a program for writing HAL boilerplate
[22:43:08] <CIA-8> 03jepler 07HEAD * 10emc2/src/hal/components/ (7 files): add "comp", a program for writing HAL boilerplate
[22:43:08] <CIA-8> 03jepler 07HEAD * 10emc2/src/emc/usr_intf/axis/Submakefile: add "comp", a program for writing HAL boilerplate
[22:43:09] <CIA-8> 03jepler 07HEAD * 10emc2/src/ (Makefile configure configure.in): add "comp", a program for writing HAL boilerplate
[22:44:47] <CIA-8> 03compile-farm 07BDI-Live rc46 (2.4.25-adeos) * 10emc2head/: build FAILED ; see
http://linuxcnc.org/compile_farm/emc2head_slot4_log.txt
[22:45:30] <CIA-8> 03compile-farm 07BDI-4.20 (2.6.10-adeos) * 10emc2head/: build FAILED ; see
http://linuxcnc.org/compile_farm/emc2head_slot5_log.txt
[22:45:47] <CIA-8> 03compile-farm 07BDI-2.18 (2.2.18-rtl3.0) * 10emc2head/: build FAILED ; see
http://linuxcnc.org/compile_farm/emc2head_slot2_log.txt
[22:45:54] <CIA-8> 03compile-farm 07BDI-TNG (2.4.18-rtai) * 10emc2head/: build FAILED ; see
http://linuxcnc.org/compile_farm/emc2head_slot3_log.txt
[22:46:57] <CIA-8> 03compile-farm 07Ubuntu 5.10 (2.6.12-magma) * 10emc2head/: build FAILED ; see
http://linuxcnc.org/compile_farm/emc2head_slot7_log.txt
[23:05:50] <robin_sz> coo, that was Roel ... havent seem him about for ages
[23:53:29] <danex> * danex is away: Away at the moment