Nope tried with my profile, your profile, Test= false, test=true and definitely no G49 here.
Is this the simple threading wizard you are using?
Hood

Hi,
tested some things. Unfortunately can not make a real test because the lathe is disassembled in the moment. This is what I tested using version .062
Created a Brain that gives me an index pulse. Then loaded the XML from Simon and the G code an run it. Everything looks like I expected it. The code
was running without problems. After a couple of hours testing I decided to wire an index sensor to the PP to see if that makes a difference.
Its also running fine here, so far as I can say.


Alex

Hi,
Sorry for the delays but work and home life can get in the way of my hobbies!

• Hood, you are quite right, I tracked down which gcode program I used as a basis and it turned out to be the taper turning wizard - so that contains a G49 in the header - whatever it does. Sorry, but my slightly disjointed investigation leads to some blind alleys
• Alex, thanks for trying, I wonder whether the PP is part of the issue which I assume is not emulated in the Brain
• Hood, no I had forgotten about diameter mode testing - however I have just tried it and exactly the same problem happens

Is there any way that I can dump the output to a file rather than to the parallel port?
Is there any other form of diagnostics that I can run in parallel or run after the fail?

Any thoughts about the very slow activity seen towards the end of my second video?


Any other suggestions....

Simon

I think Art is the only one that will be able to see where your problem is as he is the guy that does the driver and as far as I know that is where the threading is done in Mach when using the parallel port.
In previous versions Art wrote a plugin so that he could see what was happening on the systems of the people  that were helping with the tests, this however, as far as I understand, is no longer any use as the driver has been updated since.
Maybe Brett will see if Art will chime in, if not I will skype him and ask him if he can look.

Hood

Hi Guys:

 The best way to tell as  I recall, is to select the "Debug" option in the configuration, then try one line of threading. Stop the program and look in the LastErrors.txt fille in the mach3 folder. Post it here if you like, it tells you whats going on during the thread, and why it might fail..

Art

Art,
Thanks for getting involved.

I did as you suggested and set the debug flag:
3 files attached, the first one (run1) had one successful pass followed immediately by a failure. The second file (run2) had a number of successful runs followed by a failure at the very end. Gcode attached for reference.

Additional information summarised from the previous mails:
* the retract at G1 at the end of the thread run 'appears' to run much faster than programmed (difficult to tell over 2mm)
* the G0 rewind runs at 400 and not the maximum 500mm/min
* the G1 return X to the start position runs at an indicated 32-33mm/min rather than the variously programmed feed rates around 40mm/min
* in all cases when the run fails, there is a calculation for threading that appears to use a pitch of 40mm rather than the requested 1.5mm - which would require a very significantly faster feedrate.

Open to further requests for making tests.
Simon

Simon0362,
Have you contacted Calypso about this problem?
- I don't use MSM and don't know what version of Mach they want installed with MSM
- I am not sure that you want to change between screens when using MSM as that could / may create problems
- Do you have both MSM and Mach installed together on the same drive? Ask Calypso if that could create problems.

So my first concern in addressing your problem is that your using MSM and that in itself could be a culprit.

Later,

RICH




 

Rich,
I haven't contacted them but I did try using the standard turn screens because I had similar screens. However they produced the same problems - see the first video I uploaded to youtube...

Not sure what you mean by "changing between screens" -if you mean when running, I don't usually touch the UI whilst a program is running.

Msm and Mach are installed on he same drive, but this is their standard practise, I believe.
From their website:

Mach3 3.43.62 - This is the current CVI recommended Mach vrersion for MSM Turn and Mill-Turn use. It is also working well for Mill use, though it has less field test time than 3.43.37 at this point in time.
This is the version which CVI previously recommended for use with MachStdMill Turn and Mill-Turn. Earlier Mach releases between 3.43.38 and 3.43.62 each have a significant flaw wrt to some aspect of lathe operations.

Mach3 3.43.66 - This Mach release fixes a few more Mach lathe related bugs and is required for some lathe features that were introduced in MSM 2.0.4.2 beta. Without at least this Mach version, the new features (e.g. Front/rear tool post editing) will not appear in MSM (See the MSM releae notes for more information).
This is the version which CVI currently recommends for use with MachStdMill.

As I said, I did test with the standard screens but went back to MSM since I am used to them.


Meant to say I have tried 062, 066 and currently 067

Simon

Simon:
 
    I cant tell exactly whats wrong. The numbers dont look particularly bad. They show a slowdown of about 20% during the cut.
   Its been awhile since Ive odne any threading work, couple years anyway, so Im not fully up to snuff of the readings.
   I dont like that the adder value is always zero, but that may be normal in that driver. The adder controls the speed. The error
   controls the adder. Mach3 purposely increases planned speed by 20% so the thread shoudl immediately drop that speed by 20% when the thread starts, thus
   giving the right speed, and allowing it to speed up by at most 20% if the spindle speed should increase. ( yours doesnt increase so thats not an issue).
   
    The reading of pitch of 40 is simply the G1 or G0 at th end of the thread and as a result shows no threading run vaues after the report. ( Thats normal
    in other words..).
   
Thu - 11:07:22 ---Spindle Lock: 5220 , Total Ints: 0, Total Spindle Ints: 0, Error: 811, Adder: 0 LastRot: 6489
Thu - 11:07:22 ---Spindle Lock: 5220 , Total Ints: 5765, Total Spindle Ints: 5220, Error: 545, Adder: 0 LastRot: 6587
Thu - 11:07:22 ---Spindle Lock: 5220 , Total Ints: 11711, Total Spindle Ints: 10440, Error: 1271, Adder: 0 LastRot: 6481
Thu - 11:07:22 ---Spindle Lock: 5220 , Total Ints: 16977, Total Spindle Ints: 15660, Error: 1317, Adder: 0 LastRot: 6549
Thu - 11:07:22 ---Spindle Lock: 5220 , Total Ints: 22206, Total Spindle Ints: 20880, Error: 1326, Adder: 0 LastRot: 6544

  The spindle Lock is the spindle speed in interrupts just before the threading begins. The error is the difference it saw
  in the last rotation.  The resport of a large pitch you can ignore, its just a false report based on the G1 motions post
  threading. The Adder is the only value I dont like, but I cant recall if thats normal or not.
 
 Be nice to know if anyone using threading  gets an adder value in that test, I simply cant recall. The readings other than
   that though, show no failure at all. They seem to track, the errors are what Id expect from a proper thread and they dont
   seem to grow meaning the variations appear to be properly dealt with.
   
    Im assuming you have "Use Actual Spindle Speed" checked in the config? 
   
    Art
   

I just read the entire thread to see if it helps..

>> I can hear the X attempt to get close to the thread OD then there are a couple of missing step sounds 

  THAT sounds like the error. Mach will not know if steps are lost, so the failure may be lost steps beacuse the
X motor stalled. Do you have a way to tell if the emco has lost a few steps. Zero to a known and repeatable spot,
after a filure use a G1 X..Z.. to go back to that spot. Is it off position...if so, thats the problem, we need to figure out why its
lsoing spot. That double G32 HAS to go, two G32's in a row will not reset the WaitForTrigger, there always has to be a G0 or a G1 after a G32, preferable a G0.. ( which cancels threading mode so another can be mode switch can occur. ). SO ensure nowehre is there
two G32's in a row.. that will always fail in one way or another.

Art