Messages

11

General Mach Discussion / Re: Homing slave axis revisited

« on: May 15, 2013, 07:25:12 AM »

Try RefCombination(10)

NOT RefALLCombination

Also, in General Config, make sure "Home Slave with Master" is NOT checked.

It is refcombination in the code, I posted it from memory and Home Slave with Master is not checked. Already experimented with that one.

Weird thing is that the M4Home will not trigger an eStop like it did before. That's what caught my attention.

12

General Mach Discussion / Homing slave axis revisited

« on: May 14, 2013, 06:47:46 PM »

I know this topic has been beaten to death but I'm having an issue that hasn't been covered in earlier discussions.
I have a new CNC router. Mach3, G540 and an external BOB (PMDX-108). Proximity switches are all working and seem to be configured correctly. I'm using the BOB for the switches. The ref all home worked before but has somehow gotten messed up and no longer functions. My assignments are a bit nonstandard.
X is left/right short axis 24" on my machine.
Z is up down
Y is forward/backward 48" on the long axis

X has sensors on either end of travel wired together and configured as both home and X ++limit and X--limit
Y has sensors on either end wired together plus a separate A sensor defined separately.
X is configured as both home and Y++limit and Y- -limit
A is configured as A home on M4 and the sensor is on the same side as the A motor

Homing Z works fine.
Homing X works fine.
Homing Y works but does not square the gantry.

Code is
Dobutton(24)
Dobutton(22)
Refallcombination(10)

Ref All Home Homes Y first then A but leaves M4 sensor tripped and turned on. It trips the M4 switch, stops but does not back off the sensor leaving the M4Home sensor turned on and the gantry not squared.

Any ideas?

13

General Mach Discussion / Re: Mach3 software hooks

« on: May 13, 2013, 12:11:11 AM »

I have to laugh that a CNC controller loads up a modern PC.  The old Bandit controller I used to run had the same processor as the Apple II!

Gary H. Lucas

I don't think it really does load it up. We're talking about scheduling issues not real CPU usage. Even an old 80286 at 16mhz could keep up with a gcode interpreter sending a data stream to the parallel port. But its likely that some of the software libraries that are part of the Mach3 exe module are inefficient at displaying video. Depends on how they code it and which library routines get compiled or referenced at run time. That or its been coded in such a way that it does not gracefully share the processor causing a pile up or stack overflow somewhere. It may have nothing at all to do with Mach3. It may just be a quirk of the language they use to generate the exe file.

14

General Mach Discussion / Re: Mach3 software hooks

« on: May 12, 2013, 05:54:57 PM »

It just occurred to me there is probably a way to write a VB script that would serve a web page. It might require installing an MS library package but I'll bet its possible.

15

General Mach Discussion / Re: Mach3 software hooks

« on: May 12, 2013, 05:14:01 PM »

I do know that the Mach guys will remote in to do trouble shooting. not sure if they have actually run the machine or not.
I thought that one of the nice things about external motion controllers was that they took most of the load off of the CPU. You may not have your ESS setup properly if you have problems when you fiddle with the tool path display.

Mike

That's one of the reasons I bought an ESS, it does take some of the load off the CPU. But there isn't really anything to "set up" with the ESS. You assign it an address and plug it in. The driver does the rest. There really are no communication parameters to fiddle with and I don't see any options in the plugin that would effect its operation in terms of loosing communication. It's far more likely that the library calls that Mach3 uses to update the 3D display either load the CPU enough to miss communication (very unlikely) or they directly interfere with the ESS protocol by preventing an uninterrupted stream of instructions. Ethernet adapters are hardware interrupt driven devices and nearly all new adapters have on memory board buffers so it's unlikely its a communication issue. The code to operate the ESS is terse so if I get an error saying it ran out of instructions to execute its either a communication issue or something is preventing Mach from generating or sending code. I tend to think it's CPU load since the communications are interrupt driven. In any case, it would still be nice, and very easy, to add a web page server to the Mach suite.

16

General Mach Discussion / Re: Mach3 software hooks

« on: May 11, 2013, 01:58:28 PM »

You could also do a remote desktop type of thing. It would be the next best thing to being there.

Yea but I'm running a Smoothstepper Ethernet. I doubt the Ethernet communication would be an issue but I suspect the remote desktop would tend to hog CPU time and might let the ESS run out of data. It generates a tremendous amount of interrupt activity that could easily interfere with Mach. I get smoothstepper errors when I fiddle with the Mach toolpath display while running code as it is. I also have not found the remote desktop to be very reliable or functional. A web page would only take 1ms or less of CPU to generate the HTML page and slam it into an outbound Ethernet buffer ready for packeting. A remote desktop runs a screen update server as a service that continually compares the "off screen" screen with the current screen sending updates to the remote. In short tons and tons of software interrupts.

I could me wrong though, has anyone tried it?

17

General Mach Discussion / Mach3 software hooks

« on: May 11, 2013, 12:52:25 PM »

Greetings folks. My name is Tom. I'm fairly new here and still very green.

I'm recently built a 24"x48" hobbyist machine from a cncrouterparts kit. It's up and running and I'm learning more every day. My "shop" is a small storage unit below my apartment I'm just beginning to trust my machine to run unattended while it whittles away on 3D signs and address plaques. I'm wondering if the Mach software has any way to send data over the network while its running. It would be nice if it had a built-in web sever that published a current DRO screen with some kind of progress indicator? The software (.dll libraries via Apache) to implement such a thing is easy to include in the code, or it could be a stand-alone thread initiated when Mach3 starts. I think there are web libraries that will serve a simple cgi page on a custom port. If not, is there any other way besides the sound of wood being cut to indicate its progress?

18

General Mach Discussion / Re: Haywire Mach3 and bit destruction

« on: May 05, 2013, 11:36:08 PM »

I think the G43   H21 in this line is invoking the offsets

N140G00G43Z1.0000H21

you can either remove them from the table, correct them to function as intended or remove the g43...h21 from that line

John

I think the G43   H21 in this line is invoking the offsets

N140G00G43Z1.0000H21

you can either remove them from the table, correct them to function as intended or remove the g43...h21 from that line

John

Thanks, I think I tracked it down. I never really intended to use them. I don't have a ATC and I don't think I'll be needing to enter any tool wear so I doubt Ill ever be using tool offsets. BUT, I'll be very careful for a while until I'm sure. It's probably Mach that added the code since I had tool offsets enabled. It never occurred to me that I had tool offsets defined. I don't recall entering them but it's possible I did, it's been a long process building this thing. This isn't the first learning experience I've had and it probably won't be the last. Thankfully this machine is well built and won't be permanently harmed by a few crashes. Worst case so far has been burning holes in my new spoilbaord, stalling the router and exploding a bit. R&P drives seem to be quite resilient to running over limits or stalling an axis. They just jump a gear and make a lot of noise but don't seem to be damaged. I set the gear tension low to reduce motor stress and prevent any issues should I end up stalling an axis again. Hopefully I've figured it out.

Thanks again,
Tom

19

General Mach Discussion / Re: Haywire Mach3 and bit destruction

« on: May 05, 2013, 03:37:03 PM »

I've read your post several times and it's not clear to me whether your tool plunged too deep during the G31 move or later when you resumed cutting or both. Can you clarify please?

It plunged way too deep. I don't think it was a G31. It was a G1 move. It went through my workpiece and into the spoilboard beneath. In any case it certainly jammed the axes but the bad part is that it destroyed a very expensive bit. I felt and feel the need to understand why before continuing.

I think I've figured it out. I found several bits defined in the Mach database with offsets entered for them. I think that's why it plunged. That would explain why I've been having issues with certain bits before. Sometimes it starts cutting 1" above the work surface, now I understand why. The bit number assigned by Cut2D is higher than I've ever used before. I renumbered them in categories of 10 so it was bit #22 in Cut2D. In the Mach tool database tool 22 had an offset of 1.5" entered. In my mind that would work out to 1.5" ABOVE the work surface not below it but removing all tool offsets and turning the feature off seems to have solved the problem. I need to get more experience with offsets. I don't understand how Mach applies them in some instances. I'm sure it's all logical from a machinists view but to me it's Greek until I've done it a few times.

Below is a snippet of the code. This is the third tool path of 4. As you can see it moves to .2 above the surface, starts the spindle then moves down to 0.04 (the surface where the text needs to be cut) and begins cutting.

