Recent Posts

81

VB and the development of wizards / Re: Write my own homing procedure?

« Last post by TPS on May 28, 2025, 10:18:20 AM »

>> But i am unable to turn hard limits off.
i know no way to turn hard limits off.
only thing i know is DoOemButton(150) -> Override Limits.
maybe you need a hardware suluotion by switching an output to do this,
but normaly HW limit's are HW limit's and they should be are the physical limit.


>> I had never found them. If i search ""preceise" homing mach3", it yields ony one result that contains no vba scripts and only briefly mentions mach3. And even if i search "precise homing mach3", i found only one link that contains mach3 script, but it involves modbus which i do not have. Can you please provide the links you are talking about?

simple example:

Code: [Select]

  SetParam ("XRefPer",40)
  Sleep 200
  DoOEMButton (1022)  'home at 40%
  While IsMoving()
  Wend
  Code "G53 X-2"  'move off switch 2mm
  While IsMoving()
  Wend
  SetParam ("XRefPer",5)
  Sleep 200
  DoOEMButton (1022)  'home at 5%
  While IsMoving()
  Wend
  SetParam ("XRefPer",100)
  Sleep 200
or you have a motion controller witch allows indexed homing

>> I am not sure i need to home before each job. E. g. i may stop my job and run it again,
>> and the homing procedure may yield slightly different coordinates, so the machine will cut in slightly different place.

if you use machine with ATC and do more identical parts in a row, automatic homing and a couple of other preselections
are IMHO elementary, but this depends on your need's

82

General Mach Discussion / Mach3 Anomolies Strike Back!!

« Last post by wormball on May 28, 2025, 09:44:31 AM »

Hello!

Recently i encountered funny bug https://www.machsupport.com/forum/index.php?topic=49270.msg302793#msg302793 . It happened after i homed the y/b axis many times to calibrate squareness (but interestingly the first tool zeroing after calibration went perfectly fine).

But today i discovered even more funny bug! And now i even have g code to replicate it.

I cut some mdf parts by 4 at once using g52 command to shift coordinates. It went perfectly fine, except i had stock slightly smaller than needed so i had to stop the job manually slightly before the proper end. Also it included several tool changes which also went fine. But after this i tried to change tool to 0 (no tool) and saw the head heading to the point where no tool hanger is present! So i had to manually stop the machine.

When i printed the actual command that generated that move, i found it is perfectly correct:

G0G53 X1574Y68.5

, whereas de facto destination X was 2054, which differs from 1574 by 480, i. e. exactly G52 offset of the last part i had cut. But then i looked at the "diagnostics" screen and found all the g52 offsets are exactly zero! Despite i do not remember i zeroed it manually, and after manual stop they should remain the same. Regardless of this, as you can see, the aforementioned movement command is issued in G53 key, i. e. in the most absolute machine coordinates ever possible! So regardless of any g52 or any other offset it should lead us to exactly the same machine coordinates every time, namely the coordinates mentioned in the command! But clearly this is not the case.

So i dare to say we have severe felony here.

But who is guilty? As you could see, i am innocent. So i have two candidates: mach3 and the motion controller ("eth-mci", or more likely its driver plugin).

At one point i had to reset, so this effect was gone. I ran simplified version of the unlucky code:

Code: [Select]

G017 G21 G49 G80 G90 G91.1
M6 T9
G43 H9 G0 Z50.0000
(Tool Number:9) (8.000 mm dia. slot drill)
M3 S15000
M98 P1005
M5
M30


%


O1001 ; not called, maybe not needed
G52 Y0
M98 P2001
G52 X0Y0
M99

O2001 ; not called, maybe not needed
G52 X0
M98 P3001
G52 X160
M98 P3001
G52 X320
M98 P3001
G52 X480
M98 P3001
M99

O3001 ; not called, maybe not needed
M99

O1003 ; not called, maybe not needed
G52 Y0
M98 P2003
G52 X0Y0
M99

O2003 ; not called, maybe not needed
G52 X0
M98 P3003
G52 X160
M98 P3003
G52 X320
M98 P3003
G52 X480
M98 P3003
M99

O3003 ; not called, maybe not needed
M99

O1005
G52 Y0
M98 P2005
G52 X0Y0
M99

O2005
G52 X0
M98 P3005
G52 X160
M98 P3005
G52 X320
M98 P3005
G52 X480
M98 P3005
M99

O3005
(Tool Number:9) (8.000 mm dia. slot drill)
M3 S15000
G0 X1.0000 Y0.0000 Z50.0000
G1   Z40.0000 F3000
G1 X1.0000 Y285.0000  F7000
G0   Z50.0000
G0 X79.0000
G1   Z40.0000 F3000
G1  Y0.0000  F7000
G0   Z50.0000
G0 X81.0000
G1   Z40.0000 F3000
G1  Y285.0000  F7000
G0   Z50.0000
G0 X159.0000
G1   Z40.0000 F3000
G1 X159.0000 Y-0.0000  F7000
G0   Z50.0000
G0 X0.0000 Y0.0000
G0 Z50.0000
G0 X0.0000 Y0.0000
M99

I also stopped it (first "feed hold", then "stop", then "close g code") slightly before the end. This time the g52 offset was conserved and was still equal to 480, which it should be in the first case. And when i issued tool change command, this time it went to the left to the correct position (previous time it went to the right)! Then i tried to move the machine with simple g0 - it worked fine. But when i commanded G53G0X550, it went not to 550 machine X, but to 390! So this time the shift is not 480, but -160, which is negative offset of the second part (while g52 offset is still 480).

