Topics

1

Mach3 under Vista / Migration to Win7 - Simulation use only.

« on: July 22, 2011, 07:19:53 AM »

OK guys this is my situation.  I have two PCs.  One runs the machine (cnc router) and the other is used to check out scripts and gcode before running off to the machine.

The one I use to check out the scripts and gcode is my "main" computer for almost everything and it was time to give it a not so decent burial....

So, I now have a new Win7 Professional machine that will be used for design and check out.

The issue is that scripts (such as zero set plate) do not run (first one checked is a z-zero plate) correctly.  I have attached the script as things may have changed since Mach was installed on the other machine (moving to current lockdown).  But I also used the "older" lockdown version as well (same issue).

I "emulated" the probe key and the "led" on my screenset fires when the key (in this case 'p') is pressed but the script continues to run in the "ismoving" section.  It seems that the script does not "see" the keypress.  The diagnostics screen shows the probe/digitize led firing.

I am not sure if this is a configuration issue or a Win7 issue.  I am not running the PP driver (no need and doesn't work under x64) so I would not expect to see any changes on the Diagnostic screen for the corresponding leds for the PP pins.

This new machine is a quad core processor if this makes any difference.

TIA, Stan

2

VB and the development of wizards / M6End macro thoughts (newbie alert)

« on: March 15, 2011, 09:57:41 AM »

After getting my 5'x10' router running...  I am looking at ways to make things more efficient (read I want the machine to work for me 

My question is simple.  Why would I want the machine to return to the previous spot called out before a tool change?  I am working towards having a certain location that the machine moves to (got this one), wait for the tool change (got this one), and when cycle start moves to the start of the next tool operation (know how to do this conceptually) not the previous position.

I'm not sure if my idea is sound.  Basically, moving the bit to machine coord z0 in the M6End macro and then letting the gcode take over to go do whatever it is that the gcode does.

BTW, I cut molds so it is mostly 3d with CV on and don't want to mess those up.

Stan

3

G-Code, CAD, and CAM discussions / GCode Prologue from CAM...

« on: September 23, 2010, 08:25:49 AM »

Please forgive me if this has been answered before.... but...

Currently my CAM (VisualMill) generates the prologue gcodes all on one line.  I had heard/remember that Mach didn't deal with this kind of coding at some point in the past.

Does the newer versions handle this?  I could test this except my CAD/CAM machines are not at the same physical location as my Mach machine.

Stan

4

General Mach Discussion / Relationship of Velocity/Accel to G0...

« on: June 23, 2010, 07:19:45 PM »

First things first..... Newbie Alert (mach that is 

Next things - mach/machine setup info:

Motors: stepper - keling klh260-60-4a (4wire motors)
Drivers: gecko - G203v
transformer output - 25vac (according to marris this is about optimum for mH of motors
power module - pmdx power module
PC: asus mainboard, pci parallel port, agp? video
OS: WinXP Pro version 2002 SP3
Mach: R3.042.040
kernel: 60kHz
Steps per unit (in): 2546.479
Velocity: 1377 ipm
Accel: 137.07162
Step Pulse: 5us
Dir Pulse: 5us
A axis slaved to X

Now for the issue.  Although the motor tuning dialog runs the motors smoothly and quietly to 1377 ipm the best that G0/G28 can accomplish is about 425 ipm.  Beyond that the motors growl, stutter, stop.  I have watched the "blended spd" number on diagnostic screen and whenever that number gets to about 600 or so the motors start the growl, stutter, and stopping.  Due to gear reduction and r&p drive the rpm is a bit more than the the ipm (ie. 425 ipm = 552.5 rpm).

I can imagine that the 1377 ipm is a "theoretical" max while the motor tuning dialog is "in control" nothing else is going on (no math, no graphics, ...)

I would have thought that the "real" top speed would have been closer to 600-800 ipm (50% or so) than a paltry 425 ipm (30%) given the motor tuning of 1377 ipm.

Where is the bottleneck?  It doesn't appear to be the drive system (runs at 1377 ipm or about 1800 rpm).  Before anyone asks, the motors are secured to a test panel not the actual machine (MechMate for curious minds).

Stan

5

LazyCam (Beta) / Lines joined with arcs cause problems - turbocad

« on: July 18, 2008, 09:42:26 PM »

I drew the following drawing using turbocad.  Save as dxf then onto LCam.  LCam generates more than the six chains.  According to Scott the problem is in the dxf.

What the heck is going on?

Stan

6

LazyCam (Beta) / Need a tutorial on generating multi-pass g-code.

« on: September 20, 2007, 07:28:28 PM »

I've got a dxf that is supposed to be 2-d.  Open it up.  Clean it up.  Now set the rapid height on the layer to 1.0, set the cut start to 0.25 (top of cut), set cut depth to 0.25, and tool is set to cut 0.0625 per cut.  Generate G-code..

I get one pass..... Help.

BTW version 2.5

Stan

7

LazyCam (Beta) / Tabbing - How To....

« on: August 24, 2007, 05:39:39 AM »

Maybe I'm just still asleep, but I can't seem to figure out the "tab" feature.  Simple offset of polyline then tab....

Stan