Page 2 of 3 FirstFirst 123 LastLast
  1. #11
    not really :twisted:

    I am 110% sure this is not a mechanical overloading/blocking issue and have spent many hours cutting air investagating in failed attempts to identify what is happening.

    So I've come up with a little drawing as a tester. Consisting of a 40mm square, a 40mm kite(diamond) and a 40mm circle.

    It can 'air cut' square and kite three times faster than the circle. Funny thing it is always in the y- direction it stalls.

    I am sure there is a clue in that last line but I cannot resolve this one.

    Get the thinking caps on!

  2. Hi,

    I'm assuming that your machine is a moving bridge type on the Y axis, if this is the case then there is more weight on that axis to be moved. You are probably trying to accelerate/decelerate the machine too quickly for that axis.
    Try a slower accelerate rate, you may cut your parts a little slower but at least they will be correct.

    Simon

  3. #13
    The Y axis is the lightest and the x axis has to move itself and the y axis.

    Acceleration it a nice visable ramp and proved by straight line jogging and runs.

    My square /kite/ circle disproves power supply, mechanical block, overload, acceleration theories. Remember I am cutting air so no cutting forces.

    Why only Y- trouble :?:

  4. #14
    Ok here is a thought.

    my square G code has 14 lines all in.

    my circle has est. 450 lines. Remember the circle will fit into the square so its periphery is even less.

    At the same speed both files need executed in about the same time.

    Could the trouble be that my computer( well overspec for mach3)/mach3 cannot execute the file at a fast enough rate and then the pulses get mushy, loose thier defination, whatever the term is?


    Maybe it is time to start swapping motors/cards about to see if the trouble moves.

  5. #15
    Quote Originally Posted by Davidh
    Ok here is a thought.

    my square G code has 14 lines all in.

    my circle has est. 450 lines. Remember the circle will fit into the square so its periphery is even less.

    At the same speed both files need executed in about the same time.

    Could the trouble be that my computer( well overspec for mach3)/mach3 cannot execute the file at a fast enough rate and then the pulses get mushy, loose thier defination, whatever the term is?


    Maybe it is time to start swapping motors/cards about to see if the trouble moves.

    I would think has nothing to do with the number of lines in GCode. 450 lines isn't that much code. I've had mach run cuts with 100,000 lines of code without a hitch... I shit you not... Doubt it's "mushy pulses" either unless you're talking about some kind of pea related obstruction spread along your guides etc...... even on a an old 1.4 ghz duron mach software will output 46,000 pulse per sec. The default mach config of 25k pulses per sec is usually more than enough to run steppers.

    To suggest Mach is losing pulses and machine is stalling on a cut of 40mm length doesn't really hold up. Mach reserves 6 axes worth of resources and you're only running 3 If Mach starts losing pulse then it usually does it overall.. effecting the speed of all axes. Axes are driven by exactly the same hardware all the time. If the hardware can run it fast in straight lines theres nothing to suggest it should run any differently on non-straight cuts. On a straight or non-straight cut the axis will reserve an identical # of pulses per sec, and mach software will prioritise maintaining a constant pulse rate. Mach doesn't know/care about type of motion.. just sends step + dir pulses at the required place and rate throughout the motion. dir is on off signal, step is on off signal.. absolutely no difference in straight vs non-straight.... in many ways the kite is the same as a circle to mach software.

    Try swapping the X and Y axis output pin settings in Mach setup... see if the problem transfers... this will save you dismantling anything to start with. If the problem transfers then suspect your driver hardware, something in the step and dir connections from the parallel port to the drive or the Gcode itself It might also be something in the OS but I doubt it. If the problem does not transfer (which is actually what I think will happen) then it's time to suspect the motor settings, PSU or something intermittent in the power connections, loose power lead into a drive could produce this problem or loose connection from drive to motor... Could possibly be the motor spec or configuration... motor might be internally configured to run 2 active phases per step... which doubles current requirements... but again would think specs would have shown this.

    On the basis of the info you've given.. the Y axis does not stall on straight line cuts at all. You don't suggest that it stalls when moving on it's own. It stalls in combined motion with other axes on non-straight cuts.. you say it stalls even on air cuts, which you didn't mention before and also why I suggested deflection as place to start... You also didn't mention some other important info...so I'll have to ask for it..

    Have you made sure there's no feedrate adjustment in the Gcode for the circle ?
    Is feed overide in use on the circle ?
    Have you tried feed overide to see if it makes any difference ?
    Does it stall\lose steps if you jog all 3 axes together or jogging 1 back and forth while jogging others ?
    Does it stall immediately on the Y-axis.. or only above a certain speed ?
    Is it a constant loss of steps.. or a single big stall ?
    Are you sure the problem is restricted to a single axis ?
    What OS are you running ?
    Have you run the mach 3 optimisation ?.. i.e. switching off unused system processes.
    Have you run the mach 3 pulse rate test on your machine ?
    What IS your mach pulse rate on diagnostic page.. does this match set pulse rate ?
    Have you run motor tuning ?
    Are you sure your axis calculations (steps per unit) for mach 3 are correct and that settings are correctly applied
    Are all motors\settings the same ?
    Have you tried changing the origin position of the test paths along the Y axis.
    What happens after the stall ? would it complete the motion\cut.. or stall again ?

    The current limiting setup on your drives may also have a bearing on this.. i.e. is current limiting built in\adjustable.. if so how.. are settings correct for all motors.. that kind of thing..

    hope this helps...

  6. #16
    Swap the pin outputs---good idea, I'll do that.

    All the other Q's

    Have you made sure there's no feedrate adjustment in the Gcode for the circle ? is None

    Is feed overide in use on the circle ? N

    Have you tried feed overide to see if it makes any difference ? Same weather F/R is in Gcode or O/ride.

    Does it stall\lose steps if you jog all 3 axes together or jogging 1 back and forth while jogging others ? Jog is healthy al all speeds up to max (1300mm/min)

    Does it stall immediately on the Y-axis.. or only above a certain speed ? Not directly speed related, see above but would stall at a direction change

    Is it a constant loss of steps.. or a single big stall ? big stall which it usaully recovers from

    Are you sure the problem is restricted to a single axis ?Y

    What OS are you running ? WinXP

    Have you run the mach 3 optimisation ?.. i.e. switching off unused system processes. don't know. Will investagate.

    Have you run the mach 3 pulse rate test on your machine ? No. will investagate
    What IS your mach pulse rate on diagnostic page.. does this match set pulse rate ? Dont know
    Have you run motor tuning ? No

    Are you sure your axis calculations (steps per unit) for mach 3 are correct and that settings are correctly applied. Dont know, didnt calculate but reverse engineered off a ruler.

    Are all motors\settings the same ?Y

    Have you tried changing the origin position of the test paths along the Y axis.Y same trouble

    What happens after the stall ? would it complete the motion\cut.. or stall again ? recovers until next time.

    The current limiting setup on your drives may also have a bearing on this.. i.e. is current limiting built in\adjustable.. if so how.. are settings correct for all motors.. that kind of thing..
    Will triple check drive settings.


    Thanks for the input . I'll report the progress if/when I ever get a day off to play

  7. #17
    Quote Originally Posted by Davidh
    What OS are you running ? WinXP
    Have you run the mach 3 optimisation ?.. i.e. switching off unused system processes. don't know. Will investagate.
    Have you run the mach 3 pulse rate test on your machine ? No. will investagate
    What IS your mach pulse rate on diagnostic page.. does this match set pulse rate ? Dont know
    Have you run motor tuning ? No
    Are you sure your axis calculations (steps per unit) for mach 3 are correct and that settings are correctly applied. Dont know, didnt calculate but reverse engineered off a ruler.
    Are all motors\settings the same ?Y
    The problem is almost certainly with your motor setup in mach 3... the responses given to the above questions put it practically beyond all doubt. There may also be a prob with OS.. depending on which\number of processes running in the OS.

    Firstly Win XP requires optimisation to run Mach software at it's best. there's a document called optimisation.txt available from arcsoft. It explains the processes which are to be disabled.
    You haven't run the mach 3 machine test anyway.. to determine if the software will be stable and able to output a constant pulse.. run the ocxtest.exe in the mach dir.. this usually runs on install unless you cancel it.

    Mach pulse rate has nothing to do with your problem.. unless the OS is making it misbehave on it's way to the printer port. I imagine its at the default anyway as you would need to change it to get it otherwise. You need to run axis calculations or your positioning is not accurate.. simple as that... is not a hard calculation and is an example for direct drive connections in the mach manual... you only have to be 1 or 2 step per rev out in your calculations for the positioning to go adrift.

    Your main problem stalling\lockup is related to the fact that you haven't run motor tuning... so it looks like the y axis is hitting a speed where it will bind when the other axes are also running.. you have to adjust and save the motor speed\acceleration to a point where when Mach runs it "flat out" you still get smooth motion... from your description I'd suggest adjusting the accelaration setting on the Y axis... stall on direction change is most likely to be acceleration more than speed. this is what motor tuning in mach software is for. to set the performance range for each axis... such that no axis will lock up either on it's own or when in combined motion. The Mach manual is clear enough on this too... This combined with questionable steps per unit setting would give problem cutting arcs and circles.

    RTFM bro... that's what it's there for.....

  8. #18
    Here's the progress



    Careful study has revealed this is a backlash setting problem of some sort. When I uncheck 'enable backlash comp.' then the trouble is completely gone. Full speed any which way I like.
    Mechanics, electronics, hardware, power supply, printer port, motors,accel, steps, duration, everything is proved good by this although I am still in the soft stuff as I need backlash comp.

    The backlash speed % was 15% of full, I put it there after a quick run on the day I commissioned mach3. playing with this has shown 6%-8% makes things a lot better than they were. Though the x y motors are still doing something funny when pushed.

    A bit of sniffing about, there are words like 'CV mode', 'shuttle acceleration' appearing. This is where I will look next.

    Thanks for all the pointers
    BFN

  9. #19
    Quote Originally Posted by Davidh
    Here's the progress



    Careful study has revealed this is a backlash setting problem of some sort. When I uncheck 'enable backlash comp.' then the trouble is completely gone. Full speed any which way I like.
    Mechanics, electronics, hardware, power supply, printer port, motors,accel, steps, duration, everything is proved good by this although I am still in the soft stuff as I need backlash comp.

    The backlash speed % was 15% of full, I put it there after a quick run on the day I commissioned mach3. playing with this has shown 6%-8% makes things a lot better than they were. Though the x y motors are still doing something funny when pushed.

    A bit of sniffing about, there are words like 'CV mode', 'shuttle acceleration' appearing. This is where I will look next.

    Thanks for all the pointers
    BFN

    Hi there,

    glad to hear that you've located the lockup problem.. but I must admit to becoming a little concerned in terms of whats going on with your machine.

    you say that backlash compensation was the problem.. another new revelation... but I can't understand how you can compensate for backlash if you didn't run the axis calculations beforehand... you may not have a backlash problem to compensate for in the 1st place. If you spotted positioning errors and put them down to backlash they may have actually come from an incorrect steps per rev setting... which you "reverse engineered" using a ruler.

    running at speed without lockup can't be taken as "everything is proved good" i'm afraid. What you need to first establish beyond all doubt is positioning accuracy... based on what you say in the posts to date you don't have this at the moment. You mention CV mode and shuttle acceleration as being your next areas of investigation in resolving problems... I think you may be getting into a bit of a goose chase here.. at this point you don't have any factual basis on which to address any of the issues. "Looks OK" or "good enough" won't really do it, you need some facts.. hard data... measuable errors... to which you can then apply measurable solutions...

    I would seriously suggest going back to 1st principles and setting the machine up frtom scratch on the basis of the parts spec and the results of the mach setup calculations. Having accomplished this I would then run the dial-gauge test described in the mach manual to establish actual positioning accuracy/errors. Forget about speed for the time being. First get accurate, then get fast. You can run as fast as you like but if positioning is not there machine is effectively unusable for anything serious.

    Once you've established the degree of error/backlash you can then apply the correct amount of compensation and be secure in the knowledge that the setting is correct. However, I would say this is a worst case solution. Backlash compensation can deal with some problems to a degree when motion is in particular direction.. usually parallel to the compensated axis... but it is of zero benefit once the motion departs from this plane... like it will on a real cut. You would be much better off if you are able to deal with any backlash by mechanical means. This would function in all directions of motion and you would have a better machine.

    Having been through the learning curve of building and running a CNC machine I can say that you will soon have enough to deal with in terms of getting the GCode and setups right without having to chase problems in cuts down to the machine mechanics. This is the last thing you want. Might seem a pain but the fact is you would save yourself so much grief and aggravation by getting your positioning sorted... then address speed... then you can cut accurately.. and fast.. which is the whole point....

    hope this helps

  10. #20
    Yohudi,
    reverse engineering is an accepted method of setting up the steps count. See page 55 of 157 (5.5.2.3) in the Mach3 pdf doc

    http://www.artsoftcontrols.com/document ... _84-A2.pdf

    My method is very precise, using 'CenterCam', a webcam mounted in the spindle and a 300mm rule. I can easily resolve 0.1mm
    Backlash (of my leadscrews) is easily detected and measured too, as is @go to zero'

    I'd recomend setting one up, if you dont already have one. Dead simple, pecise, cheap as chips and another toy to play with. :lol:

    BFN

Page 2 of 3 FirstFirst 123 LastLast

Similar Threads

  1. Power Supply Suggestions please..
    By Ricardoco in forum General Electronics
    Replies: 37
    Last Post: 30-01-2013, 06:37 PM
  2. PCPPS V3 Power Supply?
    By birchy in forum General Electronics
    Replies: 4
    Last Post: 10-12-2012, 04:21 PM
  3. Replies: 0
    Last Post: 25-01-2012, 09:29 PM
  4. FOR SALE: 50V 20A Power supply
    By Jimmybristol in forum Items For Sale
    Replies: 8
    Last Post: 30-05-2011, 11:01 PM
  5. power supply
    By hitmythumb in forum General Electronics
    Replies: 6
    Last Post: 21-06-2009, 10:27 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •