Shark seems to be cutting at a very small scale

How-to videos on the CNC Shark

Moderators: sbk, al wolford

Shark seems to be cutting at a very small scale

Postby ManchesterSchools » Tue Nov 28, 2017 1:36 pm

I have recently set up my first CNC rougter, the Shark 4HD. My daughter sucessfully ran a simple job on it 5 days ago then she went back to college. I am not having the same success. I am trying to cut a square. I created the vectors in VCarve and saved it as a G Code TAP file to a USB thumb drive. The pendant sees the file but when I run the file the cutter moves no more than 1/8" in any direction. The more complexe the job, the longer the cutter runs, but it stays within the 1/8" area. It is as though there is a limit set on the cutting area. Any thought?
ManchesterSchools
 
Posts: 1
Joined: Tue Nov 28, 2017 9:43 am

Re: Shark seems to be cutting at a very small scale

Postby Kayvon » Tue Nov 28, 2017 6:08 pm

How big is it supposed to be? Maybe 6 inches? If so, you may have set VCarve to cut a 6mm object rather than a 6in object (6mm = ~1/8in).
User avatar
Kayvon
 
Posts: 273
Joined: Tue Oct 21, 2014 11:46 pm

Re: Shark seems to be cutting at a very small scale

Postby tonydude » Thu Nov 30, 2017 12:22 am

Are you using the correct post processor?

Tony
Attachments
pp.PNG
Buffalo,NY

"What will matter is not what you bought but what you built; not what you got, but what you gave”

Aspire 8.511, photo vcarve, cnc mako shark extended bed, control panel 2.1
tonydude
 
Posts: 1419
Joined: Tue Aug 17, 2010 9:23 am
Location: Buffalo,NY

Re: Shark seems to be cutting at a very small scale

Postby Kayvon » Thu Nov 30, 2017 11:22 am

Actually, either post processor will work. If you select the mm post processor, the lengths will be converted to mm for you and, of course, interpreted as mm. Likewise with inches. So that's not making the difference.

There's a misconception on the forum that the post processor will take, say, a 3-inch square and cut it at 3mm. Reading the documentation reveals this isn't the case and a quick experiment confirms that's not how it works. Here's a simple test:
http://www.cncsharktalk.com/viewtopic.p ... =10#p29037
User avatar
Kayvon
 
Posts: 273
Joined: Tue Oct 21, 2014 11:46 pm

Re: Shark seems to be cutting at a very small scale

Postby Rando » Mon Dec 04, 2017 1:22 pm

Kayvon wrote:Actually, either post processor will work. If you select the mm post processor, the lengths will be converted to mm for you and, of course, interpreted as mm. Likewise with inches. So that's not making the difference.

There's a misconception on the forum that the post processor will take, say, a 3-inch square and cut it at 3mm. Reading the documentation reveals this isn't the case and a quick experiment confirms that's not how it works. Here's a simple test:
viewtopic.php?f=2&t=5294&start=10#p29037


Actually, there is (was?) a condition in which the controller behaved unexpectedly, but it was related to at one point there not being a G20 (not G70/G71; thanks for the correction, Kayvon!) in the output file. If the CP software was set to inches, a mm-file that didn't include the units definition line could cause ugly problems where the controller assumed inches and took the mm numbers as 25.4x what was really wanted. It's not entirely clear in the GCODE RS-274 specs whether failing to initialize the units is an error, and this controller just assumes it's whatever it used last. So as long as there is that code in there, it should be okay.

However, note that the G20/21 has to be before any other movement, AND it can't be changed within the same program. Which means that if you're combining tap files to increase operations efficiency, you have to make sure there are no extra G20/21 in the other toolpaths. That and other controller-dependencies made me eventually write a custom program that slices up conjoined tap files into individual operations, and then recombines them based on my processing desires, and properly handles the preamble (where the G20/G21 go) and closing portions.

But, have no fear. Just when you thought the controllers were stable, it's revealed that specific, unnamed requirements in the post-processor file keep the whole thing working. For example, while coordinates like X0.250 and X-0.250 are allowed and make sense, X+0.250 is NOT ALLOWED by the controller I have, and it fails with nothing more informative than a "communications error". I'm always amused and surprised to stumble across these little areas of software fragility.

Okay, so maybe you didn't ask ;-)...

Regards,

Thom
Last edited by Rando on Mon Dec 04, 2017 4:28 pm, edited 1 time in total.
=====================================================
ThomR.com Creative tools and photographic art
A proud member of the Pacific Northwest CNC Club (now on Facebook)
Rando
 
Posts: 465
Joined: Tue Jan 06, 2015 3:24 pm
Location: Hoquiam, WA

Re: Shark seems to be cutting at a very small scale

Postby Kayvon » Mon Dec 04, 2017 3:03 pm

The post processor use G20/G21, rather than G70/G71. G20/21 are preferred, even when interpreted synonymously, because G70/71 have an alternative meaning that has something to do with repetitive finish cycle diameters. I know Mach3/4 software can take either pair, but even their documentation says, "See also G20/G21 which are synonymous and preferred."

I wasn't familiar with the prior problems causing erratic controller behavior, but the G20/21 used as part of the current post processor files prevents any issues. Additionally, Vectric's software does the mm/in conversions for you behind the scene to align with whichever tag is in use, so there shouldn't be any problems. Unless maybe you conjoin mixed tap files, I guess--I've never tried that.
User avatar
Kayvon
 
