Units mismatch at startup, v2.10

[KevinO]

Hi Ed,

Sorry, I meant V2.1 Build 10. Take a look at the new attached photo. It's the same as the previous photo, except this one shows the Virtual GCode alongside the input GCode. If you look at Line 133, you can see that the input GCode z is -0.125 and the Virtual GCode z is -0.129. Based on the coordinates shown on the virtual screen, the -0.129 is just wrong. It should be -0.121. I'm quite certain that the Virtual works by creating four triangles out of the measured z dimensions shown on the Virtual screen and then calculating each virtual z position based on the appropriate one of these four triangles, and when I did the math manually I came up with -0.121.

Machining to a depth of 0.129 at a point on the wood that is already 0.004 inches higher than the origin will result in a depth of 0.133 instead of the depth of 0.125 specified. Kind of defeats the whole purpose of Virtual.
I'm glad your experiment shows it's working for you, but I'm back to my old standby of V2.01 Release 001. (or I'll continue to use V2.1 Build 10 and just forget about using Virtual)

Kevin

[EdThorne]

Hi Kevin,

Thank you for the updated information. Your calculations are correct. I believe that their calculations must have placed this point into the wrong triangle.

Did Version 2.01 release 001 do this math properly?

Regards,
Ed

[KevinO]

I think I've found out what's happening and why Virtual is not giving the correct offsets. It's not that the software is offsetting the virtual correction in the wrong direction as I previously thought. I looked closer at the actual virtual offset required at Line 133 and it's closer to 0.003 when I include distance from the origin in the calculation. Also, I looked at the offset required at the far right of the other pocket. If I add an offset of +0.005 to the virtual calculations, they come out correct within 0.001.
So the actual problem is that there is still a z offset error in the virtual GCode of -0.005 inch. I don't see this when I don't use virtual.

My workaround solution is to go into Preferences and change the value of "Virtual Cut Depth Offset" from "0" to "+0.005". After doing this, I checked the Virtual correction in several places and they agreed with my manual calculations within 0.001.

So I'm back to using V2.1 Build 10. Hopefully the +.005 inch offset will be consistent from job to job so I don't have to check it each time.

Kevin

[Joseph Poirier]

Kevin, Did you try a micrometer on the end product to see how accurate the end result turned out to be?

[EdThorne]

That's good news Kevin. I still haven't had much test time so I appreciate your efforts. Joe brings up a good point about measuring the resulting part. I hope to have some time this weekend. Work interferes with the fun things in life.
Ed

[KevinO]

I put a thick washer under one end of the wood just to make it more interesting. The difference from end to end was about 0.070 inch. Unfortunately, I don't have a depth gauge so I had to use my caliper type micrometer which isn't as accurate, but the depth readings I got for a GCode specified depth of 0.250 varied from 0.250 to 0.260 which I think is pretty good. I would guess that most of the variation came from my measurement technique, not the machine or the software.

OK Joe, you're off the hook. I'm not going to pester you anymore about accuracies that I can't even measure with my rudimentary equipment.
Nice job. I think V2.1 Build 10 is a keeper!
Regards,
Kevin

[Joseph Poirier]

next big patch build went out today. v2.1 Build 14.

Everything finally seems to work the way I expect it to. It took 1 year 8 months to get here, but I finally feel like I can be happy with my work.

Best Regards,
Joseph Poirier
Software Developer, NextWave Automation

[Rando]

And I for one am with you in being happier with this one. More predictable, reliable, more confidence-inspiring. Thanks, Joseph! You no doubt are owed a beer (or more than one) in pretty much any city in the nation .

[EdThorne]

next big patch build went out today. v2.1 Build 14.

Everything finally seems to work the way I expect it to. It took 1 year 8 months to get here, but I finally feel like I can be happy with my work.

Best Regards,
Joseph Poirier
Software Developer, NextWave Automation

Really fantastic work and you should be proud!!
Best regards,
Ed

[4DThinker]

Well done, Joseph!

If you need something else to work on I'd love to see the 2D preview of toolpaths to evolve into a 3D dynamic view. Similar to the previews in LinuxCNC and Mach3. Perspective or Axonometric, with a toggle to plan (Z) or elevation views (X or Y) looking down the respective axis. I've failed to catch excessive (student created) Z moves a few times using the 2.0 preview as it is only a top view and the Shark controller can't warn about out-of-range cuts.

Speaking of those out-of range cuts, I'd love to see limit/home switches added to a future model, with a retrofit kit available for the more recents Sharks. At some point I realized on my old Shark Pro that X,Y, and Z switches could all be mounted on the gantry. Curious if the controller has internal pins for limit switches. My pro is a long time past any warranty and I'm happy to offer it up as guinea pig.

4D