I figured that it is difficult but I thought since it's done in SketchUp, and it does it properly, that there is a API or some place to copy the code to to it. I borrowed code all the time when I did some BASIC programing. I have version V1.5-0803db9. Installed it last November, I think.
nope, gplot is compiled from Delphi code (Pascal) and has no links to the inards of Sketchup at all. nope, 1.5 was released for Christmas, and 1.5a a few weeks later to fix a bug in Sketchup2017 with countersink bores.
All I did on the first 2 peices you noticed was as you said erace tabs and cut lines and then select the images one at a time and then Phlat edges and selected Phlat all connecteda and enter. I then went back and added the cut lines and the tabs. (honist dad that is alll I did LOL) Now that i think of it when i cut that it was the first cut I made after i got the maching running and it cut completely through the foam and i stopped it prior to the cut of those 2 parts. so i do not know if it had a problem then. I purged some of my almost 40 test and retest files and that one went with it. when I reset the PhlatboysParameters to set the table top is 0. Then set the Router Bit to about as close to the top of the foam surface. set the save hight to 3 mm. Then I loaded the origonal file that has all the corrections to the plunge cuts and larger tabs but still had the non Phlat squares. I proced to do the same as before and used the Phlatboys eraser to remove tabs and cut lines this took the non yellow cutlines away and left the yellow around them just as before. the only other thing I did was to make it oriented to the correct X and Y, I drew it wrong and the would not reach all the parts. I did this by eracing the safe area and selecting all with the curser and then rotated it 90 degrees. Re applied the save area in the by using the PhlatboysParameters that i modified as stated above. This helped the cut not go through the the tab areas. (One other problem solved) Now I got the BT problem. I wil start over on this sheet from the origonal .skp file. I now know what to look for in the Gcode. As for thesave I think my program to make the High Contrast for me to see the drawings do not show the file type to save as so I will work on that. Thanks for all you do Sir Mark
ok I went back to an origonal .skp file and started over. NO PROBLEMS AT ALL I went through the PhlatboysParameters and took out the overhead gantry. NO PROBLEMS so I added it back in NO PROBLEMS.
I am ot sure what I did that caused it. The only thing I can remember is I did many changes and eracing on the previous .skp and maybe it caused some atrifacts I will watch for it now that I know about its existance. I have several setups to cut for this airplane. Thanks Mark
On a Phlatprinter the tabletop is NOT Z Zero, the top of the material is Z Zero, ie end of bit level with the surface of the machine. Then Z moves negative to cut through the foam (Up from a looking down at the machine perspective. The surface of the foam that you can see is in effect the 'table top' that one would have on a conventional machine.
This is exactly why I set it to table top is Z 0.00 to completely simulate the standard router. Then I set the safe to 3.00 mm as I have disabled the E stops and set 0.00 manually I am only using foam that is 2.7940mm I then set it to the top of the foam and set zero. same as a std router I think. This gave me the assurance of just cutting the foam and not cutting too deep and eleminating the tabs as My first cut. I mearly on this test to see if that caused the BT problem and it did not repet. with the manual zero it really does not seem to make a difference. Still do not know what caused the BT. the nice thing is it did run a complete dry cut without any seen issues. Real cut tomight after i solve the center of the PP1 real table top flexing down into the bit. I have an idea how to fix. Thanks mark
I also tested it with it to overhead gantry. that did ot change anything on the simulation but I think it will make a better cut. Mark
I KNOW WHAT IT IS THAT DOES THE BT PROBLEM!!!!!!!!!!!!!!!!!!!!!!!!!!! I just caused it again. I flipped along the red axis a complete with cut lines and tabs. This was the just cut attempt file that failed because of a stepper motor problem. I also remember doing the same thing on the 4 rectangles that caused the first issur and then again when i flipped the corrected .skp . My guess is you must have the drawing completely done and mot bother it after the cut lines and tabs and plunges and what ever else I have mot usd tools are applied. THIS PUTS THE TABS upcide down and most likely several other things get confused. If you must flip the layout it mist be done in the .skp prior to cut lines and etc is done. Is there anyway to flip it in the Sketchucam tools that does not flip the already setup cutlines and tabs and etc. I just checked and it did not du it on a 180 deg rotate Mark
blue sides up, if you flip a shape along any axis you need to phlatten it again then add the cut lines.
Thanks David Success I did the flip and a rotate 90 to get the position I for somereason thought I should have, (No real knkowledge used on the decision) removed the tabs and cut lines, generated Gcode, transfered it to the PP1 computer, placed the foam in the PP1 with the settings I described above and pushed the start and in about 35minutes It was done................................... This was an eventful accomplishment in a short time. Lots learned, mistakes made, help from the OpenBuilds Knowledge base and some dumb luck I think. Thanks and look forward to doing more!!!!!!!!!!!!!!!!!! Not Bad for an ALMOST BLIND GUY. Mark
Posteed a BIG thanks on RC Groups ** Kline-Fogleman (KFm) Airfoils - Building/Flying Discussion ** - Page 719 - RC Groups
for theracermark... here is my terrible KF plane.... as I sit at my desk I look up and right and there it is.... not on the wing rack, the one with the spotted tail and one red, one purple leading edge. here it is a bit closer, using the terrible digital zoom on my phone... yes, it is somewhat dusty, have not been out on the slope in quite some time...
Thanks for the reply and all the help. It is cool to see this PP1 working again for sure. I have also managed to ge much better at the Sketchucam layot of parts. There is a trick to getting it correct QUICKLY. Having lots of fun and looking forward to the next CNC project, getting my old drag knife cutter going again. Today is the cut the other 3 cut layouts. Thanks Mark
@David the swarfer, another thing with Gplot is that when I orbit and close the program when I open it again, through SketchUCam after generating a new g-code, it opens in the last orbited position. Can this be changed that every time you start/open the program it will revert to the 'flat' position?
As for the airplanes lots of neet stuff. The KFm wing should be a fun thing. It looks like it has some what of a standard airfoil with the KF treatment. It also looks like the control surfaces are too large. It seems as though the wings do not need much control surface or much deflection. Lots of other nice stuff as well. Mark
no, just click the 'go flat' icon in the toolbar, either before you close it, or after you open it. The 'open flat' feature caused about half of the usage queries over the years <-: "how do I get an isometric view" kind of thing, esp for people without a 3 button mouse since middle button changed the angle. now middle and right buttons change angle, and the angle is stored for next time, and there have been 0 queries..... (-:
Not sure if this is the right place to ask, but is there a way to set the offset of the G53 G00 Zxxx command at the beginning of the gcode to a positive value? I'm using an Ooznest Workbee with Duet controller and the XYZ origin is at the machine maximums for this firmware, while not a problem for X&Y, Z home at the top of travel is 140. So the initial Z move drives the Z axis into the spoilboard, which isn't handy. This move would ideally be workpiece relative or allow a positive value. When removing this line manually the rest of the path executes fine, other than throwing a "needs filename" error on M30. But then, I don't really wan't anything deleted, so it would be handy to remove that line.
Yes of course, read about it in the manual or big blue question mark in the toolbar if you have no internet (-:
I've been there, unfortunately, the "End position Z for G53" is "ALWAYS negative since machine Z=0 is at the top of travel". In the case of my machine, Z=0 is the bottom of the travel and the offset is always interpreted as negative. In the case of my machine it needs to be something like +130. However, I hadn't realised how easy the setup was to modify, so I've just removed the G53 line from the ruby script which does the job for the moment! I'm very much liking SketchUCam for setting up simple jobs.
That is not only nonstandard, but also incorrect, incompatible with most CAMs (and dangerous). Despite the difference in firmware, the Grbl writeup still explains it very well; see gnea/grbl
Yeah, I agree, it seems bizarre and I have no idea why Ooznest have done it this way. Once the workpiece origin is set, though, it works exactly as you would expect for relative movement. Negative co-ordinates are into the stock, positive are out. So this is normal. However absolute movement in Z is just wrong. The issue here is purely that the home is at ~140mm rather than 0mm, and goes down to 0mm rather than down to -140mm. I have had a look to see if this can be changed to 0mm, but didn't immediately find an answer. However from what I saw of some G-codes, I'm pretty sure you could set the home to be either minimum or maximum on X, Y and Z. So I suspect it's fixable in the G-code setup. As the home is far back, right and up it makes sense for home to be X/Y maximum and Z minimum. Not max,max,max...
@Alex Chambers wasnt there a way to fix the machine coordinates back to how the rest of the world expects them to be?
Just having a look at the setup, I think it's this bit (not my machine in this case, a smaller one)... Code: ; Axis Limits M208 X0 Y0 Z0 S1 ; set axis minima M208 X800 Y1270 Z94 S0 ; set axis maxima ; Endstops M574 X1 S1 P"!xstop" ; configure active-low endstop for low end on X via pin xstop M574 Y1 S1 P"!ystop" ; configure active-low endstop for low end on Y via pin ystop M574 Z1 S1 P"!zstop" ; configure active-low endstop for low end on Z via pin zstop I think the Z line should be.. Code: M574 Z2 S1 P"!zstop" ; configure active-low endstop for high end on Z via pin zstop or possibly... Code: M208 X0 Y0 Z-94 S1 ; set axis minima M208 X800 Y1270 Z0 S0 ; set axis maxima I'll have a play around with that shortly. Seems bizarre they would ship a firmware which is out of step with the rest of the world here.
I've got used to it. Been busy lately (setting up a new Facebook group for Workbee users) but I'll have a look at the Rep-Rap wiki later to work out how to change the machine co-ordinate settings. The reason, of course, is that rep-rap g-code was primarily aimed at 3d printers, where the bed is Z0 and they work in all positive space. The Duet with the rep-rap firmware (and bear in mind that Ooznest are still using RRF 2.05 - I think the code given above is RRF3 - which won't work with Ooznest's firmware) correctly sets the home position back, right at the maxima for those axes, but because it works in positive space X0 & Y0 are front, left. It also sets the Z home correctly as up, but again in positive space so Z0 is down. It only causes problems with post processors that use G53 moves, workplace coordinates work in exactly the same way as the "norm". If I can't work out how to make the Duet work in negative space for machine co-ordinates I'll be happy to modify a post processor to suit its oddities. Give me a few hours to look into it. Alex.
Figured, so they maybe have posts to work around the non-standardness - but yeah, that leaves you manually editing for all other CAMs where a Duet post doesnt exist.
@James Boulton - I assume you are using SketchUcam? Not something I'm familiar with but can you confirm that you have a fairly standard set up from Ooznest - Duet 2 controller, Ooznest's user interface? Alex.
It's only post processors that use a G53 Z retract that cause any issues - workplace coordinates are exactly the same as normal, so, for example, the Vectric grbl post processors work fine with it. Alex. Oh and some M codes in Rep-Rap have different meanings - M30 is delete file from SD card, not "end programme". Duet doesn't need an end programme.
