Step-Pause-Step-Pause Program Execution

[762x51]

I finally found my spindle problem (trash/corrosion on RPM signal terminal) and loaded a program for testing.
Program executes but in a very unusual way. After each line of code the controller pauses for about 1/2 second then executes the next line of code. As this is going on, the DenStep's LED cycles between 8 & P.

Any idea why this is happening?

[Denford Admin]

Have you tried to run in Turbo mode ?
This is available in VR Milling...I'm not sure if you are on a Micromill or turn?

Even out of turbo mode, or from VR Turning, half a second between moves sounds a lot. I'd only expect to see this if there is a problem with the communications..RS232 or USB. If the data is being corrupted and having to re-send then you can get delays between moves.

[762x51]

I tried running in "Turbo" mode this morning with no change in the step-pause-step-pause execution and I did fail to mention in the original posting that I'm running this on a MicroMill 2000 with the latest version 2 VR Milling. I also failed to mention that I get a lot of "Divide by Zero" errors and the PC's mouse isn't responsive as normal while the program is executing. For example, I have to repeatedly click on the "OK" button to clear the divide by error message and pausing the program takes repeated clicks on the pause button to get the program to stop.

PC is a Celeron running at 1.6 Gig with 1 Gb memory. This is a dedicated PC with no background programs running, XP OS with the latest updates, Windows firewall turned off, and no anti-virus software running. PC is not connected to the internet.

RS232 port settings are 19,200 Baud, 1 Stop bit, no parity, no handshake.

Jog, homing, spindle start/stop, and spindle RPM control work fine.

Attached is a screen shot of the part showing the tool path of the program module I have been trying to run. I've also attached a copy of the .FNC file.

Note: The outer grey box is used to define the stock size for the CAM (HSMWorks) program.

[Denford Admin]

What I'd do with that program is alter the way the CAM creates the feed-in moves...
At the moment it's creating lots of very short helical (3 axis arc) moves...helicals are supported in VR Milling version 5 but I'm not so sure v2 could handle them properly.
See if you can change them to linear (G01) feed-in moves, depending on the material + cutter you might be able to plunge straight down into the pockets (ie just Z axis only)
The actual pocket clearance moves should machine quickly as they are made of fairly long lines and arcs in the XY plane so the control will have time to buffer the next move while one is being carried out.

[762x51]

...helicals are supported in VR Milling version 5 but I'm not so sure v2 could handle them properly.

Not the answer that I'd hoped for but it is what it is......

Any thought's as to why I get a load of "Divide by Zero" error messages and mouse commands are largely ignored while the program is executing?

[Denford Admin]

Like I say, helical arcs were added and tested in v5 milling - I'm surprised v2 milling even recognises the G03 at all, so that might explain the divide by zero errors.

It should be no big deal to alter the CAM to output a different style of feed-in move..even if it breaks it down to G01 linears the machine will perform better

[762x51]

Thanks for the followup on this and I'll look into your suggestion of altering the CAM program to delete the G03 commands.

Merry Christmas to all at Denford!!!