Hello Guest it is November 29, 2021, 04:24:23 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.

Topics - siggma

Pages: 1
This is "a down and dirty" edited version of the 1024_RPM.set from this post: https://www.machsupport.com/forum/index.php?topic=21899.0 which is an update of 1024.set included with Mach3. I've added two additional user DROs to display VFD frequency and VFD amperage from the http://royaumedeole.fr/informatique/plugin-mach3-pour-vfdhuanyang/mach3-plugin-for-huanyang-vfd/ (Le royaume d'éole)

Configure the RPM display by selecting the dropdown for RPM then enable the user DRO by setting it to 2222
Configure the frequency display by selecting the dropdown for frequency then enable the user DRO by setting it to 2223
Configure the amperage display by selecting the dropdown for amps then enable the user DRO display by setting it to 2224

General Mach Discussion / DoButton vs DoOEMButton
« on: June 01, 2013, 10:47:04 AM »
I've been having difficulty auto squaring my slaved axis. The script that comes with Mach3 uses "DoButton(x)" but all the reference material I've seen says this is deprecated and should not be used. The references (2010 version) say DoOEMButton(x) is preferred. I'm also using a smoothstepper and apparently cannot use RefCombination() yet due to an issue with the plugin. The programmers reference says to look for "CB Constants" as a reference to the axis numbers to use with the DoOEMButton() call but I cannot find any such section in any of the programmers reference or other documentation. What gives?

Does someone have a listing of OEM button numbers that includes the axes and maybe an example using DoOEMButton to zero an axis? I want to be able to square the master and slaved axes separate. If I don't I end up with the slaved switch tripping after the master axis homes.

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

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?

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?

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()
call SetDRO( 2, 1.9688)
code "G0 Z2.5 F60"
While IsMoving()
end iF


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?

Pages: 1