From: Weyland <we...@va...> - 2003-09-25 02:41:43
|
I'm stumped. I've read and read. Applied what I've been advised, but I just can't figure this out on my own. To bring you up2date - I've modified the ini again, and things seem to run pretty darn well, but again - not great. I got the 470uF/100V caps in place on the Geckos. I'm running 75VDC / 5A. (didn't get the chance to wire in the new Variac yet) (will do it tomorrow) EMC ran for a long time today, and then did it again. It just stops. Sits there. Losing steps. Screen is showing movement, but there isn't any. *OR* After a while, it seems the axis with the most motion going on starts creeping to one side... I'm at a loss, and need someone to help me through this. How can I figure this out? What can I relate to you guys that might give off a clue? I placed a piece of wood on the table, and ran a part that is a pretty lenthy file size. It's an output from Matt Shaver's bmp2cnc. It's a logo that I'm eventually going to make for someone. I left it rather large, because I thought that all the movement would be a good thing to test with to try and tune EMC to work better. With my current settings/ini file, to make it only .750" in the Y axis took about 45 minutes. To start with, I find this amazingly slow. Does anyone think I'm expecting too much, here? Granted, it should double by installing ballscrews, but I still think this is pretty slow, considering the size of the motors. (I have some tech sheets on the motors, and am willing to scan them and put them on my website if someone wants to see them.) As well, when it got to the point where it had made it through .750" in the Y (figure each X move was 6.750"), it stops in X. It did this three consecutive times. As well, in simulation (not actually hooked to the mill, while I was at work), it would report a following error in X at the same place every time, but a different place than where it is erroring when actually hooked up to the mill. I'm including the appropriate parts of the ini for help in figuring this out. I can mail anyone the part file, but didn't want to slam someone not wanting it by sending it to the list, unless everyone really thinks I should. (it's 475K, so I doubt it) Disturbed and Confounded, Weyland [EMC] ; Debug level, 0 means no messages. See emc/src/emcnml/emcglb.h for others DEBUG = 0x00000003 ; DEBUG = 0x7FFFFFFF ; Startup codes for RS-274-NGC interpreter RS274NGC_STARTUP_CODE = G20 [DISPLAY] ; Platform for GUI PLAT = nonrealtime ; Name of display program, e.g., xemc DISPLAY = tkemc ; Cycle time, in seconds, that display will sleep between polls CYCLE_TIME = 0.050 ; Initial display setting for position, RELATIVE or MACHINE POSITION_OFFSET = MACHINE ; Initial display setting for position, COMMANDED or ACTUAL POSITION_FEEDBACK = ACTUAL ; Highest value that will be allowed for feed override, 1.0 = 100% MAX_FEED_OVERRIDE = 2.0 ; Units for display, default would be AUTO LINEAR_UNITS = INCH ANGULAR_UNITS = AUTO [TASK] ; Platform for task controller PLAT = nonrealtime ; Name of task controller program, e.g., bridgeporttask TASK = minimilltask ; Cycle time, in seconds, that task controller will sleep between polls CYCLE_TIME = 0.010 [EMCMOT] ; Platform for motion PLAT = realtime ; Name of motion control program EMCMOT = freqmod.o ; Timeout for comm to emcmot, in seconds COMM_TIMEOUT = 1.0 ; Interval between tries to emcmot, in seconds COMM_WAIT = 0.010 ; Base task period, in seconds ; Don't use this if steppermot is being used PERIOD = 0.000010 [TRAJ] AXES = 3 ; COORDINATES = X Y Z R P W COORDINATES = X Y Z HOME = 0 0 0 LINEAR_UNITS = 0.03937007874016 ANGULAR_UNITS = 1.0 CYCLE_TIME = 0.005 DEFAULT_VELOCITY = 0.0167 MAX_VELOCITY = 2.5 DEFAULT_ACCELERATION = 1.0 MAX_ACCELERATION = 1.0 PROBE_INDEX = 0 PROBE_POLARITY = 1 ; Axes sections --------------------------------------------------------------- ; First axis [AXIS_0] TYPE = LINEAR UNITS = 0.03937007874016 HOME = 0.000 MAX_VELOCITY = .8333 P = 320.000 I = 0.000 D = 0.000 FF0 = 0.000 FF1 = 0.000 FF2 = 0.000 BACKLASH = 0.0003 BIAS = 0.000 MAX_ERROR = 0.000 DEADBAND = 0.0005 CYCLE_TIME = 0.000500 INPUT_SCALE = 4000 0 OUTPUT_SCALE = 4000.000 0.000 MIN_LIMIT = -10.0 MAX_LIMIT = 10.0 MIN_OUTPUT = -10 MAX_OUTPUT = 10 FERROR = 1.000 MIN_FERROR = 0.010 HOMING_VEL = 0.3 SETUP_TIME = 1 HOLD_TIME = 2 HOME_OFFSET = 0.0 ENABLE_POLARITY = 0 MIN_LIMIT_SWITCH_POLARITY = 0 MAX_LIMIT_SWITCH_POLARITY = 0 HOME_SWITCH_POLARITY = 1 HOMING_POLARITY = 1 JOGGING_POLARITY = 1 FAULT_POLARITY = 1 ; Parameters for Inland Motor BMHS-0701 X 20 TORQUE_UNITS = OZ_IN ARMATURE_RESISTANCE = 1.10 ARMATURE_INDUCTANCE = 0.0120 BACK_EMF_CONSTANT = 0.0254 ROTOR_INERTIA = 0.0104 DAMPING_FRICTION_COEFFICIENT = 0.083 SHAFT_OFFSET = 0 REVS_PER_UNIT = 10 ; Parameters for generic amplifier AMPLIFIER_GAIN = 1 MAX_OUTPUT_CURRENT = 10 LOAD_RESISTANCE = 1 ; parameters for generic encoder COUNTS_PER_REV = 4096 ; Second axis [AXIS_1] TYPE = LINEAR UNITS = 0.03937007874016 HOME = 0.000 MAX_VELOCITY = .8333 P = 320.000 I = 0.000 D = 0.000 FF0 = 0.000 FF1 = 0.000 FF2 = 0.000 BACKLASH = 0.0004 BIAS = 0.000 MAX_ERROR = 0.000 DEADBAND = 0.0005 CYCLE_TIME = 0.000500 INPUT_SCALE = 4000 0 OUTPUT_SCALE = 4000.000 0.000 MIN_LIMIT = -10.0 MAX_LIMIT = 10.0 MIN_OUTPUT = -10 MAX_OUTPUT = 10 FERROR = 1.000 MIN_FERROR = 0.010 HOMING_VEL = 0.3 SETUP_TIME = 1 HOLD_TIME = 2 HOME_OFFSET = 0.0 ENABLE_POLARITY = 0 MIN_LIMIT_SWITCH_POLARITY = 0 MAX_LIMIT_SWITCH_POLARITY = 0 HOME_SWITCH_POLARITY = 1 HOMING_POLARITY = 1 JOGGING_POLARITY = 1 FAULT_POLARITY = 1 ; Parameters for Inland Motor BMHS-0701 X 20 TORQUE_UNITS = OZ_IN ARMATURE_RESISTANCE = 1.10 ARMATURE_INDUCTANCE = 0.0120 BACK_EMF_CONSTANT = 0.0254 ROTOR_INERTIA = 0.0104 DAMPING_FRICTION_COEFFICIENT = 0.083 SHAFT_OFFSET = 0 REVS_PER_UNIT = 10 ; Parameters for generic amplifier AMPLIFIER_GAIN = 1 MAX_OUTPUT_CURRENT = 10 LOAD_RESISTANCE = 1 ; parameters for generic encoder COUNTS_PER_REV = 4096 ; Third axis [AXIS_2] TYPE = LINEAR UNITS = 0.03937007874016 HOME = 0.000 MAX_VELOCITY = .8333 P = 320.000 I = 0.000 D = 0.000 FF0 = 0.000 FF1 = 0.000 FF2 = 0.000 BACKLASH = 0.000 BIAS = 0.000 MAX_ERROR = 0.000 DEADBAND = 0.0005 CYCLE_TIME = 0.000500 INPUT_SCALE = 4000 0 OUTPUT_SCALE = 4000.000 0.000 MIN_LIMIT = -10.0 MAX_LIMIT = 10.0 MIN_OUTPUT = -10 MAX_OUTPUT = 10 FERROR = 1.000 MIN_FERROR = 0.010 HOMING_VEL = 0.3 SETUP_TIME = 1 HOLD_TIME = 2 HOME_OFFSET = 0.0 ENABLE_POLARITY = 0 MIN_LIMIT_SWITCH_POLARITY = 0 MAX_LIMIT_SWITCH_POLARITY = 0 HOME_SWITCH_POLARITY = 1 HOMING_POLARITY = 1 JOGGING_POLARITY = 1 FAULT_POLARITY = 1 ; Parameters for Inland Motor BMHS-0701 X 20 TORQUE_UNITS = OZ_IN ARMATURE_RESISTANCE = 1.10 ARMATURE_INDUCTANCE = 0.0120 BACK_EMF_CONSTANT = 0.0254 ROTOR_INERTIA = 0.0104 DAMPING_FRICTION_COEFFICIENT = 0.083 SHAFT_OFFSET = 0 REVS_PER_UNIT = 10 ; Parameters for generic amplifier AMPLIFIER_GAIN = 1 MAX_OUTPUT_CURRENT = 10 LOAD_RESISTANCE = 1 ; parameters for generic encoder COUNTS_PER_REV = 4096 ; section for main IO controller parameters ----------------------------------- [EMCIO] ; Platform for IO controller PLAT = nonrealtime ; Name of IO controller program, e.g., bridgeportio EMCIO = minimillio ; cycle time, in seconds CYCLE_TIME = 0.100 |
From: Brian M. <br...@bk...> - 2003-09-25 13:50:43
|
Weyland - I have been watching the list with interest as you get your machine up and running. Thank you for the effort you are going to here. My thoughts on the axis-stopping are that you are getting thermal shutdown of one of you motor driver circuits. You have not mentioned any forced-air cooling on the driver board itself and I am not familiar with what you are using. My own setup has a muffin fan mounted directly over the driver board. All of the modern circuits will attempt to protect themselves in some way. There may also be thermal breakers in your stepper motors. Since you say this is the axis that is really getting a workout, maybe it is also the hottest. This does not explain the simulation following error you described, though. One thing that I have noticed is that EMC frequently stops running while displaying an error that will not occur until several lines of code in the future. I have seen this most often with the old "Concave Part with Cutter Offset Enabled" error. It stops when (to my mind) it hasn't gotten there, yet. Yes, it has to anticipate operations to do the cutter offset calculations, but I don't see needing more than two steps of look-ahead. Brian McMillin |
From: Weyland <we...@va...> - 2003-09-25 14:28:03
|
On Thursday 25 September 2003 09:50 am, Brian McMillin spake: > I have been watching the list with interest as you get your machine up > and running. Thank you for the effort you are going to here. Well, let me clarify a bit -=20 While it may look like work, and might even feel like work=20 sometimes, the key to remember here is that my real love=20 is machining, so this is really just a lot of fun for me that has the=20 additional bonus of letting me make money every now and then. While my job right now may be one of Linux Admin, I've=20 only been using computers for five years, and came out=20 of the Tool Room, working in R&D as a Tool & Die maker. So don't let me bitch too much... > My thoughts on the axis-stopping are that you are getting thermal > shutdown of one of you motor driver circuits. You have not mentioned > any forced-air cooling on the driver board itself and I am not familiar > with what you are using. =20 I've got Gecko G210's. They are mounted on a piece of sheetmetal, slightly off vertical. What I've done is drill two 1/2" holes on the top and bottom edges of=20 where the Geckos mount, allowing for a Socket7 processor's fan and heatsi= nk=20 spring clip to poke through, and then hook onto the tabs of the Gecko. (I'll take a picture tonight, maybe.) Anyway, they stay very cool, just barely perceptible to be even warm. Never hot. > There may also be thermal breakers in > your stepper motors. Since you say this is the axis that is really > getting a workout, maybe it is also the hottest. Shazaam~! Now there's a thought. I have no idea. Would the papers on my motors say for sure? (I have no idea what I'd be looking for) > This does not explain the simulation following error you described, > though. One thing that I have noticed is that EMC frequently stops > running while displaying an error that will not occur until several > lines of code in the future. I have seen this most often with the old > "Concave Part with Cutter Offset Enabled" error. It stops when (to my > mind) it hasn't gotten there, yet. Yes, it has to anticipate operation= s > to do the cutter offset calculations, but I don't see needing more than > two steps of look-ahead. Also a good thought process. The errors are in the same axis, too...=20 and only slightly ahead of where it's stopping. I think I'll try it with Ray's suggestion, from the CLI,=20 and see where it's stopping and with what messages. Thanks, Weyland |
From: Weyland <we...@va...> - 2003-09-25 16:16:51
|
On Thursday 25 September 2003 09:50 am, Brian McMillin spake: > There may also be thermal breakers in > your stepper motors. Since you say this is the axis that is really > getting a workout, maybe it is also the hottest. If R's are resistors, and D's are diodes, and=20 V's are voltages in a schematic, what's a Q? I ask because there's a schematic in my papers that shows some Q's. Q1, Q2, Q3, etc... Thanks, Weyland |
From: Jon E. <el...@pi...> - 2003-09-25 17:32:23
|
Weyland wrote: >On Thursday 25 September 2003 09:50 am, Brian McMillin spake: > > > >>There may also be thermal breakers in >>your stepper motors. Since you say this is the axis that is really >>getting a workout, maybe it is also the hottest. >> >> > >If R's are resistors, and D's are diodes, and >V's are voltages in a schematic, what's a Q? >I ask because there's a schematic in my papers that shows some Q's. >Q1, Q2, Q3, etc... > > Q is the common part number designator for transistor. T is for transformer. L is inductor, C capacitor. K is often used for relay. Jon |
From: Jon E. <el...@pi...> - 2003-09-25 17:28:31
|
Brian McMillin wrote: >Weyland - > >I have been watching the list with interest as you get your machine up >and running. Thank you for the effort you are going to here. > >My thoughts on the axis-stopping are that you are getting thermal >shutdown of one of you motor driver circuits. You have not mentioned >any forced-air cooling on the driver board itself and I am not familiar >with what you are using. My own setup has a muffin fan mounted directly >over the driver board. All of the modern circuits will attempt to >protect themselves in some way. > No, Geckos have no thermal protection built into them. > There may also be thermal breakers in >your stepper motors. > This would be even worse. There would have to be one in each phase, and the motor would rattle when only one opened up. Also, opening the motor phase while the driver is turned on can blow transistors. > Since you say this is the axis that is really >getting a workout, maybe it is also the hottest. > >This does not explain the simulation following error you described, >though. One thing that I have noticed is that EMC frequently stops >running while displaying an error that will not occur until several >lines of code in the future. I have seen this most often with the old >"Concave Part with Cutter Offset Enabled" error. It stops when (to my >mind) it hasn't gotten there, yet. Yes, it has to anticipate operations >to do the cutter offset calculations, but I don't see needing more than >two steps of look-ahead. > > Because you have to anticipate the accelerations needed to make any move in the future, and then begin slowing down NOW, to be down to the required speed when you get there, N blocks of lookahead are required, without bound. If you have a program with thousands of .0001" vectors, then there are 10000 blocks per inch traveled. (This is pathological, but some programs output this horrible kind of G-code.) EMC looks ahead at least 200 blocks, but I've never been able to find out where this depth of lookahead is defined. Jon |
From: Ray H. <re...@up...> - 2003-09-25 04:39:03
|
Weyland I'm gonna snip big time and answer just a bit from my own experience. On Wednesday 24 September 2003 09:41 pm, Weyland wrote: <s> > I placed a piece of wood on the table, and > ran a part that is a pretty lenthy file size. > > It's an output from Matt Shaver's bmp2cnc. > It's a logo that I'm eventually going to make for someone. > I left it rather large, because I thought that all the movement would > be a good thing to test with to try and tune EMC to work better. > With my current settings/ini file, to make it > only .750" in the Y axis took about 45 minutes. > > To start with, I find this amazingly slow. > Does anyone think I'm expecting too much, here? > > Granted, it should double by installing ballscrews, but I still > think this is pretty slow, considering the size of the motors. > (I have some tech sheets on the motors, and am willing to scan > them and put them on my website if someone wants to see them.) > > As well, when it got to the point where it had made it through > .750" in the Y (figure each X move was 6.750"), it stops in X. > > It did this three consecutive times. Seems like I remember something like this with a file that had a line of code burried in it that the interpreter could not handle. It just stopped. No error messages or anything. I think that the line was a single command without an axis for reference. g1 or such. To find it I had to turn on full debug in the ini (I see it's off) and start the emc from a terminal. Then I watched the look ahead until it quit giving me line numbers. Ray |
From: Jon E. <el...@pi...> - 2003-09-25 05:03:32
|
Ray Henry wrote: >Seems like I remember something like this with a file that had a line of >code burried in it that the interpreter could not handle. It just >stopped. No error messages or anything. I think that the line was a >single command without an axis for reference. g1 or such. To find it I >had to turn on full debug in the ini (I see it's off) and start the emc >from a terminal. Then I watched the look ahead until it quit giving me >line numbers. > > > Hmm, I think Ray is on to something! I'll bet you downloaded this file through a Windows PC at some point, anf then transferred it to the EMC computer (or somebofy did this before the file got to you). That can sometimes cause a character or two to disappear if the power-of-2 disk blocks fall on exactly the right point, and ASCII line-feeds are added in on one system, and then removed somewhere else. Jon |
From: Weyland <we...@va...> - 2003-09-25 05:10:29
|
On Thursday 25 September 2003 01:02 am, Jon Elson spake: > Hmm, I think Ray is on to something! I'll bet you downloaded this file > through a Windows PC at some point, anf then transferred it to the EMC > computer (or somebofy did this before the file got to you). That can > sometimes cause a character or two to disappear if the power-of-2 > disk blocks fall on exactly the right point, and ASCII line-feeds are > added in on one system, and then removed somewhere else. Great idea, but not even close. I don't have any running M$ stuff... Itza bitmap run through bmp2cnc in the fashion of - bmp2cnc /home/weyland/cnc/mytest.bmp > /home/weyland/cnc/mytest.ngc which yields a text file of g-code specifically compatible with EMC... All done on any of my Red Hat boxen. Weyland |
From: Chris B. <cb...@re...> - 2003-09-25 03:52:52
|
Weyland, > I'm stumped. > I've read and read. > Applied what I've been advised, but > I just can't figure this out on my own. This may not be the most popular option, but: I'd download the mach1 or mach2 demo from http://www.artofcnc.ca and hook up a windows machine to shake things out. This will tell you if it is an issue with the EMC hardware or linux configuration, or an issue with the drivers/power supply/motors. I have two working controller configurations. One is mach1, the other is EMC. I use them both. Mach1 (now mach2) is very solid and will generate a nice smooth pulse train. Once you've tested with mach1, you should have some idea where the problem lies. Hope this helps. Chris |
From: Weyland <we...@va...> - 2003-09-25 04:56:08
|
On Wednesday 24 September 2003 11:52 pm, Chris Brick spake: > This may not be the most popular option, but: > > I'd download the mach1 or mach2 demo from http://www.artofcnc.ca and hook > up a windows machine to shake things out. This will tell you if it is an > issue with the EMC hardware or linux configuration, or an issue with the > drivers/power supply/motors. I have two working controller configurations. > One is mach1, the other is EMC. I use them both. Mach1 (now mach2) is > very solid and will generate a nice smooth pulse train. Once you've tested > with mach1, you should have some idea where the problem lies. It's actually not a bad idea. Don't get me wrong when I rant. I'm no fan of M$ products, having used them for years, and I *am* a huge fan of Linux. That said, I'm open minded enough to use what works best for a need. For a while, I used FrontPage in Crossover Office, because it actually was the best tool for the job I needed it to do, at the time. I've got a spare drive to throw a windows install on and test it. I'll try this over the weekend if I dont' get it figured out by the weekend. <light bulb> Doesn't TurboCNC run in DOS? I could probably boot from a floppy and run it off the EMC box, too.... <light bulb dims...> Thanks. Weyland |
From: Chris B. <cb...@te...> - 2003-09-25 05:15:30
|
> It's actually not a bad idea. > Don't get me wrong when I rant. > I'm no fan of M$ products, having used > them for years, and I *am* a huge fan of Linux. Me too. I'm a linux sysadmin by trade and only use windows for CAD, Photoshop, and some CNC cutting. > <light bulb> > Doesn't TurboCNC run in DOS? > I could probably boot from a floppy and run it off the EMC box, too.... <light bulb > dims...> I've done this. I had trouble with constant contouring but it should work well for testing straight line movement and finding where the problem lies. Chris |
From: Weyland <we...@va...> - 2003-09-25 14:14:09
|
On Thursday 25 September 2003 01:15 am, Chris Brick spake: > I'm a linux sysadmin by trade and only use windows for CAD, > Photoshop, and some CNC cutting. I'm a Linux Admin for a short while longer, as well. If I could just get SolidWorks to run in Crossover or Wine,=20 I'd likely never see windows again, because Gimp and=20 ImageMagick do everything I used to need PhotoShop for. > > <light bulb> > > Doesn't TurboCNC run in DOS? > > I could probably boot from a floppy and run it off the EMC box, too..= =2E. > > <light bulb dims...> > > I've done this. I had trouble with constant contouring but it should w= ork > well for testing straight line movement and finding where the problem l= ies. > Chris Kewl. I completely forgot that the laptop had win2k on it, too. It came with it and I made it dual boot, but hadn't seen the=20 windows side in so long that I completely forgot it was there. I'm gonna go get Mach1 right now and throw it on it. Thanks, Weyland |
From: Weyland <we...@va...> - 2003-09-25 05:01:38
|
On Thursday 25 September 2003 12:38 am, Ray Henry spake: > I'm gonna snip big time and answer just a bit from my own experience. Hey Ray, > Seems like I remember something like this with a file that had a line of > code burried in it that the interpreter could not handle. It just > stopped. No error messages or anything. I think that the line was a > single command without an axis for reference. g1 or such. To find it I > had to turn on full debug in the ini (I see it's off) and start the emc > from a terminal. Then I watched the look ahead until it quit giving me > line numbers. I'll look for it, but I know the line it stopped at, and it was a two axis move, rapid. The bmp2cnc output is such that it only cuts in one direction, and rapids back to start over again in X and the incremented Y. This hit the end of the X, where it lifts the Z, and rapids back the X. Only, it just stood there... This is very frustrating. And unfortunately, a great deal of the things I wanted to do with this mill are just like this... Still, I'll try your suggestion of starting EMC from the CLI. (and I'll remember to turn on the debugging) (:O) Best, Weyland |
From: Matt S. <ms...@er...> - 2003-09-25 08:36:48
|
On Thursday 25 September 2003 01:01, Weyland wrote: > The bmp2cnc output is such that it only cuts in one direction, > and rapids back to start over again in X and the incremented Y. > This hit the end of the X, where it lifts the Z, and rapids back the X. Someday I might make it read in an entire row of pixels at a time so that= I=20 can eliminate the retrace. The way it is now, I don't have to dynamically= =20 allocate any memory! Matt |
From: Jon E. <el...@pi...> - 2003-09-25 17:19:35
|
Weyland wrote: >On Thursday 25 September 2003 12:38 am, Ray Henry spake: > > > >>I'm gonna snip big time and answer just a bit from my own experience. >> >> > >Hey Ray, > > > >>Seems like I remember something like this with a file that had a line of >>code burried in it that the interpreter could not handle. It just >>stopped. No error messages or anything. I think that the line was a >>single command without an axis for reference. g1 or such. To find it I >>had to turn on full debug in the ini (I see it's off) and start the emc >>from a terminal. Then I watched the look ahead until it quit giving me >>line numbers. >> >> > >I'll look for it, but I know the line it stopped >at, and it was a two axis move, rapid. >The bmp2cnc output is such that it only cuts in one direction, >and rapids back to start over again in X and the incremented Y. >This hit the end of the X, where it lifts the Z, and rapids back the X. >Only, it just stood there... > > > Can you send me the file? I'd like to try it on my "EMC classic" system as well as the BDI/sourceforge system I do testing on. Jon |
From: Weyland <we...@va...> - 2003-09-25 17:41:00
|
On Thursday 25 September 2003 01:18 pm, Jon Elson spake: > Can you send me the file? I'd like to try it on my "EMC classic" syste= m as > well as the BDI/sourceforge system I do testing on. Absolutely, Jon. I'd like to see what ya get. Although I'm pretty sure you'll be golden... :) It's on the way. Weyland |
From: Jon E. <el...@pi...> - 2003-09-26 06:46:19
|
Weyland wrote: >On Thursday 25 September 2003 01:18 pm, Jon Elson spake: > > > >>Can you send me the file? I'd like to try it on my "EMC classic" system as >>well as the BDI/sourceforge system I do testing on. >> >> > >Absolutely, Jon. >I'd like to see what ya get. >Although I'm pretty sure you'll be golden... :) > >It's on the way. > > I'll see if I can run it in the backplotter tomorrow morning. Jon |
From: Matt S. <ms...@er...> - 2003-09-25 08:34:08
|
On Wednesday 24 September 2003 22:41, Weyland wrote: > It's an output from Matt Shaver's bmp2cnc. Well, that's obviously your problem right there... ;) > EMC ran for a long time today, and then did it again. > It just stops. > Sits there. I had this problem recently and I can't remember exactly what caused it (= it's=20 3:55am here...). It was something like: 1. Our program used an M0 to pause for a tool change. 2. If you hit "S" to resume before the GUI had time to display "Interpret= er:=20 Paused", the "S" would have no effect (motion did not immediately restart= ). 3. If you the hit "S" again (after the display of "Interpreter: Paused"),= =20 motion would continue for a while and then the program would just stop at= the=20 end of some block with "Interpreter: Idle". I don't know if this is related to your problem... > With my current settings/ini file, to make it > only .750" in the Y axis took about 45 minutes. > > To start with, I find this amazingly slow. > Does anyone think I'm expecting too much, here? Well, let's see... The default value for SPACING (the distance between pi= xels=20 in bmp2cnc) is 0.01". I can't know, without looking at your picture data,= how=20 many gcode blocks are in each scan line of your image. If adjacent pixels= are=20 the exact same color, they are aggregated into one block. If we assume th= at=20 all your adjacent pixels are different colored, and that you have a 640x4= 80=20 image, then moving .750" in the Y axis would require processing about 482= 25=20 blocks { (640 + 3) x 75 }. That's almost 18 blocks per second { 48225 / (= 45 x=20 60) }. You could try setting the SPACING parameter to 0.05" which will gi= ve=20 you less blocks... Or you could wait for Rogier and Les to fix the segmen= t=20 queue code which should speed up your contouring dramatically. Matt |
From: Jon E. <el...@pi...> - 2003-09-25 17:23:15
|
Matt Shaver wrote: >On Wednesday 24 September 2003 22:41, Weyland wrote: > > >>It's an output from Matt Shaver's bmp2cnc. >> >> > >Well, that's obviously your problem right there... ;) > > > >>EMC ran for a long time today, and then did it again. >>It just stops. >>Sits there. >> >> > >I had this problem recently and I can't remember exactly what caused it (it's >3:55am here...). It was something like: > >1. Our program used an M0 to pause for a tool change. > >2. If you hit "S" to resume before the GUI had time to display "Interpreter: >Paused", the "S" would have no effect (motion did not immediately restart). > >3. If you the hit "S" again (after the display of "Interpreter: Paused"), >motion would continue for a while and then the program would just stop at the >end of some block with "Interpreter: Idle". > >I don't know if this is related to your problem... > > > It sounds like it continues from the lookahead buffer, but has forgotten to restart the interpreter! When the buffer is exhausted, there are no further commands to process. It takes a long file to cause this sort of problem. Jon |
From: Weyland <we...@va...> - 2003-09-28 01:53:42
|
On Thursday 25 September 2003 04:34 am, Matt Shaver spake: > On Wednesday 24 September 2003 22:41, Weyland wrote: > > It's an output from Matt Shaver's bmp2cnc. > > Well, that's obviously your problem right there... ;) :) Heh. > Well, let's see... The default value for SPACING (the distance between > pixels in bmp2cnc) is 0.01". I can't know, without looking at your picture > data, how many gcode blocks are in each scan line of your image. If > adjacent pixels are the exact same color, they are aggregated into one > block. If we assume that all your adjacent pixels are different colored, > and that you have a 640x480 image, then moving .750" in the Y axis would > require processing about 48225 blocks { (640 + 3) x 75 }. That's almost 18 > blocks per second { 48225 / (45 x 60) }. You could try setting the SPACING > parameter to 0.05" which will give you less blocks... Or you could wait for > Rogier and Les to fix the segment queue code which should speed up your > contouring dramatically. Well, I think this is proving to be something in EMC. More in a few... Weyland |
From: Dam <da...@1s...> - 2003-09-25 14:49:09
|
Wayland, Just a stab in the dark. BACKLASH = 0.0003 BIAS = 0.000 MAX_ERROR = 0.000 DEADBAND = 0.0005 CYCLE_TIME = 0.000500 INPUT_SCALE = 4000 0 Working in inches 4000 steps per inch = .00025 inches per step DEADBAND = 0.0005 This is greater than BACKLASH and SMALLEST STEP INCREMENT. DEADBAND should be 1/2 or a small amount more than 1/2 of INCHES PER STEP. DEADBAND = 0.00026 or 0.0003 Last thought. 0.0003 backlash? If that doesn't have an extra zero in there then IMO 3/10000's of an inch can be ignored and that should be 0.0 Do you really expect that level of position accuracy? Stick with it and it all starts to make sense eventually. Dale |
From: Weyland <we...@va...> - 2003-09-25 15:13:22
|
On Thursday 25 September 2003 10:55 am, Dam spake: > Just a stab in the dark. > > BACKLASH =3D 0.0003 > BIAS =3D 0.000 > MAX_ERROR =3D 0.000 > DEADBAND =3D 0.0005 > CYCLE_TIME =3D 0.000500 > INPUT_SCALE =3D 4000 0 > > Working in inches 4000 steps per inch =3D .00025 inches per step > > DEADBAND =3D 0.0005 > > This is greater than BACKLASH and SMALLEST STEP INCREMENT. > > DEADBAND should be 1/2 or a small amount more than 1/2 of INCHES PER S= TEP. > > DEADBAND =3D 0.00026 or 0.0003 Riiiiight... okay, I just went for the next thing up, thinking that=20 I really couldn't resolve .0003", but possibly could resolve .0005". I'll change that right now, as soon as the laptop boots up. > Last thought. 0.0003 backlash? If that doesn't have an extra zero in th= ere > then IMO 3/10000's of an inch can be ignored and that should be 0.0 Do = you > really expect that level of position accuracy? No, not at all. Let me explain -=20 I tried putting in .008 (and another number in the other axis) and immedi= ately=20 started getting all manner of goofy movements, really not making much sen= se. So, I got to thinking (I know..., I know...), and thought it possible tha= t the=20 ini might have wanted this number in mm, not inches, like when you specif= y=20 the units as ".03937...". Thus, the .0003 is my .008" of backlash. I had asked about the backlash number specification,=20 but didn't see an answer, so made a guess. Should that indeed be in inches? > Stick with it and it all starts to make sense eventually. My life is eventualities... :) Thanks, Weyland |
From: Dam <da...@1s...> - 2003-09-25 14:54:26
|
Wayland, OOPS! DEADBAND should be 1/2 or a small amount more than 1/2 of INCHES PER STEP. DEADBAND = 0.00026 or 0.0003 should read: DEADBAND should be 1/2 or a small amount more than 1/2 of INCHES PER STEP. DEADBAND = 0.000125 or 0.00015 I need another cup of coffee. Dale |
From: Weyland <we...@va...> - 2003-09-25 15:18:04
|
On Thursday 25 September 2003 11:00 am, Dam spake: > DEADBAND =3D 0.00026 or 0.0003 > should read: > DEADBAND should be 1/2 or a small amount more than 1/2 of INCHES PER S= TEP. > > DEADBAND =3D 0.000125 or 0.00015 <eyebrows lift> <eyes widen> <bell goes off> Ohhhhhhhhhhhhhhhhhhhh.... I had done the 1/4000, but completely overlooked taking 1/2 of that... > I need another cup of coffee. Me too. I'm buying. Come on. Thanks, Weyland |