Back
[12:36:33] <skunkworks_> alex_joni:
http://www.electronicsam.com/images/KandT/testing/
[14:40:13] <alex_joni> skunkworks_: cool, thanks a lot
[14:44:25] <skunkworks_> No problem :)
[14:47:12] <skunkworks_> * skunkworks_ is glad they where still 'somewhere'
[14:47:42] <skunkworks_> someone want to take this on?
http://www.cnczone.com/forums/showpost.php?p=451123&postcount=22
[14:47:59] <skunkworks_> explain things a little more elegently../
[14:49:03] <jepler> alex_joni: whom do I credit for the serbian translation?
[14:49:22] <alex_joni> jepler: Bojan Marinkovich
[14:49:27] <alex_joni> form memory..
[14:49:31] <alex_joni> * alex_joni checks teh logs
[14:49:38] <jepler> found that in the .po file as well
[14:49:45] <jepler> dunno why I wasn't smart enough to look there first
[14:50:17] <alex_joni> it might be early ;)
[14:50:23] <alex_joni> I know it's late here..
[14:51:35] <jepler> added to
http://axis.unpy.net/translations -- maybe we should move that page to linuxcnc someday
[14:51:43] <alex_joni> yeah, we should..
[14:52:00] <alex_joni> we could make it axis.linuxcnc.org ;)
[14:53:31] <alex_joni> heh, that's the only orange one there..
[17:24:20] <skunkworks_> rayh: is dave's mazak running ok now? (last email was that he changed the NV driver to vesa solved his overrun issue)
[17:24:43] <rayh> Yes I believe it is working.
[17:24:52] <skunkworks_> Good :)
[17:25:27] <rayh> Thanks for all the help on that.
[17:25:56] <skunkworks_> no problem. Glad I could help.
[17:27:54] <rayh> I believe that was his last major obstacle.
[17:28:30] <rayh> I suspect he is into planning for the next step now that he has the current version.
[17:28:48] <skunkworks_> tool changer?
[17:29:24] <rayh> I'd guess so. Although he has to figure out how to setup orientation.
[17:29:39] <rayh> His was some sort of cam thing up there.
[17:30:09] <rayh> We tried to figure out if his casting was the same as Roland's but didn't think so.
[17:30:44] <skunkworks_> ours has a cog that gets engaged - then the spindle creaps around and engages it.
[17:30:58] <skunkworks_> easy (I think)
[17:32:08] <rayh> I believe that his is similar but I think he wants to add rigid tapping so was looking at a retrofit of an encoder like we did at fest.
[17:32:39] <skunkworks_> ah
[17:35:32] <skunkworks_> that is one thing we need to figure out - how to mount an encoder.
[17:36:14] <rayh> That can be a trick on many of these pre rigid tapping machines.
[17:36:25] <skunkworks_> yes
[17:36:30] <rayh> Often the drawbar puller gets in the way.
[18:57:10] <rayh> I started stepconf after the crash in a terminal and got
http://www.pastebin.ca/1016084 feedback.
[18:58:07] <jepler> yeah gtk likes to print stupid warning messages that nobody can figure out how to avoid but none of those explains your "crash"
[18:58:17] <jepler> did it crash during that run, or did it behave?
[18:58:34] <rayh> During the run.
[18:58:58] <rayh> I went back and switched to mm units and then was working on an axis.
[19:02:09] <jepler> the crash was the stepconf that was run from the terminal, though?
[19:04:09] <rayh> No I ran it that time from the menu.
[19:04:20] <jepler> ok
[19:04:24] <rayh> I didn't crash during the terminal run.
[19:13:40] <rayh> Ah I think I got it this time.
[19:13:53] <rayh> Traceback (most recent call last):
[19:13:53] <rayh> File "/usr/bin/stepconf", line 1294, in on_xleadscrew_changed
[19:13:53] <rayh> def on_xleadscrew_changed(self, *args): self.update_pps('x')
[19:13:53] <rayh> File "/usr/bin/stepconf", line 1251, in update_pps
[19:13:53] <rayh> if d.units == 1 or axis == 'a': pitch = 1./pitch
[19:13:56] <rayh> ZeroDivisionError: float division
[19:14:00] <cradek> ahhhh
[19:14:13] <cradek> do you know how you did it?
[19:14:29] <rayh> I think I hit two keys at once or some such.
[19:14:54] <rayh> But I'd got back and switched between inch and mm a couple times also.
[19:15:16] <cradek> I get that whenever I put 0 in the leadscrew pitch field, but it does not crash
[19:15:27] <jepler> you can easily get that message printed by setting units to mm then entering 0 for leadscrew pitch on "x axis configuration", but it doesn't crash
[19:15:36] <jepler> for me, the window stays up
[19:15:38] <jepler> (2.3 CVS)
[19:15:51] <rayh> I'll see if I can get it to do it again and watch what I do.
[19:16:42] <rayh> I was switching between 8 and 4 for pitch.
[19:16:57] <cradek> jepler: if I leave the zero and go back to the first screen and forward, it lets me continue (fails to see that the 0 should cause the Next button to still be greyed)
[19:17:12] <jepler> cradek: hm ok
[19:17:29] <cradek> I still don't get a crash, but it fails to write a config when I click Apply at the end
[19:18:08] <rayh> Got a crash again.
[19:18:11] <rayh> Traceback (most recent call last):
[19:18:11] <rayh> File "/usr/bin/stepconf", line 1304, in on_xmaxacc_changed
[19:18:11] <rayh> def on_xmaxacc_changed(self, *args): self.update_pps('x')
[19:18:11] <rayh> File "/usr/bin/stepconf", line 1256, in update_pps
[19:18:11] <rayh> acctime = get("maxvel") / get("maxacc")
[19:18:13] <rayh> ZeroDivisionError: float division
[19:18:37] <jepler> does the window disappear when that is printed?
[19:19:11] <rayh> No and it looks like some of it is still active.
[19:19:48] <jepler> the first time you said it "crashed", did you mean that the window disappeared? or something else unexpected?
[19:20:55] <rayh> looks like something named apport is saying there was a crash.
[19:21:03] <rayh> I figured out what I'
[19:21:11] <rayh> m doing though.
[19:21:39] <rayh> Accel shows 30 and i click between then add the 12 and it happens.
[19:21:53] <rayh> This is hardy
[19:22:53] <cradek> what is apport?
[19:23:38] <cradek> I wonder if that's the "gnome magically saw an error that you would rather be printed on the terminal" feature that hardy seems to have
[19:23:39] <rayh> no clue. let me see if I can figure it out.
[19:23:57] <jepler> cradek: apparently it's a thing that receives core dumps (instead of writing core files)
https://wiki.ubuntu.com/Apport
[19:24:00] <rayh> could well be.
[19:25:50] <cradek> I don't get a crash on my hardy machine, but the validation still does break after going "back"
[19:25:57] <rayh> yep apport-gtk seems to be what gets to the top of top when I ask the crash reporter to find out what went wrong.
[19:26:56] <jepler> in that page about apport I don't see any way for ray to save that problem report or e-mail it to me instead of to launchpad
[19:27:08] <cradek> huh, it tried to spew something into /var/crash/_usr_bin_stepconf.1000.crash, but failed with permission denied
[19:27:41] <rayh> It doesn't find the info I just seems to report the problem to the display.
[19:27:48] <jepler> cradek: when you trick validation and make it to the end with a 0 SCALE?
[19:28:57] <cradek> f...
[19:32:01] <rayh> I can see that the easy way to get round this is to mend my point and click ways.
[19:35:06] <cradek> there are several problems and I'm not sure you're one of them
[19:35:36] <jepler> ubuntu is treating a simple, non-fatal error that doesn't cause the application to actually exit as a "crash". It's misleading and not helpful.
[19:36:17] <cradek> then, it makes you click some things, and then tells you it doesn't know how to report the problem anyway. it also doesn't tell you what the problem is.
[19:38:18] <rayh> That sounds right.
[19:38:26] <jepler> thanks, ubuntu
[19:39:13] <cradek> often, mistaken developers confuse hiding error messages with "friendly"
[19:39:28] <rayh> And it tosses the non-fatal because it's auto computing each time there is a change in the value.
[19:40:00] <cradek> yes
[19:40:46] <rayh> As long as I double click so that the whole number is highlighted it lets me enter the next value.
[19:41:05] <rayh> Almost a right to left v left to right thing.
[19:42:02] <cradek> well we have discovered that stepconf definitely has two bugs. but we also discovered that ubuntu has some misfeatures concerning this automated bugreport thing.
[19:42:15] <rayh> I wonder if it's possible to trap the divide by zero and ignore it
[19:42:28] <cradek> sure
[19:42:39] <cradek> or, just don't divide if it's zero or empty
[19:42:41] <rayh> I don't doubt the ubuntu issue at all. Chasing that other os.
[19:43:29] <rayh> I did read that Canonical thought that the lack of bug reporting was a big problem for open source projects.
[19:43:59] <rayh> So they create a bug by trying to create a solution.
[19:44:08] <alex_joni> rayh: sure, but going from bug-reporting to something else..
[19:44:16] <cradek> here's one (the actual information is hidden from the user):
https://bugs.launchpad.net/apport/+bug/137687
[19:44:37] <rayh> looking
[19:45:02] <rayh> Yep.
[19:45:26] <cradek> but no existing bugreport for the way it (mis)handles non-ubuntu/launchpad packages
[19:45:49] <cradek> and no existing bugreport for calling every traceback a "crash" even if the program continues to run
[19:46:45] <rayh> "The problem cannot be reported:
[19:46:45] <rayh> This is not a genuine Ubuntu package"
[19:47:46] <rayh> I like that. "GENUINE" Someone has their nose in the air.
[19:51:00] <cradek> f.....
[19:57:38] <rayh> Will the same thing happen if EMC2 sends a similar error message?
[20:00:45] <jepler> rayh: if other parts of emc do something that apport thinks is a "crash", the "yes".
[20:00:53] <jepler> but as you can see, I'm hedging because I know jack about this "apport" thing
[20:08:52] <skunkworks_> is mm setup mm/min for feed?]
[20:14:03] <alex_joni> skunkworks_: depends on G20/21
[20:14:14] <alex_joni> you can have an inch setup and use G21 for mm
[20:18:33] <jepler> skunkworks_: velocity and acceleration in the ini file are in per second or per second squared, never in terms of minutes.
[20:18:42] <jepler> stepconf asks in seconds and seconds squared, too
[20:34:00] <cradek> if you mean F word feed, yes mm/min
[20:35:13] <skunkworks_> Thanks. (I was confused with the ini. Makes sense now)
[20:47:01] <skunkworks_> maybe the 'higher' the accelleration numbers - the 'higher' the percentage overhead
[20:48:31] <SWPadnos_> the higher the accel vs acceptable following error, the higher the overhead needs to be
[20:48:34] <SWPadnos_> I think
[20:48:47] <cradek> * cradek grumbles
[20:51:01] <CIA-49> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/stepconf/stepconf.py:
[20:51:01] <CIA-49> EMC: Fix several user interaction bugs
[20:51:01] <CIA-49> EMC: * on hardy, entering invalid values caused apport "quit unexpectedly" dialogs
[20:51:01] <CIA-49> EMC: to pop up, even though stepconf was alive and well
[20:51:01] <CIA-49> EMC: * upon returning to an Axis Configuration page with invalid values, the
[20:51:02] <CIA-49> EMC: "forward" button was erroneously enabled
[20:51:26] <CIA-49> EMC: 03jepler 07v2_2_branch * 10emc2/src/emc/usr_intf/stepconf/stepconf.py: from HEAD: user interaction fixes
[20:52:47] <CIA-49> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/stepconf/stepconf.py: user gefink reports that 5stepconf.py was insufficient stepgen acceleration overhead, try a larger value
[20:53:12] <CIA-49> EMC: 03jepler 07v2_2_branch * 10emc2/src/emc/usr_intf/stepconf/stepconf.py: additional stepgen acceleration headroom
[20:59:33] <cradek> jepler: + print "set sensitive"
[21:00:25] <CIA-49> EMC: 03jepler 07v2_2_branch * 10emc2/src/emc/usr_intf/stepconf/stepconf.py:
[21:00:25] <CIA-49> EMC: * when actually writing inifile, if the user's requested velocity and scale
[21:00:25] <CIA-49> EMC: would lead to too many pps, reduce the written ini maximum velocity
[21:00:25] <CIA-49> EMC: accordingly
[21:00:25] <CIA-49> EMC: * fix earlier 'fix' that caused traceback about gobject
[21:00:28] <CIA-49> EMC: * remove debugging message
[21:01:09] <CIA-49> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/stepconf/stepconf.py: remove debugging message
[21:02:54] <CIA-49> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/stepconf/stepconf.py: from branch: when actually writing inifile, lower velocity to obtainable velocity based on max pps
[21:07:11] <CIA-49> EMC: 03jepler 07v2_2_branch * 10emc2/debian/changelog: note new bugs fixed
[21:34:56] <alex_joni> * alex_joni prods SWPadnos_
[21:35:00] <SWPadnos_> why?
[21:35:03] <alex_joni> hi
[21:35:11] <alex_joni> can you set up a thingie on DH?
[21:35:11] <SWPadnos_> hi
[21:35:21] <SWPadnos_> possibly - depdnds on the thingie
[21:35:23] <jepler> * jepler wonders if alex_joni can be any more specific
[21:35:34] <SWPadnos_> at least he said "on DH" ...
[21:35:48] <alex_joni> * alex_joni moved to #emc-board
[21:35:53] <SWPadnos_> one sec
[21:38:05] <CIA-49> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: another program that would benefit from the sys.excepthook / apport hack
[21:45:19] <SWPadnos_> hmmm. I'm looking at writing a gearchange module (not quite like Stuart's) using comp, and I'd like to have a variable number of gears
[21:45:47] <SWPadnos_> I could do it the same way that e.g. or2 makes a variable number of or gates
[21:46:45] <SWPadnos_> but I'd prefer to allow for a variable number of instances which also have a variable number of gears - sort of like the debounce component (variable number of variable-sized groups)
[21:46:52] <SWPadnos_> is that possible with comp?
[22:05:00] <jepler> SWPadnos_: no.
[22:07:13] <jepler> well .. maybe 'personality' can be abused for this purpose -- I don't recall exactly how though
[22:10:14] <SWPadnos_> ok
[22:11:50] <SWPadnos_> I suspect that most machines would only have one gearchanger, so I can certainly use the count as the number of gears
[22:11:52] <SWPadnos_> hmmm
[22:12:12] <SWPadnos_> or maybe I can't, since I only want one "update" function, and it has to know about everything
[22:12:18] <jepler> yeah
[22:13:32] <jepler> you can use 'personality' for this.
[22:13:50] <jepler> give me a second to pastebin this
[22:14:46] <jepler> it has problems; for instance, I think you can crash the system if personality > 16
[22:15:41] <jepler> this is kinda-documented; the grammar in the comp documentation refers to 'MAXSIZE : CONDSIZE' in the array syntax
[22:16:28] <jepler> you probably need to customize with count_function and/or extra_setup to make it bulletproof
[22:16:55] <jepler> (for instance, count_function could look at the personality array to find out the count; extra_setup could limit the personality value to 1..16 or whatever you want)
[22:20:52] <SWPadnos_> hmmm. I'll have to take a look at this when I'm back home (or at least in the hotel, on my own computer)
[22:21:33] <jepler> basically, "personality" is an integer of extra information that is available to configure the instance, and when the instance's functions are running
[22:21:49] <jepler> one of the ways you can use it is to choose the size of an array
[22:22:37] <SWPadnos_> ah, ok. does that replace count?
[22:22:49] <SWPadnos_> like loadrt mymod personality=5,7,23
[22:23:01] <SWPadnos_> rather than loadrt mymod count=3 personality=...
[22:23:04] <jepler> no, it supplements count
[22:23:08] <jepler> oops, I forgot to paste my pastebin url
http://pastebin.ca/1016323
[22:23:12] <SWPadnos_> heh
[22:23:24] <jepler> no wonder you seemed more in the dark than I expected
[22:23:30] <SWPadnos_> heh
[22:23:32] <SWPadnos_> thanks
[22:24:04] <jepler> I *think* that using count_function you can make personality= set the count but I'm not 100% sure
[22:24:50] <jepler> one thing you'll run into is that personality is one of those weird #defines, so if you want to refer to the array personality, put get_count at the bottom and #undef personality above it
[22:25:38] <SWPadnos_> hmmm. methinks I'll have to look at this (a) when I have sufficient time and (b) on a system where I can experiment more (a.k.a one of my development systems)
[22:30:06] <jepler> updated to use option count_function:
http://pastebin.ca/1016340
[22:30:25] <jepler> I think that guards against non-valid personality values (>16) as well
[22:31:25] <SWPadnos_> ok, so if you use option count_function, then the get_count function is called, and you can do what you need there?
[22:31:51] <SWPadnos_> and the array is called personality, as long as you get rid of the #define beforehand
[22:32:29] <SWPadnos_> oh, and it looks like get_count must be run (by comp) before the pin initialization code
[22:33:09] <jepler> yes
[22:33:15] <jepler> that returns the number of instances to create
[22:33:33] <jepler> it does that by looping over personality until it hits a '0' (default value), setting entries >16 to 16 as it goes.
[22:33:43] <jepler> the return value is the same as the number of nonzero personality values seen
[22:33:51] <SWPadnos_> cool. now all I have to do is remember where this conversation is when I actually go to write the comp :)
[22:33:55] <jepler> hah
[22:34:33] <SWPadnos_> that [16 : personality] in the pin def - does that define the size of the personality array?
[22:34:42] <SWPadnos_> ie MP_ARRAY(16,...) in that case
[22:34:50] <jepler> no
[22:34:54] <jepler> all these 16s are coincidence
[22:34:56] <SWPadnos_> heh
[22:35:05] <jepler> the size of the personality array is always 16
[22:35:09] <SWPadnos_> ok
[22:35:22] <jepler> pin in bit in[16 : personality] means that 'in' is an array with max size 16
[22:35:59] <jepler> for a particular instance, the size of the array is the result of the expression 'personality' instead; that number had better be less than the number before the :
[22:36:17] <SWPadnos_> can I exit (and abort loading of the module) by returning a zero or negative count?
[22:37:30] <jepler> It looks like the answer is "no", but I believe that comp should be changed to do what you suggest
[22:37:59] <SWPadnos_> ok :)
[22:38:15] <SWPadnos_> is there any way of refusing to load at the moment?
[22:39:14] <jepler> yes, you can do it by returning nonzero from EXTRA_SETUP
[22:40:01] <SWPadnos_> ok
[22:40:19] <SWPadnos_> presumably that's called after get_count
[22:41:30] <jepler> that's called for a particular instance
[22:41:34] <jepler> hm but I get an error trying to use it
[22:42:15] <jepler> yeah looks like personality + extra_setup is broken
[22:43:06] <SWPadnos_> Mykeyboarddied
[22:43:27] <jepler> argh
[22:43:31] <jepler> sorry to hear that
[22:43:47] <SWPadnos_> itypedthatwithcharactermap
[22:44:04] <SWPadnos_> bbl