#1
|
|||
|
|||
Some files don't cut smoothly - Mach's interpret. of G-Code from various CAM programs
Everything had been operating great until today.
Had some router problems, but minor and fixed (toolheads thread). Now, when running a cut code, the Y-axis has a noticeable vibration. I disassembled the Y motor assemble (swing plate, motor, pinion) and checked components for any loose nuts or bolts. Everything was tight. When jogging at 200 ipm, all three axis run smooth. When I run a cut file, with no router operating, and no DC, I get a vibration when it's transversing in the Y direction. The X-direction is smooth when running a cut file. The vibrations diminish around 60 ipm. At a loss, any suggestion would be appreciated. |
#2
|
|||
|
|||
Greg,
Sounds like RF interference if it was consistent. Do you get the vibration will running the cut file in the air? or when in material? Hmmm...gotta think about this one. |
#3
|
|||
|
|||
Sean,
I was getting the vibration while cutting, so I tried a "dry run" (no cutting) and vibration was still there. You can certainly hear it when cutting. It's like the Y-axis motor pinion is loose (it's not, I've checked). In the back of my mind, I keep thinking it has to be something I've done over this weekend. Before this weekend, it ran perfect. I've double checked the motor acceleration, velocity, etc...... hmmmm, I did dissassemble/reassemble the router. Better check I wired it correctly. |
#4
|
|||
|
|||
Did you disturb the ground wire from the z-slide? But that is a wild shot because it shouldn't be a factor with an un-powered router. All motor cable connections tight? Are you loosing y-position?
Did you ever tune the Gecko's to minimise motor resonance? |
#5
|
|||
|
|||
I did not disturb the ground wire.
I'm assuming (you know what assuming gets ya, so I had better check )that motor cable connections are tight. I am loosing position, but in the +X position. I was cutting two concentric circles. The wall thickness on the -X side is good. The wall thickness on the +/- Y is good. The wall thickness on the + X side is gone (I'll post pic tonight). Yes, I did tune the Gecko's. |
#6
|
|||
|
|||
...I would almost consider reinstalling Mach 3. It sounds like a bug?
|
#7
|
|||
|
|||
Thanks Sean,
I didn't even consider re-installing Mach. Pretty simple really. Kinda wondering if it's not in my G-code also (Vectric Pro). I'll generate new code tonight and try that first, then re-install Mach. |
#8
|
|||
|
|||
...I saw a very similar issue early on (I am sharing steps on the x axis across 2 gecko's) and I couldn't tell if It was a parallel port issue, hardware wiring or a Mach 3 issue. SO, I reinstalled and checked the LPT card. After that, I didn't see the issue anymore. Troubleshooting is never fun! Good luck.
|
#9
|
|||
|
|||
This is going to sound strange, but, I actually like troubleshooting. There is "something" about solving problems that fascinates me. Yea, the guys at work think I'm weird too.
|
#10
|
|||
|
|||
Remember you can drop the motors away from the racks to isolate mechanical from electrical issues.
|
#11
|
|||
|
|||
Greg are you cutting a file that you have cut before? Because of the way Mach handles exact stop and constant velocity..... G61, G64 I would try running each (1 at the time) and see what happens.
|
#12
|
|||
|
|||
Thanks Guys,
Let me grab a cold beer and I'll head to the shop to see what I can learn. |
#13
|
|||
|
|||
It's the G code
I have had no problems in the past with my G code when saving in the following format,
Vision G Code Inch (*.cnc) I have been using this format since the blue beast came alive. I don't know why I choose this format to begin with, but it worked. Well, tonight I save the G code in the new following format, Mach 2/3 Arc Inch (*.txt) and everything works great. Just for reference, I'm designing a new dust foot in Rhino 4.0 and generating G code with VCarve Pro. I've done this numerous times in the past with no issues. You learn something new every day (lets hope you do). |
#14
|
|||
|
|||
Just out of interest Greg, did you go back and try gcode generated with "Vision G Code Inch" again, to see if the problem came back?
It would be beneficial, if that was the problem, to find out why. Might help with some ones future issues. Greg (From Aus.) |
#15
|
|||
|
|||
Greg,
What I did last night, was to make a simple model in Rhino 4.0. The model was a 24 inch x 24 inch square with 2 inch filleted corners. I imported (dxf) the Rhino file into VCarve Pro and generated G code in both formats. Both formats ran perfect on the MechMate. I loaded the old G code (of the new DC foot) with the Vision G format. The jerky motion in the Y-axis was back. Next, I generated new G code with the Mach 2/3 arc format of the new DC foot. It ran perfect and smooth. There has to be something in the VCarve Pro model that I missed. Maybe some open vectors, or, whatever. I'll play around with it this week. |
#16
|
|||
|
|||
Greg post the g-code that is smooth and the one that jerks.
|
#17
|
|||
|
|||
Greg,
If it is VCarve Pro that is giving you problems, I would download the program again if it is the trial version or send them a email telling them of your problem. You may have had a download problem. |
#18
|
|||
|
|||
J.R.,
The G code with the "jerky Y-axis" is 750 KB's and over size limit to upload. The good file with the *.txt extension is fine to upload, but it runs fine, so no sense to upload. Send me your email address and I'll attach the files if your interested. Nils, I really don't think it's a VCarve Pro software issue. It may just be my model and the way I'm making the cut files. Let me play with it a little. |
#19
|
|||
|
|||
Tonight's Update
Tonight I was cutting the original part with the new G code (Mach 2/3 ATC arc (inch)-Format). Everything was going good, all axis were running smooth at 180 ipm, router RPM - 20,000, Material - MDF.
The "jerky" motion returned, but now on an X-axis. And get this, only on a short section of code. Going along the X axis in both directions, on one cut, everything was smooth and perfect. On a different cut section, the -X to +X was good, but the +X to -X was "jerky" The part I'm cutting has allot of complicated sections, but the jerky section was on a short, straight section, so if I wasn't watching, I would have missed it. This is getting very interesting to say the least. I think I'll send the files to Vectric and see what they have to say. |
#20
|
|||
|
|||
After hearing more description, my money is on JR's hunch. Take a good look at exact stop vs. constant velocity.
|
#21
|
|||
|
|||
Marc and J.R.,
I'll check exact stop vs. constant velocity tonight. |
#22
|
|||
|
|||
Here's the start of code with Mech 2/3 ATC arc (inch) format.
( 1 Base Pocket ) ( Mach2/3 Postprocessor ) N20G00G20G17G20G90G40G49G80 N30G70 N40T1M06 N50G00G43Z0.7874H1 N60S12000M03 N70G94 No G61 or G64. So maybe Mach's constant velocity settings might have been changed some how. I'll check later. |
#23
|
|||
|
|||
Attachment 2394
Above is a toolpath with the jerky/vibration motion. The toolpath was generated in VCarve Pro (Mach 2/3 ATC arc (inch)) and I'm running Mach. Would someone mind doing a dry run (no cutting) with the file and see if they experience the strange motion? The jerky/vibration motion isn't that bad, and won't damage your MM. I've tried G61 and G64 and same strange motion. I've also sent the file to Vectric, but have not heard back from them yet. I appreciate any help. Thanks, Greg |
#24
|
|||
|
|||
Greg this is line #2 in the file N20G00G20G17G20G90G40G49G80G64G61 When you remove the G61 from the end and run the file does anything change? The thing that's really strange about this is, it has both G64 and G61 in the line at the same time. These commands are modal and only 1 can run at the time????
|
#25
|
|||
|
|||
J.R.,
I added G61 and G64. That file must be the last edit I did. I tried G61 only, and G64 only. The last check was G61 and G64 together. All three runs did not change anything when it came to the strange motion. What is so strange, I just ran 4 other tool paths / cuts and everything was fine. I run this 5th tool path and I get that start/stop motion. Unless you can come up with something, my next step will be to re-install Mach this evening. |
#26
|
|||
|
|||
Greg, I havn't been analysing your g-code, but just something to consider . . . .
Does your toolpath make sudden changes of direction, or does one segment flow tangentially into the next? |
#27
|
|||
|
|||
Quote:
Came home from the day job early to start playing. |
#28
|
|||
|
|||
Greg, this old discussion on the Mach Yahoo group may be of interest:
http://groups.yahoo.com/group/mach1m.../message/57925 |
#29
|
|||
|
|||
Thanks Gerald, that does help.
VCarve Pro (VCP) is generating multiple positions along a straight line of one leg and not another. The crude solution is to edit the G Code and delete these multiple positions and leave the end position. That does work, but it's a "band aid" fix and doesn't get to the root problem. Besides, I hate writing/editing code. I'm am finding out that VCP does generate G Code differently depending on how my Rhino model is imported and how it's grouped/joined in VCP. I'll figure it out. |
#30
|
|||
|
|||
OK, Finally Got It Figured Out
It's not Mach or VCarve Pro, it's the Rhino 4.0 Model.
I redrew the linear sections in the model that were giving me problems. Everything runs smooth as silk now. In the "Bad" model, Rhino was representing the lines as NurbsCurve. (shown below) Rhino object: curve name: "" id: C33A0224-DD6B-4839-A6A9-91BCF051A3E7 layer index: 3 render material index: -1 (from layer) ON_NurbsCurve dim = 3 is_rat = 0 order = 2 cv_count = 2 Knot Vector ( 2 knots ) index value mult delta 0 -3.7159872855744229 1 1 -0.88020318664774244 1 2.836 Control Points 2 non-rational points index value CV[ 0] (-0.65901313595761357, 4.0392128427723391, 0) CV[ 1] (-2.6642142819734538, 2.0340096561246197, 0) In the "Good" model, Rhino represents the lines as PolyCurve (shown below) Rhino object: curve name: "" id: 25BD945D-F8CA-4531-AA79-B02382827991 layer index: 3 render material index: -1 (from layer) ON_PolylineCurve: domain = [0,2.83578] point[ 0] = (-2.6642142819734538, -2.0340096561246197, 0), 0 point[ 1] = (-0.65901313595761324, -4.0392128427723391, 0), 2.83578 Somehow in the process of making/saving/whatever, those lines were converted so the VCarve Pro modeled them as short lines. I sure hope that helps someone in the future. |
|
|