Loading ...
Sorry, an error occurred while loading the content.

RE: [taigtools] Taig losing steps

Expand Messages
  • Boman33
    Ed: Step pulse setting is 2us and direction is 0us. Wam: Yes, I have run the driver test program and it looks good. Remember that I have the same problem
    Message 1 of 24 , Feb 13, 2013
    View Source
    • 0 Attachment
      Ed: Step pulse setting is 2us and direction is 0us.

      Wam:
      Yes, I have run the driver test program and it looks good. Remember that I
      have the same problem using two different computers and two different driver
      systems.

      Running another program to clean up the details in the 3-D machined object
      and cutting in air, it reliably kept failing at the same line so I was very
      happy about that. Eventually I could make it fail executing a line from the
      MDI. Basically a G0 move of X30mm or back X0mm works fine but a move of G0
      X30mm Y0.02mm failed every time!!!!!

      It turned out that I had both CV and backlash enabled. I really do not
      understand why that would make the X move fail. Turning off backlash it ran
      OK for 40 minutes all the way through the program.

      All is not well though. Rapid is set at 800mm/min and my federate is
      200mm/min and acceleration is set to 75.

      As a test with the backlash off, I cranked up the feed rate override to 300%
      so my feeds were 600mm/min and cutting air it failed after a minute or so.

      I changed the override to 200 % and started over and it took about 5 minutes
      until it failed again.

      These higher feed rate failures happens so quickly that I do not expect some
      background task interfering.

      It looks like part of the previous problem was the backlash and it never
      showed up on big moves, just a very small move together with a big move.
      Most cuts never met that criteria so it seldom triggered.

      Now I got to keep looking for why it only runs slowly.

      What air cutting federate, rapid and acceleration should I be able to get on
      a standard Taig MicroMill?
      Bertho
    • ED MAISEY
      Bertho,      I don t know anything about anything, but I do seem to remember having a similar problem, I believe Art Fennerty  (this goes back many years)
      Message 2 of 24 , Feb 13, 2013
      View Source
      • 0 Attachment
        Bertho,

             I don't know anything about anything, but I do seem to remember having a similar problem, I believe Art Fennerty  (this goes back many years) gave me instruction to change the number and it did solve my particular problem, I think I was losing steps, its all hazy now, perhaps some member of Mach3 could enlighten you more,
         
        ........Edmund.........


        ________________________________
        From: Boman33 <boman33@...>
        To: taigtools@yahoogroups.com
        Sent: Wednesday, February 13, 2013 2:06 PM
        Subject: RE: [taigtools] Taig losing steps


         
        Ed: Step pulse setting is 2us and direction is 0us.

        Wam:
        Yes, I have run the driver test program and it looks good. Remember that I
        have the same problem using two different computers and two different driver
        systems.

        Running another program to clean up the details in the 3-D machined object
        and cutting in air, it reliably kept failing at the same line so I was very
        happy about that. Eventually I could make it fail executing a line from the
        MDI. Basically a G0 move of X30mm or back X0mm works fine but a move of G0
        X30mm Y0.02mm failed every time!!!!!

        It turned out that I had both CV and backlash enabled. I really do not
        understand why that would make the X move fail. Turning off backlash it ran
        OK for 40 minutes all the way through the program.

        All is not well though. Rapid is set at 800mm/min and my federate is
        200mm/min and acceleration is set to 75.

        As a test with the backlash off, I cranked up the feed rate override to 300%
        so my feeds were 600mm/min and cutting air it failed after a minute or so.

        I changed the override to 200 % and started over and it took about 5 minutes
        until it failed again.

        These higher feed rate failures happens so quickly that I do not expect some
        background task interfering.

        It looks like part of the previous problem was the backlash and it never
        showed up on big moves, just a very small move together with a big move.
        Most cuts never met that criteria so it seldom triggered.

        Now I got to keep looking for why it only runs slowly.

        What air cutting federate, rapid and acceleration should I be able to get on
        a standard Taig MicroMill?
        Bertho




        [Non-text portions of this message have been removed]
      • Don
        Get out a volt meter and check the high level on your PC s parallel port. I fought lost and extra steps for a long time. I thought sure it was from brush
        Message 3 of 24 , Feb 13, 2013
        View Source
        • 0 Attachment
          Get out a volt meter and check the high level on your PC's parallel port. I fought lost and extra steps for a long time. I thought sure it was from brush noise from my DC spindle motor, and before that I was sure it was static on the belt as it only seemed to happen when the 1/8hp motor was driving the spindle on the highest pulley set. Someone finally mentioned that the drivers, in my case Parker compumotor OEM650s, may not be stable with a parallel port that is pumping out 3.5V vs the older ones that pump 5V. That was my problem. The Parker OEM650s require a "minimum of 3.85V. The PC was driving the signals at 3.6V signal to noise was awfull. It wasn't that I had escessive noise, but low signal. It's easy to check, and it may have absolutly nothing to do with your problem, but check it just in case.

          Don
          --- In taigtools@yahoogroups.com, "Boman33" wrote:
          >
          > Amazingly, I am still having problems after all the troubleshooting. I am
          > also cross-posting to the Mach3- forum.
          >
          >
          >
          > This sounds a lot like Max Cato's problems but in my case (and maybe also
          > Max case) it is not binding up.
          >
          >
          >
          > First, the setup:
          >
          > Win-XP, Taig 3000 MicroMill. Mach3 3.042.002
          >
          > I am attempting to mill half of an egg shaped and sized object in 3D.
          >
          > I am milling in air for testing.
          >
          > Motor tuning X-Y-Z: 45 kHz IRQ, 315 steps, Speed: 800mm/min, Acc.: 75
          >
          > G1 Z feed= F100
          >
          > G1 X & Y = F200
          >
          > It is basically a standard MicroMill with its driver package.
          >
          >
          >
          > Symptoms review:
          >
          > More or less randomly it fails to make a move, sometimes after 5 minutes,
          > sometimes an hour. Speeding it up using federate override makes it worse
          > (fails more often).
          >
          > I did not use to have this problem but I have not used the mill for a while
          > so it is difficult to define when it started. The errors happen in both X &
          > Y. I do not know about Z since it moves much less that X & Y.
          >
          >
          >
          > There are no unusual interference or transients noted and the system runs on
          > an UPS.
          >
          >
          >
          > Testing Done:
          >
          > I have mechanically checked the X-Y-Z axis that they run smoothly with
          > minimal friction.
          >
          > All couplings are tight, nothing lose.
          >
          > I have checked and wiggled the electrical connections without any problems
          > or glitches.
          >
          >
          >
          > To isolate any Taig driver problems with the monitoring loop I completely
          > rewired the mill using Gecko G540 connected directly to the PC. No help.
          >
          >
          >
          > I have stripped the PC of all possible software I could find and
          > disconnected external connections. No help.
          >
          >
          >
          > I changed the PC to another brand but still Win-XP. No help.
          >
          >
          >
          > Some possible failure modes:
          >
          > 1. The PC outputs proper pulses for a move,
          >
          > a. The driver electronics is intermittent or weak
          >
          > b. The driver electronics properly drive the motors but the move fails
          > because too much force is required (friction or acceleration).
          >
          > c. The move fails because of lose shaft coupling. The encoders are
          > mounted directly on the motor shafts so the error is that the motor did not
          > move, never mind the table.
          >
          >
          >
          > 2. The PC forgets to output pulses. That would not trigger a Taig
          > tracking error since the encoder would match the motor count pulses.
          >
          >
          >
          > 3. The PC outputs pulses but with wrong timing. This is a difficult
          > area where I see two possibilities:
          >
          > a. Something interrupts the PC while the steppers are steadily moving
          > but all of a sudden the pulses temporarily stops and then start up again.
          > The count might be correct but since there was no deceleration or
          > acceleration there would be position errors.
          >
          > b. Something interrupts the PC while the steppers are not moving but
          > since the PC was interrupted and when it recovers it temporarily speeds up
          > the pulses to catch up. That would also cause problems since it would
          > exceed the normal step rate.
          >
          >
          >
          > 4. There is some type of resonance in the stepper system. I do not
          > think so since nothing has changed from previously and the problem also
          > occurs with the high performance Geckos drives.
          >
          > Any bright ideas to what is wrong?
          >
          > Any clever ideas to verify the PC pulses? It would be very difficult using
          > a storage oscilloscope and try to figure out if the pulses are correct.
          >
          > TIA
          >
          > Bertho
          >
          >
          >
          >
          >
          >
          >
          >
          >
          > [Non-text portions of this message have been removed]
          >
        • WAM
          I had to increase mine to 5-10us if I recall... I ve had issues with FRO over 100% with rapids exceeding my system... I run 60 IPM rapids with PACSCI Nema 23 s
          Message 4 of 24 , Feb 13, 2013
          View Source
          • 0 Attachment
            I had to increase mine to 5-10us if I recall...
            I've had issues with FRO over 100% with rapids exceeding my system... I
            run 60 IPM rapids with PACSCI Nema 23's 280 ozin...

            The microproto site states the Taig CNC does 30ipm rapids...

            Does the microproto come with some sort of breakout/opto isolator board?

            And this was a system that was working ok previously? really strange...


            ED MAISEY wrote:

            >Bertho,
            >
            > I don't know anything about anything, but I do seem to remember having a similar problem, I believe Art Fennerty (this goes back many years) gave me instruction to change the number and it did solve my particular problem, I think I was losing steps, its all hazy now, perhaps some member of Mach3 could enlighten you more,
            >
            >........Edmund.........
            >
            >
            >________________________________
            > From: Boman33 <boman33@...>
            >To: taigtools@yahoogroups.com
            >Sent: Wednesday, February 13, 2013 2:06 PM
            >Subject: RE: [taigtools] Taig losing steps
            >
            >
            >
            >Ed: Step pulse setting is 2us and direction is 0us.
            >
            >Wam:
            >Yes, I have run the driver test program and it looks good. Remember that I
            >have the same problem using two different computers and two different driver
            >systems.
            >
            >Running another program to clean up the details in the 3-D machined object
            >and cutting in air, it reliably kept failing at the same line so I was very
            >happy about that. Eventually I could make it fail executing a line from the
            >MDI. Basically a G0 move of X30mm or back X0mm works fine but a move of G0
            >X30mm Y0.02mm failed every time!!!!!
            >
            >It turned out that I had both CV and backlash enabled. I really do not
            >understand why that would make the X move fail. Turning off backlash it ran
            >OK for 40 minutes all the way through the program.
            >
            >All is not well though. Rapid is set at 800mm/min and my federate is
            >200mm/min and acceleration is set to 75.
            >
            >As a test with the backlash off, I cranked up the feed rate override to 300%
            >so my feeds were 600mm/min and cutting air it failed after a minute or so.
            >
            >I changed the override to 200 % and started over and it took about 5 minutes
            >until it failed again.
            >
            >These higher feed rate failures happens so quickly that I do not expect some
            >background task interfering.
            >
            >It looks like part of the previous problem was the backlash and it never
            >showed up on big moves, just a very small move together with a big move.
            >Most cuts never met that criteria so it seldom triggered.
            >
            >Now I got to keep looking for why it only runs slowly.
            >
            >What air cutting federate, rapid and acceleration should I be able to get on
            >a standard Taig MicroMill?
            >Bertho
            >
            >
            >
            >
            >[Non-text portions of this message have been removed]
            >
            >
            >
            >
          • WAM
            Yea... that s why Mariss at Gecko told me that if I was going to be stubborn and not buy a commercial breakout box that I d better use those 5V 74ACT parts. I
            Message 5 of 24 , Feb 13, 2013
            View Source
            • 0 Attachment
              Yea... that's why Mariss at Gecko told me that if I was going to be
              stubborn and not buy a commercial breakout box that I'd better use those
              5V 74ACT parts. I did and it's worked well so far. I'm thinking of
              spinning my own opto coupled breakout with the EL7202 parts (just used
              them in a project and they worked really well as 5 and 14 volt buffers...)

              Do you have an o'scope? be interesting to see what the PC's you're using
              are putting out. Where do you live? Fi you're anywhere near DC I'd love
              to see what the heck is going on...




              Don wrote:

              >Get out a volt meter and check the high level on your PC's parallel port. I fought lost and extra steps for a long time. I thought sure it was from brush noise from my DC spindle motor, and before that I was sure it was static on the belt as it only seemed to happen when the 1/8hp motor was driving the spindle on the highest pulley set. Someone finally mentioned that the drivers, in my case Parker compumotor OEM650s, may not be stable with a parallel port that is pumping out 3.5V vs the older ones that pump 5V. That was my problem. The Parker OEM650s require a "minimum of 3.85V. The PC was driving the signals at 3.6V signal to noise was awfull. It wasn't that I had escessive noise, but low signal. It's easy to check, and it may have absolutly nothing to do with your problem, but check it just in case.
              >
              >Don
              >--- In taigtools@yahoogroups.com, "Boman33" wrote:
              >
              >
              >>Amazingly, I am still having problems after all the troubleshooting. I am
              >>also cross-posting to the Mach3- forum.
              >>
              >>
              >>
              >>This sounds a lot like Max Cato's problems but in my case (and maybe also
              >>Max case) it is not binding up.
              >>
              >>
              >>
              >>First, the setup:
              >>
              >>Win-XP, Taig 3000 MicroMill. Mach3 3.042.002
              >>
              >>I am attempting to mill half of an egg shaped and sized object in 3D.
              >>
              >>I am milling in air for testing.
              >>
              >>Motor tuning X-Y-Z: 45 kHz IRQ, 315 steps, Speed: 800mm/min, Acc.: 75
              >>
              >>G1 Z feed= F100
              >>
              >>G1 X & Y = F200
              >>
              >>It is basically a standard MicroMill with its driver package.
              >>
              >>
              >>
              >>Symptoms review:
              >>
              >>More or less randomly it fails to make a move, sometimes after 5 minutes,
              >>sometimes an hour. Speeding it up using federate override makes it worse
              >>(fails more often).
              >>
              >>I did not use to have this problem but I have not used the mill for a while
              >>so it is difficult to define when it started. The errors happen in both X &
              >>Y. I do not know about Z since it moves much less that X & Y.
              >>
              >>
              >>
              >>There are no unusual interference or transients noted and the system runs on
              >>an UPS.
              >>
              >>
              >>
              >>Testing Done:
              >>
              >>I have mechanically checked the X-Y-Z axis that they run smoothly with
              >>minimal friction.
              >>
              >>All couplings are tight, nothing lose.
              >>
              >>I have checked and wiggled the electrical connections without any problems
              >>or glitches.
              >>
              >>
              >>
              >>To isolate any Taig driver problems with the monitoring loop I completely
              >>rewired the mill using Gecko G540 connected directly to the PC. No help.
              >>
              >>
              >>
              >>I have stripped the PC of all possible software I could find and
              >>disconnected external connections. No help.
              >>
              >>
              >>
              >>I changed the PC to another brand but still Win-XP. No help.
              >>
              >>
              >>
              >>Some possible failure modes:
              >>
              >>1. The PC outputs proper pulses for a move,
              >>
              >>a. The driver electronics is intermittent or weak
              >>
              >>b. The driver electronics properly drive the motors but the move fails
              >>because too much force is required (friction or acceleration).
              >>
              >>c. The move fails because of lose shaft coupling. The encoders are
              >>mounted directly on the motor shafts so the error is that the motor did not
              >>move, never mind the table.
              >>
              >>
              >>
              >>2. The PC forgets to output pulses. That would not trigger a Taig
              >>tracking error since the encoder would match the motor count pulses.
              >>
              >>
              >>
              >>3. The PC outputs pulses but with wrong timing. This is a difficult
              >>area where I see two possibilities:
              >>
              >>a. Something interrupts the PC while the steppers are steadily moving
              >>but all of a sudden the pulses temporarily stops and then start up again.
              >>The count might be correct but since there was no deceleration or
              >>acceleration there would be position errors.
              >>
              >>b. Something interrupts the PC while the steppers are not moving but
              >>since the PC was interrupted and when it recovers it temporarily speeds up
              >>the pulses to catch up. That would also cause problems since it would
              >>exceed the normal step rate.
              >>
              >>
              >>
              >>4. There is some type of resonance in the stepper system. I do not
              >>think so since nothing has changed from previously and the problem also
              >>occurs with the high performance Geckos drives.
              >>
              >>Any bright ideas to what is wrong?
              >>
              >>Any clever ideas to verify the PC pulses? It would be very difficult using
              >>a storage oscilloscope and try to figure out if the pulses are correct.
              >>
              >>TIA
              >>
              >>Bertho
              >>
              >>
              >>
              >>
              >>
              >>
              >>
              >>
              >>
              >>[Non-text portions of this message have been removed]
              >>
              >>
              >>
              >
              >
              >
              >
              >
            • WAM
              Is this the system you have: http://www.microproto.com/MMDSLS.htm That says it should do 100ipm rapids...
              Message 6 of 24 , Feb 13, 2013
              View Source
              • 0 Attachment
                Is this the system you have:
                http://www.microproto.com/MMDSLS.htm

                That says it should do 100ipm rapids...

                Don wrote:

                >Get out a volt meter and check the high level on your PC's parallel port. I fought lost and extra steps for a long time. I thought sure it was from brush noise from my DC spindle motor, and before that I was sure it was static on the belt as it only seemed to happen when the 1/8hp motor was driving the spindle on the highest pulley set. Someone finally mentioned that the drivers, in my case Parker compumotor OEM650s, may not be stable with a parallel port that is pumping out 3.5V vs the older ones that pump 5V. That was my problem. The Parker OEM650s require a "minimum of 3.85V. The PC was driving the signals at 3.6V signal to noise was awfull. It wasn't that I had escessive noise, but low signal. It's easy to check, and it may have absolutly nothing to do with your problem, but check it just in case.
                >
                >Don
                >--- In taigtools@yahoogroups.com, "Boman33" wrote:
                >
                >
                >>Amazingly, I am still having problems after all the troubleshooting. I am
                >>also cross-posting to the Mach3- forum.
                >>
                >>
                >>
                >>This sounds a lot like Max Cato's problems but in my case (and maybe also
                >>Max case) it is not binding up.
                >>
                >>
                >>
                >>First, the setup:
                >>
                >>Win-XP, Taig 3000 MicroMill. Mach3 3.042.002
                >>
                >>I am attempting to mill half of an egg shaped and sized object in 3D.
                >>
                >>I am milling in air for testing.
                >>
                >>Motor tuning X-Y-Z: 45 kHz IRQ, 315 steps, Speed: 800mm/min, Acc.: 75
                >>
                >>G1 Z feed= F100
                >>
                >>G1 X & Y = F200
                >>
                >>It is basically a standard MicroMill with its driver package.
                >>
                >>
                >>
                >>Symptoms review:
                >>
                >>More or less randomly it fails to make a move, sometimes after 5 minutes,
                >>sometimes an hour. Speeding it up using federate override makes it worse
                >>(fails more often).
                >>
                >>I did not use to have this problem but I have not used the mill for a while
                >>so it is difficult to define when it started. The errors happen in both X &
                >>Y. I do not know about Z since it moves much less that X & Y.
                >>
                >>
                >>
                >>There are no unusual interference or transients noted and the system runs on
                >>an UPS.
                >>
                >>
                >>
                >>Testing Done:
                >>
                >>I have mechanically checked the X-Y-Z axis that they run smoothly with
                >>minimal friction.
                >>
                >>All couplings are tight, nothing lose.
                >>
                >>I have checked and wiggled the electrical connections without any problems
                >>or glitches.
                >>
                >>
                >>
                >>To isolate any Taig driver problems with the monitoring loop I completely
                >>rewired the mill using Gecko G540 connected directly to the PC. No help.
                >>
                >>
                >>
                >>I have stripped the PC of all possible software I could find and
                >>disconnected external connections. No help.
                >>
                >>
                >>
                >>I changed the PC to another brand but still Win-XP. No help.
                >>
                >>
                >>
                >>Some possible failure modes:
                >>
                >>1. The PC outputs proper pulses for a move,
                >>
                >>a. The driver electronics is intermittent or weak
                >>
                >>b. The driver electronics properly drive the motors but the move fails
                >>because too much force is required (friction or acceleration).
                >>
                >>c. The move fails because of lose shaft coupling. The encoders are
                >>mounted directly on the motor shafts so the error is that the motor did not
                >>move, never mind the table.
                >>
                >>
                >>
                >>2. The PC forgets to output pulses. That would not trigger a Taig
                >>tracking error since the encoder would match the motor count pulses.
                >>
                >>
                >>
                >>3. The PC outputs pulses but with wrong timing. This is a difficult
                >>area where I see two possibilities:
                >>
                >>a. Something interrupts the PC while the steppers are steadily moving
                >>but all of a sudden the pulses temporarily stops and then start up again.
                >>The count might be correct but since there was no deceleration or
                >>acceleration there would be position errors.
                >>
                >>b. Something interrupts the PC while the steppers are not moving but
                >>since the PC was interrupted and when it recovers it temporarily speeds up
                >>the pulses to catch up. That would also cause problems since it would
                >>exceed the normal step rate.
                >>
                >>
                >>
                >>4. There is some type of resonance in the stepper system. I do not
                >>think so since nothing has changed from previously and the problem also
                >>occurs with the high performance Geckos drives.
                >>
                >>Any bright ideas to what is wrong?
                >>
                >>Any clever ideas to verify the PC pulses? It would be very difficult using
                >>a storage oscilloscope and try to figure out if the pulses are correct.
                >>
                >>TIA
                >>
                >>Bertho
                >>
                >>
                >>
                >>
                >>
                >>
                >>
                >>
                >>
                >>[Non-text portions of this message have been removed]
                >>
                >>
                >>
                >
                >
                >
                >
                >
              • Boman33
                Thanks WAM, Yes, that is the model I got. I forgot to check the specs for it so it is good you pointed them out. I am in Florida and I have the test equipment
                Message 7 of 24 , Feb 13, 2013
                View Source
                • 0 Attachment
                  Thanks WAM,

                  Yes, that is the model I got. I forgot to check the specs for it so it is
                  good you pointed them out.



                  I am in Florida and I have the test equipment but I have not convinced
                  myself it is an interface problem so I have not dragged it out yet and I was
                  correct. See the next post.

                  Bertho



                  From: WAM Sent: Wednesday, February 13, 2013 21:28



                  Is this the system you have:
                  http://www.microproto.com/MMDSLS.htm

                  That says it should do 100ipm rapids...



                  [Non-text portions of this message have been removed]
                • Boman33
                  Finally it is working! Henrik pointed out that my 45 kHz IRQ was unnecessarily fast and suggested that only 25 kHz is needed. When I went to change it, I
                  Message 8 of 24 , Feb 13, 2013
                  View Source
                  • 0 Attachment
                    Finally it is working!

                    Henrik pointed out that my 45 kHz IRQ was unnecessarily fast and suggested
                    that only 25 kHz is needed. When I went to change it, I realized that I had
                    by mistake selected 65kHz. Setting it back to 25kHz and at the same time I
                    changed to step pulse from 2 to 3us and the direction from 0 to 3us. I now
                    can cut air at at least 600mm/min (23inches). I have not tried faster but
                    that is 3 times better than before.

                    So it looks like the Backlash + CV mode and the too fast IRQ has been
                    causing all the problems.



                    Thanks to all of you sending suggestion,

                    Bertho



                    [Non-text portions of this message have been removed]
                  • Don
                    No, mine was a roll your own setup. Parker Compumotor OEM650 drivers, Pacific Scientific 253InOz double stack nema 23 motors, and a 66 volt 8 amp power
                    Message 9 of 24 , Feb 13, 2013
                    View Source
                    • 0 Attachment
                      No, mine was a roll your own setup. Parker Compumotor OEM650 drivers, Pacific Scientific 253InOz double stack nema 23 motors, and a 66 volt 8 amp power supply, 15amp surge.

                      For what it's worth, I am unable to get beyond 45 ipm at 10x micro steps due to a mid range resonance issue with my setup. I limit the motors to 30ipm just to be on the safe side. Sure would like a faster rapid, but what I have works for now. Not worth a couple grand for some OEM 750's or a complete new motor/driver set.

                      I do have a scope, but the parallel port voltage is easy to measure with a digital Volt meter. Noise is another issue, but you can't eliminate all of it, so a good 5V step and direction to the divers overpowers the noise. When the parallel port is only pumping out 3.5V, and that is very close to the driver specs for input, an little bit of noise becomes a major problem.

                      This is one case of older is better. The old PC's all had 5V logic output, but most all of the winXP and later versions showed a drop to 3.5V

                      Either get an nice old PC that is about 10 years old, or get one of the smooth steppers or a breakout board that will provide the 5V output with a 3.5 input. That is if you have this problem. IE low signal level for your drivers.

                      Don


                      --- In taigtools@yahoogroups.com, WAM wrote:
                      >
                      > Is this the system you have:
                      > http://www.microproto.com/MMDSLS.htm
                      >
                      > That says it should do 100ipm rapids...
                      >
                      > Don wrote:
                      >
                      > >Get out a volt meter and check the high level on your PC's parallel port. I fought lost and extra steps for a long time. I thought sure it was from brush noise from my DC spindle motor, and before that I was sure it was static on the belt as it only seemed to happen when the 1/8hp motor was driving the spindle on the highest pulley set. Someone finally mentioned that the drivers, in my case Parker compumotor OEM650s, may not be stable with a parallel port that is pumping out 3.5V vs the older ones that pump 5V. That was my problem. The Parker OEM650s require a "minimum of 3.85V. The PC was driving the signals at 3.6V signal to noise was awfull. It wasn't that I had escessive noise, but low signal. It's easy to check, and it may have absolutly nothing to do with your problem, but check it just in case.
                      > >
                      > >Don
                      > >--- In taigtools@yahoogroups.com, "Boman33" wrote:
                      > >
                      > >
                      > >>Amazingly, I am still having problems after all the troubleshooting. I am
                      > >>also cross-posting to the Mach3- forum.
                      > >>
                      > >>
                      > >>
                      > >>This sounds a lot like Max Cato's problems but in my case (and maybe also
                      > >>Max case) it is not binding up.
                      > >>
                      > >>
                      > >>
                      > >>First, the setup:
                      > >>
                      > >>Win-XP, Taig 3000 MicroMill. Mach3 3.042.002
                      > >>
                      > >>I am attempting to mill half of an egg shaped and sized object in 3D.
                      > >>
                      > >>I am milling in air for testing.
                      > >>
                      > >>Motor tuning X-Y-Z: 45 kHz IRQ, 315 steps, Speed: 800mm/min, Acc.: 75
                      > >>
                      > >>G1 Z feed= F100
                      > >>
                      > >>G1 X & Y = F200
                      > >>
                      > >>It is basically a standard MicroMill with its driver package.
                      > >>
                      > >>
                      > >>
                      > >>Symptoms review:
                      > >>
                      > >>More or less randomly it fails to make a move, sometimes after 5 minutes,
                      > >>sometimes an hour. Speeding it up using federate override makes it worse
                      > >>(fails more often).
                      > >>
                      > >>I did not use to have this problem but I have not used the mill for a while
                      > >>so it is difficult to define when it started. The errors happen in both X &
                      > >>Y. I do not know about Z since it moves much less that X & Y.
                      > >>
                      > >>
                      > >>
                      > >>There are no unusual interference or transients noted and the system runs on
                      > >>an UPS.
                      > >>
                      > >>
                      > >>
                      > >>Testing Done:
                      > >>
                      > >>I have mechanically checked the X-Y-Z axis that they run smoothly with
                      > >>minimal friction.
                      > >>
                      > >>All couplings are tight, nothing lose.
                      > >>
                      > >>I have checked and wiggled the electrical connections without any problems
                      > >>or glitches.
                      > >>
                      > >>
                      > >>
                      > >>To isolate any Taig driver problems with the monitoring loop I completely
                      > >>rewired the mill using Gecko G540 connected directly to the PC. No help.
                      > >>
                      > >>
                      > >>
                      > >>I have stripped the PC of all possible software I could find and
                      > >>disconnected external connections. No help.
                      > >>
                      > >>
                      > >>
                      > >>I changed the PC to another brand but still Win-XP. No help.
                      > >>
                      > >>
                      > >>
                      > >>Some possible failure modes:
                      > >>
                      > >>1. The PC outputs proper pulses for a move,
                      > >>
                      > >>a. The driver electronics is intermittent or weak
                      > >>
                      > >>b. The driver electronics properly drive the motors but the move fails
                      > >>because too much force is required (friction or acceleration).
                      > >>
                      > >>c. The move fails because of lose shaft coupling. The encoders are
                      > >>mounted directly on the motor shafts so the error is that the motor did not
                      > >>move, never mind the table.
                      > >>
                      > >>
                      > >>
                      > >>2. The PC forgets to output pulses. That would not trigger a Taig
                      > >>tracking error since the encoder would match the motor count pulses.
                      > >>
                      > >>
                      > >>
                      > >>3. The PC outputs pulses but with wrong timing. This is a difficult
                      > >>area where I see two possibilities:
                      > >>
                      > >>a. Something interrupts the PC while the steppers are steadily moving
                      > >>but all of a sudden the pulses temporarily stops and then start up again.
                      > >>The count might be correct but since there was no deceleration or
                      > >>acceleration there would be position errors.
                      > >>
                      > >>b. Something interrupts the PC while the steppers are not moving but
                      > >>since the PC was interrupted and when it recovers it temporarily speeds up
                      > >>the pulses to catch up. That would also cause problems since it would
                      > >>exceed the normal step rate.
                      > >>
                      > >>
                      > >>
                      > >>4. There is some type of resonance in the stepper system. I do not
                      > >>think so since nothing has changed from previously and the problem also
                      > >>occurs with the high performance Geckos drives.
                      > >>
                      > >>Any bright ideas to what is wrong?
                      > >>
                      > >>Any clever ideas to verify the PC pulses? It would be very difficult using
                      > >>a storage oscilloscope and try to figure out if the pulses are correct.
                      > >>
                      > >>TIA
                      > >>
                      > >>Bertho
                      > >>
                      > >>
                      > >>
                      > >>
                      > >>
                      > >>
                      > >>
                      > >>
                      > >>
                      > >>[Non-text portions of this message have been removed]
                      > >>
                      > >>
                      > >>
                      > >
                      > >
                      > >
                      > >
                      > >
                      >
                    • Don
                      Boy, the fixes are easy once you know what they are, arn t they? It only took me a couple years of fighting the symptoms vs the problem before I got mine
                      Message 10 of 24 , Feb 13, 2013
                      View Source
                      • 0 Attachment
                        Boy, the fixes are easy once you know what they are, arn't they? It only took me a couple years of fighting the symptoms vs the problem before I got mine stable.

                        Glad you got it under control. This is all a balancing act. Even between the same motors and drivers. One of my axis humms on rapid, one sings, and the other howls. All with the same settings. Almost seems I'm setting up the timing on my folks 53 Chevy by ear again.

                        Don



                        --- In taigtools@yahoogroups.com, "Boman33" wrote:
                        >
                        > Finally it is working!
                        >
                        > Henrik pointed out that my 45 kHz IRQ was unnecessarily fast and suggested
                        > that only 25 kHz is needed. When I went to change it, I realized that I had
                        > by mistake selected 65kHz. Setting it back to 25kHz and at the same time I
                        > changed to step pulse from 2 to 3us and the direction from 0 to 3us. I now
                        > can cut air at at least 600mm/min (23inches). I have not tried faster but
                        > that is 3 times better than before.
                        >
                        > So it looks like the Backlash + CV mode and the too fast IRQ has been
                        > causing all the problems.
                        >
                        >
                        >
                        > Thanks to all of you sending suggestion,
                        >
                        > Bertho
                        >
                        >
                        >
                        > [Non-text portions of this message have been removed]
                        >
                      Your message has been successfully submitted and would be delivered to recipients shortly.