I searched for a post on this problem but didn't find anything useful for me to act on. I am currently using v1.0.388. I had the issue on v1.0.370 as well. I am using Sheetcam to create gcode. Depending on the post processor I get different results in the 3D view. Fortunately the actual machine control is fine during cutting or check size. The gcode files are attached. I tried deleting the preamble gcodes but it didn't make a difference in the display results. Here is an example of good: Here is an example of bad:
The "bad" one uses G92 for offsets after probing (good one doesn't probe) - which is not good practice, usually probe macros reset Zero using G10 L20... G92 - being offsets instead of proper positions, looks like this in side profile (rotate the 3D view of the "bad" file and view it from the side instead of top down) to demonstrate the offset, which is why the outline and some other elements looks bigger - its much closer to the camera in a orthographic view - visual representation of the offsets that are applied (recursively) on each probe (but never cancelled). Its not scale per se, its orthographic, closer to camera, because of the height of the items that appear to scale wrong Whichever post you use, make sure the Probe macro uses G10 L20 instead, which is more technically correct, below example out of Openbuilds CAM with the OpenBuilds LEAD Plasma's 3mm offset, and it will be more compatible Code: G38.2 Z-30 F500; Touch off Probe G10 L20 Z-3; Set Z Zero to current position switch trigger -3mm actual zero because of float As your G92 was G92 Z-3.4 should probably work with Code: G10 L20 Z-3.4 Edit the "bad" post and change the Probe macro's section on rezeroing to G10 L20 to resolve
THANK YOU!! I will check out open builds CAM. I have been using Sheetcam for the last 6 years with various non GRBL tables, that use Mach3, plasmacam, or dynatorch. Have always skated by using other people's post processors. Thanks again for the schooling.
