Messages

1

General Mach Discussion / Re: ( COMMENT ) causes stall on rapid moves?

« on: August 16, 2010, 09:33:18 PM »

Not to worry Hood - there's only so many problems you can look into for other people.

The thread dragged Alastair out of the woodwork to post a fix, and I'm on my way.
Hopefully anyone else out there experiencing the same problem will stumble on this thread too.

2

General Mach Discussion / Re: ( COMMENT ) causes stall on rapid moves?

« on: August 16, 2010, 01:30:42 AM »

Thanks Alastair,
How on earth did you think to turn off sounds as a possible fix for this one?
We've never had any speakers plugged into our mill machine, so I generally forget about that beep.
I can confirm that turning off all the sounds under windows changes the behaviour - the offending programs run smoothly!

The operating system must be prioritising the comms to the sound card over the parallel port, or otherwise just slowing things down and messing up the stepper movement.

Hood,
I've attached the threading program and a trimmed version of the parting out program for you to look at. (The rest of the program is really just repeats of the pocket, with some side milling in the 4 corners)
The threading program stalls on traverses between subroutines.
The parting program stalls on the rapid before the plunge to Z-25 on the first side-milling path - Line 116

If you can observe the same behaviour it might be good to get a note somewhere to turn off sounds in windows.

Very pleased to have this worked-around/solved.
Cheers.
 - Ian

3

General Mach Discussion / ( COMMENT ) causes stall on rapid moves?

« on: August 13, 2010, 04:07:21 AM »

I've been having issues with losing steps on rapid moves in my programs.  This appears on all axes, and seems to be highly repeatable re-running the offending programs.

Previously this has happened on plunges in Z at the beginning of a program, stepping through the code in single block mode works fine, and this was enough to get me going and move on.

I had a thread milling program this week that calls a sub-routine which was stalling on every traverse in X, so it forced me to spend some more time looking into the issue.

I know that it is not the slides binding.  I can run a program with a different Z offset and see identical behaviour.  Manual jogging rapids and single block rapids both work fine.
This has to be something to do with how Mach3 processes code.

I tried all kinds of things with the subroutine to try and find the source of the bug, thinking this is something to do with my code, or the complexity of interpolating the helical moves as it reads ahead.
Eventually I stepped through the entire thread milling program just to get the part off the machine.

Today I've finally got to running a program that mills away webbing between parts in a billet.  I had this stall in Z issue meaning my webs were left intact and rerunning the program gave me the same results.
This prompted me to look more at the read-ahead settings.

Conspicuously, the "( MILLING POCKET )" comment/message that TurboCADCAM puts in the code was 19 lines ahead of the rapid move which stalled.  Changing the read-ahead settings to 10 lines gave me a stall in Z at a different level (convenient coincidence that my cutting passes were 9 lines long and there was a rapid move in Z).
So far, I've not observed this behaviour where a feed-rate move is at the appropriate position in the code, but a global replace of '(' with '%(' to make the headings real comments appears to have fixed the issue.

Does anyone have any experience with this kind of thing or anything else to add on the topic of comments/messages in code, and how Mach3 (doesn't) handle them?

I can post some example code or provide more information next week if anyone would like to look into replicating the behaviour themselves.

It's been a long week, far too many nonsense errors.  The weekend came just in time!

Thanks,
 - Ian.

4

General Mach Discussion / Possible Soft Limit Bug

« on: May 10, 2010, 09:44:47 PM »

I found an issue with Soft Limits in Mach3 Mill, I'm posting here to let Artsoft know about the behaviour I have seen.  No great urgency in addressing it, since I'm aware of it now, and no one else seems to be speaking up about having the same issues.

Following text is cross posted from my post at CNCZone: http://www.cnczone.com/forums/showthread.php?t=104676

===
I've come across what I suspect to be a bug in Mach3, but would really like to get some other people to try it out or let me know if I'm doing something wrong.

When I program a move on the MDI screen that has a target outside the soft limits, the machine drives to the soft limit and stops, then program a move away from that position, the motor stalls - it may or may not break free and move again by itself, steps have obviously been lost though.

In contrast, if I hold shift to override the jog setting and drive the table against the soft limit, and back off again, all is fine.
It all seems so bizzare that the behaviour is different. I can't imagine any physical difference between a manual jog rapid against the soft limit and a programmed rapid against the soft limit.

I've observed this on my Y axis, and haven't looked at X.
We have our soft limits set very close to the physical end stops, so we spent a bit of time loosening off the gib screws and concerned about it actually hitting the hard stops and binding there.

I have tried setting the soft limit on the other end of the Y axis well inside the normal setting. And seen the same behaviour.

Our mill is a Syil X4 Standard.
Really only been running it since February this year.
I haven't looked at changing the motor settings yet, and I'd prefer not to at this stage, since it's previously been okay with the defaults from Syil. I don't think we've had a program that has ever tried to drive outside the Y travel limits.

Running Mach3 Ver 3.42.029
I don't see anything like this listed in the change log since.

If anyone can have a look and replicate the behaviour, or otherwise have some feedback for me, that would be great.

- Ian.

===
 Obviously, intentionally driving the machine against soft or hard stops is 'doing something wrong', so I've stopped doing that for now.

I've observed the same stall behaviour on the X axis, with soft limits set inside what they usually are.

I'm going to leave Z well alone.

Though I haven't checked with a loaded program, just running commands on the MDI.

So long as we don't create any programs that are too large, or setups too offset, and take note of the soft limits warning, then we shouldn't have a problem.

I'll just have to be a bit more careful about my edge-finding then offsetting to part-zero method.

- Ian.