Messages

6731

General Mach Discussion / Re: how to control z-axis brake

« on: June 05, 2010, 06:56:51 PM »

(;-) Where you have a built in wait state then that is not really a problem. BUT when you are trying to run the gcode transparently there is no way to avoid the time lag of the mechanism in relation to the flow of moves coming out of the buffer.

Try running your setup without the wait states, I bet you will randomly trip from positional errors with a servo OR miss steps from a stepper

The only way I have seen it done without problem was from a realtime system that incorperated the I/O sensing into the motion data control point so the movements could NOT occur until conditions were met.

6732

VB and the development of wizards / Re: start from line #

« on: June 05, 2010, 04:46:04 PM »

I don't know.

 I do not work on code that may endanger the operator or machine

6733

General Mach Discussion / Re: how to control z-axis brake

« on: June 05, 2010, 02:52:21 PM »

O K here we go again(;-)

YOU "could"  monitor the Z axis velocity and

 IF  Zvel =zero then apply output signal to apply brake

AND
IF Zvel <> zero then turn off output to release brake


BUT you run into the latency problem with using a buffered system. The Z moves are already stacked into the buffer ready to go AND when the signal comes to run there is NOTHING in machs design that will allow the buffer to hold UNTIL the brake is releases fully before the Z can safely move without a loss of steps do to the drag of the brake untill it has fully released.

EVEN IF you had an intelligent drive that could do the function you could run into an accuracy problem as MACH is assuming that ALL drive can react very closely the SAME.  Testing has shown that 1 slow reacting drive out of 3 can cause a mispositional error . Mach has NO way of knowing the timeing points of the drives it just assumes ALL the moves have been made as a coordinated move. It would depend on the resolution and amount of drive dwell as to HOW MUCH error would be involved

With "any" form of monitoring the Gcode pulses to active or deactivate BY the time it "sees" the movement it is TOO LATE to release the brake.

In the normal world brakes are used to HOLD the axis when it is NOT active/enabled. It is UP to the motor to HOLD the axis in position when it is active/enabled. Mostly to HOLD the position when the machine is OFF and to Catch the axis in the event of a power failure and loss of holding force.

IF the axis cannot hold itself you have 2 options mentioned above. Increase the motor to the proper size OR counterweight it to require LESS holding force.

Hope that helps

6734

VB and the development of wizards / Re: start from line #

« on: June 05, 2010, 02:13:09 PM »

IT works just fine here. there is nothing wrong with the process just the application.

6735

General Mach Discussion / Re: DRIVING A STEPPER MOTOR LIKE SPINDLE

« on: June 05, 2010, 12:12:30 AM »

Hi Rene, The i/o sampling rate for mach using the VB engine is ONLY 10hz or 10 time per second, FAR FAR too slow for what you want. ALSO there can be a sync problem in vb/gcode where proceesses may get slowed down from high CPU loads.

This could create HUGE problems in keeping your machine in sync.

That said it may be possible to do it all in gcode with the striching being controlled with a stepper/servo motor that drives the head up and down through a mechanical motion conversion, rotary to osilating linear. Tha way it is posible to sync all moves to the position of the head.

BUT it will be a very very hard thing to GCODE as the head moves will be required to be broken down so xy can only move in specific periods and even then I am not sure they can be ran very fast as the speed b be controlled by the slowest axis and the more MICRO moves it has it the Z axis the slower the processing becomes.

For what you need you may want to consider a realtime motion controller board that can run at extremely high sample rates .

Hope that helps

6736

VB and the development of wizards / Re: start from line #

« on: June 03, 2010, 11:18:23 PM »

Amir look in the MACH Macro Programmers Manual, Page 57. That will tell you what you need to know.

6737

VB and the development of wizards / Re: start from line #

« on: June 03, 2010, 08:55:04 PM »

:-) LOL  HIYA Ian, we spend a LOT of time with new code proofing it to run correctly , but with plasma you never know when the torch will cough or sneeze and put the fire OUT. Then you have to stop and verify the torch and restart where you left off.

That was why we developed the stop/restart routine a time saver.

6738

VB and the development of wizards / Re: start from line #

« on: June 02, 2010, 07:16:33 PM »

IAN, Run from here does not work with plasma or jet cutting WITH a Top of material routine. The G28.1 or G31 throws a monkey wrench into the mix.

Also you must restart and stop the torch at each cut point.

I gave Amir a solution that we use here ,(Stop and restart as an auto function ran by screen buttons or hotkeys) actually gave him 2 solutions but they don't seems to work on his end  for some reason.

http://www.machsupport.com/forum/index.php/topic,14927.50.html

6739

General Mach Discussion / Re: RUN REVERSE, Serious problem

« on: June 02, 2010, 07:01:30 PM »

(;-) That was why we had the OTHER version as one did not have to deal with the restat window, But is does not seem to work on your end.

Right now I don't have any other suggestions other than working with the old version and see what it takes to make it work on your end.

(;-)

6740

General Mach Discussion / Re: Display Spindle Temperature on Mach3 ??

« on: June 02, 2010, 10:26:28 AM »

it would be best to set up the timer in a brain to set an led. Sometimes trying to do a timer loop in the macropump causes problems with CPU hogging.

Set the brain to set an LED /on. Then when the macropump sees the LED/ON then do" code whatever" AND set the LED to OFF.

Just a thought