Shark not recognizing different vectors depths

[Sdanjou]

I have a Shark 2.0 that I have been using for the last two years. I have routed over 1000 of the same plaques using the same images. Up until two weeks ago, the machine recognized the thinner lines in the images and routed them shallower than the thicker (wider) vectors. The images were great and showed a lot of detail. For the past two weeks, the machine will not recognize the different depths and the entire image is routed at the same depth, resulting in a washed out image with not detail.

I am routing at a depth of .075 and using a 60 degree V bit. This is the same setup I have used for the past 2 years successfully. All of the settings are the same but the results now are horrible. I have been on the phone with NextWave trying to figure it out and also spents a couple hours on the phone with the folks at Vector in London. We can't get this figured out. The machine is not the problem as I have sent the files to Next Wave and they have been run on two of their machines with the same, horrible results. We have tried using a different post processor, but still not change.


I have also re-imported the image and created a new .crv and .tap files in case the original .crv/.tap files were corrupted. Still no change.


Frustrating to say the least. Can anyone offer any help ????/


Steve

[Kayvon]

That sounds frustrating. You've already ruled out a problem with the machine by having the Next Wave guys test the file independently. That implies that the file generated by VCarve/Aspire is the problem.

That leaves two likely possibilities:
1) There's a problem with your .crv project. Something changed that you didn't notice. You said you're using the same file you've always used. Would you mind uploading it (or a subset of it that generates the problem) for others to verify?
2) There's a bug in VCarve/Aspire. This is pretty rare, but I have seen it happen. I've reported two bugs in the several years I've used it. One was quickly confirmed and a fix planned for the next version (which I don't own). The other was user error on my part.

[Sdanjou]

I was thinking the problem was with the .crv file I used as well. To rule that out, I took one of the images I use on that file and uploaded the jpeg of the image into a new .crv file and traced the vectors as always. Still the same problem. I also emailed the original jpeg to Next Wave and had them import as well. Same results on their machine.

Even the original files I used 2 years ago are now having the same problem. If I had made some change. or continuing to re-use the .crv file resulted in some corruption, shouldn't the original file still be good???

When I talked to Vectric, they checked the file and emailed me:

"Looking through your file, I see that you have the line:
G64 P.1
Looking back on the last set of Nextwave Post Processors this line is now output at G64 P.01
Might their controller update now require this to be the .01 value, and you are still using older Post Processor that previously worked with the older firmware?

According to Next Wave, the output variance from .01 to .1 is not an issue. I have no idea what any of that means to know one way or another. As for the Post Processor question from Vectric, I am using the newest post processor and have update the software and all firmware updates. This has been confirmed with Next Wave.


I am thinking that there was some firmware update that doesn't sync up correctly with the reading files with varying vector widths. Could this be the problem?

Steve


I

[Kayvon]

The G64 operator is for tolerance. It just tells the machine, "You only need to be this close to be good enough." The difference between P0.1 and P0.01 is the tolerance of 0.1" and 0.01". It's not an issue. (Incidentally, it's also the only difference between the two post-processors: 3d contour and arcs.)

Varying vector widths doesn't sound like the culprit either, at least in the G-code file. The g-code merely tells the machine, "Move here." There's no width involved at that level.

Can you narrow this down the the simplest path possible that still produces the problem? Try eliminating half the vectors and see if it still occurs. If the problem goes away, hit "undo" and delete the other half of the vectors. Eliminate as much as you can and it will be much easier to see the problem.