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