#emc-devel | Logs for 2009-10-28

[00:02:50] <skunkworks> I may have to up my speed at some point. (now that the wife has an nano and we stream a lot of stuff)
[00:10:57] <jepler> I'd settle for a link that stays up
[01:07:22] <dgarr> jepler: thanks for applying the notifications-clear patch
[02:26:15] <jepler> dgarr: I tested it and it seemed to work
[02:33:55] <SWPadnos> is there any way to distinguish between errors and warnings?
[02:44:06] <jepler> SWPadnos: in the nml level there are EMC_OPERATOR_ERROR and EMC_OPERATOR_TEXT which I guess could be taken to mean error and warning
[02:44:40] <SWPadnos> ok - I was just thinking that there should be separate clear inputs for errors and warnings
[02:44:46] <SWPadnos> if AXIS can differentiate at that point
[02:44:55] <jepler> oh, I don't think AXIS makes the distinction at the moment
[02:45:10] <cradek> I thought it used a different icon
[02:45:36] <jepler> ah, you're right -- it does
[02:46:39] <SWPadnos> but then again, a more generic solution needs the equivalent of level and edge warnings - some things shouldn't be clearable until the error condition has been remedied
[02:46:52] <SWPadnos> which probably should be done in HAL I guess
[02:46:57] <jepler> oh, and it seems there's also NML_ERROR and NML_TEXT
[02:47:16] <jepler> (and _DISPLAY for each kind, but I don't think we use those -- the comments indicate something about displaying a document by URL)
[02:47:52] <cradek> I wish we had a good way to show errors
[02:48:28] <cradek> one thing that really struck me retrofitting jr was that virtually every possible error was reported to the cpu and would show up on the screen.
[02:48:29] <SWPadnos> I like the way AXIS does it now
[02:48:40] <SWPadnos> but auto-clearing seems kind of dangerous to me
[02:49:02] <cradek> a fuse blown, it tells you which one - no air pressure - lube low - spindle didn't orient right - Y amp tach signal fault - etc etc
[02:49:29] <cradek> I bet there was 50 of them
[02:49:36] <SWPadnos> yeah, the big machine I worked on also had that
[02:49:53] <SWPadnos> there was a separate window/panel that had a list of the active error codes
[02:50:11] <SWPadnos> the frame would turn yellow or red, depending on the most severe condition displayed
[02:50:12] <cradek> I have a bunch of stuff in the estop chain - if it doesn't come out of estop, I either guess or open the box and look at stuff
[02:50:40] <SWPadnos> you can get some of that with the message .comp jepler posted
[02:50:52] <jepler> only if you had the 100 inputs to spare
[02:50:58] <SWPadnos> right
[02:51:06] <cradek> several are coming in already, for ladder to see
[02:51:08] <SWPadnos> the 5i22 would be useful there ;)
[02:51:18] <cradek> but not most of them, it's true
[02:51:41] <cradek> I have plenty of inputs left but I'm tired of wiring stuff
[02:51:51] <SWPadnos> heh
[02:54:02] <cradek> SWPadnos: do you have any magic sources for opto22 modules? I can't find a specific one anywhere except opto22 and I'm loathe to call and talk to a salesman.
[02:54:16] <SWPadnos> just ebay
[02:54:36] <SWPadnos> there are other automation houses that sell them though, like Automation Direct (I assume), and maybe even DigiKey
[02:54:37] <cradek> ok, I've got a saved search going there
[02:55:33] <cradek> no luck at digikey
[02:55:45] <SWPadnos> hmmm
[02:56:04] <SWPadnos> there are other modules that fit, they just don't have the screw (at all, or in the right place, depending)
[02:56:26] <cradek> looks like none at automationdirect (surprising)
[02:56:44] <cradek> specifically looking for some G4IDC5K
[02:56:55] <SWPadnos> K means inverted?
[02:57:03] <cradek> high speed
[02:57:07] <SWPadnos> oh
[02:57:22] <cradek> I could sure use 3
[02:57:58] <cradek> even 1 would make me happier (probe input)
[02:58:04] <SWPadnos> hmmm
[02:58:20] <SWPadnos> IDC are white, right?
[02:58:24] <cradek> yes
[02:59:45] <cradek> they're only $15 from opto22.com - I should just suck it up and do their stupid thing
[03:01:23] <SWPadnos> all of mine are non-K
[03:01:25] <SWPadnos> sorry
[03:01:35] <cradek> thanks for checking!
[03:01:51] <SWPadnos> I think there's a board on eBay that has a couple of them in it though - let me find it
[03:02:47] <SWPadnos> except that eBay isn't serving me descriptions or photos at the moment
[03:02:55] <cradek> hm, wfm
[03:03:15] <SWPadnos> it's one of those intermittent things
[03:05:24] <SWPadnos> geez -that guy is selling them for $15.95 now
[03:05:29] <SWPadnos> (the boards)
[03:05:50] <cradek> wow, he must have a LOT of them
[03:05:56] <cradek> they sure work nice
[03:06:00] <SWPadnos> I think he had 10 or 20 when I asked
[03:14:42] <cradek> "IMPORTANT: Your UPS or FedEx shipping account number is required for ALL credit card/PayPal orders"
[03:14:46] <cradek> WTF?!?
[03:14:55] <cradek> you fail at e-commerce
[03:15:24] <SWPadnos> heh
[03:15:45] <cradek> if I cannot buy from you, you fail. fail fail fail!
[03:16:04] <SWPadnos> (if it's your fault, Mr. website)
[03:16:37] <cradek> it lets you pay by paypal
[03:16:53] <cradek> but they can't, for some reason, calculate and charge the shipping amount
[03:17:12] <SWPadnos> or they don't want to be on the hook for it if you decide to reverse the payment
[03:17:23] <cradek> for shipping?
[03:17:32] <SWPadnos> yeah, silly isn't it
[03:17:34] <cradek> this is only about the shipping charge
[03:17:37] <SWPadnos> sure
[07:54:15] <micges_work> good morning
[13:05:17] <cradek_> cradek_ is now known as cradek
[16:28:37] <skunkworks_> yay chris - I think you got it :)
[16:41:17] <cradek> what do/did I get?
[16:42:18] <cradek> oh I see it
[16:42:31] <cradek> I never reproduced the problem he had (where it sometimes worked and sometimes not)
[16:43:21] <cradek> although when I look at his plot, I see that the different passes start differently - some have a big initial overshoot
[16:43:27] <cradek> I never saw that
[16:43:40] <cradek> they may have triggered the oscillation in the old buggy code
[16:44:24] <cradek> wonder if his hardware or rtai setup are bad - I think he's using a custom kernel.
[16:53:11] <mhaberler> well yes, a homegrown smp kernel
[16:53:38] <cradek> oh hi
[16:53:41] <mhaberler> hi!
[16:53:54] <cradek> I'm still suspicious that you have a problem I don't
[16:54:01] <cradek> although the new code sure deals with it better
[16:54:34] <mhaberler> I'm unsure what to try; I can revert to the standard hardy rtai kernel
[16:55:49] <mhaberler> what I can try is back out all your fixes from master and see wether I arrive at the plots I had before
[16:56:20] <mhaberler> option#2: declare victory ;-)
[16:56:29] <cradek> if your last plot is from exactly the same code I was running, there is a difference outside that code
[16:56:39] <cradek> it's not the config, since you shared that with me
[16:56:59] <cradek> do you ever get the rtai realtime-delay error?
[16:57:00] <mhaberler> last - you mean what I just sent half an hour ago?
[16:57:37] <mhaberler> no realtime delay since I dont use base-thread anymore (hm2)
[16:58:16] <cradek> yes this one http://mah.priv.at/cgi-bin/viewvc.cgi/emc-syncmove-without-hardware/post-fix.png?revision=1.1&root=CVS&view=markup
[16:59:49] <mhaberler> ok, where should I look for a difference?
[16:59:57] <mhaberler> have both in front of me
[17:00:07] <cradek> both what, sorry?
[17:00:32] <mhaberler> http://timeguy.com/cradek-files/emc/14b8248.png and http://mah.priv.at/cgi-bin/viewvc.cgi/emc-syncmove-without-hardware/post-fix.png?revision=1.1&root=CVS&view=markup
[17:00:59] <cradek> ah
[17:01:37] <cradek> on your plot, start at the [7] button at the bottom, see the vertical dotted line above it, follow up to the cyan line
[17:01:47] <cradek> at that point see the downward spike at the beginning of the threading pass?
[17:01:54] <cradek> I think that is wrong and I don't have it
[17:02:06] <mhaberler> ok, copy that
[17:02:40] <cradek> I think that is still a wrong initial sync, like you had on some passes before
[17:03:01] <cradek> but that disturbance does not freak out the new algorithm
[17:03:27] <cradek> on my plot, you can see all passes have the same initial sync
[17:03:59] <mhaberler> I see; any hints where I should try probing?
[17:05:22] <cradek> the apparently-missing sync-accel would still explain it
[17:05:34] <cradek> it baffles me why you have that
[17:06:23] <mhaberler> I moved away the old tree and fetched today; have a hard time believing one of my changes made it in there, that is out of the way; kernel?
[17:06:46] <mhaberler> that box can be made reachable over the net btw
[17:07:29] <mhaberler> but emc over vnc is a loser
[17:07:46] <cradek> git status will tell you if you have changes - you do not need to guess
[17:08:19] <mhaberler> ok... back in 5mins - will turn machine on and see for good
[17:08:54] <cradek> would be fun if you would change kernels and do nothing else (except the needed make clean; make)
[17:09:19] <cradek> it *could* be a coding error that gets tickled for you but not me
[17:10:17] <cradek> bbl, lunch
[18:19:10] <cradek> y'know, I've always tested this (I think always) on sim
[18:23:45] <skunkworks_> what is the worst that can happen?
[18:23:48] <skunkworks_> ;)
[22:27:53] <cradek> jepler: I like the no-pointer change. it looks much cleaner. I am still getting a different color on the last-poked button though (it is hardy)
[22:32:04] <jepler> cradek: hmph, ok
[22:33:35] <alex_joni> jepler: bet it's coming from greasy fingers
[22:34:50] <jepler> whatever theme I've got on here, it's nearly impossible to tell the difference between a clicked-in and clicked-out button
[22:35:03] <jepler> but the color of the just-clicked button and the pointed-at button are the same as anything else
[22:35:04] <cradek> yeah I had to look through several to find a sane one
[22:36:07] <cradek> I guess I have "custom" with "redmond" controls
[22:36:20] <mhaberler> cradek: I'm baack
[22:36:21] <mhaberler> did two shots with stock kernel and my smp kernel - can you tell a difference? I'm not sure
[22:36:23] <mhaberler> smp: http://mah.priv.at/cgi-bin/viewvc.cgi/emc-syncmove-without-hardware/mahsmp-kernel.png?revision=1.1&root=CVS&view=markup
[22:36:24] <mhaberler> stock: http://mah.priv.at/cgi-bin/viewvc.cgi/emc-syncmove-without-hardware/vanillakernel-shot2.png?revision=1.1&root=CVS&view=markup
[22:36:53] <cradek> gotta run, bbl
[22:37:01] <mhaberler> ok
[22:38:07] <jepler> 74.1Hz?
[22:38:57] <mhaberler> are you suggesting higher sample rate?
[22:43:12] <jepler> is that your servo-period, or are you using "multiplier" in halscope?
[22:43:21] <jepler> if it's your servo period, I'm suggesting it is an uncommon configuration
[22:43:40] <mhaberler> has a mulitplier of I think 700 in halscope
[22:44:05] <mhaberler> no, it'snot the servo period - now i get it
[23:07:03] <alex_joni> good night all
[23:35:02] <cradek> the -smp one looks wrong and the vanilla one looks right
[23:39:04] <cradek> but small sampling...