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

Re: [taigtools] Taig losing steps

Expand Messages
  • WAM
    From Gecko s manual http://www.geckodrive.com/gecko/images/cms_files/Step%20Motor%20Basics%20Guide.pdf page 11: An unregulated power supply will be sufficient
    Message 1 of 24 , Feb 12, 2013
    • 0 Attachment
      From Gecko's manual
      http://www.geckodrive.com/gecko/images/cms_files/Step%20Motor%20Basics%20Guide.pdf
      page 11:

      "An unregulated power supply will be sufficient and is recommended for
      most applications
      because of its simplicity. If a motor with a large inertial load
      decelerates quickly it will act as an
      alternator and send voltage back to the drive which then sends it back
      to the power supply. Because
      many regulated power supplies feature protection circuitry this may
      cause the power supply to fault or
      reset; however, if the supply is unregulated it will simply get absorbed
      by the filter capacitor. "



      Some reg power supplies and SMPS (switch mode) would be able to handle
      the inductive kick a bunch of steppers are sending back thru the drives;
      especially if the SMPS or reg supply had fairly sturdy hold up caps...
      some will de reg or go into protection.

      Batteries would probably work well (depending on chemistry) , as long
      as the instantaneous discharge current were not exceeded and had some
      sort of back EMF protection...

      :


      Jeffrey Birt wrote:

      >>>Note Gecko rec's an unregulated, linear supply...
      >>>
      >>>
      >
      >
      >
      >That is not accurate: The stepper drives don't know or care what type of
      >power supply is connected as long as it can supply the required current at
      >the specified voltage. You could use a big bank of batteries and the stepper
      >drives would be just as happy. Gecko has said that some of the (cheap)
      >switch type power supplies may not hold up. Any good quality power supply
      >will do the job though. I have a 25 year old bench top mill with the
      >original 24 switch type power supply.
      >
      >
      >
      >A linear unregulated supply is often the cheapest way to go but not
      >necessarily the only way or best way.
      >
      >
      >
      >Jeff Birt
      >
      >Soigeneris.com
      >
      >
      >
      >From: taigtools@yahoogroups.com [mailto:taigtools@yahoogroups.com] On Behalf
      >Of WAM
      >Sent: Tuesday, February 12, 2013 2:50 PM
      >To: taigtools@yahoogroups.com
      >Subject: Re: [taigtools] Taig losing steps
      >
      >
      >
      >
      >
      >OK... you should be able to go faster than that.
      >
      >Next thing I'd check is the power supply. What type of power supply are
      >you using?
      >
      >Note Gecko rec's an unregulated, linear supply...
      >
      >Another issue I had was with the P Port voltages; the gecko's I use
      >really need a 5V logic signal. Use a scope, since a logic analyser will
      >just show timing, not amplitude. recall you only have to look at the
      >step output (unless you have a quad drive like the Maxnc's stock drive
      >then you need to use something like an XY plot - see below.).
      >
      >Mariss told me that since most PC's us 3.3V for the PPort to use
      >something like an 74ACT or equiv buffers, since they drive +/- 20mA and
      >have a input that will switch at 2V. A real nice part I recently came
      >across are these EL7202 clock drivers that have ungodly drive and low
      >prop delay
      >
      >Also here's a vid of my Gecko's on my test bench:
      >http://ajawam5.home.comcast.net/DSCN1211.avi
      >The scope is in XY mode looking at the output of the drive - this is
      >used to measure the phase between the windings. Nice sharp corners as it
      >steps.. this was slow jogging; as i sped up it, maintained the nice
      >looking waveform, tho i was able to see the issues with reflections
      >being caused by the winding inductance as I got it higher in speed.
      >
      >The spectrum analyser is there since I was looking at any EMI issues I'd
      >have to deal with.
      >
      >Boman33 wrote:
      >
      >
      >
      >>Thank you for providing a detailed answer.
      >>
      >>It is metric. I gave the max speed (Rapid) as 800mm/minute in the
      >>description and a feed of 100mm/min is just 4 inches/min- crawling only.
      >>
      >>With the Gecko G540 I got a limit of 1800mm/min and was initially setting
      >>the Rapids at 1500mm/min= 59"/min but later backed it down to be safe.
      >>
      >>Bertho
      >>
      >>
      >>
      >>From: WAM Sent: Tuesday, February 12, 2013 13:12
      >>
      >>
      >>
      >>That sounds like a motor stall due to commutation issues...
      >>
      >>F100 would be 100 ipm? That's pretty fast. With my Gecko 201's, a 45V
      >>beefy liner supply and 80,000uF cap and anti backlash nuts (BSA XCT
      >>1/4" with low drag coefficient) I can get 60IPM rapids max. Using
      >>PACSCI 204 ozin steppers. I'm using 5usec pulse widths in Mach.
      >>
      >>
      >>
      >>
      >>
      >>>>>The faster you make that stepper go, the less torque you'll have <<<
      >>>>>
      >>>>>
      >>>>>
      >>>>>
      >>---- < snip
      >>
      >>
      >>
      >>[Non-text portions of this message have been removed]
      >>
      >>
      >>
      >>
      >>
      >>
      >
      >
      >
      >
      >
      >[Non-text portions of this message have been removed]
      >
      >
      >
      >
    • WAM
      Strange... the one time I had a weird issue with Mach/PC was as i mentioned earlier - a specific piece of G code that would fail to move the Y, with a noise
      Message 2 of 24 , Feb 12, 2013
      • 0 Attachment
        Strange... the one time I had a weird issue with Mach/PC was as i
        mentioned earlier - a specific piece of G code that would fail to move
        the Y, with a noise similar to what you describe.

        In MACH, besides some weird unknown bug, the only thing I can think of
        is the motor tuning that might cause something like that. Might be a

        Have you run the DriverTest program?

        From
        http://www.machsupport.com/docs/Mach3Mill_Install_Config.pdf

        2.2.1 If You Are Using the Default Parallel Port Driver

        If you are using the Mach3 parallel port driver, it is worthwhile to set
        up an icon for a desktop shortcut
        to another Mach3 program. Use Windows Explorer (right-click Start),
        navigate to the folder in which
        you placed the Mach3 installation, and create a shortcut to
        DriverTest.exe by right-clicking on the
        DriverTest.exe filename. Drag this shortcut onto your desktop.
        DriverTest.exe tests the opera-
        tion of the parallel port driver.
        Double click the DriverTest icon that you just set up, or run the
        program DriverTest.exe from the
        Mach3 installation folder. Running DriverTest.exe will install the
        parallel port driver if it was not
        installed previously. A screen shot of DriverTest is shown in Figure 2-4.


        Interesting thing here too:
        2.4.1 Running DriverTest After a Mach3 Crash
        Should you for any reason have a situation when running Mach3 where it
        crashes - this might be an
        intermittent hardware problem or a software bug – then you must run
        DriverTest.exe as soon as possi-
        ble after Mach3 has failed. If you delay for two minutes then the Mach3
        driver will cause Windows to
        fail with the usual “Blue Screen of Death.” Running DriverTest resets
        the driver to a stable condition
        even if Mach3 disappears unexpectedly.
        You may find, after a crash, that it fails to find the driver the first
        time it is run. In this case merely run
        it again as the first run should fix things up.

        Boman33 wrote:

        >WAM,
        >
        >The normal setup is Taig's original configuration. I checked the internal
        >powersupply and it is normal.
        >
        >
        >
        >The other system is driving with the Geckos and an independent 48V power
        >supply.
        >
        >
        >
        >Same problems with both systems.
        >
        >
        >
        >I suspect it has something to do with my configuration or software that
        >randomly, maybe every half hour, locks up the PC for a fraction of a second.
        >
        >I will check the printer port levels but remember this used to work.
        >
        >Bertho
        >
        >
        >
        >From: WAM Sent: Tuesday, February 12, 2013 15:50
        >
        >
        >
        >OK... you should be able to go faster than that.
        >
        >Next thing I'd check is the power supply. What type of power supply are
        >you using?
        >
        >Note Gecko rec's an unregulated, linear supply...
        >
        >Another issue I had was with the P Port voltages; the gecko's I use
        >really need a 5V logic signal. Use a scope, since a logic analyser will
        >just show timing, not amplitude. recall you only have to look at the
        >step output (unless you have a quad drive like the Maxnc's stock drive
        >then you need to use something like an XY plot - see below.).
        >
        >Mariss told me that since most PC's us 3.3V for the PPort to use
        >something like an 74ACT or equiv buffers, since they drive +/- 20mA and
        >have a input that will switch at 2V. A real nice part I recently came
        >across are these EL7202 clock drivers that have ungodly drive and low
        >prop delay
        >
        >Also here's a vid of my Gecko's on my test bench:
        >http://ajawam5.home.comcast.net/DSCN1211.avi
        >The scope is in XY mode looking at the output of the drive - this is
        >used to measure the phase between the windings. Nice sharp corners as it
        >steps.. this was slow jogging; as i sped up it, maintained the nice
        >looking waveform, tho i was able to see the issues with reflections
        >being caused by the winding inductance as I got it higher in speed.
        >
        >The spectrum analyser is there since I was looking at any EMI issues I'd
        >have to deal with.
        >
        >Boman33 wrote:
        >
        >
        >
        >>Thank you for providing a detailed answer.
        >>
        >>It is metric. I gave the max speed (Rapid) as 800mm/minute in the
        >>description and a feed of 100mm/min is just 4 inches/min- crawling only.
        >>
        >>With the Gecko G540 I got a limit of 1800mm/min and was initially setting
        >>the Rapids at 1500mm/min= 59"/min but later backed it down to be safe.
        >>
        >>Bertho
        >>
        >>
        >>
        >>From: WAM Sent: Tuesday, February 12, 2013 13:12
        >>
        >>
        >>
        >>That sounds like a motor stall due to commutation issues...
        >>
        >>F100 would be 100 ipm? That's pretty fast. With my Gecko 201's, a 45V
        >>beefy liner supply and 80,000uF cap and anti backlash nuts (BSA XCT
        >>1/4" with low drag coefficient) I can get 60IPM rapids max. Using
        >>PACSCI 204 ozin steppers. I'm using 5usec pulse widths in Mach.
        >>
        >>
        >>
        >>
        >>
        >>>>>The faster you make that stepper go, the less torque you'll have <<<
        >>>>>
        >>>>>
        >>>>>
        >>>>>
        >>---- < snip
        >>
        >>
        >
        >
        >
        >
        >
        >[Non-text portions of this message have been removed]
        >
        >
        >
        >
      • ED MAISEY
        If you have Mach3, in config and Motor tuning, there is step pulse 1-5 and dir pulse 1-5 what do you have both set at?, I have both mine set at  3, just a
        Message 3 of 24 , Feb 12, 2013
        • 0 Attachment
          If you have Mach3, in config and Motor tuning, there is step pulse 1-5 and dir pulse 1-5 what do you have both set at?, I have both mine set at  3, just a thought, or for what its worth,
           
          ........Edmund.........


          ________________________________
          From: WAM <ajawam2@...>
          To: taigtools@yahoogroups.com
          Sent: Tuesday, February 12, 2013 5:48 PM
          Subject: Re: [taigtools] Taig losing steps

          Strange... the one time I had a weird issue with Mach/PC was as i
          mentioned earlier - a specific piece of G code that would fail to move
          the Y, with a noise similar to what you describe.

          In MACH, besides some weird unknown bug, the only thing I can think of
          is the motor tuning that might cause something like that. Might be a

          Have you run the DriverTest program?

          From
          http://www.machsupport.com/docs/Mach3Mill_Install_Config.pdf

          2.2.1 If You Are Using the Default Parallel Port Driver

          If you are using the Mach3 parallel port driver, it is worthwhile to set
          up an icon for a desktop shortcut
          to another Mach3 program. Use Windows Explorer (right-click Start),
          navigate to the folder in which
          you placed the Mach3 installation, and create a shortcut to
          DriverTest.exe by right-clicking on the
          DriverTest.exe filename. Drag this shortcut onto your desktop.
          DriverTest.exe tests the opera-
          tion of the parallel port driver.
          Double click the DriverTest icon that you just set up, or run the
          program DriverTest.exe from the
          Mach3 installation folder. Running DriverTest.exe will install the
          parallel port driver if it was not
          installed previously. A screen shot of DriverTest is shown in Figure 2-4.


          Interesting thing here too:
          2.4.1 Running DriverTest After a Mach3 Crash
          Should you for any reason have a situation when running Mach3 where it
          crashes - this might be an
          intermittent hardware problem or a software bug – then you must run
          DriverTest.exe as soon as possi-
          ble after Mach3 has failed. If you delay for two minutes then the Mach3
          driver will cause Windows to
          fail with the usual “Blue Screen of Death.” Running DriverTest resets
          the driver to a stable condition
          even if Mach3 disappears unexpectedly.
          You may find, after a crash, that it fails to find the driver the first
          time it is run. In this case merely run
          it again as the first run should fix things up.

          Boman33 wrote:

          >WAM,
          >
          >The normal setup is Taig's original configuration.  I checked the internal
          >powersupply and it is normal.
          >
          >
          >
          >The other system is driving with the Geckos and an independent 48V power
          >supply.
          >
          >
          >
          >Same problems with both systems. 
          >
          >
          >
          >I suspect it has something to do with my configuration or software that
          >randomly, maybe every half hour, locks up the PC for a fraction of a second.
          >
          >I will check the printer port levels but remember this used to work. 
          >
          >Bertho
          >
          >
          >
          >From: WAM  Sent: Tuesday, February 12, 2013 15:50
          >
          >
          >
          >OK... you should be able to go faster than that.
          >
          >Next thing I'd check is the power supply. What type of power supply are
          >you using?
          >
          >Note Gecko rec's an unregulated, linear supply...
          >
          >Another issue I had was with the P Port voltages; the gecko's I use
          >really need a 5V logic signal. Use a scope, since a logic analyser will
          >just show timing, not amplitude. recall you only have to look at the
          >step output (unless you have a quad drive like the Maxnc's stock drive
          >then you need to use something like an XY plot - see below.).
          >
          >Mariss told me that since most PC's us 3.3V for the PPort to use
          >something like an 74ACT or equiv buffers, since they drive +/- 20mA and
          >have a input that will switch at 2V. A real nice part I recently came
          >across are these EL7202 clock drivers that have ungodly drive and low
          >prop delay
          >
          >Also here's a vid of my Gecko's on my test bench:
          >http://ajawam5.home.comcast.net/DSCN1211.avi
          >The scope is in XY mode looking at the output of the drive - this is
          >used to measure the phase between the windings. Nice sharp corners as it
          >steps.. this was slow jogging; as i sped up it, maintained the nice
          >looking waveform, tho i was able to see the issues with reflections
          >being caused by the winding inductance as I got it higher in speed.
          >
          >The spectrum analyser is there since I was looking at any EMI issues I'd
          >have to deal with.
          >
          >Boman33 wrote:
          >

          >
          >>Thank you for providing a detailed answer.
          >>
          >>It is metric. I gave the max speed (Rapid) as 800mm/minute in the
          >>description and a feed of 100mm/min is just 4 inches/min- crawling only.
          >>
          >>With the Gecko G540 I got a limit of 1800mm/min and was initially setting
          >>the Rapids at 1500mm/min= 59"/min but later backed it down to be safe.
          >>
          >>Bertho
          >>
          >>
          >>
          >>From: WAM Sent: Tuesday, February 12, 2013 13:12
          >>
          >>
          >>
          >>That sounds like a motor stall due to commutation issues...
          >>
          >>F100 would be 100 ipm? That's pretty fast. With my Gecko 201's, a 45V
          >>beefy liner supply and 80,000uF cap and anti backlash nuts (BSA XCT
          >>1/4" with low drag coefficient) I can get 60IPM rapids max. Using
          >>PACSCI 204 ozin steppers. I'm using 5usec pulse widths in Mach.
          >>
          >>
          >>
          >>   
          >>
          >>>>>The faster you make that stepper go, the less torque you'll have <<<
          >>>>>
          >>>>>
          >>>>>         
          >>>>>
          >>---- < snip
          >>   
          >>
          >
          >
          >
          >
          >
          >[Non-text portions of this message have been removed]
          >
          >

          >


          ------------------------------------

          To Post a message, send it to: 
          taigtools@yahoogroups.com

          To Unsubscribe, send a blank message to:
          taigtools-unsubscribe@yahoogroups.com

          Let the chips fly!
          Yahoo! Groups Links



          [Non-text portions of this message have been removed]
        • 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 4 of 24 , Feb 13, 2013
          • 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 5 of 24 , Feb 13, 2013
            • 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 6 of 24 , Feb 13, 2013
              • 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 7 of 24 , Feb 13, 2013
                • 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 8 of 24 , Feb 13, 2013
                  • 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 9 of 24 , Feb 13, 2013
                    • 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 10 of 24 , Feb 13, 2013
                      • 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 11 of 24 , Feb 13, 2013
                        • 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 12 of 24 , Feb 13, 2013
                          • 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 13 of 24 , Feb 13, 2013
                            • 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.