( COMMENT ) causes stall on rapid moves?

[vi_tasIT]

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.

[alcwell]

I had the same problem.

I my case it was caused by the computer going beep when the comment was displayed.
I disabled sounds and haven't had any issues since.

Alastair

[Hood]

Never seen this problem but would certainly give your code a test to see.
Alastair may have hit on the cause though so might be worth trying the disable as he describes.
Hood

[vi_tasIT]

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

[alcwell]

Glad you got it going.

The monitor I use had built in speakers so I could here the beeb. Eventually the penny droped that the stall always happened shortly after a beep.

Alastair

[Hood]

Sorry forgot I removed the parallel port from the only machine I have with steppers so cant test

Hood

[vi_tasIT]

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.