Back
[02:54:07] <cradek> interesting. a new guy who wants to do something with ethernet
[02:54:15] <jmkasunich> yep
[02:54:38] <jmkasunich> and he recognizes the #1 problem - low level RT drivers for all the NICs in the world
[02:54:42] <cradek> yep
[02:54:48] <cradek> he seems plenty clueful
[02:55:27] <cradek> I bet it would be easyish to write for a particular card. But how to pick one that will be available for a while?
[02:57:18] <jmkasunich> these days, "card" is usually the mobo
[02:57:36] <jmkasunich> although you'd probably want to keep the mobo connector for the internet, and use a dedicated NIC for the RT link
[02:57:39] <cradek> no, you'd always want to use the 'second' interface for this
[02:57:46] <cradek> right
[02:59:06] <jmkasunich> at newegg, intel has 41! NICs, linksys 8, dlink 6, SMC 6, 3com 5
[02:59:46] <jmkasunich> there are 64 PCI ones, 26 PIC-express
[02:59:47] <cradek> can you still get an intel etherexpress pro?
[03:00:14] <cradek> I was trying to think of the one card that's most saturated the world over the past several years
[03:00:30] <jmkasunich> 3com 3C905?
[03:00:39] <cradek> pci: intel eepro, isa: 3c509/590
[03:03:00] <cradek> I know, we need scsi servo drives
[03:03:06] <jmkasunich> heh
[03:03:43] <jmkasunich> I wonder if the Linux NIC drivers are structured in such a way that we could steal the register-level/packet-level driver code?
[03:04:44] <cradek> I know nothing about kernel drivers...
[03:06:40] <jmkasunich> ditt
[03:06:41] <jmkasunich> o
[03:06:54] <cradek> I wrote one once, but for freebsd
[03:07:00] <cradek> never for linux
[03:07:24] <jmkasunich> probably a while ago, right?
[03:07:29] <cradek> many moons
[03:07:46] <jmkasunich> they seem to change the driver architecture every couple kernel versions anyway
[03:07:54] <jmkasunich> and never in the direction of simpler
[03:08:01] <cradek> yes I'm sure it would be constant work to keep up
[03:08:57] <jmkasunich> CNC lathe benefit #17: being able to stand far enough away to avoid the hot chips
[03:10:03] <cradek> I had a blast making the last three of four parts the other night. I set up all three tools for the job and could just swap them in and let it go
[03:10:14] <cradek> usually cnc is not a huge win for me, doing one-offs
[03:10:28] <cradek> well unless I want an arc :-)
[03:10:51] <jmkasunich> what parts were those? for the futon frame?
[03:11:16] <cradek> yeah just some steel with holes drilled and pockets milled
[03:12:14] <jmkasunich> thats gotta be some futon
[03:13:01] <jmkasunich> the brick shithouse of futon frames ;-)
[03:13:30] <cradek> it had legs in the middle to support the weight - they have to come off to fit over the wheel-well
[03:13:40] <cradek> so it has to be a LOT stronger than it was.
[03:13:55] <jmkasunich> ah, so you made it strong enough to not need the middle legs
[03:14:20] <cradek> yes
[03:14:20] <jmkasunich> I suppose you could have kept the middle legs and shortened them to set ON the wheelwell
[03:14:45] <cradek> no, because to put it in bed mode, it has to be moved out from the wall
[03:15:01] <jmkasunich> * jmkasunich demonstrates lack of futon knowledge
[03:15:09] <jmkasunich> they switch from couch to bed?
[03:16:08] <cradek> yes
[03:16:18] <cradek> they can just fold down flat
[03:17:10] <cradek> they're a very functional/flexible piece of furniture
[03:18:03] <cradek> http://en.wikipedia.org/wiki/Futon
[03:18:09] <jmkasunich> already reading
[03:18:15] <cradek> we have the US type model of course
[03:20:13] <jmkasunich> you use that just for the bus, or do you sleep on them at home too?
[03:20:29] <cradek> this one will stay in the bus, but we have a couple at home too
[03:21:02] <cradek> nice for a TV room. you can watch sitting or laying, and a surprise visitor can comfortably sleep there too
[03:22:45] <jmkasunich> I have a sofa-bed in the family room for the same reason
[03:22:48] <cradek> also, they're very cheap compared to sofas
[03:23:06] <cradek> and in the case of a pet-based disaster they're much better
[03:23:56] <jmkasunich> better because they're easier to clean? or cheaper to replace?
[03:24:42] <cradek> both. often the mattress has a removable cover.
[03:29:56] <cradek> goodnight
[03:30:00] <jmkasunich> goodnight
[14:42:20] <alex_joni> jmkasunich: around?
[14:42:43] <alex_joni> I started working on the joint/axis fixing
[14:42:55] <alex_joni> and a **LOT** of things will get changed
[14:43:21] <alex_joni> including NML commands
[14:43:35] <alex_joni> but there are a couple referring to jogging which I'm not sure how should be named
[14:43:59] <jmkasunich> which ones?
[14:44:06] <alex_joni> (basicly jogging is usually done in joint space, so the regular jogs should be EMC_JOINT_JOG and EMC_JOINT_ABORT right?)
[14:44:30] <alex_joni> and only teleop jogging is in carth. space and thuse refers to EMC_AXIS_whatever
[14:44:48] <jmkasunich> well, I dunno if you need to distinguish
[14:45:03] <jmkasunich> you are either in joint mode (free) or axis mode (teleop)
[14:45:05] <alex_joni> so far I will be touching close to all files
[14:45:37] <jmkasunich> so you could just have "EMC_JOG" with an axis/joint number, and it will jog an axis or a joint depending on the mode it is in
[14:45:57] <alex_joni> yes, but it's treated differently atm
[14:46:12] <alex_joni> jogs in joint mode are done with position specification
[14:46:18] <alex_joni> and teleop with vel. prescription
[14:46:27] <jmkasunich> that is planned to change
[14:47:09] <alex_joni> ok, so the code to check if a joint/axis is out of bounds then referrs to max(EMC_AXIS_MAX, EMC_JOINT_MAX) ?
[14:47:13] <jmkasunich> at the EMCMOT level, jogs are done with "EMCMOT_JOG_CONT" (move till stopped), EMCMOT_JOG_INCR (incremental) and EMCMOT_JOG_ABS (absolute)
[14:47:16] <alex_joni> for jogging I mean
[14:47:46] <jmkasunich> not to max(those-two-things)
[14:47:54] <jmkasunich> just to whichever one is appropriate
[14:48:00] <alex_joni> say the GUI wants to jog something
[14:48:07] <alex_joni> tkemc to be rpecise
[14:48:10] <alex_joni> precise..
[14:48:14] <jmkasunich> ok
[14:48:24] <alex_joni> it calls sendJogCmd(6)
[14:48:26] <jmkasunich> (be advised, I just woke up)
[14:48:51] <alex_joni> which 6 needs to be < joint_max if in joint mode, and < axis_max if in carth. space
[14:49:03] <alex_joni> but motion does the check too.. right?
[14:49:23] <jmkasunich> currently motion checks jogs against joint limits
[14:49:27] <alex_joni> hmm, I can probably just drop the checks before the command is sent
[14:49:39] <alex_joni> (I really mean joint_nr out of bounds checking)
[14:49:50] <alex_joni> like joint Nr. 6 on a 3-joint machine
[14:49:58] <jmkasunich> oh, I understand
[14:50:13] <jmkasunich> IMO, there should _always_ be 9 cartesean axes
[14:50:30] <alex_joni> right, I agree on that
[14:50:32] <jmkasunich> there will always be 9 at the motion level
[14:50:50] <alex_joni> and above too
[14:50:51] <jmkasunich> however, a GUI may want to display less than that
[14:51:02] <alex_joni> right, based on what's appropriate for the machine
[14:51:49] <jmkasunich> anyway, command.c should NEVER rely on stupid user code for checks
[14:52:14] <jmkasunich> if it doesn't check that axis_num < 9 or joint_num < number of joints on this machine, that is a bug
[14:53:05] <alex_joni> right
[14:53:18] <alex_joni> this is going to be one huge code change
[15:03:15] <alex_joni> can I ask you to look at something?
[15:03:54] <alex_joni> I'll commit a changed emc.hh in the branch I made (with changed NML command names)
[15:04:07] <alex_joni> have a look if I overchanged any ..
[15:06:50] <CIA-22> EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/nml_intf/emc.hh: changed message names from _AXIS_ to _JOINT_
[15:10:19] <alex_joni> cvs diff | wc -l
[15:10:21] <alex_joni> 1680
[15:10:27] <alex_joni> (and I barely started..)
[16:03:17] <BigJohnT> interesting... during a MDI move from halui the halui.program.stop and halui.estop.activate have no effect on the running MDI
[16:04:25] <alex_joni> hmm.. estop.activate should work
[16:05:11] <BigJohnT> that's what I thought but it does not change states until the MDI is over
[16:05:53] <BigJohnT> If you toggle the halui.estop.activate during the MDI it does nothing
[16:05:55] <cradek> isn't there an abort pin?
[16:06:02] <BigJohnT> yes
[16:07:12] <cradek> that should stop mdi, like hitting keyboard escape
[16:07:57] <BigJohnT> nope just tried it and the mdi completed
[16:09:04] <cradek> are you talking about an mdi issued from halui itself?
[16:09:11] <BigJohnT> yes
[16:09:29] <BigJohnT> with [HALUI]
[16:09:29] <BigJohnT> MDI_COMMAND = G0 X0 Y0 Z0
[16:10:40] <BigJohnT> they all work if I start a g code program running from halui as expected
[16:11:37] <alex_joni> the halui.estop.activate should be valid at all times
[16:11:42] <alex_joni> independent from mdoe
[16:11:43] <alex_joni> mode
[16:11:44] <cradek> I see that halui stops reading its other inputs while the mdi is running.
[16:11:50] <BigJohnT> it's not
[16:11:59] <cradek> this is a halui bug
[16:12:15] <BigJohnT> want me to file a bug report on it?
[16:12:23] <cradek> yes please do
[16:12:29] <BigJohnT> will do
[16:13:28] <cradek> halui tries to put the machine back in Manual mode after the MDI command is complete. It does this by waiting for it to complete, then switching modes back
[16:14:02] <BigJohnT> ok I'll add that to the bug report
[16:16:28] <alex_joni> BigJohnT: assign it to cradek (he put the mdi stuff in there :P)
[16:16:34] <alex_joni> kidding, you can assign it to me
[16:16:35] <BigJohnT> ok
[16:16:47] <cradek> haha
[16:21:30] <BigJohnT> it gave it to jmk automagicly
[16:21:36] <BigJohnT> bug report 1929461
[16:22:10] <alex_joni> I'll change it
[16:22:19] <BigJohnT> ok
[16:22:42] <alex_joni> * alex_joni wonders why jmk got it automatigally
[16:23:04] <BigJohnT> dunno it didn't give me a chance to set it...
[16:23:54] <alex_joni> ah, there's no halui cathegory
[16:24:53] <BigJohnT> nope
[16:28:11] <BigJohnT> bbl
[16:31:00] <cradek> heh, category hal :-)
[16:31:18] <alex_joni> well.. as good as any other
[16:31:32] <cradek> yeah, halui surely needs its own
[16:43:19] <alex_joni> I added the 'halui' cathegory, and set it to autoassign it to me
[17:55:56] <skunkworks> Running 0x0ff - locked up after about an hour and a half
[17:56:13] <skunkworks> alex_joni: ^
[17:56:35] <alex_joni> so it seems proportional to the number of inputs?
[17:57:03] <skunkworks> seems to be..
[17:57:10] <skunkworks> Does that make some sort of sense?
[17:58:22] <alex_joni> what's the driver called again?
[17:59:23] <skunkworks> pci_8255.c
[17:59:32] <alex_joni> yeah, found it
[18:04:07] <alex_joni> skunkworks: does it lock up even if you don't add the read-all function to a thread?
[18:06:09] <skunkworks> let me look back at the history - I think we had tried that..
[18:08:24] <alex_joni> what's your loadrt invocation?
[18:08:44] <skunkworks> hold on
[18:09:48] <skunkwork1> oadrt pci_8255 io="0x1000" dir=0x0ff
[18:10:11] <skunkwork1> addf pci8255.read-all servo-thread 1
[18:10:24] <skunkwork1> addf pci8255.write-all servo-thread -1
[18:11:06] <skunkworks> *l
[18:11:27] <alex_joni> skunkworks: try it without the read-all
[18:13:59] <skunkwork1> running right now with 0xfff and no read-all
[18:14:04] <skunkwork1> wait and see
[18:14:20] <alex_joni> ok
[18:23:41] <skunkworks> according to the irc history - it did lock up.. (you guys must hate me)
[18:24:07] <alex_joni> not really
[18:24:08] <skunkworks> (without the read-all )
[18:24:36] <skunkworks> damn users. ;)
[18:28:57] <alex_joni> can you confirm it again?
[18:29:26] <skunkworks> waiting. Seems to be running so far.
[18:32:52] <skunkwork1> http://www.pastebin.ca/963631
[18:32:58] <skunkwork1> running still
[18:35:18] <alex_joni> ok :)
[18:36:50] <skunkworks> I am very ocd about running 0x000 first to see if I can physically change and output - so yesterday I might have ran it first with read-all and 0x000 - then exited and removed the read_all and ran it agian. (may have already been screwed up)
[18:37:24] <alex_joni> probably
[18:52:22] <alex_joni> still going?
[18:52:28] <skunkworks> so far
[19:28:46] <skunkworks> still running
[19:28:46] <alex_joni> skunkworks: still going?
[19:28:49] <alex_joni> heh
[19:29:05] <skunkworks> :)
[19:34:28] <alex_joni> did you also change the time?
[19:35:21] <alex_joni> we just went +1 last night
[19:48:35] <skunkwork1> daylight savings time?
[19:48:56] <skunkwork1> we changed a few weeks ago.. One of our fearless presidents changes.. :(
[19:49:08] <skunkwork1> still running
[19:50:00] <alex_joni> skunkworks: then I bet the culprit is somewhere inside read-all
[19:52:35] <skunkwork1> :)
[20:03:02] <alex_joni> skunkwork1: if you feel like debugging it further, you can enable individual reads
[20:03:19] <alex_joni> or wait for jepler, I'm sure this is quite valuable info to him
[20:10:57] <alex_joni> bleah, these errors won't go away
[20:11:14] <alex_joni> I fixed about 500 of them so far.. can't see any light at the end of the tunnel
[21:18:28] <skunkworks> still running
[21:18:44] <alex_joni> ok, I'd say you've proven that the read-all function is the culprit
[21:18:59] <alex_joni> now I would try to define them all as inputs
[21:19:06] <alex_joni> and start running with one of the read functions
[21:19:17] <alex_joni> see if only one or any of them makes it freeze
[21:29:20] <alex_joni> ok, nuff for today
[21:29:33] <alex_joni> skunkworks: you might want to grab a boat or soemthing :)
[21:29:38] <skunkworks> so - say run it with pci8255.0.0.read
[21:29:49] <alex_joni> yeah, that's what I meant before
[21:29:49] <skunkworks> function running and see if it locks up.
[21:29:54] <alex_joni> right
[21:29:57] <skunkworks> ok
[21:30:05] <alex_joni> if that locks up, trey 0.1.read
[21:30:14] <skunkworks> can do :)
[21:32:38] <skunkwork1> running.
[21:33:04] <CIA-22> EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: first pass at fixing joints/axes issues. doesn't quite compile yet..
[21:33:04] <CIA-22> EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/usr_intf/ (7 files): first pass at fixing joints/axes issues. doesn't quite compile yet..
[21:33:04] <CIA-22> EMC: 03alex_joni 07joints_axes * 10emc2/src/Makefile: first pass at fixing joints/axes issues. doesn't quite compile yet..
[21:33:06] <CIA-22> EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/motion/ (command.c homing.c motion.c motion.h usrmotintf.cc): first pass at fixing joints/axes issues. doesn't quite compile yet..
[21:33:09] <CIA-22> EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/nml_intf/ (8 files): first pass at fixing joints/axes issues. doesn't quite compile yet..
[21:33:15] <CIA-22> EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/task/ (emctask.cc emctaskmain.cc taskintf.cc): first pass at fixing joints/axes issues. doesn't quite compile yet..
[21:39:01] <CIA-22> EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: undo last commit. didn't mean to add that hear. it's in TRUNK already, and will only hurt the merge
[21:59:27] <skunkworks> skunkwork1: still working?
[22:05:27] <skunkworks> skunkwork1: still working?
[22:05:43] <skunkworks> Heh - never mind. Thought I would get an irc reply.
[22:06:34] <skunkworks> So far it is still running with just the first read running pci8255.0.0.read
[22:07:05] <skunkworks> it is working - I can change an input and it changes in hal
[23:47:05] <skunkworks> it is still running.. I wonder what I should do next?