Hello Guest it is July 24, 2019, 03:40:30 AM

Author Topic: losing probe signals with USB game controller?  (Read 14498 times)

0 Members and 1 Guest are viewing this topic.

Re: losing probe signals with USB game controller?
« Reply #10 on: February 03, 2010, 12:24:39 PM »
Well, each time it happened I touched the plate to the bit to see the light come one, and then clicked the mouse to run it.  I suppose it is possible that in the meantime the connection became poor, but I really believe that is unlikely.  It worked for me many times as well, but it also ruined a couple of expensive bits.  In any case, setting the Z axis in this manner is proven to be unreliable for me, so I am using a different method.  

Not trying to point fingers, but I though Artsoft ought to know that there are problems occuring.

Also, it was a wired USB game controller, not wireless.

I am just using the mods I downloaded for the blue screen set unmodified - what is this G90 code - do I need to edit the script for setting the Z?
« Last Edit: February 03, 2010, 12:27:14 PM by revwarguy »

Offline budman68

*
  • *
  •  2,360 2,360
    • View Profile
Re: losing probe signals with USB game controller?
« Reply #11 on: February 03, 2010, 12:30:38 PM »
No worries on pointing fingers, there's obviously a problem as you're definitely not alone apparenty.

I was just trying to narrow down some issues, but if it's wired, I guess we're back to square one in the "investigation". There are just so many various manufacturers out there, it makes it difficult to find where the culprit is.

It now makes me a "little" nervous using this at times,
Dave
----------------------------------------------------------------------
Just because I'm a Global Moderator, don't assume that I know anything !

Dave->    ;)

Offline Jeff_Birt

*
  •  1,107 1,107
    • View Profile
    • Soigeneris
Re: losing probe signals with USB game controller?
« Reply #12 on: February 03, 2010, 01:45:43 PM »
I would not depend on a current return path through the collet/toolholder, bearings, spindle housing, etc, etc. It will never be reliable unless it was specifically designed for the task. It takes bearings with conductive grease among other things to get it to work every time. The other potential issue is that your using the machine frame, which is likely (earth)grounded, for a DC current path; using an (earth)ground as a current conduction path is just asking for trouble from ground loops.

I clip one wire to the bit and one to the stock or touch plate and have never had it miss.
Happy machining , Jeff Birt
 
Re: losing probe signals with USB game controller?
« Reply #13 on: February 03, 2010, 02:23:03 PM »

"Greg has done a lot of work on this correcting possible problems that could occur, depending on the current Mach settings in force when the script is envoked and perhaps the best for me has been the addition of the G90 to this line Code "G90 G31 Z -15 F" &ProbeFeed 'Probing move at ProbeFeed rate."

Is this line to be added or changed in the blue screen mods that I downloaded?  I haven't made any changes to what I installed.  What effect does the G90 code have in this instance?

"Other related factors (which have been well discussed on the Zone)  include residue on the tool shank or in the collet, partially insulating the tool from ground and also how good is the earth connection of the spindle shaft through its bearings ?."

Don't think its a Mach setting issue, as it worked 99% of the time.

My spindle is double insulated from the frame; therefore I have a stiff battery clip that I apply to the collet.  You can see it on the URL given in the first post.  As I said, this is clipped and tested to see the green "LED" light come on on the screen, and once it does, the Z setter button is clicked, so while a poor connection might be possible, I believe its highly unlikely.

At any rate, this method of setting the Z has proven to be unreliable for me, so I've gone to a different method that is just as easy, but without risk.  It also works with tips that are non conductive like pens, diamond point engravers, etc.

My game controller is a wired USB, not wireless.
Re: losing probe signals with USB game controller?
« Reply #14 on: February 03, 2010, 08:05:55 PM »
Here is the downloaded script code I copied for my z axis set button.  If anyone sees anything missing or a problem, please let me know.

Rem   VBScript to probe in the z axis

If GetOemLed (825) <> 0 Then       'Check to see if the probe is already grounded or faulty
   Code "(Z-Plate is grounded, check connection and try again)" 'this goes in the status bar if aplicable
Else
   Code "G4 P1"         'Pause 1 seconds to give time to position probe plate
   PlateOffset = GetUserDRO(1151)   'Get plate offset DRO
   CurrentFeed = GetOemDRO(818)    'Get the current feedrate to return to later
   Code "F4"         'slow down feedrate to 4 ipm

