Trying to run a test with my rotary and I get strange movement where it will move like 10mm pause then move another 10mm and pause all the way around the circumference of the object I am burning.
My test project consists of a jar that is wrapped in blue tape and its circumference is 275mm.
Below is an image from LB of the project. It almost acts like the controller is starving for data and pauses waiting for more data from LB and then it continues on. Seems like a buffering issue.
My laser is a upgraded K40 with a Cohesion3D Laserboard.
What are the possible causes of these strang delays?
I assume this is a vector cut? If so, there are a few lines of code generated for grbl. I would doubt it’s a communications issue. If there are firmware updates, are you current?
Might want to post the .lbrn2 file for inspection.
Since the cut appears to be larger than your work table, maybe you are hitting the Y axis software limits? Does this happen if you make the cut fit the work table and start at Y0?
No I am not using the Y axis, the rotary is plugged into the A Axis on a Cohesion3D Laserboard controller.
I included the circumference of the jar in the details in my first post above.
Rotary is new, custom built, but I following all the instructions from here about setting up a rotary.
Its a rotary there are no limits and I am using the A Axis on a C3D laser board.
Making the cut fit the work table is counter intuitive to using a rotary so I don’t believe that to be relevant to the issue.
I don’t use that board, so I can’t comment on how it’s handled there.
When I use the rotary, the only use of the circumference is for a ‘tool’ frame in which to create my design.
Maybe I’ve got this all wrong, but when the driving wheel turns 1 turn it will move the material it’s ‘1 turn’ distance no matter the diameter of the work piece. I could understand the difference in a ‘chuck’ where there is a mathematical relationship. Are you using a chuck rotary with your jars?
Whatever axes you are using, you want the rotary to move the object surface the same ‘amount’ as the table or whatever that axes moves. If it doesn’t, your ‘engraving’ will be distorted.
Just to see if there are any differences, try saving the gcode. It should not be too big with that square. That my help identify what’s going on.
This is the gcode it generated rotarytest.txt (289 Bytes).
I have to fain some ignorance here, as I’ve only used one kind of rotary and only with a Ruida. I couldn’t afford or justify it for my grbl machine.
Mine doesn’t know it is a rotary, so it checks boundaries. I have set my origin to the proper place or it will give me the dreaded ‘Y slop over’ error.
If it has no limits, could you run a screw pattern from one end of the jar to the other? Just curious…
