getting really really really annoyed with photovcarve

Dan Noren

Moderator
Staff member
Messages
7,984
Location
falcon heights, minnesota
tried to do some more stuff with this cursed software, with the usual results, all bad. tried a pic of the wife and i with mr peanut, and as usual with photovcarve, even though you tell it bottom left, it zooms to bottom right to start working its magic. no sooner than it had gotten to the corner, it zipped up and to the left, and started from there. since i hadn't tried it on real wood, i decided to use a scrap bit of walnut. needless to say, the results were less than spectacular (downright cruddy), the only way i could tell if anyone was in the pic, was to hold it at arms length, and tip it back some, and even then, it was touch and go. so i cancelled the run, and started a pic of our dad, figuring that that may work, on a bit of odd red oak. got my hopes up too high again. after 2 hours of it going back and forth, back and forth, back and forth, it decided after making its run from lower left to upper right, to zoom straight down, then back to where it was, went down and to the left, then back up and to the right, then hammered the bit right into the wood, right up to the collet nut, after vacuuming the dust (wanted the image to be a surprise), and giving it a quick coat of amber shellac, the image was just plain awful. right now i'm just about at my wit's end with this software. first, it didn't have the post processor for grbl, then got the patch for it, and it wouldn't accept it, then put in patch mkII, sort of works with the program, now with this latest misadventure, i'm just about ready to demand a refund. if anyone has any ideas, i'm wide open to them. the vectric people have referred me to the forum, as they cannot tell what is going on with the software.
 

Attachments

  • pop test3.JPG
    pop test3.JPG
    82.2 KB · Views: 30
  • pop test 1.JPG
    pop test 1.JPG
    50.7 KB · Views: 26
  • pop test 2.JPG
    pop test 2.JPG
    51.8 KB · Views: 24
  • pop test 4.jpg
    pop test 4.jpg
    50.6 KB · Views: 30
  • pop test 5.jpg
    pop test 5.jpg
    82 KB · Views: 42
Don't know what to tell you. There's a learning curve for sure. Been playing with my new laser toy and there's a lot more gotchas than I wanted.

But I'm going small and just working my way through some small projects and scrap before I get to deep into things. Kind of fun to learn new things.

I look at like learning to play an instrument or anything else. I figure it takes time to get good at it.
 
Weird. I know nothing about this stuff, but I wonder if the photos need some kind of prep work to level things out before it gets processed? Just from my playing around with my little toy, I've been discovering that more time in the software helps in what comes out.

You guys know way more than I do, but just wondering if there was some kind of off 'pixel' in the picture that caused the shapeoko to commit hari kari?

I'm sure someone with more experience will chime in. And I'm watching. I may want to get into this someday.
 
PhotoVcarve was the first thing I bought back in 07. I DID do a couple of lithophanes on corian and they were pretty cool. At that time my machine was in it's original state so the finishes were not what I can do today.

I think I tried what you are trying, but I never really went in that direction. I cannot advise.

That is all I have done with PhotoVcarve- or PVC for short.

I can say that since 2007 I have seen some really awesome stuff done with PVC, so I am CERTAIN is it possible. It is NOT junky software, but it DOES take some learning.

One of the staff members recently posted to darken the v-grooved lines to get the image to pop.

I must FULLY AGREE with the response that Vectric gave you - use the user forum. That place is by far the best support you will find. There are users there that CAN help you through the issues you are having.
 
I've just started making lithophanes in Corian and so far so good. I've got a few settings to get honed in still but decent results. Is there something in the gcode that's burying the bit or is it maybe some kind of interference? I don't use any post processor other than the generic gcode-inch export so I don't know about that. Hope something comes to light soon! I know wood is hard to get good PVC results in. Have you looked at HalfToner (free), it makes nice drilled or lined photos that come out pretty good in wood. PVC is so detailed that it takes quite an artist to get crisp results in natural material.
 
I got to see a Shapeoco 3 yesterday and the problems he is having with it all seen to go back to the control board that Shapeoco is using it seem to have a lot of glitches like you are talking about. To me and this is just my opinion junk there system and go to Mach 3 and a new driver board and you will solve a lot of your problem and be happier in the end. :dunno:
 
