Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: Mach3noob on September 19, 2011, 01:25:41 PM
-
Hello,
I have a grinding application in which I use a cylindrical diamond coated bit to cut 2D parts from sheet stock that must be ground, not milled. The sheet is a laminate and one layer of it is very hard on the diamond, stripping it quite rapidly. I can cut more parts before a tool change is required if I oscillate the bit up and down. At present I do this by post-processing my g-code to add the additional movement, however this carries several disadvantages for me. It would be convenient to simply turn on a function from within my g-code that causes Z to oscillate up and down about its current position at a specified frequency and amplitude. Can anyone suggest a means of doing this?
Thanks.
-
THis is a process BEST handled by the Post from your CAM it would be a simple process for most CAMs.
NOW there are several ways it can be done inside MACH but it ain't pretty. I will look back thru the project notes and check it out again.
How complex is the average code you are working with? Do you use offsetts or Tool comp?
(;-) TP
-
Thanks for your reply.
My user name is Mach3noob. There's a reason for that. CAM program? We don't need no steenkin' CAM program! Seriously, Ive gone from coding entirely by hand to using a very nice but quite simple 2D CAM package that does most everything I need but certainly doesn't have this oscillation capability.
My code is quite simple, and at present I do use offsets or tool compensation.
-
Sorry, that should have been, "at present I do NOT use offsets or tool compensation."
-
What is the name of the CAM?
(;-) TP
-
SheetCAM. Allthough it has no oscillate feature, I just found out you can write your own post processors for it, and I believe you can access the current feed rate as well as arc and line parameters from within the Lua programming language in which they are written. That is enough info to break the lines and arcs into sections with ascending and descending Z movements to create the desired oscillation.
Still, I find this a PITA compared to simply turning oscillation on and off as needed. After all, the nature of the thing is to have Z oscillation that is independent of X and Y; breaking up each X/Y move into a variable number of pieces that depends on the feed rate feels inelegant, like forcing a square peg into a round hole. And if I ever switch CAM packages, I'll have to do it all over again.
-
That I am aware of there is NO CNC controller that can do z oscilations as a standard motion. (;-) There is NOT a gcode for it either.
Yes Scam could do it easy enough. You could set the frequency and amplitude based on OnARC() and ONmove() and then compare to units travel to set the Zdepth to oscillate with xy movement. Then on OnPenUp() you could make sure it raises Z back to safeZ before it does a rapid.
Like I said CAM is where it is normally done.
Just a thought, (;-) TP
-
Okay, I can take a hint - you REALLY think I should do this from within SheetCAM. Now just suppose I am truly nuts, and despite this excellent advice, I STILL want to do it from within Mach3. I would like to trigger some code that will start the Z axis oscillating, and another to stop it again. I would be content to have the frequency and amplitude hard-coded, as I expect to change these very seldom. How would you pull it off? I understand that there is no standard G-code for oscillation, but I was thinking the natural thing to do would be to rededicate and hook a pair of on/off M codes that have no meaning on my machine, e.g. M10/M11 or M23/M24.
-
Normally I would say not possible BUT Mach has a few tricks up its sleeve. I will do some testing to see IF I consider it safe to try it.
Can you post a SMALL program of the code you would normally run as a test base.
(;-) TP
-
Why not have some sort of mechanical/electrical oscillator on the axis in question then you could turn it on and off with a M code.
I occasionally do work for a guy that makes weird and wonderful electronic gizmos for the oil industry and one of them a while back had an oscillating action to it, cant remember the details but sure it was just similar to a solenoid valve with a few capacitors/resistors thrown in.
Hood
-
Below is a short program typical of the code I run, with comments added to indicate where I would like to turn the Z axis oscillation on and off.
Can a Mach3 brain be used to generate motor movements?
To user Hood: my Z axis is a pretty standard affair, it has a stepper motor that turns a lead screw. I can't get that to move with an analog oscillator driving a solenoid. I suppose I could design a digital circuit that, when triggered, disconnects the Z axis stepper pulse and direction inputs from the Mach3 PC and connects them instead to an independent pulse/direction generator that creates the oscillation. This seems like way too much work to me compared to any purely software solution however.
N0000 (Filename: Test Code.tap)
N0010 (Post processor: Mach3.scpost)
N0020 (Date: 20/09/2011)
N0030 G20 (Units: Inches)
N0040 G40 G90 G91.1
N0050 F1
N0060 (Part: Test Code)
N0070 (Operation: Outside Offset, 0, T12: Mill/router, 0.125 in diameter, 0.125 in Deep)
N0080 S10000 G00 Z1.0000
N0090 (Mill/router, 0.125 in diameter)
N0100 T12 M06 G43 H12
N0110 M08 (Flood coolant on)
N0120 S10000 M03
N0130 G00 X1.4240 Y0.4593
N0140 Z0.2000
N0150 G01 Z-0.125 F1
(TURN ON Z OSCILLATION HERE)
N0160 G03 X1.4568 Y0.4787 Z-0.1250 I-0.0000 J0.0375 F3.0
N0170 G02 X1.5990 Y0.5625 I0.1422 J-0.0787
N0180 G01 X1.9000 Z-0.125 F3
N0190 G02 X2.0625 Y0.4000 Z-0.1250 I0.0000 J-0.1625 F3.0
N0200 G01 Y0.1000 Z-0.125 F3
N0210 G02 X1.9000 Y-0.0625 Z-0.1250 I-0.1625 J0.0000 F3.0
N0220 G01 X0.1000 Z-0.125 F3
N0230 G02 X-0.0625 Y0.1000 Z-0.1250 I0.0000 J0.1625 F3.0
N0240 G01 Y0.4000 Z-0.125 F3
N0250 G02 X0.1000 Y0.5625 Z-0.1250 I0.1625 J0.0000 F3.0
N0260 G01 X0.3990 Z-0.125 F3
N0270 G02 X0.5412 Y0.4787 Z-0.1250 I-0.0000 J-0.1625 F3.0
N0280 G03 X0.6068 Y0.4787 I0.0328 J0.0182
N0290 G02 X0.7490 Y0.5625 I0.1422 J-0.0787
N0300 G01 X1.2490 Z-0.125 F3
N0310 G02 X1.3912 Y0.4787 Z-0.1250 I0.0000 J-0.1625 F3.0
N0320 G03 X1.4240 Y0.4593 I0.0328 J0.0182
(TURN OFF Z OSCILLATION HERE)
N0330 G00 Z1.0000
N0340 X0.0000 Y0.0000
N0350 M09 (Coolant off)
N0360 M05
N0370 M05 M30
-
What about THC? possibly that could be worked via a brain, then again Terry is the guy for plasma so probably no use as I am sure he would have mentioned it.
Hood
-
Sorry, you lost me - what does plasma cutting have to do with oscillating a grinding bit?
-
I believe Mach can control torch height independent of code for Plasma. I think it can be done via button or input so possibly a Brain could be used but as said Terry knows plasma well so if he hasnt mentioned it its likely not possible.
Hood
-
OK As to a simple SOftware only solution?? Close but no cigar. It is easy eanought to do with the THC control BUT I cannot find an access to that function INTERNALY through CB.
Now there WAS a software/Hardware solutoin we did years ago. (You are NOT the first to ask about this) where you take 2 outputs and rewire them to 2 inputs. THEN you set up a simple Flip/FLop loop to drive the thc up/down based on Z height and THCSPEED%. IT would give the down signal unitl the z got to a set point and then drive the ZUP until it hit the upper setpoint. The THCSpeed% controlled the speed at which the Z moved.
We used the M7 to turn the function ON/OFF so ANY cam could be used(;-)
SO that is the rest of the story, (;-) TP
-
BUT now that I said that I found and old NOTE where art had added that access into the brains section.
SO yes it may be possible. You would have to setup a brain to do the flip/flop function based on Z heigh and a lower setpoint. The M7 would trigger it to start osc and the M9 would shut it off.
THere you go Oscillation of the Z. A DIY CNC first event IF it does not crash you machine(;-) and tear up your tools.
(;-) TP
DANG GONE NOW I am going to have to try it to see IF it can be made usable. (;-)
-
Okay, this is cool! Thanks for your help. Is that note from Art available somewhere I can get at it? I assume you work at ArtSoft...
You used two acronyms that I don't know - CB and M7. Would you mind defining them, or just say RTFM and I'll go dig in the docs/videos if they're defined there (perhaps a hint as to which M to go RTF would be nice ;-).
-
Work At Artsoft? (;-) No. Most of us here are volunteers helping out the MACH3 community.
Notes ? These are project/trouble notes from the last 6 years working with Mach. Most are in an ancient form of low end gibberish(;-).
CB = Cypress Basic, the Mach3 form of the basic programming language used to create Function Macros or Mcodes than can be ran in Gcode.
M7 = An internal Macro that Mach3 used to turn ON the Mistcoolant relay. It is ready available in the CAM side of programing so no changes to the post required. You would just MONITOR that led indicator to see IF it is active then IF SO turn ON the OSC function.
I would tell you to RTFM and send you to the MACH LIBRARY to get the DOCs "BUT" ???????
(;-) TP
-
Wow, you have spent all this time answering my dumb-ass question as a volunteer. Thanks! Can I buy you a virtual beer? I don't see a smiley for that, unfortunately.
I THINK I understand enough now that I may be able to create a brain to do this. We'll see!
-
Let us know IF you get stuck, (;-) TP
-
Okay, will do. I am wondering about one thing though. Earlier you wrote that, while you thought Z oscillation was likely to be impossible, Mach has some tricks up its sleeve. Then we got onto this discussion about brains, and you gave me your ideas related to that. Were these the tricks you were referring to, or did you have something else in mind that you haven't even mentioned yet?
-
Just thinking outloud;
Set-up a second computer running Mach3, driving just the Z axis. Wire up a multi-pin plug for the Z motor power/encoder/tack feedback to make a quick changeover. The Z progam could be incremental steps rising and falling, with shorter steps at beginning and end of each end of travel to mimic a s-curve for smoother performance. Use a pot for feedoverride to regulate the speed of osscilation. Lots of cheap used computers out there, maybe even an old laptop would work. A second breakout board needed also. :)
-
> Let us know IF you get stuck, (;-) TP
Well, here I am over a year later finally trying to implement this (don't ask)... AND... I am stuck.
I set myself the simpler task of, upon an M7 Mist On code, moving the Z axis by any amount. I ran into two problems:
1) I first set up a brain that works exactly like the sample brain in the intro to brains tutorial video. That brain sets output 2 if the X feed rate is greater than zero. All I did was change the input from X Feed Rate to Mist On. The brain broke. When I watch it in the viewer I can see that the input block shows Mist Coolant On is 1 when I enter an M7 code, however the Compare Immediate lobe fails to light up.
2) I then decided to try modifying the output side, so that on X Feed Rate > 0 the Z axis would start moving. I cannot figure out what sort of termination block to create to do that. I tried for example to issue a Jog Z Right button press, which resulted in no movement when I started the X axis moving. Perhaps this is because the jog buttons are ignored when G code is running? In any event, I am not sure how I should be getting the Z axis to move in tandem with ongoing X/Y movements coming from my G code.
I appreciate any help anyone can provide...
Thanks.
-
In all honesty this is something BEST handled from your CAM. It can add the code in to do the up/down and amount moved based on amount of travel of the cutter.
The THC function on MACH3 is a SLAP and go feature. You cannot really control how much it moves it just does until you release control.
(;-) TP
-
Thanks, I know I can do this by pre-processing my G code, but there are various reasons why I still want to be able to just turn the Z oscillation on and off with an M code. Earlier in this thread you pointed me in the direction of using the M7 code to trigger a brain that does the oscillating. i am stuck in the two ways I mentioned: can't seem to trigger the brain from the Mist On LED, and can't seem to find a way to trigger a Z move from within the brain. If anyone has a clue about either issue I would greatly appreciate hearing it.
-
OK IS it possible yes I just did it . IS it reliable and safe NO. MACH3 does not have 100% control over the sync of the CB thread and it can run away.
SO being it is a safety issue I am not going to talk about it further.
It would have to been done internally to be safe and that would be up to Brian to create.
IT IS a good idea though, (;-) TP
-
Thanks for trying. You mentioned that you did it with a CB thread - would that be a macro pump, or a brain?
-
Macro PUmp That way you CAN compare the Z height to drive the function up and DOWN (;-) IF I can find a way to make it safe I will get back to you.
That's all , (;-) TP
-
Is there a way to get a brain to issue a Z move command, or to generate pulse and direction outputs directly to the Z axis? That had been our original thought.
Thanks.
-
No there is not a "direct" way from the brain. (;-)
(;-) TP
-
Still working on it,
I have seen some of the strangest things doing so.
(;-) TP
-
Do tell! ;-)
Thanks for working on this.
-
OK is this possible from Mach3 CB ? yes
Will I release the test CODE? NO it is still dangerous. THe running of such a function COULD end life as we know it on this planet (;-) .
What you have to do is Hard wire through relays 2 outputs from MACH3 back into the LPTport pins and setup THCup and THCdown as inputs
Next create code to trigger the thc to go down unitll you are a certain level. THEN trigger the THC up to go back up to a certain level.
IT takes DO while loops running concurrently to make it function. The big problem is keeping the CB macro from buffer overflow. IF it does then ODD things can happen and uncontrolled movement HAS been know to happen. ALSO you have to make SURE you do not overload the CPU as then either the Gcode or MACRO or both will lock up.
You also have to provide safeties to be able to break out of the loops AND safely shut the function down or you can end up in an infinate loop with no easy way out other than [CTRL ALT DELETE} and reboot.
IF you error out you MUST restart MACH3 to clear the CB threads that can create a problem by showing up later in your code.
IF " I " can figure it out YOU can also(;-) , (;-) TP
-
Well, I can see why you think I should stick to doing this via a pre-processor!
I am curious though - I am using Mach3 to generate step and direction signals that go to a Gecko stepper motor controller. How are you getting from the THCup/down to actually driving the Z stepper?
-
The THC up/down is an internal function of MACH3 used for plasma systems that HAVE a THC device.
IF you input a signal on the LPT pin that is setup as THCdown() MAch3 will drive the Z down reguardless of the Gcode values. It overrides the Z position internally and drives the Z down.
Same with THCup() only it drives the Z up.
YOu can build a simple 2 button systems and manually control(overide) the Z DURING a GCODE program run. THe problem here is you do NOT have precise control over the Z. It just does a TURN ON THE DRIVE to go down or TURN ON THE Drive to go up. (SLAP AND GO) The THC device itself regulates the Z based on the arc voltage it sees from the plasma cutter.
NOW you could build a simple SMALL variable speed (DC) gear reduction motor that has a disc with slots and and 2 optical switches 180 degrees apart. When the signal #1 turns ON then activate the THCdown() and when the signal turns off stop.
When Switch#2 turns on then active THCup().
You would have to adjust the speed based on the time you need each function to work. NOT precise but could work. You can also adjust the %speed of the Z motor
(;-) TP
-
Thanks for the explanation. So if I could generate signals to THCup and THCdown with great precision, would you say that this would give me precise control over the Z movement? Because I can generate signals that are good to better than a microsecond very easily (meaning THCup for X microseconds, pause for Y microseconds, THCdown for X microseconds, pause for Y microseconds, repeat). If X and Y are stable values, do you think I can get exact repeatability, same as if I did G code to move up and then back down over and over?
-
Pretty close (;-) You will just have to try it.
(;-) TP