Hello Guest it is June 28, 2022, 02:14:20 PM

Author Topic: Mach3 Turn, ESS and G95 - very strange  (Read 3397 times)

0 Members and 1 Guest are viewing this topic.

Mach3 Turn, ESS and G95 - very strange
« on: January 13, 2016, 02:47:59 PM »

after probably fixing the problem on mill with the G31 mode, I'm trying the other problem zone - G31 and G95 moves in Turn. I'm running the last two Mach3 versions (066 and 062) and two versions of the ESS plugin. But if I try a G95 move, I'll get something like on the screenshot in the attached picture, which doesn't make even remotely sense. As you can see, my Spindle Index is configured correct and shows 70 revolutions per minute. The GCode states G95 and a F1, so the feed should be 70 mm/minute or 1 mm/revolution. But it is 0.38 !!

Something similar happens if I code a threading move, G32. Then the feed is so slow, only 0.0 is shown. But in the G76 threading macro, it works which is completely out of the picture, but only in the sequence G32,G32,G1 like in the original version of the M1076.m1s macro. Any other combinations there will fail. I tried to optimize the threading sequence while working on my threading helper application, but that seems to be impossible. Anyone an idea where the problem is located? Mach3 itself? ESS plugin? Or between the ears of the poster?

A few tries later, it gets even move confusing: With manual Gcode, it works like it should. But now the same shown program feeds only with 0.015 per rev. !? And I get even more different results if I change the sequence between G95, F1 and M3. Without the init G94 and F85, I'll get 0.13, with initial G95 and F1 direcly after s65, 0.00 like in the G31 case ... but never, ever 1.0. That looks like a very fatal error.
« Last Edit: January 13, 2016, 02:59:48 PM by stephanbrunker »
Re: Mach3 Turn, ESS and G95 - very strange
« Reply #1 on: January 13, 2016, 04:02:01 PM »
Without the S word to tell Mach what spindle speed to run it won't know what the "rev" is in G95 "Feed per rev."  I'm still learning this stuff but that's what jumped out at me about your code.
Milton from Tennessee ya'll.
Re: Mach3 Turn, ESS and G95 - very strange
« Reply #2 on: January 14, 2016, 04:27:59 AM »
Unfortunately, the S word is further up in the code and also shown in the S DRO.
Re: Mach3 Turn, ESS and G95 - very strange
« Reply #3 on: January 14, 2016, 07:50:32 AM »
Oops, I told you I'm still learning.  Sorry, I wish I could help.
Milton from Tennessee ya'll.
Re: Mach3 Turn, ESS and G95 - very strange
« Reply #4 on: January 14, 2016, 09:12:50 AM »
No problem. I'm going to install Mach3 on an old computer with parallel port and going to look what happens. If the problem is located at the ESS, there is the possibility it can be corrected. On Mach3 - practically end of life'd.
Re: Mach3 Turn, ESS and G95 - very strange
« Reply #5 on: January 14, 2016, 07:13:24 PM »
I set up an old computer with parallel port and found out it's an ESS related problem because then it worked properly. So, I'm going to contact Warp9.

Offline Fastest1

  •  920 920
  • Houston, TX
    • View Profile
Re: Mach3 Turn, ESS and G95 - very strange
« Reply #6 on: January 18, 2016, 11:24:56 AM »
I had issues with that combo too. Turn is the red headed step child.
I want to die in my sleep like my grandfather, not like the passengers in the car! :-)
Re: Mach3 Turn, ESS and G95 - very strange
« Reply #7 on: January 20, 2016, 03:27:36 PM »
After some intense discussing in the ESS forum, some of my problems are caused probably from noise, you have to set a debounce value for probe and index input, then the input-dependent moves (G32, G1 in G95 mode and G31) work actually right.

The second issue is in the whole threading process, so if someone sometimes wants to write an CAM postprocessor for Mach3 threading:

Mach3 has two threading modes: A normal one with a G32 command, and a special one. You can see this on the diagnostics screen with the "Threading" LED. If you enter a single G32 command, Mach3 waits for the trigger and executes the command, and leaves the threading mode. The problem the programmers had was that they couldn't continue the cut seamlessly for the retraction move, because an following G1 command in G95 mode would wait for its own trigger and thus causing an interruption. They hacked this with a special secret threading mode, you enter it with two G32 commands in a row - there mustn't even be a movement involved. In this special mode some changes are made: Even if the "G94 Mode" LED is still on, G1 commands following a G32 are executed as G32 commands too - with the feed per revolution. Thats why the retraction mode is per revolution even without an explicit G95 in the macro. The next and most important thing is that the cut is continous, in the sense of a single G32 with waypoints and no intial wait for the trigger. But different than in the "Mach3 threading guide", you should be in constant velocity mode, because in exact stop there will be still a slight delay at the "waypoints". And for all moves, the G32 the same like the chained G1 the feedrate is along the path and not fixed to the Z-axis. So, for tapered threads the F-value has to be corrected with the cosine of the taper, i.e. the standard M1076 macro does that wrong, but for a R thread with a taper of 1.78 degrees the difference is less than 0.1%. But if you ever want to make a breech screw, you have to take that into account ..

So, if you want to code anything after your G76 command, you're still in this special mode. You have to reset your feedrate and you can leave the mode with a M0 or G80. If you had G94 before, it's G94 afterwards. But I'm going to reset the feedrate to the original value in my version of the macro.
« Last Edit: January 20, 2016, 03:46:51 PM by stephanbrunker »