Messages

1831

General Mach Discussion / Re: How to wire steppers???

« on: April 03, 2008, 08:34:22 AM »

Hi Jim

I am running 1/8 step, 1.8 degree, 3 to 1 reduction, 1/10" leadscrew which, I think gives me 48,000 pulses per inch and therefore 192,000 pulses per minute for travel.

Absolutely right - or - to put it another way a theoretical resolution per pulse of 0.00002 of an inch. Or more correctly taking out the microstep factor of 8, a theoretical resolution of 0.00016 of an inch. (microsteps should not be included in resolution calculations because they can't be relied upon to be equal in size)

So the first question is - do you require this theoretical resolution? The route from here on in is dependant on that answer. But for the time being let's just look at the status quo.

As you say, at 4 in/min you have a pulse rate of 192,000 ppm or 3200Hz. Clearly Mach/parallel port/USB etc. is not of issue here so let's look at your drivers and motors. Motors first.

The motors are Arc Euro Trade Hybrid Steppers - 220Ncm, 2.5amp 7.5volt - and all in all I am satisfied with them - they are certainly powerful enough to do the job and at £22.95 each are relatively cheap.

They are 8 wire motors - and I have wired them in series.

We need to be clear here exactly how you have them wired and exactly what each coils resistance is.

If indeed you have them wired in series and the 2.5Amps you quote is per coil then you may well be halfing your potentially useful current. But we need to be sure we're both on the same page here if we don't want to damage your drivers.

You need to get your multi-meter out and measure the resistance of 1 of the 4 coils. If you do that and get back we can continue.

Cheers

Ian

1832

General Mach Discussion / Re: Visualmill post proc. for Mach 3

« on: April 03, 2008, 05:20:47 AM »

Hi Bruce

Yes I remember this now - I'm not sure why Mach has a problem with G43 - afterall it's in the gcode list that Mach reckons it supports. It doesn't matter of course because by using CAM your toollength offsets are already taken into consideration.

Anyway here's the way I got rid of this particular problem with mine.

If you run the post editor, the problem is that it can be difficult to find where (under which tab) any particular gcode actually is, well it is for me anyway! so...

Go to your VM instalation folder (presumably under "c:\program files" or similar.
Look for the "posts" folder.
Find Mach3.spm or more likely the Mach2.spm and load it into wordpad or notepad.
Do a find for G43 - you'll find it first under the MISCELLANEOUS DEFINITION SECTION - ignore this.
Continue the find and you'll see it in the TOOLCHANGE DEFINITION SECTION - You can either edit it out there and then, or probably safer go back to the post editor and take the line out there (you now know to look under the ToolChange Tab for G43)
Save your post as Mach3 (or whatever) and away you go.

Personally I find it easier just to edit the .spm file but until you're comfortable with the layout you're probably better off doing it in the editor as no doubt corruption of the file will screw things up right royally.

Hope this helps

Ian

1833

VB and the development of wizards / Re: mach vs VB sleep call problem?

« on: April 02, 2008, 11:38:15 AM »

Hi Stirling,

Thanks for your input, but there was definitely an increase in processor usage without the sleep commands.

Processor usage w/o sleep commands is at a constant 62%.... after adding the sleep commands processor usage is below 5%.

Thanks,

JJ

Hi JJ - Sorry - I havn't made my point very well. Obviously with a call to sleep you're going to see CPU usage falling but my point is - is that useful? and what are the downsides overall?

Let me try it another way. IF the CPU was whiting out then the possibility would exist that the Mach thread was being starved of CPU. In this case it may be useful to reduce the CPU being used by the VB thread. But from what you've said - this isn't the case - you're only at 62%. So the downside of slowing down the VB thread's reaction to the semaphore is somewhat pointless IMHO. By way of example:

code "G1 X100 Y100"
while isMoving()
  sleep(100)
wend
code "G1 X0 Y0"

On average there is going to be a delay of 50ms between the first move finishing and the second move starting - for what? Without the delay you have a CPU that's spending 38% of its time idle anyway. I don't know what the loop cycle is without any explicit delay but clearly its going to be shorter without it - 100ms shorter.

As I say - just my opinion but to my no doubt crazy brain - it seems to make sense to me 

1834

General Mach Discussion / Re: Visualmill post proc. for Mach 3

« on: April 02, 2008, 08:51:31 AM »

Hi Bruce - you might want to post a link to where on the site the post is. But anyway - if there's a problem with it you should be able to correct it using the post generator/editor within VM.

I use RhinoCAM which is basically VM as a plugin for Rhino - I had to make a few alterations to the Mach2 post that came with it to suit my use of Mach3 - but seems to do the trick so far.

1835

VB and the development of wizards / Re: running batch files in VB

« on: April 02, 2008, 05:37:32 AM »

If you can operate your S70 from DOS, then yes you can do this the way you've siggested. However I have an S50 and although I know how to remotely operate it from the windoze app supplied with the camera, I wasn't aware that you could do it from DOS. Tips would be appreciated. It's a shame that a windoze API isn't shipped with these things!

1836

VB and the development of wizards / Re: mach vs VB sleep call problem?

« on: April 02, 2008, 05:29:46 AM »

From my experience of writing multi-threaded applications, the while isMoving() construct is polling a semaphore in the Mach thread. By sleeping for 100ms you're simply slowing down the VB thread's response to the change of that semaphore.

Without it, the test by isMoving() will pick up the change of the semaphore as quickly as the VB thread possibly can. But with it, on average the change in semaphore will be picked up 50ms later than it could otherwise have been.

Personally I'd think that this will actually waste more resources than it could possibly save.

Just my opinion.

1837

General Mach Discussion / Re: Lubrication of belts and racks

« on: April 01, 2008, 12:39:31 PM »

  - speaking of which - I wonder if there's any petroleum based plastic or particularly latex in the belts - given .... erm... certain erm.... things.... shouldn't be used together... maybe not a topic for this forum.

Oh just google latex vaseline 

1838

General Mach Discussion / Re: Mach 3 Pulse Rates per axis

« on: April 01, 2008, 12:12:42 PM »

do they make a descending growling sound and subsequently stall?
you say above 8000Hz, how much above that have you tried?
what speed are they doing at 8000Hz in terms of rpm?
what drives are you using?
what is the rated voltage and current (or phase resistance) of your motors?
what is the Vdc and amperage of your power supply?

1839

General Mach Discussion / Re: Z not working well

« on: April 01, 2008, 11:09:42 AM »

When I loaded this, Mach complained and was generally an unhappy little motion controller. I corrected the following before I could run it.

1) You can't have zero spindle speed
2) You can't have zero feedrate
3) use some spaces here and there (they're free  ) - particularly before an an axis word (X Y and Z)

It then ran fine - Z stopped on 1.5

However it may be worth reading my posts at http://www.machsupport.com/forum/index.php/topic,6339.0.html

Ian

1840

VB and the development of wizards / Re: Tool changer routine with hot swap

« on: March 31, 2008, 08:11:39 AM »

Hi Terry - Have you got the actual tool changer mechanics built yet? if not, would it be poss for you to do that?

I will get back to you asap but at the moment I'm pretty tied up time wise.

Cheers

Ian