Author Topic: Mach 4 Bug Reports  (Read 343969 times)

0 Members and 1 Guest are viewing this topic.

Offline BR549

  • Mach4 Alpha
  • Posts: 6,855
    • View Profile
Re: Mach 4 Bug Reports
« Reply #10 on: May 05, 2014, 12:13:08 PM »
Mach4 does not want to run the older Mach3 complex subs. It stalls and or cannot display the proper toolpath. I have examples of some that RUN fine in mach3 but not mach4 IF needed.

Also Mach4 does not want to run older fanuc macros that LOOK like it should run fine in Mach4 .

(;-) TP

Offline smurph

  • Administrator
  • *
  • Posts: 1,051
  • "That there... that's an RV."
    • View Profile
Re: Mach 4 Bug Reports
« Reply #11 on: May 05, 2014, 12:33:31 PM »
Yes, please provide an example.  The sub stuff is all new code (as most of Mach 4 is), so there is bound to be something that doesn't work the same as Mach 3.  The example will help me make it more compatible.

Are you talking about macro A?  Because that will not work at this time.

Steve

Offline smurph

  • Administrator
  • *
  • Posts: 1,051
  • "That there... that's an RV."
    • View Profile
Re: Mach 4 Bug Reports
« Reply #12 on: May 05, 2014, 12:40:21 PM »
Recent File entries not working with long strings

Description:
When loading G code files with filename length > 80 characters, the file will load successfully. Clicking Recent File button later will fail, if full path and filename is longer than 80 characters, because path is stripped after 80th character.

Ok, good one!  Thanks.  It has been taken care of.

Offline BR549

  • Mach4 Alpha
  • Posts: 6,855
    • View Profile
Re: Mach 4 Bug Reports
« Reply #13 on: May 05, 2014, 03:36:42 PM »
HIYA Steve here is an example of a sub that fails in Mach4 but runs perfect in Mach3.

I had another that would not run yesterday no matter what I did BUT today it ran fine  from the get go.


Looking at THIS program and how Mach4 displays the toolpath it seems Mach4 is having a bit of trouble with G18/19 and IJKs

If you need to see HOW it SHOULD be look at it in Mach3. It is making a hemisphere for a ball in cube routine.

Thanks, (;-) TP


Offline smurph

  • Administrator
  • *
  • Posts: 1,051
  • "That there... that's an RV."
    • View Profile
Re: Mach 4 Bug Reports
« Reply #14 on: May 05, 2014, 03:51:22 PM »
Hmm...  I know that G17/18/19 have all been made to work "correctly" as to conform to Fanuc.  So it may be a case that the older Mach3 G code just may not work anymore.  We will have a look and see!

Steve

Offline Graham Waterworth

  • Administrator
  • *
  • Posts: 1,837
  • West Yorkshire, England
    • View Profile
    • Autovalues Engineering
Re: Mach 4 Bug Reports
« Reply #15 on: May 05, 2014, 03:58:38 PM »
Its a local var problem not a sub or plane issue

G-Code is on the cutting edge

Autovalues Engineering, CNC machining specialists, Bradford, England

Offline smurph

  • Administrator
  • *
  • Posts: 1,051
  • "That there... that's an RV."
    • View Profile
Re: Mach 4 Bug Reports
« Reply #16 on: May 05, 2014, 04:11:19 PM »
I'm glad Graham caught it because I was missing it.

To explain further because this IS a change from how Mach 3 operated.  It is because you are using local vars to pass values to a sub.  Used global vars instead.  Because the local vars are "local" to the main program just as they would be "local" to a sub.  local vars acted like global vars in Mach 3, which was not correct.

Steve

Offline BR549

  • Mach4 Alpha
  • Posts: 6,855
    • View Profile
Re: Mach 4 Bug Reports
« Reply #17 on: May 05, 2014, 04:17:40 PM »
SLAP on the head, Of course it is. I have been in Machism too long now.

Sorry for the waste of time, (;-) TP

Offline BR549

  • Mach4 Alpha
  • Posts: 6,855
    • View Profile
Re: Mach 4 Bug Reports
« Reply #18 on: May 05, 2014, 04:42:48 PM »
OK I moves all vars up into the 100 range AND tried it in the 1000 range same problem.

Also simple testing show that Mach4 is perfectly happy using the G65 local vars in global applications. IS it suppose to or NOT ?

#1 =10
G0 X#1

There is not an error and the code runs fine.

I happy to se that G1 X- #1 is a legal call now instead of having to resolve the NEG direction from inside the variable G1 X[0-#1]. Both are excepted now.


??? , (;-) TP

Offline smurph

  • Administrator
  • *
  • Posts: 1,051
  • "That there... that's an RV."
    • View Profile
Re: Mach 4 Bug Reports
« Reply #19 on: May 05, 2014, 04:53:58 PM »
G65 local vars?  You mean the parameters?  Or this:

#1 = 2
#2 = 4
G65 P1000 X#1Y#2

type of thing?

The general rule of thumb is that result accessing local vars without first setting them "locally" is undefined.  They may have a value.  But it may not be what you want.

Try this...  Graham converted and it seems to work fine.

G50 G40 G80 G20 G94 G91.1
#101=1 (size of box)
#102=.125 (cutter radius)
#103=.125 (size of box bars)
#104=1 (degrees of resolution)
#105=#104 (COUNTER)
#106=[[#101/2]+#102] (ACTUAL RADIUS OF CIRCLE - CUTTER RADIUS + RADIUS)
G01X0Y0F100
m3 s3600 m8
M98 P140 L40
G0Z0
X0Y0
M30
%

o140 
   #108 = [[SIN[#105]*#106]*SIN[45]] ( X AND Y POSISION)
   #109 = [0-[[1-COS[#105]]*#106]] (Z HIGHT)
   g4 p0
   G1X[#108]Y[#108]F30
   Z[#109]
   G18 G02 X[0-#108] Z[#109] I[0-#108] K[0-[#109+[#106]]] F5
   G19 G03 Y[0-#108]Z[#109]J[0-#108]K[0-[#109+[#106]]]
   G18 G03 X[#108]Z[#109]I[#108]K[0-[#109+[#106]]]
   G19 G02 Y[#108]Z[#109]J[#108]K[0-[#109+[#106]]]
   #105=[#105+#104]
M99