Hello Guest it is May 04, 2024, 07:47:55 AM

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

151
General Mach Discussion / Re: ATC code help
« on: February 27, 2016, 11:33:32 AM »
You old charmer - what do you want?  ;D

Dang - you went and edited whilst I posted...

Dang - you just dd it again...

152
General Mach Discussion / Re: ATC code help
« on: February 27, 2016, 08:29:59 AM »
OK - so you need to understand something about macros.

They run in a totally separate thread from Mach proper. i.e. they run CONCURRENTLY.

So when you issue (say)

Code "G53 G0 X40"  'Move to clear the tool holders

The macro is saying to Mach - please insert this into your execution queue.

Mach will do as it's asked but here's the thing. Mach will EXECUTE that line of code in it's own good time.

Meanwhile, the macro will move onto the next line and say to Mach - please insert this into your execution queue.

Again, Mach will do this BUT it's probably (most likely) still actually executing the first line.

What you're doing is asking Mach to queue all four lines and then immediately activating output 4.

HOWEVER, Mach is probaby STILL just actually executing the first gcode line.

So you end up activating your draw bar WELL before you should.

So when you ask Mach to queue requests (in this case for movement), you MUST then WAIT until Mach has finished before you carry on. This is called thread synchronisation. The method Mach provides us to do this is the isMoving() function.

So what you need is:

Code: [Select]
Code "G53 G0 X40"       'Move to clear the tool holders
Code "G53 G0 Y61.61"   
Code "G53 G0 X6.83"     'Move to directly above the tool position
Code "G53 G1 Z-30 F500" 'Move to a safe height just above the tool
while isMoving()        'wait for Mach to do everything in the queue
wend
ActivateSignal(OutPut4) 'THEN - Open the drawbar

153
Why not use current sinking then any BOB should do. Just go from the UC300 to one BOB and then from each BOB output to each pair of drivers.

As far as squaring is concerned - you could just drive the axes against the end stops for a moment.

154
General Mach Discussion / Re: ATC code help
« on: February 27, 2016, 07:51:33 AM »
In the context of what you're doing here - yes. So don't you want to wait for something to stop before you open the drawbar?

155
General Mach Discussion / Re: ATC code help
« on: February 27, 2016, 07:38:55 AM »
do you know what the while isMoving() statement does?

156
General Mach Discussion / Re: Mach 3 PWM signal inverted?
« on: February 27, 2016, 05:15:20 AM »
 :-X

<a href="http://www.youtube.com/v/VmW-ScmGRMA?hl=en_US&amp;amp;version=3" target="_blank" rel="noopener noreferrer" class="bbc_link bbc_flash_disabled new_win">http://www.youtube.com/v/VmW-ScmGRMA?hl=en_US&amp;amp;version=3</a>

157
General Mach Discussion / Re: Tangential Control
« on: February 26, 2016, 03:59:53 AM »
Hi Terry - Well it does here. T'would be nice to hear from the OP to know if it works for him  ;)


158
General Mach Discussion / Re: Mach 3 PWM signal inverted?
« on: February 25, 2016, 12:15:41 PM »
You have a max pulley of 30000. Let's say you're set active HIGH.

If you command S30000 then you're asking for 100% duty cycle. You can't have a 100% duty cycle PWM - it would be permanently high and therefore wouldn't be PWM anymore. What you get is what you see in scrnsht1.jpg. i.e. you're getting as near as 100% i.e. 99.3996% HIGH.

When you command S5000 you're commanding 30000/5000 i.e. 1/6th speed. 1/6th is 16.666%. See attached scrnsht2.jpg. Bang on.

Flip it to active low and you get the exact opposite i.e. 99.3996% LOW and 16.666% LOW. Again Bang on.

159
General Mach Discussion / Re: Mach 3 PWM signal inverted?
« on: February 25, 2016, 10:45:10 AM »
Joelaw1 is my mach3 file and joelaw2 is my router xml.

Not sure what you're meaning there - which is the xml you're using?

Anyway - I tried your Joelaw1.xml and it works just fine here. I get positive going correct duty cycles and when I tick step low I get negative going duty cycles.

160
I know this thread is about the SS but it does raise an interesting point about PP users upping their kernel rate beyond that which is strictly needed for velocity.

A 60KHz kernel will certainly empty the existing buffer faster than a 25KHz kernel, so feedholds WILL be quicker. We're talking speeding up the buffer unload from a max of 819ms to a max of 341ms. Is it worth it? Well I suppose if your machine can handle higher kernel speeds then why not? Then again if your (lower than ideal) accel is what's really slowing down feedhold then probably not.