Hello Guest it is March 28, 2024, 08:17:15 PM

Show Posts

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


Messages - Sage

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 »
331
Newfangled Solutions Mach3 Wizards / Re: Bug ?? need help quick please
« on: September 25, 2008, 07:08:49 PM »
Further to above, I've discovered that if I change the diameter to 5.493 instead of 5.483 that small difference makes the MACH posted code show properly.

Can anyone figure out why?

 Still confused as to what is going on. The manual says that a G02 may change its path depending on tool offsets and such but it makes no sense to move from inside to outside when it's an ouside path specified.

???

Sage

332
I think I've found a bug in the NFS wizard "Cut Circle"
I'm trying to use it to clean up the ouside diameter of a 1" thick round plate.

I set the following into the cut circle NFS wizard.
Material Aluminum = +1
Max spindle speed 1450
max feed rate 20
inches
select the cut circle wizard
surface speed for special tool 0.0
tool #1
tool diamter .250
HSS tool
number of cutting tips 4
chip load per tooth .0017
inches
spindle direction CW
Flood
overides - spindle 100% Feed 100%
Percent plunge 20
speed and feed calculates to 1450 and 9.6
X center 0 - Y Center 0
Circle diameter 5.483Groove
Outside
CCW (conventional mill)
Pitch 0.5
Depth 1.02
Rapid Height 0.1
Step Depth 0.01

If I look at the preview IN THE WIZARD I see what I would expect, which is the tool approaching the material from the outside and spiriling down to the full depth of 1.2 inches while milling on the outside diameter of the plate - Good!

If you post the code and look at the toolpath display in MACH,  the tool is following some stange path. It starts above the plate, spiraling down and out to the proper diameter. The path downward apparently meets the plate at a point of the proper diameter just as the tool touches the plate. It continues around the plate at the proper diameter so theoretically it should work but if the tool height does not start exactly right the tool will meet the plate too soon.

Good thing I checked the code with foam.

Can someone figure out what I'm (or the program) is doing wrong. I have a job I need to get out the door by the end of the weekend and sorry to say I'm not experienced in G-code enough to write the program properly by hand.

PS> I used the wizard to create a similar program using a 1/2" hogging mill to rough out the initial diameter. That tool path looks ok when posted so I'm not sure why the particular parameters I listed above do not work.

Thanks

Sage


333
General Mach Discussion / Trying to understand offsets
« on: September 05, 2008, 02:30:17 PM »
I'm new to using offsets so I thought I write a short program to see if my understanding is correct. I won't attach it as someone may be able to explain what's going on just by looking at the code below. I haven't run it on my machine yet but, by following the machine co-ordinates DRO it looks like it is working properly but the toolpath screen seems confused.
 It should machine three 1" squares the first with it's bottom left corner at 0,0 the second starting at the upper right corner of the first at 1,1 and the third starting at the upper right corner of the second at 2,2.
Maybe someone can explain why the machine co-ordinates DRO looks corect but the toopath seems to write over the same squares more than once it might help me. (I tried bot normal and table modes of toolpath and neither looked correct)
Thanks
Sage

(Setup as follows)
(manually set the following X,Y fixture offsets in config)
(G54 is co-ordinates 0,0)
(G55 is co-ordinates 1,1)
(G56 is co-ordinates 2,2)
(Z is zeroed at work surface)
(Set M1 optional stop on to observe movement)
(ref all home)
(run program)
(tool path screen shows ok with 3 boxes linked top left to bottom right)
(if program is run production movements are correct on machine co-ordinates DRO)
(on tool path screen production movements are confused)

