This probably isn’t the problem you are having, but it may help later down the road with those big g-code files… make sure that the computer sending the g-code won’t go to sleep and will keep the USB port active.
I tried PicSender, and I’m still having problems. Maybe somebody here can help point me in the right direction.
I generated a small (about 1.6MB) .gcode file from PhotoVcarve using the generic Gcode postprocessor. The job used a 1/8" ball nose to 1/3" cut depth, linespacing set to 50% as a rough cut.
Checked the .gcode file with a file checker (can’t remember the name of the program at the moment), and it seemed to parse fine. It traced the tool paths onscreen, and nothing looked incorrect.
Used PicSender to serve it up to my X-carve. I placed the bit, zeroed out my XYZ, and ran the file.
At first, it all went fine, properly starting at the bottom right and moving up and left at a 45 degree angle. But then it went wonky, and started bringing the Y axis much too far down. I watched the thing go for a couple of minutes, then killed it. See image below.
OK, so that didn’t work. Maybe if I use the X-carve for Vcarve Desktop postprocessor. Oh wait, PhotoVcarve won’t load, it throws an error on startup. So I found a tweaked version of the postprocessor (with arc parsing commented out, I believe), and generated another gcode file, this time saving as .tap format.
Again using PicSender, served it to my X-carve. This time it went crazy earlier - see below.
All righty then. Mechanical problem? Nothing felt too loose or tight. So without changing anything on the table, I created a quick circle and two stars design in Easel and carved that job. It took about an hour, but turned out perfectly. See below.
Since Easel is properly cutting jobs, it seems that the machine is mechanically in OK shape, and the gShield and Arduino are working properly. The only variables are the program that generates gCode (Easel vs PhotoVcarve) and the gcode sender (Easel vs UGS, Chilipeppr, and PicSender). To make sure the Photovcarve files are OK, I sent a sample one to Vectric, and they validated the file was OK. So I don’t think it’s PhotoVcarve - although the postprocessor might be an issue.
The only thing left, in my mind, is the gcode sender. I’ve tried three, and none work on the type of file I’m trying. I did manage to get a very small (2"x2") Photovcarve job to cut, but anything bigger starts going wonky.
I checked my Windows 10 machine, and it’s set to never sleep while plugged in, so it’s not that. I’m at a loss at this point, since I really need to be able to generate and send large gcode files… using only Easel isn’t really an option for what I want to do.
Any thoughts or suggestions on what to look for are most gratefully accepted.
Ouch…I’m at a loss. I also re-read what you posted and saw that you’re using PicSender, and I have no experience with it. I’ve used UGS for larger files (500K lines or so), but I had to use the Nightly Build in order to do so. Version 1.0.8 gave me issues to where the job would freeze at about 60% completion.
It is definitely worth a shot! I had have zero major issues with the nightly build. The only issue I’ve run across is that when I have to cancel a job (because I goofed up), when I go to jog the machine around, it’s stuck in millimeters no matter what I do. So the fix for that is to close UGS, re-open, and all is well.
It has to be something with how the post processor generates the gcode, or it’s loosing steps during the cut. Charley in the Lithophane thread uses Aspire for his image engraving, so his PP may generate the gcode differently. The issue he had was with loosing steps and needed to adjust the pots for the steppers on his gshield to correct it.
Also open the PP in a text editor and check if these variables are set this way. With this setting, it will generate all axis moves on every line of gcode, even if an axis position has not changed from one incremental step to the next. Our image to gcode programs generate the gcode this way because we found it runs smoother with grbl. A stands for All and C stands for Change. Leave the feedrate to C since PVC does not have a variable feedrate feature like our PicEngrave Pro 5 has.
VAR LINE_NUMBER = [N|A|N|1.0]
VAR SPINDLE_SPEED = [S|A|S|1.0]
VAR FEED_RATE = [F|C|F|1.1]
VAR X_POSITION = [X|A|X|1.4]
VAR Y_POSITION = [Y|A|Y|1.4]
VAR Z_POSITION = [Z|A|Z|1.4]
VAR X_HOME_POSITION = [XH|A|X|1.4]
VAR Y_HOME_POSITION = [YH|A|Y|1.4]
VAR Z_HOME_POSITION = [ZH|A|Z|1.4]
In PicSender use the GRBl Z Code and Position Sent options.
For setting to Inch units in the startup block, type in $N0=G20 into the Do. Cmd window and select the Do Cmd. button. Also to set a default jog feedrate, type in $N1=F50 the same way. Set $13=1 (report inches, bool) this way in the grbl settings for inch units
So, I did the following actions, and now the machine is working as expected:
Adjusted the potentiometers as described in this helpful post (my current was low, especially on Z, so it bogged down easily)
Tightened the belts again and triple-checked all the V-wheels so there was no slop in movement
Adjusted the Vcarve post procesors as picengravertoo suggested
Ran PicSender with the suggested settings
Nearly perfect rough and final passes!
The only problem I had was using the wrong bit and it ran too fast, too deep per pass, so the bit broke, but that’s a separate problem I can deal with. All my hardware and software issues seem to have been solved.
I also bought the PicSender software, and am very happy with it. A very inexpensive addition to an expensive hobby.
Thanks very much for everyone’s advice! As soon as I get a finished piece together, I’ll post it in the gallery.
We have a program called PicFRC that adds a variable feedrate to a gcode so it will slow the bit in deeper cutting areas and speed up the bit in shallower cutting areas. This reduces the chip load and minimizes the risk of bit breakage. We written it for our PicLaser Lite & PicLaser (released today) image to gcode programs and have not tested it with any others.
Download the Demo and run your PhotoVcarve gcode file through it and open in a text editor to see if it properly adds the variable feedrate on each line of gcode. In Demo mode it will only do half of the gcode file’s lines.
Or if you wish, zip the gcode file and send it to the PicSender Registration email and I can test it here and if it works properly, I can email it back to you with the variable feedrate added for you to test.
I too have the “stuck in mm” issue in UGS.
My solution to it was to enter G20 in a ine in the macros tab in UGS and when I finish a job, as usual, it’s stuck in mm. I click the macros tab, hit the c3 button (In my case), and carry on.
@JkWestphal Do you use UGS for long gcode files? If so, what version/build are you using. I was able to run a few long projects with the nightly build with no issues until a couple weeks ago, but now it freezes at about 33% completion. The only thing that changed was a Java update, so I’m wondering if that is the issue.
I tried using bCNC for the same project, but it takes forever to load the file, and if/when it does (sometimes the program freezes and I have to restart it), when I hit Start it takes forever to move and I have yet to get it to function properly. It either moves to the carve start point and just sits there, or it won’t move at all.
Ever since I downloaded PicSender, I’ve used that for sending gCode to my XCarve. However, I did find that the potentiometers were set low, so the machine would sieze up. I’d thought it was the software truncating the jobs, but it seems like the motors weren’t getting enough current to continue.
However, I haven’t tried UGS lately (as in the last 2 weeks), so I don’t know for sure if the problem was absolutely solved. I really like how PicSender works, so I’ll likely stay with that; I find it worth the $15.
I saw PicSender as an alternative, but after putting over $2k in the machine and software, I’m trying to be cheap and not pay for anything else…even tho it’s only $15. lol If I can’t solve the UGS or bCNC problem, I’ll give in and pony up the $15.
I do use UGS nightly build 2.0 (several months old) to send but I dont really think the files I have sent thus far would be considered long" .
Most of what I have ruin thus far has been 1.5 hrs or less and alot of that has consisted of files that clear alot of area but dont require a large gcode line count.
I have been limited in my shop time in the last few months since winter is coming on in the north county and I work as a propane service tech/delivery driver in my real life and this is a really busy time of year for us.