Rem   Probe in the z direction
   ZNew = GetDro(2) - 2      'probe move to current z - 2 inches
   Code "G31Z" &ZNew
   While IsMoving()      'wait for probe move to finish
   Wend

   ZNew = GetVar(2002)       'read the touch point
   Code "G0 Z" &ZNew       'move back to hit point incase there was overshoot
   While IsMoving ()
   Wend

   If PlateOffset <> 0 Then
      Call SetDro (2, PlateOffset)   'set the Z axis DRO to  plate thickness
      Code "G4 P0.25"       'Pause for Dro to update.
      ZNew = PlateOffset + .25
      Code "G0 Z" &ZNew       'put the Z retract height you want here
      Code "(Z axis is now zeroed)"    'puts this message in the status bar
   End If

   Code "F" &CurrentFeed       'Returns to prior feed rate
End If

Offline Tweakie.CNC

*
  • *
  •  7,853 7,853
  • Super Kitty
    • View Profile
    • Tweakie.CNC
Re: losing probe signals with USB game controller?
« Reply #15 on: February 04, 2010, 08:21:30 AM »
Quote
Is this line to be added or changed in the blue screen mods that I downloaded?  I haven't made any changes to what I installed.  What effect does the G90 code have in this instance?

If your machine is operating in Incremental Distance Mode when the Auto Tool macro is evoked then it will not work correctly.
The macro was designed to operate in Absolute Distance Mode and for this reason Greg suggested adding the G90 'to be sure to be sure'.

Tweakie.
Success consists of going from failure to failure without loss of enthusiasm.  Winston Churchill.

Offline stirling

*
  • *
  •  2,188 2,188
  • UK
    • View Profile
    • www.razordance.co.uk
Re: losing probe signals with USB game controller?
« Reply #16 on: February 04, 2010, 09:35:46 AM »
The line
Code "G4 P0.25"       'Pause for Dro to update.
is also better replaced with
while isMoving()
wend

For a discussion of why - see http://www.machsupport.com/forum/index.php/topic,12764.0.html which although titled "G4 versus sleep" also deals with G4 versus while isMoving().

Cheers

Ian
Re: losing probe signals with USB game controller?
« Reply #17 on: February 05, 2010, 04:51:42 PM »
Since the plate offset has never been zero, didn't the "while isMoving() ... wend: just get executed?  If so, what difference could a G4 make - i.e., shouldn't the G4 just be deleted then?

Ahhh, the incremental/absolute thing - this has always bugged me.  Why do g-code generators assume which mode it should be?  Should that be declared specifically whenever it is used thereby avoiding any conflict?  I will add the G90 to the G32 line, but I did check, and this is the mode that is the default upon launch.
« Last Edit: February 05, 2010, 05:03:46 PM by revwarguy »

Offline stirling

*
  • *
  •  2,188 2,188
  • UK
    • View Profile
    • www.razordance.co.uk
Re: losing probe signals with USB game controller?
« Reply #18 on: February 06, 2010, 05:20:25 AM »
Since the plate offset has never been zero, didn't the "while isMoving() ... wend: just get executed?  If so, what difference could a G4 make - i.e., shouldn't the G4 just be deleted then?
Sorry I don't understand what you mean.

In the following code snippet:

   If PlateOffset <> 0 Then
      Call SetDro (2, PlateOffset)   'set the Z axis DRO to  plate thickness
      Code "G4 P0.25"       'Pause for Dro to update.
      ZNew = PlateOffset + .25
      Code "G0 Z" &ZNew       'put the Z retract height you want here
      Code "(Z axis is now zeroed)"    'puts this message in the status bar
   End If

The Z axis DRO MUST be allowed to finish updating before the Z axis is commanded to move by "G0 Z" & ZNew, otherwise the DRO and hence Mach's notion of Z WILL be wrong. The "G4 P0.25" does NOT guarantee this but a "while isMoving()" DOES.

Ian
Re: losing probe signals with USB game controller?
« Reply #19 on: February 06, 2010, 04:55:56 PM »
I think I see what you mean, but don't understand why.  If you include the previous two lines before your snippet:

  While IsMoving ()
   Wend

   If PlateOffset <> 0 Then
      Call SetDro (2, PlateOffset)   'set the Z axis DRO to  plate thickness
      Code "G4 P0.25"       'Pause for Dro to update.
      ZNew = PlateOffset + .25
      Code "G0 Z" &ZNew       'put the Z retract height you want here
      Code "(Z axis is now zeroed)"    'puts this message in the status bar
   End If

You see a While IsMoving () ... Wend just got executed, so the table is now stationary.  Since PlateOffset is never zero, it falls through to the SetDro line, then the Code G4 P0.25.  My mistake, since I didn't think the SetDRO command needed any latency, as it doesn't involve the actual table movement, it just sets an internal Mach variable such that it is complete before it returns to the next line.  I take your word for it, but why do we need to wait for SetDro?  What other commands that don't involve the physical table need to be waited on in these scripts?

Trying to learn,