Also this makes my homing procedure impossible, cos it involves slight move from zero, which now is performed to the point beyond the limit switch. Another fun effect is it says "Machine out of limits for SoftLimit Activation.", albeit all machine coordinates are well within soft limits, even regarding aforementioned machine coordinate shift.

So the question is: do you observe this (or maybe another) bug after running this code?

Thanks in advance.

83

VB and the development of wizards / Re: Write my own homing procedure?

« Last post by wormball on May 28, 2025, 06:26:02 AM »

> to use softlimits it is allways necessary to have a propper homed machine.

But if i am not homed yet and prepare for such homing, i do not need soft limits nor hard limits. But i am unable to turn hard limits off.

> homing is normaly handled by the motion controller an every motion controller

Yes, but my motion controller issues loud kick after it homes the slave axis. It is a controller bug they had "fixed" in the latest firmware, but such fix works only first time after power on. And overall i have some reasons to not trust this homing.

And even if it were not the case, i think g31 has some advantages over the mach3's homing. Namely, after such homing the machine coordinates are reset, so i can never tell how much they were shifted and how precise such procedure is. But with g31 i can easily get the exact difference and then set whatever coordinates i want. And also you can set any feed rate you want and even first move the machine fast to the home switch and then do slow precise measurement, whereas in "home" you have only one speed parameter. And you can gather many points and then set the machine coordinate to some average, which is impossible in case of ordinary homing. And i suspect g31 is also handled by the same motion controller in similar manner (but slightly different).

> if you search for "preceise" homing you will find a lot of code samples to get it more precise.

I had never found them. If i search ""preceise" homing mach3", it yields ony one result that contains no vba scripts and only briefly mentions mach3. And even if i search "precise homing mach3", i found only one link that contains mach3 script, but it involves modbus which i do not have. Can you please provide the links you are talking about?

> homing must no be done by pressing button's, it can be handled by script and also by gcode,
so it can be done more or less "automatic".

I have such script at "ref all home" button (written by myself), but at the core it (and all other scripts i had seen) boils down to pushing good old buttons 1022, 1023, 1024 (or 22, 23, 24 which are the same). The only difference in my script is that i also home the slave axis alone with button 1026 (which i think gives better results with my "eth-mci" controller).

> i use homing on all my machines and it is done by a simple macro call at the beginning of every
GCode programm.

I am not sure i need to home before each job. E. g. i may stop my job and run it again, and the homing procedure may yield slightly different coordinates, so the machine will cut in slightly different place.

84

VB and the development of wizards / Re: Elapsed time is always 0

« Last post by wormball on May 28, 2025, 05:28:46 AM »

I think it is the same as dro 814. My machine is running now, but i am pretty sure it won't work too.

Moreover, GetTimer/SetTimer do not work either.

The manual for these function says:

Note that this
function works only with the parallel port driver, and support for this function may be
removed without notice in a future release.

Why do you even need parallel port to measure time?? Especially considering the desired time is actually always shown on mach3's first screen.

In case of dro 814 the manual says nothing besides "Elapsed Time".

However i have managed to write my own function to do this:

Code: [Select]

Sub showtime(t)
    ' usage:  setvar(CYCLE_START_TIME_VAR, now); ..... elapsed = datediff("s", getvar(CYCLE_START_TIME_VAR), now); Message showtime(elapsed)
    Dim s As Integer, m As Integer, h As Integer
    m = Int(t / 60)
    h = Int(m / 60)
    s = t Mod 60
    m = m Mod 60
    showtime = h & ":" & Format(m,"00") & ":" & Format(s,"00") ' there is no function to get date as difference of other dates in mach3! and also no function to properly display time intervals larger than 24 hours! and TimeSerial() yields error on numbers greater than 32767!
End Sub

85

General Mach Discussion / Re: Trouble with code?

« Last post by TPS on May 27, 2025, 12:42:28 PM »

the K parameter is usualy only used if you are NOT working in G17 plane (G18/G19).

86

General Mach Discussion / Re: Trouble with code?

« Last post by Tweakie.CNC on May 27, 2025, 12:09:26 PM »

I am pleased that you got it working.

Tweakie.

87

General Mach Discussion / Re: Trouble with code?

« Last post by Pancerny on May 27, 2025, 08:11:53 AM »

Well I just ran a full program removing all of those key references and everything seems to be working great. Cannot thank you enough!

88

General Mach Discussion / Re: Trouble with code?

« Last post by Tweakie.CNC on May 27, 2025, 07:16:31 AM »

Any idea why those lines would have been added?

Probably the settings within BobCad ?

Tweakie.

89

General Mach Discussion / Re: Trouble with code?

« Last post by Pancerny on May 27, 2025, 06:50:36 AM »

Interesting.  I removed those instances in a short piece of code and it seems like Mach 3 is MUCH happier.  Thanks VERY much!!

Any idea why those lines would have been added?  I'm using an older version of BobCAD, is the software itself flawed?

90

General Mach Discussion / Re: Trouble with code?

« Last post by Tweakie.CNC on May 27, 2025, 01:16:16 AM »

Try removing the command K0.0001 from two instances within your GCode file.

Basically your GCode is not well compiled. (It is improtant to have valid entry and exit moves when using G41).


Tweakie.