Normally we would use the lower left extreme as the origin, because it’s easier to position the material that way.
Estlcam lets you set the machine origin.
So here, you can see that the origin (Blue “+” marked as zero) This is the default for the artwork I’ve indicated the origin tool. When you click it, it will give you a number of points on the drawing that it can “snap to” or you can place it on the grid.
And here, you can see that I set the origin to be the center of the circle. I could choose the center because I chose a grid size that divides evenly into the size of the drawn circle.
Once that is done…
Power up the CNC. or a Primo, it is best to power it up with the rails against the stops, so that it is guaranteed to be square, and you will get a circle and not an oval. Jog the machine to the center top of your work piece and use the command:
G92 X0 Y0 Z0
You can either add this to the start of your GCode in Elstcam or you can do it from the terminal in your Gcode sender. If you are using the LCD (With default V1 firmware) this will be in the V1 custom menu. I think that needs 2 items, as the set origin command there only sets for X and Y.
If you power cycle the Primo, it will start assuming that the current position is 0,0,0, so that will work as well, but it’s not good practice.
For the record, I will reiterate that I believe using the default lower left origin is a much better idea.
Now, next, if you are not getting a circle as a result, then I think that there is another problem that ought to be addressed.
If you are using 8bit electronics (RAMBo, RAMPS/Mega 2560) then there is a setting in Estlcam to disable arc commands. This breaks any curves down into a series of short straight lines. this is a good thing as arcs are more computationally expensive. They take more processor power to be able to work them out, and those 8bit boards fall short.
This is not necessary for 3D printing, because .STL mesh files already break things down to short straight lines. You should be used to this happening already, and you probably will never really notice the difference.
32bit boards can generally handle the extra computation.
If your board is barfing trying to work out an actual circle, it might instead be fine with the series of short straight lines. I think Estlcam’s default configuration is to use arcs. Look in your gcode file, if there are G02 or G03 commands, then it is expecting your board to calculate the arcs, and it might just not be up to it.
Hope this helps.