Having seen the gcode output the last time, I am certain the problem is NOT pvc -- there was nothing in there making it do that on purpose.

I think it's somewhere else in your train but I said that last time. I don't know where, and I don't know how to advise other than the suggestions I gave last time. What does your gcode preview show? If it doesn't show those moves, it's not a CAM problem, it's a control problem.
 
Ditto on the comments about learning curve AND participating in the Vectric Forum. I've been a member of the Vectric Forum since buying VCarve Desktop and PVC a while back and it's been great for learning details about both.

As to the skipping around you've seen, that has to be the way PVC is setting up toolpaths. All the control system does is use the commands from what ever software is used. I've practiced with several photos but mostly with one so far. PVC always starts at the lower right, working from there to upper left. In almost all of my projects, I used the center point as the origin; it's become a personal preference.

With the success I see others having with the Arduino/Gshield boards as well as my own experience, there's no reason to bail on them.
 
As to the skipping around you've seen, that has to be the way PVC is setting up toolpaths.

I would agree if there actually were those lines in the gcode. I saw some of it the last time and there was NOTHING moving things around like that in the code.

All the control system does is use the commands from what ever software is used.

In theory, that's true. Assuming everything is working properly and you don't have mechanical or electromechanical issues like signal noises or bad connections/components somewhere.

The path to solving this is to make no assumptions - trust, but verify the code is correct - trust, but verify that control software is acting properly - trust, but verify there's no signal noise or other hardware level problems going on.

To blame this on PVC without any gcode showing problems is not going to solve this. From what I saw last time, the output was fine and the problems lie further downstream. I'm sure i sound like a broken record - but the gcode preview in mach3 tells me everything i need to know about whether it's a gcode problem or not. I would hope you have a similar preview tool available to you. If not, i'd consider it an inferior method and go to emc2 or mach3.

At the very least, go grab NC Corrector and load up your gcode there. It's not the greatest app, but if I didn't have any other way to preview my gcode, it's what i'd use.

All of this is under the assumption that the gcode is clean - I can only guess that it is from the last gcode I saw ... Dan, attach the gcode and some of us experienced guys can comb through it to see if anything sketchy comes up.
 
You guys know way more than I do, but just wondering if there was some kind of off 'pixel' in the picture that caused the shapeoko to commit hari kari?

Kinda, but not quite. Most of the algorithms take averages so a single pixel wouldn't send it off.

But. Even if one could, for the sake of argument...

It would be very obvious in the gcode preview - you'd see lines jutting all over and one sending the tool into the table up to the collet. If it's the gcode, there has to be a command in there telling it so. It's not voodoo, it's very simple text - there'd need to be a command telling Z to drop super far.
 
... The path to solving this is to make no assumptions ...

Exactly! Making the assumption that the control boards are an issue when tens of thousands of people use the same setup without issue is poor reasoning.

When Dan had a problem with a previous PVC photo, he sent me his gcode. I loaded it into OpenSCAM to view it and it looked fine. I loaded it into GRBL Controller and it looked fine in the viewer. I then loaded it into UGS, brought up the viewer and it looked fine. Next I ran the job with UGS feeding my controller which is identical to his and it ran fine.

The main difference between Dan's setup and mine is the wiring arrangement. He followed the Inventables instruction pages. I did a custom installation because I wanted to place my electronics in a box on the wall with power supplies on a shelf under my machine. My cables are 2-3 times the length of his; so far I have had no indication of crosstalk. That's not to say I didn't have some missed steps in the beginning but I tweaked the drive current until I got no skips.
 
Dan I just read your posts on the Vectric forum.

I know you are frustrated - but - when you go into a user forum where well over 90% of the population is extremely happy withthe products and you seriously criticize and bash the company - THEN - want help ---- WELL - that does not set a very good tone.

Still - the responses to use were kind - gentle and helpful.

Just sayin - that's all.

It is a learning experience. The software is good and sound - That is NOT where the problem is at.

Go back to Vectric user forum. Don't bash the software. Break your questions down to basics.

I don't know Arduino, I don't know Shapeko. I DO have an engineering Bachelors degree in machine design. I do have 40 years experience working with literally hundreds of machines. I do NOT need to know your machine to know how it works - and it is not unique. I also have tons of experience with programming and with training lots of people.

