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