Messages

251

CVI MachStdMill (MSM) / Re: Tool Change

« on: August 15, 2010, 12:54:55 PM »

Can you send me your M6ATC script to look at?

Here is one idea:
Does your script do G01 or G00 moves?
If you don't specify the movement type, a movement will use whatever the movement mode is when M6 is called.....
perhaps you are getting Feed rate moves when you expected rapid rate moves?

Dave

252

CVI MachStdMill (MSM) / Re: Tool Change

« on: August 15, 2010, 12:38:40 PM »

Hi Alan,
thanks - it's nice to hear that things are generally working well for you.

I'll need some more information to be able help.
How did you interface the tool changer?
is it controlled by hardware or software or a combination thereof?

Did you use the M6ATC hook to get tool changer code called during the M6 sequence?

Dave

253

CVI MachStdMill (MSM) / Re: Returning to start of code after tool change!

« on: August 15, 2010, 12:10:22 PM »

Calum,

let's try to narrow down to see what the problem depend on.

1) having more than one axis move when a G31 is issued to mach sounds to me like a bug that Brian has been looking for for a long time.  When I experienced that once, it seemed to be a corrupted XML file. I found that creating a fresh XML made the problem go away.
Before you do that, I would like to see if we can get some information about the bug....
Please save a copy of the XML in use when you saw multiple axis movement.
If you can make the multiple axis movement happen again, when it does, stop mach and close mach.
Then find ProbeDiag.txt in the mach dir and  please email the XML, ProbeDiag and as detailed a description as you can as to what you saw happen.


If the multi axis movement is no longer happening, and the rewind problem is still reproducible -

2) Lets try to determine if the rewind is a function of one of the MSM options:
We'll use my little test case code for this -
turn off AutoTCP and MTM and AutoTLO
run the test code - is it rewinding now?

If not, add back the options one at a time, checking each option:
AutoTCP: causes rewind?
MTM: causes rewind?
AutoTCP + MTM: causes rewind?
AutoTCP + MTM + AutoTLO: causes rewind?

Dave

254

CVI MachStdMill (MSM) / Re: Returning to start of code after tool change!

« on: August 15, 2010, 01:20:34 AM »

Calum,
Is it really rewinding or is it stopping on the tool change?

I can't run your code fragment with MTM and ATLO at the moment as I have the mill down for a mod and I need the TCP TP to play ATLO games.
But I tried it with just ATCP (No MTM & No ATLO) - and I'm seeing this happen:

start the code - goes to line N2
mach executes the M6,
mach calls M6start, the M6start code is run (M6start is what swaps us to the tooling page).
The machine gets to the TCP, I press the cycle start buton on the tooling page
mach sees the button action and calls M6end.
M6end finishes and we are at the run page (which is where I was when before the TC) -

At this point the code should be running again - but it is not.
Instead what I see is that the code is has not been restarted by mach - it is just sitting on the N2 line.

An "Extra" click of the cycle start button on the run page, will get the code to continue....

here is another test case I used that shows the problem to me:
G90 G00 x0 y0 z0
x1 y1 z-1
t1 m6
g43 h1
x2 y2
t2 m6
g43 h2
x3 y3

Mach fails to restart the code after each tool change.
So, I'm not seeing a rewind, but I am seeing a "it did not continue running from the TC" problem.

This particular Mach problem has been "fixed" multiple times in the last couple of months- yet here it is again.
I suspect that whatever was done in 3.43.16 to stop MDI from causing a cycle start, has reintroduced this bug.

I'm not yet sure if there is only 1 problem here or two - so I need to confirm if you are seeing the same problem I am, or are you really seeing it rewind?

If it's really rewinding, the gcode window's highlighted line (for your code) will be on N1 in and not N2 after the tool change.

Dave

255

General Mach Discussion / Re: Windows 7 64 bit advise needed

« on: August 15, 2010, 12:13:55 AM »

Greg,
I've not tried what you are doing on Win64 so I'll not be of much direct help.
I think that the script editor is a customized version of one of the sample editors that come with the Cypress package.
IIRC Cypress supplied a couple of different sample editors for use with the package.

If you go here
http://www.cypressinc.com/techsupp.htm
you can DL demo.zip - inside are Edit42.zip, sdkSded.zip, MFCSdiEd.zip and vbEnEdit.zip - which I think are the sample editor sources.
I don't remember if the exe files are included or if you'd have to compile the sources.
I'm thinking you could try the sample editors to determine if it is the base code or the mach extensions that are the issue.

Btw, I'm curious, are you running Mach as a 32bit app directly under win64, or are you having to run it in an XP compatibility box (which uses a CPU mode that not all CPU models have)?

Dave

256

CVI MachStdMill (MSM) / Re: How to get started with MSM Probing

« on: August 14, 2010, 11:59:18 PM »

Welcome to the wonderful world of herding electrons - I'll skip the EE discussion and keep things empirical.