That said - I will tell you - slow down, take it easy. I do not mean to disrespect you - but the problems are MOST likely something that you are doing. Again - Don't Assume anything. Don't assume everything you are doing is correct.

Ask simple basic and specific questions, and be nice - you will very likely get some good answers. The population on the Vectric forum will help even if it is not a Vectric related question. BTW - Adrian is a high level professional.

There are lots of great examples of really great stuff done with PVC. Don't assume the software is bad.
 
... There are lots of great examples of really great stuff done with PVC. Don't assume the software is bad.

I haven't been on the Vectric Forum today so I can't speak to the rest of your post, Leo. Your last statement is spot on. I've been amazed at the quality of the PVC project that have been posted there. I have a lot to learn to achieve anything like what some of those folks have done!
 
I wonder if speed is a factor ... how fast are you telling it to cut?

Have you done any other cuts similar to this (basically 3D cuts or anything moving all 3 axes at once at a similar speed).

It's my belief that since bob had no trouble with the gcode that it's AFTER pvc - so i'm thinking control or mechanical -- maybe noise, not sure. Noise may be the thing... interference screwing up the pulses ... those are always hard to suss out ... but I have heard that cutting speed can be a factor there - slowing down sometimes helps, so i'm told.
 
If it were noise, wouldn't it be showing up in anything done with cut2d as well? I haven't had any problems with the cut2d side like I have with pvc. Unless I have forgotten to reset the zero point (and I had done that often enough enough starting out), I have never had cut2d go from its start point of the cut, cutting up and to the left, then starting the programmed cuts at that point (ignoring all cuts in the lower right-hand corner completely), then after cutting according to the program, go straight down, then back up again, cut a few more lines, then try to plunge the bit into the board. Hasn't happened with cut2d, but several times with pvc. If I remember correctly, I think the speed was in the neighborhood of12feet per minute.
 
If it were noise, wouldn't it be showing up in anything done with cut2d as well? I haven't had any problems with the cut2d side like I have with pvc. Unless I have forgotten to reset the zero point (and I had done that often enough enough starting out), I have never had cut2d go from its start point of the cut, cutting up and to the left, then starting the programmed cuts at that point (ignoring all cuts in the lower right-hand corner completely), then after cutting according to the program, go straight down, then back up again, cut a few more lines, then try to plunge the bit into the board. Hasn't happened with cut2d, but several times with pvc. If I remember correctly, I think the speed was in the neighborhood of12feet per minute.

I assume that you've posted or sent one of us your gcode to inspect? If not, I'd be happy to take a look at it, just shoot me a pm.

For the noise, you might consider isolating the controller by plugging into a separate circuit in the garage. If you don't have one, perhaps you have a small UPS that you can use to to plug the controller and laptop into to filter out any noise from the router. Also make sure that your power cord for the router isn't in the same loom as your motor or limit switch cables.
 
If it were noise, wouldn't it be showing up in anything done with cut2d as well? I haven't had any problems with the cut2d side like I have with pvc. Unless I have forgotten to reset the zero point (and I had done that often enough enough starting out), I have never had cut2d go from its start point of the cut, cutting up and to the left, then starting the programmed cuts at that point (ignoring all cuts in the lower right-hand corner completely), then after cutting according to the program, go straight down, then back up again, cut a few more lines, then try to plunge the bit into the board. Hasn't happened with cut2d, but several times with pvc. If I remember correctly, I think the speed was in the neighborhood of12feet per minute.

at 12 FEET per minute, that's 144ipm -- that's pretty dang speedy. I wouldn't rule out noise because the cuts being made are much more intricate than anything you've sent through cut2d -- those typically don't involve a bunch of direction changes on the Z usually. I'd try something more like 10-20 INCHES per minute and see how it does.

Noise is never logical or consistent. If your machine is being pushed too fast, noise can be a lot more likely. My first test would be to slow it WAY down - assuming that really was FEET and not INCHES already. My machine couldn't do 144ipm on a litho or 3D cut... so if it was really the speed, I would immediately suspect the machine's being pushed too fast.
 
Top