Posts: 273
Joined: Tue Oct 21, 2014 11:46 pm

Re: Shark seems to be cutting at a very small scale

Postby Rando » Mon Dec 04, 2017 4:26 pm

Kayvon wrote:The post processor use G20/G21, rather than G70/G71. G20/21 are preferred, even when interpreted synonymously, because G70/71 have an alternative meaning that has something to do with repetitive finish cycle diameters. I know Mach3/4 software can take either pair, but even their documentation says, "See also G20/G21 which are synonymous and preferred."

I wasn't familiar with the prior problems causing erratic controller behavior, but the G20/21 used as part of the current post processor files prevents any issues. Additionally, Vectric's software does the mm/in conversions for you behind the scene to align with whichever tag is in use, so there shouldn't be any problems. Unless maybe you conjoin mixed tap files, I guess--I've never tried that.


Right...I was reading backward through the list of G's and came to 70/71 first, not thinking :D. Thanks, I'll fix my post :D.

There is a significant "perspective" difference that is important to note here: for erratic behavior of a machine in an environment where customization is EXPECTED, it is IMO not acceptable to expect that only the unchanged, company-issued files are somehow authoritative for use. To say that a post file or application is somehow error free is absurd on the face of it. Not only for the bug-free fantasy, but the silly idea that the actual controller requirements (embedded or implied in the post) somehow don't need to be identified because everyone should be using the specific software and post files that they give us. Well, the world doesn't work that way. I use Fusion and BobCAD as well as Vectric, just a few of dozens of CAD/CAM packages that might be used with a Shark CNC controller. Nearly all of those have non-company issued post files as default. Heck, I'm not confident NWA even COULD make a Fusion post file from scratch: it's actual C-style code. The idea that somehow not identifying the low-level requirement to set the units in the file, or that a + in an address value is somehow a fatal error, is the lazy company's way of saying they don't really understand their own controller. They're saying that after many hours, they got it to work, and please, Dear GOD, nobody breathe on it because they don't actually know what made it work. Engineering BS, if you ask me, that results in a) having no real reference as to the system requirements, and b) a bunch of really smart people struggling with and having to figure out why a + sign breaks everything, or why there's a new hole in the bed because of a minor post-file error leaving a crucial setting uninitialized, or why it clips the side of a part on the way out, or any of a number of strange behaviors related to post processor files and often fully-conformant controller behaviors.

I'm sure you remember the excessive G64 value that was in the posts, and causing part gouges and out-of-tolerance parts? Another excellent example of a bug that NWA intentionally put in there. It's things like that that make me not confident that "just use what they tell you" will produce acceptable results. I'm only willing to say "I'll use it if and when my review shows zero changes needed." ;-).

As for the slicing and dicing, I tend to use the "currently in-use" bit for roughing and the "next in line" bit for finishing, even when they're the exact same geometry. By doing all the roughing and then all the finishing for a single part/machine-setup, and combining the individual toolpaths, I reduce the bit-changes and file-loads to a minimum. When there's just a v-carve and a profile, it's not a problem. When there's 40+ individual features across six different machine setups (think a cube with machining on all sides), it becomes problematic to make even minor changes. In BobCAD, I can output every single one of the toolpaths into a single file, and then my software does the "splatter-gather" operations, stitching them together based on a line in a text file, and then naming them in step-sequence for easy loading. ;-)

Cheers, and thanks for the correction, greatly appreciated!

Thom
=====================================================
ThomR.com Creative tools and photographic art
A proud member of the Pacific Northwest CNC Club (now on Facebook)
Rando
 
Posts: 465
Joined: Tue Jan 06, 2015 3:24 pm
Location: Hoquiam, WA

Re: Shark seems to be cutting at a very small scale

Postby Kayvon » Mon Dec 04, 2017 6:32 pm

Yuck. Sounds like it's a case of only partially implementing a standard, then hoping nobody tries anything outside of exactly what you got working.

Thanks for the thorough reply, Thom. I think we lost the original poster a week ago after he submitted his only post. Hopefully he got it working, though it'd be nice if he'd follow up here to let everyone know.
User avatar
Kayvon
 
Posts: 273
Joined: Tue Oct 21, 2014 11:46 pm

Re: Shark seems to be cutting at a very small scale

Postby Rando » Mon Dec 04, 2017 8:03 pm

Kayvon wrote:Yuck. Sounds like it's a case of only partially implementing a standard, then hoping nobody tries anything outside of exactly what you got working.

Thanks for the thorough reply, Thom. I think we lost the original poster a week ago after he submitted his only post. Hopefully he got it working, though it'd be nice if he'd follow up here to let everyone know.


Totally welcome for it...I often add these longer answers to an older post just so the next person will find it without the delay of asking. And so I won't have to remember it (accurately) next time it's asked :lol:
=====================================================
ThomR.com Creative tools and photographic art
A proud member of the Pacific Northwest CNC Club (now on Facebook)
Rando
 
Posts: 465
Joined: Tue Jan 06, 2015 3:24 pm
Location: Hoquiam, WA


Return to CNC Shark videos

Who is online

Users browsing this forum: No registered users and 2 guests