Hello Guest it is May 11, 2021, 11:49:08 AM

Show Posts

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

Messages - Highspeed1964

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 »
General Mach Discussion / Re: newbe with 4th axis problem
« on: July 22, 2016, 09:37:25 PM »
You need to set the 4th axis to rotary.  It is calculating the input (A10 in your example) as a linear measurement and not a number of degrees.  You may also need to check if your 4th axis driver is configured for "micro steps".  If so, your calculation is not complete.  On my 4th axis, I have 8 micro-steps/step so a full rotation is actually 1600.

Hopefully, it's one of those two things and you should be on your way.

Stephen "Highspeed" Kruse

Ummm, it sounds like your machine is running in G21 (milimeters) mode.  Since you said your program is preparing the G-code in inches, then this is most likely the issue.  Make sure there is a G20 at the beginning of the g-code file and it should work out ok.  It it's still off, then tune the motors.

Stephen "Highspeed" Kruse

Nice find!  Thanks for posting the fix.

Stephen "Highspeed" Kruse

FAQs / Re: Zero Tool not reading allowance
« on: July 21, 2016, 07:51:09 PM »
Firstly, that yellow "Abnormal Condition" was a bugger for me, too.  Not related to this tool zero, but rather when I changed the table size in the limits/homing configuration.  What you DO NOT want to do is double click that yellow button and accept the following prompt as this is guaranteed to further muck things up.  I ended up having to start a new profile all over again.

Now having said that, I found since then that you can go to the Operator menu and do a restore.  The system backs up the previous 21 configurations (a new one each time you run Mach 3) so you can back track to a previously known good state... if it's within the last 21 times you've run Mach 3.  What I found out to be my issue was that it seems one of the Y axis limit switches had gotten stuck and that triggered the abnormal condition.  But instead of realizing the issue and fixing it, I double clicked the button and accepted the abnormal condition as normal.

Bottom line here is try to determine what is causing the abnormal condition.  It could be any number of things and I have not found any specific documentation on it.  if you're sure everything is operating normal (with the exception of your tool zeroing) try going back to a previous known good configuration as mentioned above.

Now, regarding that tool zero... could you post the current macro you are using (and what you are using to trigger it, i.e. Auto Tool Zero button or M6 Macro)?  I'm sure there have been a couple of changes or so since you first posted it so let's look at the current state.  Also, G54 is a more common Workpiece offset to use, so if the code is expecting to use G54, but your machine is running in G58 then you are working with two different offsets and this would definitely cause inconsistent operation like this.

Let me know what you find on the abnormal condition and post the current iteration of your macro.  I'll look it over.

We'll get you there.


General Mach Discussion / Re: Motors are not operating correctly
« on: July 21, 2016, 07:30:24 PM »
Hmmmm, definitely something flakey.  Could be a heat issue, either with the motors themselves or with the stepper drivers.  You may need to see about putting some cooling fans on the drivers since we're getting into the hotter months of the year.  They may have worked in the past, even during the hot months, but as they get older the heat could become more of an issue.  And since they worked for a few cycles, then started going wonkey but worked again after letting them rest a while heat is definitely a likely culprit.

You said your drivers are enclosed, so is there sufficient ventilation on the enclosure?  Is there a fan in that that may have stopped working?

Check to make sure your drivers are staying cool enough and then check your motors, too.

Let me know.


General Mach Discussion / Re: Spindle control problem
« on: July 21, 2016, 03:12:40 AM »
From what I can see in your screen shots, you have the PWM output on pin 14 and a control signal configured for pin 17, correct?  However, you do not have the Spindle Relays enabled in the last screenshot.  Normally, you would have the PWM setting the spindle speed and then the configured output (Output 1 on Port 1 Pin 17 in your case) driving a relay to send the VFD a start/stop control.  This would likely be a relay that connects a "Common" lead to the Start or FWD Run pin on the VFD itself.  Otherwise, the VFD would have to be set to Run manually and then the PWM would control the speed and if Mach 3 is told to set the speed to 0 the spindle would stop running, but still be engaged.

I would suggest unchecking the "Disable Spindle Relays" on the Spindle Setup tab and setting BOTH outputs (M3 and M4) to the output you configured in the "Output Signals" tab - Output 1 in your setup.  Make sure the output you configured controls a relay to close the path between the "Common" and FWD Run pins on the VFD.