( Profile Text 90-V )
( File created: Sunday, May 05, 2013 - 08:19 AM)
( for Mach2/3 from Vectric )
( Material Size)
( X= 9.000, Y= 12.000, Z= 0.750)
()
(Toolpaths used in this file:)
(Profile Text 90-V)
(Tools used in this file: )
(21 = Amana Signmaking V {90° 1.5"})
N100G00G20G17G90G40G49G80
N110G70G91.1
N120T21M06
N130 (Tool: Amana Signmaking V {90° 1.5"})
N140G00G43Z1.0000H21
N150S22000M03
N160(Toolpath:- Profile Text 90-V)
N170()
N180G94
N190X0.0000Y0.0000F60.0
N200G00X-1.6792Y2.0086Z0.2000
N210G1X-1.6792Y2.0086Z-0.4120F30.0
N220G1X-1.0775Y2.7066Z-0.4120F60.0
N230G1X-1.2171Y2.8269Z-0.4120
N240G1X-1.6008Y2.3818Z-0.4120
N250G1X-1.7857Y2.9859Z-0.4120
N260G1X-1.7969Y3.0215Z-0.4120


I think most of the issues I've been having can be traced to either work or tool offsets. It never occurred to me the tool number might cause an issue. Hope that's it...

Tom

20

General Mach Discussion / Haywire Mach3 and bit destruction

« on: May 05, 2013, 10:14:18 AM »

Greetings folks,

First a little about my setup.

I'm Tom and I'm new to both Mach and the CNC world. I'm an amateur loudspeaker builder and recently purchased and built a CRP-2448 from cncrouterparts. The machine went together slowly and I now have it up and running. I assembled all my own electronics including a SmoothStepper G540, PMDX-108 BOB and SuperPID. I have my Y axis defined as the long 49" axis, X as the 25" horizontal axis and Z is of course up and down. This machine uses two motors on X, they are wired as X and A on the G540. I have 6 limit/home sensors mounted on the axes. Three on Y, two on X and one on Z. Z has a "high limit/home" switch that defines zero at 5" above the spoilboard on startup. The intent is, or course, to prevent any undesirable plunging if I forget to use the tool height plate. X has two simple limit switches wired together that also serve to define home and a third "A" switch used to square the "A" side of the gantry after Y is set. I'm using the Dobutton(23,24) and recomb(9) code to set my home position and it seems to work fine. My Z zero code is listed below:

Code: [Select]

iF IsSuchSignal (22) Then
code "G31 Z-3 F20"
While IsMoving()
Wend
call SetDRO( 2, 1.9688)
code "G0 Z2.5 F60"
While IsMoving()
Wend
end iF

Problem:

I recently found the 3D samples on the Vectric forum and decided to cut a few as a test. The sample requires 4 tool changes during the run. First and second tool change went without a hitch. Third tool change I did the exact same thing but this time the Z axis plunged the bit below zero all the way to the Z axis limit destroying my piece and nearly destroying my bit. It was a 60° straight bit or it wouldn't have survived. I assumed I did something wrong and was able to recover and finish cutting the piece.

Next piece was the Vectric Fleur. First tool fine, second tool fine, third tool not so fine. This time I chucked up my brand new Amana 1045 45° V bit, the expensive one with replaceable knives. Set the Z height but didn't notice what the actual value was in the DRO. It started and again plunged the bit through the piece and before I could stop it, shattered the bit and stalled the router.

I've doubled checked the Z height code and can't seem to find any problems. It sets the Z height to 1.9866 which is exactly what it should be. Actual zero is -.002 below the workpiece so it's setting Z correctly. The code is cutting at a Z height of -0.45 for the first half of the pocket run and it runs fine a second time. I can't understand why this keeps happening. I've broken three bits now, this last one is not an inexpensive bit. It may have actually damaged the tool holder making the entire bit a waste of steel. I suspect something in the Zero height code is not working correctly but I don't know the quirks of Mach.

By my calculation the Z zero position must have been set to a large negative value in relation to absolute machine coordinates. That's the only way a plunge to -0.45 could reference below the spoilboard. I didn't think to write down the Z coordinate for debugging but I'll watch the DRO when I use the height tool from now on and see what it's doing.

Is it possible the Z DRO is not being set or being set to something other than 1.9866 by the code above?
Is there a bug in Mach?
Would it help if I were to add code to check the actual DRO against the set value to verify it was set correctly?
Help?!