hi, I am having an issue with sheetcam and masso g3
Basically, any new tap file made with sheetcam will not allow me to use the first half of my x and y axis on my plasma or specify start point on the sheet. I have narrowed the issue to sheetcam as my older tap files are fine and any new ones created in the beta version work as normal
Is there a bug or way around this? should i just use the beta version instead from now?
both are latest version
The battery switch works as normal and rear arch doesn’t
Yes, clearly the parts being cut in ‘rear arch’… tap file are located with a huge XY offset to top right quadrant of the material sheet, while ‘battery switch.tap’ cutting is lower left quadrant much nearer WCS X0Y0.
The large XY offset from WCS X0Y0 can be caused by the job origin. Check menu Options->Job Options for the job origin. This can be adjusted on a per job basis, and for new jobs, the settings are inherited from the previous job I’ve noticed in my Sheetcam install. This inheritance (in part) is likely the reason there is a job template feature, many other setups are saved in the job temlplate also, such as Toolset, part names, Operations, Layers, etc. Setup your job options as you like them for the majority of your cutting and then use menu File->‘Save job as template’ feature to make a job template. Now anytime you want to ensure you begin a new job from a consistent setup, load the job template before you import your dxf drawing.
thanks sheetcamcs2, I did double check the job origin and that is the same. It’s always in the lower left corner. Is there a reset or way to return sheetcam back to factory settings?
I’ll use one of the older files as a template for a work around
re. license use- its a single seat license for use on one computer. Yes, you can use it on stable and development versions simultaneously on the same computer. The installed folders and settings folders are different for each of those version types.
re. the problem of wrong part offset- Please prepare a support.zip file for us using the following procedure. We’ll look at it to find an answer as to what is causing the offsets.
If Sheetcam is running, Close it and relaunch.
Open the problematic job.
Without changing anything in the job, simply Run the Post Processor to build a fresh gcode file. However, IF you did change something in the job already, then Save the Job before running the post processor.
Goto menu Help->‘Create a Support File’ and fill in the description of your problem as in what you have mentioned in prev memo and any other info you can remember or notice is wrong. Retain the default selection/check box of all of the artifacts to be zipped up from the list in the bottom frame. Click ‘Create file’.
Send that .zip file to sales@sheetcam.com. We will review it along with your detailed description of the issue.
after a closer look at ‘rear arch…’.tap, the toolpath coordinates show a part rotated +90 deg from part center point. Rotating it -90 deg has the part lower left corner on or near x0y0 . Could be cause by inadvertent mistake in the rotation ‘A’ field in Sheetcam’s lower right corner of main window.
thanks Lou, sorry to be a real pest but in the development version when trying a simulation my code snippets don’t show
I can see the rules with corresponding code on the drawing as they have changed colours and my plasma definitely turns on and off
I can confirm it does not work, and has not worked since the new simulator was introduced. Unfortunately it won’t be a quick fix. @sheetcamCS2 You may interested to hear that the fix for this may tie in with your request for an OnPathRule event.
Hi guys,
I may have found a clue to why this is happening. I created two new tools today in my library for plasma cutting, and gave them the number 126 and 127. I placed my part with 5mm offset from the lower left corner, then compiled the program:
It for some reason offset the part by 220 mm in the Y direction and and 111,5 mm in the X direction, and now gives M08 as the start command instead of M03 as it normally does.
I then changed the tool number to 28 from 126 and compiled again and got the correct output as below:
The only change I made was the tool number, nothing else. I dont know if it means I have to keep my tool numbers below 100, but maybe someone smarter can make sense of it.
Not sure if it’s related or not, but when I was reading about setting up an air scribe on my table, there was mention of setting the tool number to 100 or over for marker tools. At some point a marker tool type was added to SheetCam so the post had a way to differentiate between marker tools & other tools without going by the tool number.
Maybe there’s some old code inside SheetCam that is applying the offset for marker tool if the tool number is over 100.
Incidentally, M8 is the command most use for the markers. It’s actually a coolant command, but that’s what they use.
@djreiswig nailed it. There is code in the ‘uccnc jcoldon.scpost’ pp that is treating tool numbers > 99 as MarkerTool, you can edit the pp and delete that
‘or tool > 99’ condition if you like. The X tool offset for a MarkerTool (scriber) is 110mm, for Y 220mm, and those values are set in the pp prologue comment area near top of file, and you’ll see the values used in OnPenDown() within the following condition test…
function OnPenDown()
if(toolClass == "MarkerTool") or tool > 99 then
