Hello Guest it is August 08, 2020, 11:06:16 PM

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - dpekin

Pages: 1
Great, thanks. 

And yes, I reveiwed the change log from 1.84 and the error I was experiencing w/ backlash was fixed in V 1.90 .

Do you know if the configuration files are compatible from 1.84 to the current version? 

Is there anything I should be aware of upgrading?

I was correct in that the servo error is mapped to the limit switch input so when the DSLS 3000 detects a mismatch, it faults by raising the limit switch flag. 

However, the root of my problem is actually that backlash compensation was enabled in Mach 3.    If I turn BL comp off, the system runs fine.  If I turn BL compensation on, the system fails as described above.

Now the question is:  Is there a difference in BL compensation between V1.84 which I'm running and the latest version?  Also, will the license for V1.84 work for the latest version?


Thank you Hood.  I agree that turning off those limit switches will probably keep the error from occuring.  But, don't think that will solve the real problem...

I believe the DSLS 3000 is wired to the limit switch I/O port to trigger the "Limit" when the encoder feedback is outside of some error band.  So, the system is working correctly from the stand point of triggering the limit switch when the motor/stage doesn't respond as it is programmed to.    Thus, when a stage binds or hits end of travel, the encoder feedback error increases and the "limit" is triggered.

My problem is that on the move described above, the stage doesn't move as programmed (and the encoder error band is exceeded).  I suspect that the pulse train generated by Mach 3 is getting polluted or corrupted in the DSLS 3000 box so when it gets amplified and sent to the stepper motors, it doesn't correctly move the motors.  Does this sound feasible? 

The documents on the DSLS 3000 talk about checking the voltages on a high and low voltage capacitors when this type of thing occurs.  Does anyone have any input here?  I'm going to check the voltages this weekend.   

Any other suggestions or ideas?


- Dave


Thank you for the responses.  I've attached the config file.  I believe the Limit Error is actually a servo error in disguise. 

I had previously routed all control cables away from AC and spindle cables.  These tests were done without the spindle running as well.

Below is an area in the BobCad generated G-code that fails.  Specifically the XY move on line 182 generates the error.  It sounds like the stages are binding but when I jog through that area everything is clear and smooth.  It looks like a slight G-code generation error since line 181 goes to rapid movement (G00) so line 182 would be rapid as well.   In other areas of the code the Z movements (181 & 183) are always sequential, i.e. there is no XY movement between Z motion.  I've tried changing line 182 by adding a F15.0 feed rate and it still fails.  I've reduced the stage speed to 20 ipm and it still fails.  In any event, there are other places in the program where I receive the Limit Error.  This is just very repeatable.

N175 X-.6434 Y-.355 F15.0
N176 X-.6381 Y-.3505
N177 X-.6277 Y-.344
N178 X-.6172 Y-.3399
N179 X-.6023 Y-.3375
N180 X-.0012
N181 G00 Z.1
N182 X-.0086 Y.3375
N183 G01 Z-.1031 F12.2231
N184 X-.5875 F15.0
N185 X-.6089 Y.3381

Finally, the DSLS 3000 docs talk about checking the voltage across the high and low power capacitors.  Could bad caps cause the problem I'm experiencing?

Once again, thanks for the support!

- Dave


I'm currently running version R1.84 on a 1GHz computer w/ 512 MB of RAM.  It runs somewhat but has problems with a  "limit switch triggered" error when I'm running a g-code program.   I don't even have limit switches on the system so I assume this is a problem with stepper pulses counting properly or ???  It is connected to a DSLS 3000 MicroMill system.

I have a few questions: 

Should I try to upgrading to the current rev to see if this help the limit switch problem or is there a solution w/ 1.84?

If I upgrade will my current license be good for the new version? 

Will the machine config XML from R1.84 be OK for the new version?   (I'm sure I woudl have a problem bringing up a system from scratch since I have just purchased this used system).

Any thoughts appreciated.

- Dave


I'm relatively new to this forum and Mach 3.  I have purchased a 2nd hand DSLS 3000 controled Taig 3 axis mill that was supposed to work correctly.  It is running R.1.84 version Mach 3 on a 1 Ghz computer.  This is the only software that runs on the system and the CPU loading is less than 5% when operating.  The driver test program indicates that everything looks good, i.e. there is not great excursion from the  25Khz signal trace.

My problem is that when I run a g-code program, the Reset line goes high and the log trace (lasterrors.txt) indicates that the limit switch has triggered.  To the best of my knowledge, there are no limit switches on my hardware.  I see none on the stages so I'm assuming that the limit switch error is due to some sort of following error with the encoder(?)....  

I have adjusted the stage speed down to 40 ipm and 4 ipm/pm.  

The g-code program that I'm running is using a feed rate of only 15 ipm.   If I change the feed rate down to 10ipm, it fails with the limit switch error after only a few moves.  It runs better at a feed rate of 20 but still fails at certain moves....

Does anyone have any idea of what's going on here?

Thanks in advance,

- Dave

A couple more questoins:

Does Mach 3 maintain an error log that I can review to find out which axis is causing the Reset fault? I am running an older version on a 1 Ghz machine. 

Also, how does the maximum stage speed set in Mach 3 relate to the "F" feedrate commands in the G-code? 

Does backing off the feedrate from 100% to say 50% do exactly the same as halving the "F" rate?  Is there any difference?


Thank you.  I'll see how that compares w/ mine. 

Just for my information, when you set a maximum feed rate in Mach 3 at say 60 in the motor configuration page, that sets the upper limit on what a G-code Feedrate command can be, right?  I noticed that my toolpath ran correctly when I had errantly told BobCad that I was milling soft steel.  The feedrate was set to approximately 4.  When I corrected my error and indicated that I was milling aluminum, the feedrate was set to approximately 20.  The same toolpath that ran correctly slowly caused the fault running at the faster rates.

I'm sorry I wasn't clear.  I was basing the 250ms timing by the acceleration/velocity profile graph that is displayed in Mach 3.  In that graph, the acceleration ramp takes 250ms to reach the velocity of 66 IPM.  I'll try to figure out what acceleration that converts to.

My gut feel is that the acceleration is not the problem since it has no problem jogging or running longer X or Y stage motion.  The failure only occurs running curves or very short back and forth X or Y motion.


I've just recently purchased a 2nd hand Taig 3 axis mill with a MicroMill DSLS 3000 controller.  It has a 1Ghz PC and it's running an older version of Mach3 software circa 2005/2006.

It appears to run well.  I can jog the full stage travel with no problem.  The stages do not bind when I move them by hand.

The problem is that when I run a g-code toolpath, it often will fault and I will have to Reset the system to continue.  It does this on arc  moves or very short back and forth linear motion mostly.   If I slow the feed rate down to say 50% the complete program will run withouth faulting.

I assume the fault is being caused by the motors losing steps or not being able to keep up w/ what the computer is telling it.  Is there a diagnostics log in Mach 3 that I can view to verify this?

The motor settings are max velocity approx 66 ipm and acceleration set to approx 250ms to reach that velocity.  Are there values correct?  Are there any tuning routines that can be run to determine optimal values for this? 

I understand the computer that came with the system is old however Mach 3 is the only thing running on it and the CPU loading when running a toolpath is only about 5-10% so there is no resource problem with the computer.  I know there are new versions of Mach 3.  Those require a newer computer system than what came with the tool.  I'd prefer to get this system running reliably rather than spend significant $$ upgrading hardware.  Is this viable?

I read some posts about a Smooth Stepper USB device.  What is required to convert the system to use this?  What would be the benefit/drawbacks. 

Thanks in advance for any suggestions.

- Dave

Pages: 1