The cap is acting in conjunction with a resister in the BoB to create a simple filter circuit.
The higher the cap value, the larger the amount of filtering added.

Adding the cap is an electronic way of doing what the mach software de-bounce setting is doing.
So the effects from adding the cap and the debouce setting will be additive  - and this matches what you are seeing - with the cap you need less software filtering.

If you are curious to learn more, you can google "RC time constant".
Here is reasonable tutorial I spotted from the google results:
http://www.electronics-tutorials.ws/rc/rc_1.html

Dave

257

CVI MachStdMill (MSM) / Re: How to get started with MSM Probing

« on: August 14, 2010, 03:12:29 PM »

FYI -
I separated this thread from the "how to get started with MSM probing" thread so that people looking at the "how to" thread would not need to read this particular discussion thinking it was part of the "how to" info.

Dave

258

CVI MachStdMill (MSM) / Re: How to get started with MSM Probing

« on: August 14, 2010, 03:07:35 PM »

FYI - If you initiate a probing operation (any G31 command, not just a MSM probing operation) on a PC that is running mach in Sim mode (I.e. there is no motion driver layer present), you will see the DROs run until the end of time in the direction you issued the G31 for.

This is because mach can't do G31 with out a motion layer present...

Mach starts the G31 motion and then waits to be notified that either the motion reached the target coordinate or that the probe triggered. Since the motion layer is not present, mach just keeps waiting for an event that never happens.

Dave

259

CVI MachStdMill (MSM) / Re: How to get started with MSM Probing

« on: August 14, 2010, 01:14:25 PM »

be a bit wary of slow probe freed rates -
at low FR the probe is moving so slow that there is little speed or momentum - that can cause worse switch bounce problems than if the probe is moving faster.
If I keep my probe above 5 ipm it's happy - below 5, I tend to get enough switch bounce that I get false trigger pulses.
I've had other people tell me they experiences similar problems  - so slower is not always better in this game.

Dave

260

CVI MachStdMill (MSM) / Re: How to get started with MSM Probing

« on: August 14, 2010, 11:30:25 AM »

Some MSM manual references:
Edge width: 7.1.3.3.5 & 7.1.5.11 & 7.1.6
Calibration diameter: 7.1.3.1.2 & 7.1.4.10

I just added the following info to the How to post:

[Info added 8-14-2010]
The basic mach probing sequence:
    1)   G31 starts, mach starts moving machine
    2)   Probe input triggers; mach records the position of the probe when it was triggered
    3)   Mach decelerates the probe and movement stops. Note that the stopping position is not the trigger position. The difference is “overrun”.  A bit of Overrun is expected and good – as it keeps the probe in the triggered state.
    4)   Mach returns from internal G31 execution to program that issued the G31 (for the MSM probing operations, this will be a return to the code in the MSM probing library)
    5)   Script looks at probe signal –
        a.   If probe is not active, we ran out of distance w/o triggering the probe
        b.   If probe is active, we found something and were triggered.
    6)   Probing Lib gets the trigger position and does what it needs (For example sets axis zero to the face we found).
    7)   Library backs off by the overrun amount (this lets the probe become un-triggered)
    08)   Library back off the user defined clearance amount.

Noise on the probe input line will make this sequence not work correctly –

Example: A short noise pulse at step 2 can stop the G31 motion; but at step 5 if probe will not be in the triggered state when checked. MSM thinks nothing was found and so puts the probe back to the starting position.

Adding some Debounce may help:

Mach's debounce is really a software fix for a hardware problem.
The ideal solution is to remove the noise from the system and use a debounce of 0.
Many people either can't or don't want to expend the effort required to accomplish that.
The pragmatic approach is to lower the debug number until the problem appears, then raise it back up a little.
That leaves the issue of "How do I tell if my required debounce setting is too high"?

"Debouce" is the amount of time a signal must be continually "on" before mach will consider it as just having turned on.
Each number in the debounce DRO represents about 40usec of time (25kHz Mach: 1/25KHz = 40uSec)
A debounce of  40uSec* 4000 = 160mSec. That is a long time for a computer, it's even pretty noticeable to a human.

At 4000, the probe signal has to be on for a minimum of 160ms before mach will see it and stop the probe motion.

How fast are you probing?  Let's just pick a number for illustration:
Say you are probing at 50ipm; during the debounce interval the probe will have moved (50ipm * 160msec ) / 60 sec/min = 0.133 inches....
So the probe will travel 0.133 in past where the edge is before mach will think the probe is triggered - and then it has to decelerate and stop.....
Consider - how much tip travel does the probe have? 0.133 inches over travel could be hard on the probe -  depends on the probe design.

Same scenario with 200 debounce: 50ipm * (200*40usec) / 60 sec/min = 0.0067 inch over travel

Personally, I prefer to see a debounce of no more than a few hundred. but the real answer is whatever combination works that makes the machine run reliably.

Play with the numbers and decide what you are comfortable with.
[end added info 8-14-2010]

Dave