Hello Guest it is April 20, 2024, 06:53:46 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

161
General Mach Discussion / Re: Mach 3 PWM signal inverted?
« on: February 25, 2016, 09:29:46 AM »
please post your xml file (usually C:\Mach3\Mach3Mill.xml unless you're using a different profile) copy it, rename it to joelaw.xml and use reply/additional options (not quick reply).

162
Sorry - flush was perhaps the wrong term. The buffer isn't so much flushing as emptying.

As your motion is going along, Mach is constantly checking for space in the buffer and constantly adding more of its planned motion. When you feedhold it stops adding motion from the planner and instead adds the decel motion. So whatever motion was in the buffer MUST be allowed to finish and then the decel ramp finishes the job. Does that make sense?

Contrast that with a limit or e-stop where motion ceases immediately and the currently buffered motion IS flushed or dumped.

163
mostly for hobby use and also to maybe make a few bucks in spair time.

Just highlighting this - your title might be misleading perhaps.

164
To calculate the TOTAL time from feedhold to stopped motion - don't forget to add in the deceleration ramp. If you have poor accel then this can be significant compared to buffer flush time.

165
G-Code, CAD, and CAM discussions / Re: The Arc Command
« on: February 25, 2016, 04:09:15 AM »
LOL - I don't mind admitting you had me convinced it was a bug and now you have me convinced it isn't.

166
General Mach Discussion / Re: Tangential Control
« on: February 24, 2016, 11:59:45 AM »
try this and let me know how it goes

Code: [Select]
G00 G49 G40.1 G17 G80 G50 G90
G20
G17
(2 1/2 Axis Profiling)
G00 Z0.0000
G00 X-1.2292 Y-0.3717
G01 Z-0.3000 f100
G4 p0
G02 X-0.1397 Y-0.5086 I0.5129 J-0.3220 f100
G02 X-0.4167 Y-1.4766 I-0.7741 J-0.3020
G02 X-0.7216 Y-1.7075 I-5.2693 J6.6393
G03 X-1.2241 Y-2.2658 I1.2598 J-1.6394
G4 p0
G00 Z0.0000
G00 X-1.2586 Y-2.2238
G01 Z-0.3000 f100
G4 p0
G03 X-2.0651 Y-1.4633 I-2.4982 J-1.8414 f100
G02 X-1.9607 Y-0.1278 I0.4639 J0.6355
G02 X-1.1878 Y-0.4262 I0.2264 J-0.5639
G4 p0
G00 Z0.0000
G00 A0
G00 X0 Y0
M30
%


167
G-Code, CAD, and CAM discussions / Re: The Arc Command
« on: February 23, 2016, 01:41:35 PM »
Quote from: Tweakie.CNC link=topic=32004.msg222712#msg222712
They are both used in LinuxCNC as well.

Again - happy to be corrected but I think I'm right in saying that Mach3 and LinuxCNC share some of the same code base (particularly I think - the interpreter) so that's probably why.

I'm also still confused about the difference between G90 and G91.1. It appears they do different things so are not in conflict. G90 is for axis movement. G91.1 is for IJK movement.

This is what I was trying to get at in Reply #6. I think it's just a Mach3 (and possibly LinuxCNC) cockup. i.e. they've ended up in the same modal group but they shouldn't be.

Gerry's mention that they are NOT in the same group in Mach4 would tend to back this up.

168
G-Code, CAD, and CAM discussions / Re: The Arc Command
« on: February 23, 2016, 11:30:22 AM »
Nice one Rick - never knew that.

Hmmmm - that G90 G91.1 thing is a bit of a doozy. Functionally there's NO reason for them to be in the same modal group (at least as far as I can see but happy to be corrected by the gcode gurus).

I'm wondering if they've ended up in the same group for no other reason than they share major numbers.

BTW - Am I right in thinking 90.1 and 91.1 are a purely Mach3 thing?

169
General Mach Discussion / Re: THC Problem
« on: February 23, 2016, 06:11:19 AM »
in the diag tab I can see the inputs for thc up/down working but the Z never changes.  There has to be a connection I'm missing, I dont understand what the motion control board has to do with the thc not working.  The software see's the inputs just fine all it has to do is change the Z.

PCs running Windows are NOT real time systems. CNC machines ARE real-time. For PCs to control CNC machines, they need something else to do the real-time things on their behalf.

One such thing is an external BUFFERED controller.

One other such thing is a kernel level BUFFERED driver that can actually give itself higher priority than Windows itself and can thus implement a passable version of real-time.

In older versions of Windows this was possible. In later versions the "holes and hooks" that allowed this have been closed - period. Address all complaints to:

Microsoft Corporation
1 Microsoft Way
Redmond


Soooooooo... you're using the external controller option:

1) Your THC hardware activates (say) TorchUP.

2) Your motion controller "sees" that signal

3) Your motion controller **** To Do ****

4) Your motion controller sends a packet of info via USB to Mach3 (which includes the fact that TorchUP is activated).
(remember that although USB is fast in communication - yes - even faster than a parallel port - unlike a parallel port, it will only send this message when IT is good and ready - if this doesn't make sense to you - read up on USB. In a nutshell though, it's all very well for me to be able to send you a message at the speed of light - but if I choose to wait a while before I send it - then your going to get it "in a while" - regardless of how fast the comms medium is.

5) Every 1/10th of a second Mach3 reads any packets of info pending and updates the GUI so a human being can see what's going on.

So...

What do you reckon goes in the ToDo?
Does YOUR controller do this?
If it doesn't, is that a Mach3 shortcoming or your controller's?

170
General Mach Discussion / Re: Tangential Control
« on: February 23, 2016, 04:36:58 AM »
can you post some example code of where the issue is happening?