Back
[09:08:05] <skunksleep> pcw_home: when are you expecting the 7i73 in?
[09:55:15] <pcw_home> Uh oh, we found one and they shipped to to someone, I thought it was you :-(
[09:55:47] <pcw_home> they kit is there so it should not be too long
[10:32:44] <mozmck> pcw_home: did you ever figure out how to get NetworkManager to not touch the interface that the 7i80 is attached to?
[10:33:41] <pcw_home> Yes theres a token you can use to make it ignore an interface
[10:39:13] <pcw_home> http://askubuntu.com/questions/21914/how-can-i-make-networkmanager-ignore-my-wireless-card
[10:42:47] <mozmck> ok, I found that information about the networkmanger.conf managed=false and wanted to make sure you had found it or something that worked.
[10:44:54] <pcw_home> well... I didnt actually try it yet because Ive been swapping MBs around so
[10:44:56] <pcw_home> its easier to just click on an interface name for that MB to enable it
[10:46:46] <mozmck> That is set in my NetworkManager.conf by default, and I think in Debian wheezy as well, so simply adding the interface to /etc/network/interfaces as per the instructions here should work:
http://www.linuxcnc.org/docs/html/man/man9/hm2_eth.9.html
[10:48:21] <pcw_home> This method looks to be the easiest
[10:48:22] <pcw_home> unmanaged-devices=interface-name:eth3
[10:50:35] <pcw_home> the stuff in the hm2 manpage prevents linux from sending packets on the RT interface
[10:50:36] <pcw_home> but for a real machine you would also want to disable the network manager from poking at the interface
[10:53:44] <mozmck> Yes, but if [ifupdown] managed=false is set then any interface listed in /etc/network/interfaces should be ignored by NetworkManager altogether.
[10:54:29] <mozmck> So it looks like the unmanged-devices=.... should not need to be used
[10:55:18] <mozmck> https://wiki.debian.org/NetworkManager
[10:55:22] <pcw_home> OK maybe but dont wnt to lose the ability for NM to manage normal interfaces
[10:56:05] <mozmck> yes, so for normal interfaces, just don't mention them in /etc/network/interfaces
[10:56:23] <pcw_home> OK I see so if you use the older interfaces method its supposed to leave them alone
[10:56:39] <mozmck> yes, looks like.
[10:56:56] <mozmck> and that is the default setting in debian and linux mint - probably ubuntu as well.
[10:57:03] <pcw_home> I'll have to give that a try
[10:57:18] <mozmck> there is just usually nothing in the /etc/network/interfaces file anymore.
[10:58:23] <mozmck> mine has: "auto lo" and "iface lo inet loopback" and that is all.
[10:58:28] <mozmck> by default
[10:58:36] <mozmck> bbl
[11:02:15] <skunkworks> pcw_home: no problem.
[12:10:21] <seb_kuzminsky> skunkworks: rob ellenberg and i would like to pick your brains about TP testing sometime - i think you have more experience in this area than anyone
[12:17:03] <skunkworks> sure - but all I really do is run large scary programs and make sure they don't violate...
[12:19:07] <skunkworks> I do stand on one foot at the time though...
[12:20:42] <seb_kuzminsky> cool
[12:24:45] <skunkworks> I could see some runtesst though running through gcode looking for constraint violations..
[12:26:24] <seb_kuzminsky> yeah, that's one class of test that would be useful
[12:27:15] <seb_kuzminsky> the other class is smaller tests of just a handful of hal changes and/or motion commands, without task & interp & the rest of linuxcnc running
[12:28:10] <seb_kuzminsky> something like this:
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=rss;h=refs/heads/seb/2.7/sam
[12:28:44] <seb_kuzminsky> you currently check for constraint violations with a pyvcp panel that tracks the max & min accels, right?
[12:29:07] <seb_kuzminsky> maybe we could connect accel to a window comparator, to the estop chain
[12:30:37] <seb_kuzminsky> rob wants to do a google hangout instead of irc, are you free tonight at 10 PM mountain time?
[12:38:15] <seb_kuzminsky> well hi rob_ellenberg
[12:38:35] <rob_ellenberg> hi, just got x-chat installed
[12:38:39] <rob_ellenberg> much easier than the web client
[12:38:42] <seb_kuzminsky> cool
[12:39:05] <seb_kuzminsky> sam (skunkworks) and i were just chatting about motion-testing
[12:39:14] <rob_ellenberg> good timing :)
[12:39:46] <seb_kuzminsky> i'm at my dayjob and can't get very deep into this right now, but how does 10 PM Mountain sound for more discussion?
[12:41:42] <rob_ellenberg> That's good for me
[12:41:53] <seb_kuzminsky> great!
[12:42:34] <micges> seb_kuzminsky: what's current Mountain time?
[12:42:54] <seb_kuzminsky> last time i thought about testing Motion, i imagined a "stand-alone motion" module comparable to our stand-alone interpreter, the prototype is here:
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=rss;h=refs/heads/seb/2.7/sam
[12:43:03] <seb_kuzminsky> micges: it's currently 11:22
[12:43:07] <seb_kuzminsky> (AM)
[12:43:10] <micges> thanks
[12:47:08] <rob_ellenberg> I'll take a look at that branch. I like the idea of testing in user-space
[12:47:23] <seb_kuzminsky> yeah, me too
[12:47:36] <seb_kuzminsky> and i like the idea of testing outside of realtime
[12:48:28] <seb_kuzminsky> in tests/motion/g0 there is an early attempt at testing motion in realtime, with a complete linuxcnc setup running around it, and it was a bit of a hassle
[12:49:41] <seb_kuzminsky> zlog: link pls
[12:50:29] <seb_kuzminsky> rob_ellenberg: here's the brief conversation skunkworks and i had before you came:
http://tom-itx.no-ip.biz:81/~tom-itx/irc/logs/%23linuxcnc-devel/2015-02-03.html#12:10:21
[12:52:39] <rob_ellenberg> Having some tests in realtime would be handy, at least to catch dumb floating point errors
[12:54:18] <rob_ellenberg> Also, the configs in the current TP test folder are set up to abort on velocity / accel violations
[12:54:19] <seb_kuzminsky> realtime vs non-realtime for uspace shouldnt matter for floating point issues, but userspace vs kernelspace sure could
[12:54:40] <seb_kuzminsky> rob_ellenberg: abort/estop seems like a good way to signal test failure
[12:55:05] <rob_ellenberg> yeah, that makes sense, do some testing in the kernel
[12:56:25] <seb_kuzminsky> we have several tests that run the real Motion, but that don't pay close attention to the time-series of joint coordinates that it emits
[12:56:56] <seb_kuzminsky> when those tests run on RTAI buildslaves, we get *some* of that kind of coverage - build Motion for kernelspace and make sure it loads and runs
[12:57:51] <cradek> at fest I think jepler added support for single-stepping a thread. it seems like you could usefully analyze motion by doing that
[12:58:08] <seb_kuzminsky> oh yeah! did he finish that?
[12:58:14] <cradek> trying to find it now
[13:00:59] <cradek> I can't find it
[13:01:08] <seb_kuzminsky> i can't either
[13:01:49] <seb_kuzminsky> bbl dayjob
[13:03:17] <rob_ellenberg> cool, talk to you tonight
[13:05:02] <cradek> I must be wrong
[13:15:12] <seb_kuzminsky> i've only been wrong one time, and that was when i thought i was wrong but i was actually right
[13:24:07] <cradek> it was wrong of you to say that
[13:46:42] <skunkworks> I should be able to make it - That is 11:00 here if my calculations are correct..
[23:21:23] <skunkworks> hey rob
[23:21:28] <rob_ellenberg> hey
[23:21:36] <seb_kuzminsky> howdy
[23:22:00] <skunkworks> hey seb
[23:22:19] <rob_ellenberg> the dev channel is quiet this time of night
[23:22:46] <seb_kuzminsky> conversation here is pretty bursty
[23:23:24] <seb_kuzminsky> ok, what kind of testing is on your mind?
[23:24:21] <rob_ellenberg> Something like the build tests that auto-run when you push a new commit to the build-bot
[23:24:39] <seb_kuzminsky> yeah, that would be super useful
[23:24:48] <seb_kuzminsky> i am in favor of this idea
[23:24:59] <rob_ellenberg> I liked what you started with the G0 test
[23:25:22] <seb_kuzminsky> tests/motion/g0
[23:25:24] <rob_ellenberg> yeah
[23:25:41] <rob_ellenberg> The direct analysis of halstreamer output is good
[23:26:07] <seb_kuzminsky> it was the only way i could think of at the time to test Motion
[23:26:16] <rob_ellenberg> That covers a fair amount though
[23:26:29] <seb_kuzminsky> it also (unfortunately?) tests interp
[23:26:39] <rob_ellenberg> Yeah, I see what you mean there
[23:27:09] <seb_kuzminsky> and it doesnt let you do anything to motion's hal pins in a synchonized way
[23:27:32] <rob_ellenberg> Good point there
[23:27:46] <seb_kuzminsky> maybe a halstreamer comp could be added, but it starts to feel baroque
[23:27:54] <rob_ellenberg> We may have to take multiple approaches here
[23:28:03] <seb_kuzminsky> that's why i started sam
[23:28:29] <rob_ellenberg> Ahh, ok
[23:28:58] <seb_kuzminsky> instead of the script in the main() there, it could read those things from a .sam input file
[23:29:07] <seb_kuzminsky> feed them to the mocked motion
[23:29:22] <seb_kuzminsky> and record the joint commands to a file
[23:29:39] <seb_kuzminsky> to be analyzed/verified by checkresults afterwards
[23:30:35] <seb_kuzminsky> the "dont exceed acc limits" check is easy, just take the second derivative of the position data
[23:30:50] <seb_kuzminsky> vel limits and pos limits ae easy too
[23:30:54] <rob_ellenberg> What format are the mocked motion commands?
[23:31:10] <seb_kuzminsky> they dont exist yet
[23:31:38] <seb_kuzminsky> sam would have to be finished by adding them
[23:31:54] <rob_ellenberg> But in principal, it would be something like the contents of EMC_MOT_CIRCULAR_MOVE?
[23:32:22] <seb_kuzminsky> yeah, i imagine a serialization of the emcmot structs
[23:32:49] <seb_kuzminsky> possibly interspersed with hal commands
[23:34:20] <rob_ellenberg> so that would be a nice divorce from the interpreter
[23:34:35] <rob_ellenberg> and useful for simple standalone motion tests
[23:34:35] <seb_kuzminsky> that would let us expose Motion to specific inputs, and verify the outputs (hal pins)
[23:34:51] <seb_kuzminsky> yeah, i think there's a place for that kind of capability in our test suite
[23:35:10] <rob_ellenberg> I imagine you want to be able to serialize output from a program too
[23:35:24] <seb_kuzminsky> there's potentially a lot of complexity needed in the checkresults scripts to verify things like blending
[23:35:41] <seb_kuzminsky> you mean from a gcode program?
[23:35:42] <rob_ellenberg> Yeah, tolerance checking will be a PITA
[23:35:43] <rob_ellenberg> yeah
[23:35:56] <rob_ellenberg> G-code to serialized commands
[23:36:03] <seb_kuzminsky> we sort of have that in sai
[23:36:08] <seb_kuzminsky> the stand-alone interpreter
[23:36:10] <rob_ellenberg> ahh
[23:36:12] <seb_kuzminsky> aka bin/rs274
[23:36:36] <rob_ellenberg> maybe that's a goal too, make sai and sam compatible?
[23:37:10] <seb_kuzminsky> see for example tests/interp/flowsnake
[23:37:14] <seb_kuzminsky> mmmmaybe
[23:37:29] <seb_kuzminsky> ou want to do to sam that sai doesn't know about
[23:37:40] <seb_kuzminsky> err, "i think there are things you want..."
[23:37:50] <seb_kuzminsky> for example, poking the motion hal pins
[23:38:05] <seb_kuzminsky> but yeah, compatibility between them could be interesting
[23:38:12] <rob_ellenberg> of course, sam should have additional commands that sai doesn't make
[23:38:14] <seb_kuzminsky> if sam accepts a superset of the things sai emits
[23:38:16] <seb_kuzminsky> yeah
[23:38:40] <rob_ellenberg> It looks like the output of sai is serialized canon commands
[23:39:27] <seb_kuzminsky> yeah, i think that's right
[23:39:49] <rob_ellenberg> So potentially canterp could be a front-end for sam
[23:39:55] <seb_kuzminsky> i think "canon commands" is another name for "emcmot structs"
[23:40:23] <rob_ellenberg> The problem is that canon inconsistently does a lot more than just copy info in
[23:40:51] <rob_ellenberg> (especially with arcs)
[23:41:38] <rob_ellenberg> I'm not sure what the original intention was, but modern canon seems to be motion middleware sometimes
[23:43:01] <rob_ellenberg> so canterp would have to be made consistent with emccanon for that to work
[23:43:14] <seb_kuzminsky> i'm not really sure how that part works
[23:45:38] <rob_ellenberg> Maybe I'm misunderstanding canterp, but if it reads in canon commands and sends them to emccanon, then it would work
[23:47:21] <seb_kuzminsky> i hadn't thought much about piping rs274 (sai) output into sam
[23:47:25] <rob_ellenberg> So the tests for motion could be a combination of functional (i.e. run a g code program and see if it meets constraints) and standalone
[23:47:34] <seb_kuzminsky> maybe that's the right way to do it
[23:47:54] <seb_kuzminsky> i had imagined something smaller & simpler, just running tests that are specific to motion
[23:48:22] <seb_kuzminsky> for larger integration-style tests it may be better to stand up a linuxcnc instance
[23:48:36] <seb_kuzminsky> replace skunkworks with a shell script ;-)
[23:48:54] <seb_kuzminsky> he and i talked earlier today about that
[23:49:03] <rob_ellenberg> I've already sortof done that with the test-all.sh script
[23:49:06] <skunkworks> The vel-acc constraints testing seems doable but he hard part is probably testing path following.. (is path within x.xxx of programed) that is something that as far as I know has not been tested otherthan verifying the path in the axis preview...
[23:49:20] <seb_kuzminsky> he's got a pyvcp panel (i think) that shows the min & max accel while your program runs
[23:49:30] <rob_ellenberg> Good point sam, that's a tough one
[23:49:55] <seb_kuzminsky> i've thought about that problem some
[23:50:21] <seb_kuzminsky> if you have a time-series of axis coordinates from motion trying to follow some ideal path, you could test it like this:
[23:51:20] <seb_kuzminsky> if you keep track of where you are, and the derivatives thereof (vel & acc), it places a constraint on where you can be next
[23:51:40] <seb_kuzminsky> so the next point must be within vel + acc of the previous point
[23:54:21] <seb_kuzminsky> so you can walk the time series coming out of Motion and do constraint validation
[23:54:52] <rob_ellenberg> The problem is that, for a sharp corner, the blended path will be both shorter and faster, so you can't just measure distance one-to-one with the ideal path
[23:54:56] <seb_kuzminsky> and you can do something similar i think to verify that you're close to the (known) ideal path
[23:55:51] <seb_kuzminsky> each point on the actual Motion output must be within the G64 P limit of the ideal path
[23:56:33] <rob_ellenberg> You'd need some kind of representation of the ideal path
[23:57:22] <seb_kuzminsky> you have that, as the canon/emcmot input file to sam
[23:58:07] <rob_ellenberg> So for each path point, check distance to the known current and next segment
[23:58:58] <seb_kuzminsky> yeah, something like that
[23:59:23] <seb_kuzminsky> you have a list of emcmot lines & arcs, and a list of axis positions
[23:59:24] <rob_ellenberg> good idea, with a collision checking library or a bit of math, that would be much faster than brute force
[23:59:59] <seb_kuzminsky> the first point in the time series should be equal to the starting point of the first move