I'm not sure why you cannot change the spindle speed, but if you're running a program you should be using the SRO (Spindle RPM Override) to adjust the actual RPM.  (I see you don't have that on your screen set.  You may need to upgrade to the newest release of Mach 3 to get it.)

Hope this helps,

Stephen "Highspeed" Kruse

Found the problem!

And that was...?

Stephen "Highspeed" Kruse

Those M24, M25, etc. codes are not familiar to me and are not listed in any of the reference guides I can find.  They are probably custom macros used by your controller so could be causing these errors.  As "bob" said, you'd need to check with your controller manufacturer or vendor.

Stephen "Highspeed" Kruse

General Mach Discussion / Re: Motors are not operating correctly
« on: July 21, 2016, 02:18:35 AM »
Yep, you're correct in assuming that you need to check the direction lines (at least in the case of the X axis), but not sure how to really explain the use of a meter briefly enough to state in a forum post.  The Z axis acting the way it does (intermittently) still indicates to me something is loose somewhere or a wire got broken inside the insulation.  It definitely seems weird that this happened from routine maintenance (cleaning/lubrication) of the machine.

The other possibility is that something got shorted out in the drivers as a result of liquid getting into the contacts or wiring pins touching while power was applied.  I'm sure, though, that you didn't do this maintenance without turning off the machine first, right?

Could you try swapping the motors to different axis drivers and see if the symptom follows the motor or stays with the driver output?  BE CAREFUL doing this as you'll easily get confused as to which axis should be moving for a given control and you may crash your spindle, tool or other components against other things and this is not good.  Just short, slow movements to verify the driver/motor is working correctly.  If the symptom stays with the motor, your drivers are good and you need to inspect the wiring more closely including weird kinks in the insulated sections where there may be broken wiring inside.

Let me know what you find and we'll keep looking if needs be.

Stephen "Highspeed" Kruse

FAQs / Re: Zero Tool not reading allowance
« on: July 21, 2016, 01:58:22 AM »
Sounds like we've got some consistency, now.  Yay!  So the sleep command would go on a separate line between the "While IsMoving()" line and the "Wend" line as follows:

While IsMoving()

Now as far as top of the puck is concerned, that is where the probe actually touches.  Then the DRO should be set to the height of your puck (in my case, 25.69 mm) which would mean that zero should be at the bottom of the puck.  Are you saying that you then try to move to Z0 and it does not go there but remains at the puck height?  Then a couple of other things I see that need to be checked:

Does the probe actually touch the puck surface?  The SetDRO(2, 10) puts the the value of the puck height (10 in this case) into the Z DRO.  So if the probe move did not find the puck it will set the current location to 10 which may be 10 or 15 mm above the actual surface.  G31 is a code that tells the machine to move the Z axis a certain amount and if it detects the probe then stop the move.  However, if it does not detect the probe it will move the full amount and stop there.  Additionally, GetVar(2002) would return random (possibly a previously set) value that would be meaningless to this operation.  The macro should check for the probe to be active before checking the GetVar(2002) and setting the DRO.

Here is a little snippet of the code I use (you can follow along in the comments to see what it's all doing):

ProbeD = 20                                              'Sets how far to probe with the G31 Command below
   Code "G53 G0 Z" & ToolChangeZ         'ToolChangeZ is MC for starting location of probing
   While IsMoving()
      Sleep (10)
   ZCurrent = GetOemDro(802)         'Current Z DRO
   ZNew = ZCurrent - ProbeD         'Probe depth end height
   Code "G90F100"               'slow feed rate to 100 MM/MIN
   Code "G31 Z" &ZNew            'Start the probe move
   While IsMoving()
   If GetOEMLed(825) = True Then         'Probing successful
      ProbeTouch = GetVar(2002)      'Exact height touch plate was contacted
      Code "G1 Z" & ProbeTouch      'Go there (corrects for potential over-run)
      While IsMoving()
      Call SetDro(2,GageH)         'Set Z DRO to adjusted value
      FinalMove = GageH + 10
      Code  "G0 Z" &FinalMove         'Raise probe off of touch plate
      While IsMoving()
      Message("Press Cycle Start to continue...")
   Else                  'Probe did not contact touch plate
      Message("Zero not achieved - Check probe and try again manually")
   End If
Else                     'User selected Cancel on Auto Tool Zero prompt

This is not the whole code as I'm doing a lot more in the M6Start macro so some of the variables are defined prior to these lines of code.  However, the line "If GetOEMDed(825) = True" checks that the probe has made contact before performing the commands to set the DRO and raise the tool off of the surface of the puck.  If this check fails and your code proceed to set the DRO you will get unpredictable results.

Finally, I do not use tool offsets as my CAM software adjusts accordingly.  The tool path it generates is already offset.  So I'm not sure how tool offsets would affect this process.  But I would imagine it could affect where the tool tip is after a zeroing operation.  Remember, the coordinate systems (Machine coordinate, Workpiece coordinate, etc.) refer to the location of the tool tip as long as everything is zeroed correctly so if a tool offset is in effect for the Z axis, it could definitely change where the tip actually is..  One other thing that could throw this off would be a G92 offset.  It is really recommended not to use this command unless you fully understand how it would impact the other coordinate systems.  So until we get this figured out for you, make sure your G-Code program is not using it.

We'll get to the bottom of this for you.  Let me know how things go.

Stephen "Highspeed" Kruse

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 »