(program starts here)
M1 (stop to view screen)
Z.1 (tool up to stay clear)
G54 (reset offsets)
G0X0Y0 (go fast to 0,0)
m1 (stop to view screen)
Z-.010F1 (tool slowly into work 10thou)
X1F5 (mill a 1" square)
Y1
X0
Y0
G0Z.1 (tool up quickly)
g55 (Load second set of offsets)
G0X0Y0 (go quickly to new 0,0 location which is actually 1,1)
m1 (stop to view screen)
Z-.010F1
X1F5 (mill a 1" square)
Y1
X0
Y0
G0Z.1
g56
G0X0Y0 (go quickly to new 0,0 location which is actually 2,2)
m1
Z-.010F1
X1F5
Y1
X0
Y0
G0Z.1
G54 (cancel offsets)
M30 (end and rewind)


334
General Mach Discussion / Re: MPG Signal requirements
« on: August 29, 2008, 10:50:04 AM »
Thanks. I'll see what I can cobble together.

Sage

335
General Mach Discussion / MPG Signal requirements
« on: August 29, 2008, 09:51:48 AM »
Can someone confirm the signal requirements for Mach3 MPG inputs to a parallel port? I haven't been able to find it anywhere.
It looks like there are two signals required as the setup shows A and B signals.
Is a quadrature signal required or something else?
I'm asking becasue I came across a nice handwheel on a panel with a bunch of switches. The handwheel may already produce a quadrature signal. If not I'll make my own circuit to generate whatever is required.

Sage

336
General Mach Discussion / Re: Progressive Move Error with X and Y
« on: August 29, 2008, 08:54:08 AM »
Glad to hear it's working. Enjoy.

PS> Eliminating the BOB was only suggested as a trouble shooting step. As a general rule, be sure to use some sort of BOB. The Gecko's will be fine driven directly since they effectively have a BOB circuitry built in, but all kinds of disaster could happen if you wire external signals directly to the parallel port.

Sage

337
General Mach Discussion / Re: Progressive Move Error with X and Y
« on: August 28, 2008, 12:29:05 PM »
HimyKabibble:

You could be right. But the difference between you, cmnewcomer and me is is that you both have the hardware in front of you. I'm just trying to convey reasonable troubleshooting princples (which appeared to be lacking) so he can draw some reasonable conclusions as quickly as possible.  If you put the thing in front of me I'm sure I'd come to the right conclusion about what's going on pretty quickly. I've been doing electronic maintenence for 32 years.
  Following the principals I'm trying to convey and keeping accurate track of the results without confusing the issues, the conclusions would be the same anyway. If pin 4 is one of those that cannot handle the high speed it would be weeded out as not working for that function. Eventually you'd end up with a set of pins that work. (He's already 2/3 of the way there). Assuming of course the BOB has 3 pins (XYZ) that are up to the task. Maybe it doesn't. You can tell him that.

Sounds like you've had EXACTLY the same problems. If that's the case then scrap the BOB and get on with life. Life is short. Running the machine is more fun than troubleshooting any day. Spend the extra money and go with the PMDX 132 which can take 4 Gecko's. I've Had absolutley no issues with mine.

Feel free to take over and coach since you know about the inherent problems with the board. I wasn't aware that the BOB might be a piece of crap.

Sage


338
General Mach Discussion / Re: Progressive Move Error with X and Y
« on: August 28, 2008, 09:48:07 AM »
By the looks it you moved the Y-axis BOB hardware to a completley new set of parallel port pins and it works. So that most likely means the BOB hardware is fine for the Y-axis. That pretty much points to the parallel port being bad or possibly wiring on the BOB for those pins (4or5). Not sure what happens on the board.

Your next move to test the Z-axis completley baffles me. You've really confused the issue (for me). But there may be some useful information buried in there none the less.
From what I can see you have taken a good pin (2) which was working fine on the X-axis and used it along with a pin (4) that could have contributed to the Y-axis not working and discovered that it doesn't work for Z-axis either. You may be safe to assume that pin (4) s the culprit.
Do you see the common problem here? Remember I suggested to look for what's common when you try stuff?
 The only problem with your approach is you've introduced a different set of hardware i.e. the Z-axis to test the pins. That inroduces another possible unknown.
 Forget about the Z-axis for now. Use your good stuff (X-axis) to test the susicious stuff. When you finally find another set of good pins by testing them with known good hardware like the X-axis then use those new pins to drive Z-axis and leave the X and Y on whatever works for them (what you have already found that works).
  The approach now would be to continue proving that pin(4) in the problem. You should probably try it with know good hardware like making the X-Axis use it. Leave the Y-axis on the other known good pins.

Try this slight modification to what has proven to work.

X-Driver Step   -   4 (was pin 2 and was working fine)
X-Driver Dir                   -   3
Y-Driver Step   -   8
Y-Driver Dir                   -   9

In this example the X axis will probably screw up because pin 4 is being used to step it.
If that works for some strange reason try pin(4) as the X-Direction signal and put 2 back as the step. Direction doesn't do much but I suppose if it were picking up noise the driver might toggle back and forth a step or two instead of going in one direction.

Gong further, pin 5 was also a possible contributor to the Y-axis not working it should be tested in a like manner i.e move JUST pin (5) to a know good confirguation.

Baby steps targeting a particular signal is best to avoid confusion.

Sage



339
General Mach Discussion / Re: Progressive Move Error with X and Y
« on: August 27, 2008, 08:56:08 AM »
 Your description can be interpreted in a couple of ways (I think)

You wrote:
>>>I moved the y output on the breakout board to another set of outputs for the step and dir pulses and ran a perfect test three separate times.

Does this mean you moved the original BOB Y-axis circuitry to another parallel port output?
OR
You selected another complete path including software configuration, parallel port output AND BOB circuitry.

If the former then the BOB must be ok and the parallel port is at fault.
If the latter and you're using another parallel port AND BOB circuitry then it could be either of them at fault.


As Hood points out it is most likely the BOB and, as he suggested, it might make sense to bypass the BOB altogether and connect the drivers direct to the parallel port and be sure it works. If you really need the BOB (recommended for inputs at least) then systematically introduce it back maybe one axis at a time to see if and when it causes problems.

If you think the BOB ciruitry is bad for one axis then ONLY move that circuitry to be driven by something else. Not sure how much flexibility you have to do that but if the problem seems to follow the BOB circuitry then you have the problem. Alternately if the problem seems to move to whatever is being driven by a particular parallel port then that's likely the issue.

Sounds like you are on the right path. Keep testing. Follow the fault and determine what is common with each faulty configuration. Don't make huge changes and be thrown off by completlely new results (i.e. the Z-axis move to something new).

 I'm now confused by your original analysis (way back) that either axis was fine when it was run individually and that it was only a combination of running them both together that caused the errors to appear. Not sure about that.
 
Sage

340
General Mach Discussion / Re: Progressive Move Error with X and Y
« on: August 26, 2008, 08:40:26 AM »
So, if you are saying that it wasn't perfect for the remaining axis by removing the signals from the interface board then the problem must be back further i.e. a the parallel port or the software. (well actually it could still be mechanical but I don't think it would be progrssive if it was).
 You might try connecting everything back up and try the other suggestion of disabling one axis in the MACH3 configuration so it does not even generate pulses. I think the g-code should run anyway. I might be wrong on this.
 If it runs and the axis remaining does not have any errors then there could be something wrong with the parallel port or the ability of the sofware to activate it properly. Maybe something like the TTL logic and it's power supply on the parallel port gets messed up generating pulses on two drivers on the same chip - I know I'm grasping here but you obviously have a unique problem.
 I can't recall if you said you tried a different computer or even what computer you are using. I know some laptops (and even some desktops) have compromised versions of a parallel port hardware - at least by the old fashioned standards.

Just some suggestions.
 
Sage

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 »