Hello Guest it is May 08, 2021, 10:16:08 AM

Author Topic: Preparation Positioning, bug?  (Read 12464 times)

0 Members and 1 Guest are viewing this topic.

Preparation Positioning, bug?
« on: April 06, 2008, 04:12:32 AM »

I have noticed that in using the 'Run From Here' command, if that selected line is some type of M command, and perhaps others, though the Prep Positioning dialog box indicates what seem to be correct target coordinates for a prep move, the system runs away- generally hitting a soft limit, but sometimes just randomly stopping at some weird place. I have called this 'run from here' command several times against a given line, and the runaway position seems to vary, and is not related in any obvious way to machine coordinates or offsets, etc; it seems random. However, if I 'run from here' on any G or coordinate line, the positioning function actually goes where it says it will go.

Here is a (subsection) sample drill operation, with a change to a facing operation. I can 'run from here' on any drill coordinate line, and all is fine. If I 'run from here' on M09, M05, M01, or M08, I get the runaway. Perhaps there is some problem with my code, but if the Preparation Positioning dialog box says, for example, x=2, y = 2, z = 1, and that is within reason for the part, but the table goes to x=18, y=0, z = 2.2, Im not sure how I can be causing that; the dialog box suggests Mach knows where it should go, it just doesnt go there.

Any insight? Using the current lockdown version of Mach3 under Win XP.


(TOS = .12)
(MAX - Z.25)
(MIN - Z-.22)

Offline jimpinder

  •  1,232 1,232
  • Wakefield, West Yorks, UK
    • View Profile
Re: Preparation Positioning, bug?
« Reply #1 on: April 06, 2008, 05:01:55 AM »
It says, quite clearly in the notes, that using "Run from Hrere" Mach may step back a few lines to pick up.

I do not recommend "Run from Here" and is is, I would have thought, bad practise to use it in normal work. I think it is designed for, and should be used, only when something unforseen has stopped the program. You E stop, or whatever, rectify the work, and (instead of running right from the beginning again) try to carry on (because it is quicker to go forward than go back.

The problem is (as you have found out) POSITION.

Unless you have some independent system, reading back into Mach3, then position is calculated on the move, from your base position - either when you home, or when you set up your work. From this start position Mach 3 adds or subtracts distances, or offsets as it moves.
If you step backwards through the program it can calculate that as well. But if you jump Mach has to find its position. It does that by trying to find its last positional move and working from there, but if offsets and other similar types of "distractions" are there it doesn't always get it right.

If you are going to stop at that place on a regular basis, I would put in a stop (M1). If you are only going to do part of the drilling program and then want to advance, then put in a positional move G0 to a safe tool spot before the G80 and "Run from There"
Not me driving the engine - I'm better looking.
Re: Preparation Positioning, bug?
« Reply #2 on: April 06, 2008, 05:16:48 AM »
Well, I am doing some debugging on a complex toolpath, and sometimes it is useful to run from here vs. cut air for an hour. However, I ran into this inconsistency, and felt it to be significant.

I dont think I follow the logic here as to why this should lose position, unless of course you crashed or lost steps in some way in open loop. But if Mach knows where it is, and it knows where it should be by running through the code, it seems to me that resuming (at least in a 2d or 2.5d path) should not be difficult. There should be no problem at all if the 'run from here' is defined at a tool change operation, since you are already retracted and (presumably) are in the same state at resume as you would be following a tool change regardless.

Having used "run from here" many times in this process, even with the runaways, I have not seen any cut offsets. Im not suggesting this is a great option, but it has worked for me. My inquiry was on the fact that there is a runaway that happens when 'run from here' is used at certain points in a code list, and that is a big problem- could easily cause a crash with a fixture, etc. So if this is not user error (dont see how it can be, since I have no ability to modify the run to positions it calculates (they are greyed)), it seems like it may be a bug- one that seems to me to have potentially serious consequences if you are not prepared to hit Reset.

Offline jimpinder

  •  1,232 1,232
  • Wakefield, West Yorks, UK
    • View Profile
Re: Preparation Positioning, bug?
« Reply #3 on: April 06, 2008, 01:46:01 PM »
I understand what you are saying, and in theory you are right. However, I have no idea what mathmatics are involved in keeping track of where Mach3 is, and , more importantly, when it is implemented. If you press the Stop or Feed Hold button whilst a line is being processed, how do you know if the full details of the new position has been logged. Yes I appreciate if it is a non-move, the positional data should be the same - but the logic might post the data in a temporary file at the start of a line. It might post the new position at the end of the move and if it hasn't moved pull the data back from the temporary file. When you stop half way through it might prevent that happening, and if you start on another non-move it could get totally confused.

I must admit, I don't know the exact answer, and perhaps someone could look at it, or explain if there is a more reliable way to do what you want.

As I say, Mach3 does not always start again from where you are. It steps back and tries to gather breath - presumably to find it's position, and then carries on.

We'll see if any of the higher ups can have a crack at this one.
Not me driving the engine - I'm better looking.
Re: Preparation Positioning, bug?
« Reply #4 on: April 06, 2008, 04:25:32 PM »
Hey Rob, not sure, but for whatever reason, it is not to be used in a subroutine, may also apply to a Macro. ? ? ? ?
Try allways starting a line or two before the M block.   ? ? ?
Just guessing, no real experience.
« Last Edit: April 06, 2008, 04:27:40 PM by Overloaded »
Re: Preparation Positioning, bug?
« Reply #5 on: July 17, 2016, 09:13:23 AM »
This problem still exists. I have avoided Run From Here for a long time but yesterday took a closer look. The manual explains that RFH does a dummy run from the top of the program in order to establish the correct position for the line immediately before the line to be executed. Seems clear enough to me. I created a video of my experience: https://www.youtube.com/watch?v=_ML7LPLecw4

My work-around is to do a Rewind, enter the line number, do a Set next line only in a place that will fully define the cutter's position, and then hit Run. Until proven otherwise, I think RFH is buggy. Hmmm, maybe "Run From Here" means that I should Run (for my life) From this (Here) function ;-)

PLEASE prove me wrong!

Offline Hood

  •  25,838 25,838
  • Carnoustie, Scotland
    • View Profile
Re: Preparation Positioning, bug?
« Reply #6 on: July 17, 2016, 09:45:25 AM »
Have you read the replies to  your own post and confirmed whether the Safe Z is set correctly? seems not to be from looking at your video.
Re: Preparation Positioning, bug?
« Reply #7 on: July 17, 2016, 10:28:30 AM »

I could not find "Safe Z" on any of the screens but did find "Preparational Move to:"/Rapid Height which was set to 0. I changed it to 1.1 and that solved the initial movement to 0. The non-zero value in Y is annoying but so far has been harmless. I will update the comment on the video.



Offline ger21

  • *
  •  6,289 6,289
    • View Profile
    • The CNC Woodworker
Re: Preparation Positioning, bug?
« Reply #8 on: July 17, 2016, 11:05:59 AM »
Config > Safe Z

2010 Screenset

JointCAM Dovetail and Box Joint software
Re: Preparation Positioning, bug?
« Reply #9 on: July 17, 2016, 01:20:13 PM »

Ah, that solved the Z problem.