sheetcam.com

I have a Rotary Plasma in the works and some problems. Due to the structure of the machine, the g-code should control the y-axis and not the x-axis.
Can I change something so that I can control the y-axis of the machine?
I turned the control with the BOB card between x and y axis but it is not good.
I also use the machine for normal plasma cutting.
In the video, I do the first experiments... the marker replaces the plasma. The motors have not been adjusted...
https://youtu.be/FmSYoXOqsho?si=EjoGvHIyEtuYZWn_

It's hard to understand the problem since we don't know what the drawn shape is supposed to look like. Please post a picture of flattened shape as it appears in the SC graphic window, and might as well post the job file, scpost, and .nc or gc files also.

But besides that unknown, I don't see a problem with the motion per se, the linear axis stayed on cylinder center axial line, and the cylinder rotated to simulate the other "linear" axis. I assume the linear axis we saw was X and you'd like it to be Y ? If so, then the rotary chuck will have to be positioned parallel to Y, and in that case the rotary axis is B as defined by the grbl / gcode spec NIST RS274 NGC.

Further, I have not been able to get Sheetcam to gen code for YB motion, only XA as it pertains to rotary, but the Rotary-plasma plugin seems to imply that it would support YB. viewtopic.php?t=9151

In the video, I have connected the signal wires to a cross. The x-axis is the y-axis and the y-axis is the x-axis. The machine then works correctly.

OK, got it, I think. You DO desire the YB motion then, so you don't have to swap the XY motor control signals to do rotary.

Someone (Les?) will have to advise on how Rotary-plasma plugin and a related scpost produce YB motion.
again - viewtopic.php?t=9151

I can't get my head around it just yet, but thinking out loud I'm wondering if in the scpost, specifically in OnRapid(), OnMove(), and OnArc() have conditional logic if rotaryAxis = B then swap endX and endY assignments to X and Y gcode words ? One would also have to do the same test and assignment swap for any other X and Y gcode production throughout the scpost. Is it that simple ? I'll try to run some tests on that later today, but in the meantime if someone has experience with this, please advise.

I got it working, I changed the post processor. I have Mach3 in use. Now the Y-axis is controlled.
I have a YA axle in use.
https://youtu.be/p5nDx3gitCQ?si=nhbtNZHk64A-QgFu

Ah ha - like minds
I have been updating my scpost to do the same. Just finished it. Not tested but a only a couple of times with "bench" test through grbl.
I first tried B axis word with my 4 axis grbl and it puked on the B word, understandable since grbl is configured to expect A axis rotary word.
So I modified the scpost to give the option of producing XA, YA, or YB motion.
But it seems like you have a similar solution also, well done.

Good thing.
Are you using Floating Head?
Probe and THC?
I haven't operated on Rotary yet.
Are they used with that code?
I haven't found any video on how to reset the z-axis.
Of course, if they are in use, the reset happens automatically.

yes to all the above.
However the gcode I posted was produced for "bench" testing, where I use a grbl Atmega2560 4 axis board on my desk and not connected to a physical CNC machine; thus I have to produce different torch probing cmds and not set reset G92 Z0 point after each probe. The scpost external var LdcBenchTest controls this simple mod, its default state is machine mode.

My scpost expects Z to be zeroed on the surface of the rotary object, not the center axis of rotation.

Some experiments with Rotary plasma. I'm still experimenting with markers. I use Mach3 Rotary as code.
Does it use Probe and THC?
https://youtu.be/oYO3UDu08VQ?si=SQi1QI_Cwrp-C4fo