Hello Guest it is July 28, 2021, 06:46:53 AM

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Llaves

Pages: 1 2 3 4 »
1
yes, a genuine license file once I became aware that the one sent with the machine was bogus. (I wasn't terribly surprised to discover that).
Yes, I had some problems early on, but that was five years ago. It's been working smoothly for quite a while (with a few hiccups). But this is new. I understand the relationship between Mach and the controller board, that's why it's so baffling that Mach can simulate the cut with the board disconnected, but not with it connected. After all, in simulation mode it's not communicating with the controller.

2
the weirdness continues.
I moved the laptop to my office, disabled the plug-in for USB connected controller (Xulifeng). The program runs just fine.
Took the laptop back to the shop, connected the controller (which re-enables the controller plug-in), I again get the error message.
With the controller plugged-in, I deactivate the plug-in (meaning the controller is not visible), no error.
Re-activate the controller plug-in - error.

Why would the presence of the controller cause this error?

3
I'm getting the dreaded "radius of arc differs" error, but with a twist.
My code begins like this:
Code: [Select]
( Made using CamBam - http://www.cambam.co.uk )
( Bottom3 12/28/2020 12:39:25 PM )
( Post processor: Mach3 )
( T4 : 0.236 )
G20 G90 G64 G40
G91.1

The program errors out in the simulator on the marked line:

Code: [Select]
(many lines of previous pocketing operation omitted)
S19600
G0 Z0.75
G0 X8.2874 Y0.8916
G1 F25.0 Z0.375
G1 F75.0 X8.2708 Y0.8244
G2 X8.2707 Y0.8242 I-0.1213 J0.03
G1 X8.2018 Y0.5483
G2 X8.2016 Y0.5475 I-0.1213 J0.0303
G1 X8.1167 Y0.2176
G2 X7.9737 Y0.1257 I-0.1211 J0.0312
G1 X7.3166 Y0.2429
G2 X7.3149 Y0.2432 I0.022 J0.1231
G1 X6.6596 Y0.3695
G2 X6.6579 Y0.3699 I0.0237 J0.1227
G1 X6.0043 Y0.5053
G2 X6.0026 Y0.5057 I0.0254 J0.1224  <<------------error here
G1 X5.351 Y0.6501
G2 X5.3493 Y0.6505 I0.0271 J0.122
G1 X4.6998 Y0.804
(more code follows ...)

So, it's incremental mode and the website says to use absolute.
OK, so let's change the G91.1 to G90.1
Now things get weird. I still get the radius differs error message. But I also get incorrect tool paths in the preview. Instead of drawing/cutting 10-15° of arc, it draws the compliment - 350° or so.

Since debugging this on the laptop in my office is more comfortable than standing over the machine in the shop, I copy the g-code file and the Mach3 XML configuration file and bring them to my office.

I launch Mach3 using the config file from the shop computer and run the g-code. No error with either G90.1 or G91.1. Same funky toolpath with the G90.1 setting.

One more oddity:
If I launch Mach3 on the shop computer and don't hit reset, then load the g-code and run simulate, I don't get the error. But Mach3 launches in metric units and my initialization string - G80 G20 F1905 S1000 - isn't being executed so the DROs continue to appear in metric units in spite of the G20 at the start of the program. Even if I return to the Program Run tab, reset does not set the DROs to inch.

Both computers are running 3.043.066, and have been for several years with no problems like this.
I've been running CamBam for a while, as well, and have successfully run quite a few programs of comparable complexity (or worse).
The main difference is that one computer is actually connected to a controller.

I'm at a loss where to look next. Suggestions (preferably other than reinstall)?




4
General Mach Discussion / issue with homing macro
« on: October 27, 2020, 07:32:04 PM »
I have a fairly simple macro that touches off against a reference block to zero the X and Y axes. The machine moves 1" in +X, then moves in +Y till it makes contact, and sets the DRO. Next it  moves back to the starting position, moves 1" in +Y, then moves in +X until it makes contact and sets the DRO.

The macro has worked for quite a while (months). In the past day or two the behavior is bizarre. It will run the first time or two I invoke it (from a button on my pendant). But the next time, it will start up and run through the Y contact, but then instead of returning to the starting position, it moves towards the starting position but also moves in the +Z direction. Since there are no Z moves in the macro, this is extra baffling. If I restart Mach3 (but not the machine or interface board), all is good again for one or two runs of the macro.

Other than this, Mach3 and the machine seem to run normally.

Any ideas on what to look at?

5
General Mach Discussion / Re: Using G54-G59 in macro?
« on: September 14, 2020, 09:09:50 AM »
thanks - that's the info I needed.

6
General Mach Discussion / Re: Using G54-G59 in macro?
« on: September 13, 2020, 06:43:43 PM »
Answered half of my question -
I forgot that the motion code call would return before the move completed, so the offset is reset to G54 before the move completes.
The correct code is
Code: [Select]
code ("G59")
code (G0 x0 y0 z0)
while (IsMoving())
    sleep(100)
wend
code ("G54")

I'd still be interested in learning how to save and restore the current fixture setting.

7
General Mach Discussion / Using G54-G59 in macro?
« on: September 13, 2020, 06:06:56 PM »
I have a very simple macro to position my router above the touchplate  that relies on offsets saved in fixture 6 (G59):
Code: [Select]
code ("G59")
code (G0 x0 y0 z0)
code ("G54")
If I type this code manually it works fine. But in the macro the change of fixture offset doesn't seem to get recognized and the machine moves to the origin of the current fixture offset (usually G54). How do I make this work?

Bonus credit - how to a read the save and restore fixture current when the macro starts instead of relying on it's being G54?

Thanks

8
I tried to time a program in simulation mode (Tool path screen) and it fails with an error that the radius at the start and end of an arc don't match. The odd thing is that I can run the program in actual execution mode with no error. I would have thought the simulator and execution mode would have behave the same.

9
General Mach Discussion / Re: Z-Probe macro for inches and millimeters
« on: April 14, 2016, 12:43:13 PM »
Ahh, the peculiarities of Mach3 abound.

Obviously there is an explanation but I don't have much interest in why, I just try to remember what works and what doesn't work and then go from there.  ;)

Tweakie.

Fair enough.
But is there a way to make the G20 work in the initialization so that the F parameter is inches? Some extra punctuation, perhaps?

10
General Mach Discussion / Re: Z-Probe macro for inches and millimeters
« on: April 14, 2016, 12:12:05 PM »
That worked. Thanks.
Is there an explanation why you can't combine G20 on the same block/line? I've encountered this before in my Mach3 initialization string. I have "G80 G20 F1875". I had originally tried setting the F parameter in inches, but the controller is still in millimeters when this line is processed. Obviously the same problem is occurring here, but why?

Pages: 1 2 3 4 »