Hello Guest it is March 28, 2024, 10:26:19 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 - stirling

1511
General Mach Discussion / Re: twinned motors; 2 sharing 1 driver
« on: August 17, 2010, 06:34:46 AM »
There's some stuff on cnczone by Marris and others about this but I can't find it at the moment. I seem to remember though that it went something like this: Stepper motors don't play well together off one driver. If you keep speed down to no more than two revs/sec then it'll probably be ok. Otherwise oscillation will occur and one motor is likely to draw all the current and the other will stall.

Now Marris has no doubt forgotten more about stepper systems than I'll ever know, BUT - as I've said above I've done this on several of my systems and never had a problem and that was with the motors doing up to about 10 revs/sec. Maybe geckos are even better than Marris thinks!

Personally I can't think of any reason why your drivers should be at risk but it's ultimately your choice.

2 drivers off of 1 signal is a much better solution than 2 motors off of 1 driver.
Well as I've tried to say - that depends. Are you for example suggesting that I should buy a fourth driver at over $100 a time for each of my systems that work perfectly well with three?

Cheers

Ian

1513
General Mach Discussion / Re: twinned motors; 2 sharing 1 driver
« on: August 14, 2010, 05:12:04 AM »
This is generally not recommended - however, I've built several machines driving two steppers from one driver and it's worked very successfully. There are many factors which can make it a bad idea BUT generally speaking - success is inversely proportional to motor speed if that helps.

1514
General Mach Discussion / Re: Mach Plugin problems
« on: August 14, 2010, 05:00:03 AM »
AFAIK this is still the case. Other probing routines are available though.

1515
Although I use sheetcam - I'm no expert and am still working my way through understanding it's details. That said basically a POST (post processor) deals with the machine specific part of the code generation process. Anoyingly, AFAIK sheetcam doesn't document the purposes, differences or subtleties of each different post. So we're kind of on our own I think when it comes to choosing one that best suits our purposes. Maybe someone else can help you better with this or of course go onto the sheetcam forum and ask - Les et al are very helpful. I chose the THC300 (because I currently use a THC300 THC) one and modified it till it did exactly what I needed.

Second issue sounds like you're using short line segments for arcs, which with exact stop mode will do a pretty good job of getting your machine to sound like a machine gun on heat! My thoughts would be that for plasma you're going to HAVE to get CV working best you can within the accel capabilities of your machine. Exact stop mode with plasma is going to be grief IMHO.

1516
I am assuming a Torch Height Controller is necessary to get the initial spark started.
No (because of your next statement). You just need to arrange your torch to be at "pierce height" above the work and fire the torch.

My plasma cutter has a pilot arc starter so I could ignite without touching the cutting surface.
there you go - that's why you can do the above

My torch has a detachable guide to keep the nozzle a consistent distance from the cutting surface. Couldn't I just build a holder for my torch and set my z axis to the required height and just leave it there?
You could indeed.

Do I still need a THC?
Depends on how good a cut you want and how often you're happy to renew your consumables and how long before you get fed up of the "drag tip" moving the metal and ruining your part

A THC will give you FAAAAAAR superior cut quality, save you lots of cash in consumables and allways keep your torch off the work and at the correct cutting height as it travels over the warped metal. Warped as in to start with and as the heat affects it. BUT for THC to work you also need IHS - see below.

How do I get Mach3 to pause for ignition before moving the x and y axis'?
write a gcode cut prolog. OR use a CAM (I like Sheetcam) to generate your gcode and you're done. It's not just pause for ignition. It's move to pierce height, fire torch, make sure arc is good, pause for pierce, lower to cut height, commence XY. The question is: where is pierce height? for this you need Initial Height Sensing (IHS). This is often done with a floating head and switch arrangement.

And the last part of my question which I don't think is a function of Mach3. Say I was cutting a 3" circle in thin steel stock. It only seems logical to me that the cutter not ignite on the perimeter of the circle but rather somewhere inside or outside of the circle to provide a really smooth cut transition. Could somebody tell me if this is an accurate statement and what this type of manipulation is called? Is it some type of offset? How do I implement it in say CamBam etc?
Correct - it's called leadin (there's also leadout) again it's a function of CAM.

Ian

1517
Why use the Arduino for THC if Mach already has it?
Mach has THC software but you still need THC hardware to interface between Mach and the plasma cutter. A bit like Mach puts out step signals and reads input signals but you still need drivers for your motors and switches for your limits if that's not too crap an analogy. For example - if you *were* to use Mach's THC control of Z then it would "think" your pump sensor was the THC hardware sending a torch down request.

Ian

1518
I think Mach's THC functions would do what you want but if you already have an arduino that may be the way to go. Also I don't know if your ncpod supports THC - I think for example the smoothstepper doesn't - whether that's of any relevance I don't know. I'm just thinking that by using the eeno you'd have complete programable control over the pump and be able to let Mach get on with the X Y interpolation which is what it does best.

FWIW - co-incidentally I'm currently working on an eeno based THC for Mach.

Ian

1519
If I understand correctly - you want the Z to be driven at some fixed rate under the control of your logic signal and independantly of the "commanded" axes.

A possible way of doing this is to use Mach's THC. If your logic signal is wired to THC down (say) then as long as your signal is active Z will move down and will stop when your signal goes inactive - completely independantly of X and Y motion.

You will of course need to modify your screen set to include the THC control.

Ian

1520
General Mach Discussion / Re: Slave Axis Homing
« on: July 06, 2010, 12:17:51 PM »
As you've said, when the Y homes, both the Y AND the A move BUT only the Y is "homed". To "square" the axis the A then homes and should have a switch of it's own. Alternatively, if you don't want that feature, just take out the line that homes A (doButton(25)) from the RefAllButton.