On Thursday, May 03, 2012 09:36:13 AM Michael Haberler did opine: > Gene, > > Am 03.05.2012 um 04:34 schrieb gene heskett: > > On Wednesday, May 02, 2012 10:24:12 PM Michael Haberler did opine: > >> Gene, > >> > >> please read the mail pertaining to your report which I just posted on > >> emc-developers. > > > > I am not on the devel list, was 3-4 years back till I got it figured > > out that I didn't, and couldn't, speak the level of math you folks > > do. Where can I read the archives, and approximately when? > > the linuxcnc wiki page 1 links you to the open archive: > http://news.gmane.org/gmane.linux.distributions.emc.devel > > Subject: 'queued MDI execution does not work in master' > > >> I strongly oppose 'restoring this feature'. Unless a proper solution > >> is implemented, this means restoring a bug which is just waiting to > >> get somebody into real trouble. There is a reason the bugfix is > >> there, and it is not about killing a popular feature. > > > > Ok, but how much trouble, in terms of code, is putting that back in. > > And what do you call real trouble? Perhaps it has happened to me and > > I just did a reboot without reporting the problem. > > The message I posted outlines the problem and the real fix. The fix is > not in removing the code which changed the Axis behavior as you noticed > it to be, but in removing the underlying problem. > > >> For further reference on the issue, I formally ask you again to file > >> a bug report. There is a reason for doing so - retaining history. > > > > Where? > > Page 1 of the linuxcnc wiki links you here, which tells what to do: > http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Trackers > I am there, logged into srcforge with the report filled in, but I have no submit button. Firefox 12.
??? > It shows the history of filed bugs. You can look for yourself if > somebody else reported a similar problem, for instance if there is a > workaround. You will find it very easy to do, and there's a wealth of > information there. > > > I was ignored on IRC when I asked where I should post the logs from > > setting > > You were not ignored. I happened to not be around, you started prodding > other folks into 'restoring the feature', and when I saw Andy digging > around in Axis to patch it up I looked myself, although I am very short > on time right now. The first thing I did was to create exactly that log > I asked you to. > > Fact is, I feel ignored on my requests to you to file a bug report - > several times on different issues, which is why am a bit more candid > right now. Precisely because (see above) filing a but report is so damndably difficult Michael. I followed that link, was advised I wasn't logged in, so I found my srcforge username & pw and logged in. But it has shown me no other bug reports. The only clickable button at the bottom of the form I am looking at is "add artifact". I have searched for the bug reports on the mill box and clicked on that button once for each file, which strikes me as way too small since the biggest one is only 800 some bytes, created yesterday and I haven't reset the ini files debug to 0 yet. I have an nfs link from here to the milling machine. I did have an nfs share setup to the lathe machine too, but that seems to have disappeared from the /net directory here. No clue where it went. That is why you didn't get the last bug report. I sure wish we had a linux box to box network on the local network that actually Just Worked(TM). Having the nfs linkage time out, without refreshing it except by backing out and then cding to each directory in the path shared every 30 minutes, and otherwise needing "adjustment" every time a machine, any machine, on the local net gets rebooted is a PIMA. They fixed a security thing in cifs about a year ago, and its been unusable since, so I can't use that network either. Do windows people have this problem? Its like the config files that make all this work are kept in the /tmp directory, which gets housecleaned at least monthly. Whatever it is, its a PIMA, but that's not your fault in any way. > It is 'the process', and it is there for a reason: it records history, > and related actions. The purpose is to help other users if they have a > problem, and also reduce demand on developers time, and that is what I > am asking. Some email here, some IRC message there is not a proper bug > documentation, that is just lost. It is not a fascist plot of > developers to force useless clerical work onto users. > > Since this has happened to me just too many times before and not just > here, I just dont do this > on-the-fly-patching-up-because-a-user-complained-loud-enough-and-it-loo > ks-like-I'm-a-great-guy-when-I-do-it anymore. Three months later nobody > remembers, and that forces everybody to rediscover history the hard > way. So very often the net effect of 'I'll fix it right away' is to > waste everybody's time. I can appreciate that Michael, everything needs a 'paper trail' and this is no exception. But when a formerly working network disappears with no action on my part, and the bug submission process is such a pain in the ass too, they are not going to be submitted for everytime something sneezes. I'll leave the debug setup for everything until I can submit a report. Just give me a Submit button. Right now the mill is setup to sharpen threading tools, and will likely have to do that again before I get the G76 tamed on the lathe. Its confusing to me, that the rest of the gcode seems to run on diameters, but G76 seems to run on radii, but I don't think that is much more than a too concise page for G76. In fact, for those who play with snakes for fun, a configurator for G76 would be a welcome addition to our "bag of tricks", hint, hint. Several things, with the right bits of math, could be amazingly simplified. For instance, I want a 28 tpi thread, so the length of a tooth in z is 1/28=0.0357142857143". Easy enough. Now, since the normal angle of the tooths face for USS and USF threads is 60 degrees included, the min and max diameters should be capable of being calculated rather than being looked up in the handbook & miss-translated, then clip off the top and bottom 10%, then adjust the pitch diameter until the OD is at the diameter wanted. There are of course rules for the other thread forms, square and acme among the more popular, so that is 3 face angles to deal with, could get complex to cover everything I 'spose. I did make a good looking thread once I had a properly sharpened cutoff tool formed, but although I told it to take the first cut at -.003" from the finished diameter, which it did, and an R2.0, it took it nearly 2 hours to cut that 28 tpi thread because it was only advancing the tool about 0.00015 a pass. Some of that swarf was finer than 0000 steel wool! And no clue what I entered that was wrong since the MDI history window is about 60 chars too narrow to display the whole command while it was running. At some point, that needs to be drag & drop adjustable like the code view window. ;-) I guess that could be called a feature request... FWIW, the axis backplot like the docs show for that command was never drawn. Should it have been? Or is this another wannabe bug report? :) > Thanks for your consideration. > > - Michael Thanks & Cheers Michael, Gene -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) My web page: <http://coyoteden.dyndns-free.com:85/gene> The only way to amuse some people is to slip and fall on an icy pavement. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
