[Emc-users] EMC2 newbie woes
I picked up a Sherline mini mill in late '06, and their mini lathe in early '07, and then essentially never used them. I worked too much, and couldn't run them in my apartment building by the time I'd get home. Now I'm in a house, and have been trying to get it all set up again, but I have to say that unfortunately I've had nothing but troubles for about a month now trying to get EMC2 and my mill set up properly. I need to say that I do appreciate the efforts of the group, and am committed to getting this to work, and I love free/open software, but alas, I'm still trying to get even the simple things working correctly after many weeks. The #1 issue right now, as I'm afraid it could be responsible for the inaccuracies I'm seeing in what I'm trying to make, is the error message I get almost every time I fire up the program: RTAPI: unexpected realtime delay on task 1 There are 5 pages available through Google on the matter, and they don't answer the question, beyond hinting I should change my base period. I read whatever I could find awhile back about setting up the latency, but couldn't really make heads nor tails of it. The information in a few docs I found online didn't match up with anything I was seeing on the screen, and I don't have intimate knowledge of these things, so was unable to guess at anything. Tonight, I ran the latency-test again, and having again been handed many numbers that don't mean anything to me (and aren't explained anywhere I've been able to find), I decided to just use the Base Thread (25.0 µs) Max Jitter (NS) in my inch.ini file for BASE_PERIOD - a total guess, but it seemed right. The error stopped occurring, for a few more launches, but then returned. I understand absolutely nothing about any of this, so I have no next step. The default BASE_PERIOD in the file was IIRC 5. I've tried down to 1 (makes it super slow to load up), and up to the very high number I got from my latency tests - 187525 - and even 20. The error always comes back. Am I going to have to build the software from source (for some reason, as indicated in some of my Google finds?). I'll save my other curiosities for future emails, as I don't want this important bit to get lost in a flood of other questions :) Thanks very much! -Gary - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] EMC2 newbie woes
On Tue, Mar 18, 2008 at 07:14:12AM -0500, [EMAIL PROTECTED] wrote: and up to the very high number I got from my latency tests - 187525 - and even 20. The error always comes back. Am I going to have to build the software from source Nope, you need to fix your computer. Right now it is incompatible with realtime software. This is a hardware issue. Nothing you change in EMC can fix it. 187525 microseconds is nearly 0.2 seconds, which is an interminably long time for the computer to stop sending step pulses. It will definitely ruin your part because your motors will stall. The most common hardware problem is onboard video. You do not say anything about your hardware so it's hard to guess what's wrong. If you are trying to use a laptop, don't. Turn off any power saving features in the system BIOS. There are some hints here: http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?TroubleShooting#On_board_video Also in the mailing list archives, you will see lots of people have had these problems and found various fixes. I hope you get it working. Let us know more about your system and maybe we can offer better advice. Chris - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] EMC2 newbie woes
Based on the latency results (187525) you are not going to be able to run EMC on that machine. I had the same problem. The problem is most likely caused by running an integrated video interface which is sharing system RAM. You need to install a video card. Literally any video card should work. Then re-run the latency test and you should see a huge reduction in the numbers. Then EMC will work. That is where your problem is. The documentation for EMC states what latency numbers will work. I had the same problem, installed an old video card in my machine, the latency numbers dropped to very low numbers and things run fine. Give that a try. Jim Combs [EMAIL PROTECTED] m Sent by: To emc-users-bounces emc-users@lists.sourceforge.net @lists.sourceforg cc e.net Subject [Emc-users] EMC2 newbie woes 03/18/2008 08:14 AM Please respond to Enhanced Machine Controller (EMC) [EMAIL PROTECTED] sourceforge.net I picked up a Sherline mini mill in late '06, and their mini lathe in early '07, and then essentially never used them. I worked too much, and couldn't run them in my apartment building by the time I'd get home. Now I'm in a house, and have been trying to get it all set up again, but I have to say that unfortunately I've had nothing but troubles for about a month now trying to get EMC2 and my mill set up properly. I need to say that I do appreciate the efforts of the group, and am committed to getting this to work, and I love free/open software, but alas, I'm still trying to get even the simple things working correctly after many weeks. The #1 issue right now, as I'm afraid it could be responsible for the inaccuracies I'm seeing in what I'm trying to make, is the error message I get almost every time I fire up the program: RTAPI: unexpected realtime delay on task 1 There are 5 pages available through Google on the matter, and they don't answer the question, beyond hinting I should change my base period. I read whatever I could find awhile back about setting up the latency, but couldn't really make heads nor tails of it. The information in a few docs I found online didn't match up with anything I was seeing on the screen, and I don't have intimate knowledge of these things, so was unable to guess at anything. Tonight, I ran the latency-test again, and having again been handed many numbers that don't mean anything to me (and aren't explained anywhere I've been able to find), I decided to just use the Base Thread (25.0 µs) Max Jitter (NS) in my inch.ini file for BASE_PERIOD - a total guess, but it seemed right. The error stopped occurring, for a few more launches, but then returned. I understand absolutely nothing about any of this, so I have no next step. The default BASE_PERIOD in the file was IIRC 5. I've tried down to 1 (makes it super slow to load up), and up to the very high number I got from my latency tests - 187525 - and even 20. The error always comes back. Am I going to have to build the software from source (for some reason, as indicated in some of my Google finds?). I'll save my other curiosities for future emails, as I don't want this important bit to get lost in a flood of other questions :) Thanks very much! -Gary - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users - This SF.net email is sponsored by: Microsoft Defy all
Re: [Emc-users] Homing using 2 motors per axis
Thanks for the great report, Rob. Good luck with that first paying project. Your idea of suppressing motion on the first motor to reach it's switch sounds like it should work. If I remember right, long years ago there was a fellow in Finland that proposed a yearly contest for the most innovative "work around." Rayh--- [EMAIL PROTECTED] wrote:From: Rob Jansen [EMAIL PROTECTED]To: "Enhanced Machine Controller (EMC)" emc-users@lists.sourceforge.netSubject: Re: [Emc-users] Homing using 2 motors per axisDate: Sun, 16 Mar 2008 09:00:14 +0100 Clint, home with the motors on. My machine's motors are not strong enough to hurt the machine when they run into the stops so I usually just crash the axis then home... Oh ya, stepper motors...This method is brutal but effective. Brute and destructive on my machine ... It happened once, while overshooting the home switch and if I now place a hair ruler on the bearing block (made out of 6082-T651 alu) I can see it's bent ... I used the manual procedure you described a few times but the problem, as Rayh acknowledges, is that the motors move to a full step position when the controllers are switched on and at that time there already is a misallignment of max. 0.02 mm. But I'll leave this as it is for now - A full step is 0.025 mm and the two axes are 1220 mm apart so that gives a max. 0.001 degree error. If a customer wants more accuracy, they'll have to pay enough for me to upgrade my machine ;-) Rayh, As long as you don't have to worry about loosing steps, both motors could be driven from the same set of step and direction pulses -- except when trying to find home. I'm thinking of a real kludge here but since you can home anytime, you could build a little switch that disconnects one drive from the step and direction signals at a time while the other one homes. Once both are homed, send the motion pulses to both and you should have a well behaved system. No lost steps seen here the last few weeks and I have made some funny mistakes - like running an 18mm end mill through a 15mm workpiece at 400 mm/min ... Ruined my workpiece but both the milling bit and the machine's zero position were not affected at all. I found a simple and effective solution for the kludge that you described above: a few logic gates to disable the stepper pulse to the axis when the corresponding home switch triggers during a travel towards the switches. The homing signal to EMC is only activated when both axes are homed. I'll add this solution some day, but I first need to finish the machanical/electrical construction: mounting of the energy chains, mounting all electronics in the control cabinet, add an extra plate to the table and ... and ... and ... Just got a phonecall: my first customer is finished and wants to deliver materials and milling data coming Friday - originally this was planned two weeks later. So I've still got 5 days to get the machine in a proper shape, including today. Luckily I don't have to start milling right away but it should at least look as if I'm ready O:-) Rob - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] How do I calculate leadscrew push/pull forces?
Patrick, The screw's pitch is such that one turn gives 0.2 of travel, or 5 turns per inch. That would seem to give it a mechanical advantage of 5, but what has me a little bit confused is the translation of a torque (from the motor) to a linear force (by the nut). This confuses me a bit. If the diameter of the screw is 0.5 the circumference is pi*0.5 = 1.57 which gives 1 linear travel per 5 rotations (7.85) so a 1::7.85 ratio. I believe it is correct to say that a 200 oz.-in. motor, for example, can exert a force of 200 oz. (12.5 lb) at a distance of one inch from the center of its shaft. Nope, most likely the 200 oz.in is the hold torque. This means that at a full step, with full current, the motor will be able to withstand up to 200 oz.in When the motors start moving, torque is less. How much depends on the motors, kind of stepper controller used and the speed. Since the leadscrew has a mechanical advantage of 5 and is 0.5 in diameter, does that mean that I should expect (200 oz. / 0.5) * 5 = 2000 ounces (or 125 pounds) of push? * 7.85 * efficiency. Ball screws have a high efficiency and since the calculation is a rough estimation anyway I use 100%. I did a simple measurement with a weighbeam on the current leadscrews and determined the force needed to move the leadscrew and selected my motors based on this. Replacing the old leadscrews by ballscrews would even reduce the torque needed but I decided to stay on the safe side. Hope this helps a bit. Regards, Rob - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] EMC2 newbie woes
On Tuesday 18 March 2008, [EMAIL PROTECTED] wrote: I picked up a Sherline mini mill in late '06, and their mini lathe in early '07, and then essentially never used them. I worked too much, and couldn't run them in my apartment building by the time I'd get home. Now I'm in a house, and have been trying to get it all set up again, but I have to say that unfortunately I've had nothing but troubles for about a month now trying to get EMC2 and my mill set up properly. I need to say that I do appreciate the efforts of the group, and am committed to getting this to work, and I love free/open software, but alas, I'm still trying to get even the simple things working correctly after many weeks. The #1 issue right now, as I'm afraid it could be responsible for the inaccuracies I'm seeing in what I'm trying to make, is the error message I get almost every time I fire up the program: RTAPI: unexpected realtime delay on task 1 This error, if it comes up as the progam is finalizing the gui, is apparently a never mind. It seems to be video card related as I do not get that error when I am ssh -Y -l gene shop into that machine from this machine. That machine has a GForce2 FX 5200 card in it with the motherboard video disabled in the bios. According to dmesg, it isn't identified and until x starts is running the framebuffer in vga-16 mode. The video card in this box is also an nvidia, a 3DForce 6200. I let stepconf set the base_period, and I have reduced it by several microseconds without encountering the error later while running. If you hit it while running, That is a different animal entirely. I have not seen it since about 2.0.3 or so, which is about the time that check was added to emc2 I believe. The actual effect in the milling would I believe, be a later than normal issuance of the next step, which could effect the maximum speeds reliability. At 10 ipm cutting speeds its not going to be a wreck the part error as it would be only a late step, not a missed one. So if you see it at startup seems to be un-important, if you see it while running (leave the motors off and run the axis logo would be one test) then it should be a concern. In that event slowing the base thread by increasing the number in the .ini file might then be indicated. Doing something about the video is the other, on-board video with its shared memory has been a problem in times past, and is why there is the cheap nvidia card in my shop machine. Interestingly I ran that card on the kernels nv drivers for quite a while, but it had trouble with slow display refreshing, and installing the drivers for it from the nvidia site made a huge difference there, but did not effect the single error it puts up at startup. There are 5 pages available through Google on the matter, and they don't answer the question, beyond hinting I should change my base period. I read whatever I could find awhile back about setting up the latency, but couldn't really make heads nor tails of it. The information in a few docs I found online didn't match up with anything I was seeing on the screen, and I don't have intimate knowledge of these things, so was unable to guess at anything. Tonight, I ran the latency-test again, and having again been handed many numbers that don't mean anything to me (and aren't explained anywhere I've been able to find), I decided to just use the Base Thread (25.0 µs) Max Jitter (NS) in my inch.ini file for BASE_PERIOD - a total guess, but it seemed right. The error stopped occurring, for a few more launches, but then returned. I understand absolutely nothing about any of this, so I have no next step. The default BASE_PERIOD in the file was IIRC 5. I've tried down to 1 (makes it super slow to load up), and up to the very high number I got from my latency tests - 187525 - and even 20. The error always comes back. Am I going to have to build the software from source (for some reason, as indicated in some of my Google finds?). Those sound like the sort of numbers one might get from a shared with main memory on-board video system, see above. A different video card might be in order. I'll save my other curiosities for future emails, as I don't want this important bit to get lost in a flood of other questions :) Thanks very much! -Gary - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Cheers, 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) WHERE CAN THE MATTER BE Oh, dear, where can the matter be When it's converted to energy? There is a slight loss
[Emc-users] 4 axis .nc example file
Hi guys, Where could i find some 4-axis .nc example files compatible with emc2? Carlos Pena Santo Domingo, Dominican Republic - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] EMC list troubles, and thanks, Gene Heskett!
I set up an account for this list - [EMAIL PROTECTED] - through my host, but couldn't reply to the confirmation email from Thunderbird on Linux at home. It would send, and go into my outbox, but nothing would ever come of it. I had to click through to the site (from Thunderbird), and confirm it there. I then couldn't send, nor reply to any message ever from Thunderbird, though I tried several times to do both over the past few weeks, hoping it would finally take. It would, however, always let me send, and reply from the web interface. I'm not sure why, as it's the same account - just a different interface on my end, and a different outbound server (verizon at home / probably my host - hostrocket - at work). Thunderbird was receiving every list message, including the ones I'd sent through the web interface. Every message sent through the web version always made it, and promptly. Clearly, the Verizon server's version of my mail was just being dropped, probably by the list, as I've not had that problem sending mail anywhere else, and have for years now, including to about 5 other list serves. Anyway, I just thought I'd mention this, with details, in case anyone in here has power over these things. Maybe it's just a flipped switch, or someone's chair is on the internet cable ;) Also, a big thanks to Gene Heskett for answering my RTAPI error question from last night. I forgot about my mail troubles, and downloaded the messages into Thunderbird this morning, and of course, can't reply to that one now from in there. It would seem I can use this new Gmail address from now on, so I'm moving to this account, and dumping the cnc@ address from my host. I use Gmail daily anyway, so it's not a big deal, but it's frustrating that I can't use any personal email through my own server. I may have more questions about RTAPI issues, but I'll start a new thread with this address should it come to that. Thanks again. -Gary - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] EMC list troubles, and thanks, Gene Heskett!
Gary, Some band width providers will block socket 25 as a measure to cut down on spam. When you receive mail, that goes through another service (POP3 is the most common) which is on a different port (110 for POP). This can explain why you are able to receive, but not send. The way to test this is to do the following in a terminal session (command prompt on Windoze): telnet SMTP server name 25 The SMTP server name is the one you set up for outgoing mail on your [EMAIL PROTECTED] email account and '25' specifies the SMTP socket. If the connection times out, then socket 25 is being blocked. If you get a telnet session (it should start 220 SMTP Server name...) then you have a different problem. Additionally, if this is the problem, then you should not be able to send to any email address, not just this list. Having said that, I also have Verizon at home and it is not blocking socket 25 for me. Regards, Eric I set up an account for this list - [EMAIL PROTECTED] - through my host, but couldn't reply to the confirmation email from Thunderbird on Linux at home. It would send, and go into my outbox, but nothing would ever come of it. I had to click through to the site (from Thunderbird), and confirm it there. I then couldn't send, nor reply to any message ever from Thunderbird, though I tried several times to do both over the past few weeks, hoping it would finally take. It would, however, always let me send, and reply from the web interface. I'm not sure why, as it's the same account - just a different interface on my end, and a different outbound server (verizon at home / probably my host - hostrocket - at work). Thunderbird was receiving every list message, including the ones I'd sent through the web interface. Every message sent through the web version always made it, and promptly. Clearly, the Verizon server's version of my mail was just being dropped, probably by the list, as I've not had that problem sending mail anywhere else, and have for years now, including to about 5 other list serves. Anyway, I just thought I'd mention this, with details, in case anyone in here has power over these things. Maybe it's just a flipped switch, or someone's chair is on the internet cable ;) Also, a big thanks to Gene Heskett for answering my RTAPI error question from last night. I forgot about my mail troubles, and downloaded the messages into Thunderbird this morning, and of course, can't reply to that one now from in there. It would seem I can use this new Gmail address from now on, so I'm moving to this account, and dumping the cnc@ address from my host. I use Gmail daily anyway, so it's not a big deal, but it's frustrating that I can't use any personal email through my own server. I may have more questions about RTAPI issues, but I'll start a new thread with this address should it come to that. Thanks again. -Gary - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] EMC list troubles, and thanks, Gene Heskett!
On Tuesday 18 March 2008, Gary Fixler wrote: I set up an account for this list - [EMAIL PROTECTED] - through my host, but couldn't reply to the confirmation email from Thunderbird on Linux at home. It would send, and go into my outbox, but nothing would ever come of it. I had to click through to the site (from Thunderbird), and confirm it there. I then couldn't send, nor reply to any message ever from Thunderbird, though I tried several times to do both over the past few weeks, hoping it would finally take. It would, however, always let me send, and reply from the web interface. I'm not sure why, as it's the same account - just a different interface on my end, and a different outbound server (verizon at home / probably my host - hostrocket - at work). Thunderbird was receiving every list message, including the ones I'd sent through the web interface. Every message sent through the web version always made it, and promptly. Clearly, the Verizon server's version of my mail was just being dropped, probably by the list, as I've not had that problem sending mail anywhere else, and have for years now, including to about 5 other list serves. Anyway, I just thought I'd mention this, with details, in case anyone in here has power over these things. Maybe it's just a flipped switch, or someone's chair is on the internet cable ;) Also, a big thanks to Gene Heskett for answering my RTAPI error question from last night. I forgot about my mail troubles, and downloaded the messages into Thunderbird this morning, and of course, can't reply to that one now from in there. It would seem I can use this new Gmail address from now on, so I'm moving to this account, and dumping the cnc@ address from my host. I use Gmail daily anyway, so it's not a big deal, but it's frustrating that I can't use any personal email through my own server. I may have more questions about RTAPI issues, but I'll start a new thread with this address should it come to that. Thanks again. -Gary I have not had any probs with vz dropping this list, but the jerks kept dropping and bouncing the lkml, getting me un-subscribed twice so I had to move that account to gmail. But, when vz gets a corncob up their anus about a list, you may as well give up and use gmail. I actually have 3 servers I can 'pop3' fetch from, using fetchmail, which in turn uses procmail as its MTA, and procmail steers it through spamassassin and disposes of it accordingly if its too spammy. All kmail has to do is sort it to the right folders. Does that make this old fart (73) a 'power user'? Nah, just a wee bit better than the average bear, a small amount of the time, and dumber the rest of the time. :) In re the rtapi and unexpected realtime delay issues, I experimented some this afternoon with my base thread which was set at 78000ns when I started, reducing it to 38000ns for the last test, running most of the stuff in the nc_files dir to test, and never did see another error AFTER the startup, even when running at 200% speeds here. However, as has been noted, every motherbaord/video combo is going to be enough different that sometimes the only thing you can do is to throw more money at the hardware. There have been a couple of motherboards that just weren't usable but I don't even recall their trade names now. Perhaps one of the developers has a better memory than mine on what brands to avoid. -- Cheers, 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) A vivid and creative mind characterizes you. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] EMC list troubles, and thanks, Gene Heskett!
Gene Heskett wrote: In re the rtapi and unexpected realtime delay issues, I experimented some this afternoon with my base thread which was set at 78000ns when I started, reducing it to 38000ns for the last test, running most of the stuff in the nc_files dir to test, and never did see another error AFTER the startup, even when running at 200% speeds here. You never will. The realtime delay error message is printed only once, the first time EMC notices a delay. We don't print it every time because if you have your period set too low, or you have a computer with bad realtime issues, you could get hundreds or thousands of those messages every second. Only printing the message once solves that problem, but it means that you really don't know how often you are getting a delay. But DON'T think just because you get it only once that it is happening only once. Regards, John Kasunich - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] EMC list troubles, and thanks, Gene Heskett!
On Tuesday 18 March 2008, John Kasunich wrote: Gene Heskett wrote: In re the rtapi and unexpected realtime delay issues, I experimented some this afternoon with my base thread which was set at 78000ns when I started, reducing it to 38000ns for the last test, running most of the stuff in the nc_files dir to test, and never did see another error AFTER the startup, even when running at 200% speeds here. You never will. The realtime delay error message is printed only once, the first time EMC notices a delay. I have, once or twice, seen 2, but they don't coome from the same code, the windows it opens are different sized. But thats very rare. Both at startup, just as axis has finished drawing its screen, and many seconds before emc would ever be asked to do anything. We don't print it every time because if you have your period set too low, or you have a computer with bad realtime issues, you could get hundreds or thousands of those messages every second. And a machine that could only be rescued by a tap on the reset button. Thats not a Good Thing(TM). OTOH, if the first thing you did after rebooting was to add 20% more time to the base_period, you would soon know if the hardware was usable for emc. Only printing the message once solves that problem, but it means that you really don't know how often you are getting a delay. But DON'T think just because you get it only once that it is happening only once. Regards, John Kasunich Hummm, much food for thought, does it hit the logs or is that skipped too? Doing the test over an ssh -Y link, I see some decent numbers with a worst case n about 5 minutes of web browsing of 14500ns, 14.5 u-secs. I don't believe its that good running on its own screen, giving numbers in the 17800ns area IIRC. Still, even 20 u-secs is tolerable. The last time I ran stepconf, it chose a 78 u-second base period, which did seem rather slow. However since the advent of one cycle steps in the stepgen these days, the text is in bad need of updateing on the wiki page that discusses the latency-test and how to use it. That is at: http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?TweakingSoftwareStepGeneration#Run_a_Latency_Test Since it is assuming 2 cycles per step, the description gets confusing fairly quickly as I'm not sure what I should throw out to make it sensible in a one cycle step scenario. Its still running, and showing a base_thread of about 38500ns, and a jitter of just under 14000ns, so what would be the ideal base_period, ignoring the startup message that axis's drawing of its gui apparently creates? BTW, 2.2.4 'feels' good. No surprises so far, but then I haven't made any chips either as I'm still rebuilding that corner. I bought a 36x48 sheet of some sort of acrylic that is supposed to be 250 times stronger than glass, but in nibbling off a corner to use as the mount for the suicide brakes resistor (40 ohms), I found cracks propagate through it just like regular acrylic. Lexan it ain't.. Whats left will be placed on the frame between the mill and the computer, and the keyboard shelf will get wider so there is room for the mouse etc etc. I haven't figured out what to do with the ups yet, it is about 60 pounds crowds the hell out of the shelf above the monitor where the xylotex and its psu live alongside the computer. 60 pounds that high in the air on a step stool is a bit much for this old fart these days. Thanks John. -- Cheers, 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) Outside of a dog, a book is man's best friend. Inside of a dog, it is too dark to read. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] EMC list troubles, and thanks, Gene Heskett!
Gene Heskett wrote: [snip] Only printing the message once solves that problem, but it means that you really don't know how often you are getting a delay. But DON'T think just because you get it only once that it is happening only once. Regards, John Kasunich Hummm, much food for thought, does it hit the logs or is that skipped too? There are two different places where overruns may be displayed. One of them is available in HAL as the parameter motion.servo.overruns. You can stick a halmeter on that and see if it increases over time. Note: that parameter may go up by 5 every time there's one overrun - it looks at 5 samples and it's possible that the error will be reported as long as the bad sample is in the buffer. There are a couple of other parameters as well, motion.servo.last-period (the last servo thread period in CPU clocks) and motion.servo.last-period-ns (the last servo thread period in ns - in some cases, this version won't be available). Doing the test over an ssh -Y link, I see some decent numbers with a worst case n about 5 minutes of web browsing of 14500ns, 14.5 u-secs. I don't believe its that good running on its own screen, giving numbers in the 17800ns area IIRC. Still, even 20 u-secs is tolerable. The last time I ran stepconf, it chose a 78 u-second base period, which did seem rather slow. That does sound a bit slow for PWM, but may be fine for step generation. A period of 78 us gives you ~12800 steps/second. If you have 8000 steps/inch, this gives you 96 IPM. However since the advent of one cycle steps in the stepgen these days, the text is in bad need of updateing on the wiki page that discusses the latency-test and how to use it. That is at: http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?TweakingSoftwareStepGeneration#Run_a_Latency_Test Since it is assuming 2 cycles per step, the description gets confusing fairly quickly as I'm not sure what I should throw out to make it sensible in a one cycle step scenario. I wouldn't throw much out, but adding something on calculations for double-step might be a good thing. Remember also that type 1 stepgens may not be the only thing running in the base thread. Any of the phase drive outputs or quadrature can't use (and don't need) doublestep, and then there's PWM to throw in the mix. Its still running, and showing a base_thread of about 38500ns, and a jitter of just under 14000ns, so what would be the ideal base_period, ignoring the startup message that axis's drawing of its gui apparently creates? I wouldn't blame it on AXIS until someone shows that it doesn't happen with any other GUIs. :) Actually, it's not AXIS in any case since that's a userspace application - it could be your video drivers if it has something to do with the 3D preview, your disk drivers if it's from loading the startup g-code file, your file system itself (I actually traced a large, periodic RT bump to kjournald on one setup)... It's also possible that the problem is within RTAI - like some kind of condition where some timer setup is done, but before the interrupt is enabled (or directed where we want), more time elapses than expected. That would cause one problem at startup, but isn't indicative of a run-time issue. It's hard to tell what the ideal base period is. Stepconf is probably choosing something that will work for whatever scaling and max velocities you've chosen. I don't know if it takes PWM period/resolution into account when choosing the BASE_PERIOD though. Incidentally, what tells you that the generated time is not ideal? - Steve - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
