rotate/skew/resize coordinate system
-
depends if thats applied to work place co-ordinates or not.
Ideally, you probe 2 points on the stock material in X and 2 points in Y. The firmware would then know where the origin is and skew the work piece accordingly. -
@deckingman said in rotate/skew/resize coordinate system:
If he set that as the deviation for both X and Y
there is only one value for the xy plane, and one for yz, and one for zx as I'm reading it; so it will not be linear aftervif the machine is already trammed.
The X, Y and Z figures are the number of millimeters of the short side of the triangle that represents how out of true a pair of axes is. The X figure is the error between X and Y, the Y figure is the error between Y and Z, and the Z figure is the error between X and Z. Positive values indicate that the angle between the axis pair is obtuse, negative acute.
-
@bearer You are probably right but I can't really be bothered to think about it. I go back an awfully long time to the Duet 06 boards as used on the RepRap Pro Mendel. It used to be called "Orthogonal Axis Compensation" and was used to correct printers that were built from threaded rods and therefore the axes did not necessarily move at right angles to each other. That is what M556 was designed to compensate for.
-
@deckingman said in rotate/skew/resize coordinate system:
axes did not necessarily move at right angles to each other.
correct; so if the machine does move at right angles and you adjust it, it will not rotate, but change the angle to be obtuse or acute instead - causing non-linearity.
-
@bearer said in rotate/skew/resize coordinate system:
@deckingman said in rotate/skew/resize coordinate system:
axes did not necessarily move at right angles to each other.
correct; so if the machine does move at right angles and you adjust it, it will not rotate, but change the angle to be obtuse or acute instead - causing non-linearity.
I can't really be ars*d to think about it, but if you have a square and apply an orthagonal offset to X and the same offset to Y, don't you end up with the same square but rotated? How is it non-linear?
-
@bearer said in rotate/skew/resize coordinate system:
not without G68/G69 implemented in RRF i think
and we have only 53-59 ..
-
@arhi Is there any way that you could model the object as if it was going to be printed, then use a slicer to rotate it on the build plate and generate the required move co-ordinates?
-
@deckingman said in rotate/skew/resize coordinate system:
@arhi Probably not but is axis skew compensation any good for you ? https://duet3d.dozuki.com/Wiki/Gcode#Section_M556_Axis_skew_compensation
great, skew is one of the things I want to compensate too. on large boards it happens that film stretches unevenly, especially if you make a board yourself and print on fscking samsung printer that will stretch the paus in length
... so hitting feducials with skew compensation should work .. need to check how it works with examples. I know TT printers use something like that (not trough g-code) to compensate for messed up mechanics -
@deckingman said in rotate/skew/resize coordinate system:
@bearer said in rotate/skew/resize coordinate system:
@deckingman said in rotate/skew/resize coordinate system:
axes did not necessarily move at right angles to each other.
correct; so if the machine does move at right angles and you adjust it, it will not rotate, but change the angle to be obtuse or acute instead - causing non-linearity.
I can't really be ars*d to think about it, but if you have a square and apply an orthagonal offset to X and the same offset to Y, don't you end up with the same square but rotated? How is it non-linear?
because if you do
M556 S100 X-0.512 Y-0.512 Z0.thenX-0.512causes the right angle at he XY plane to become slightly acute, andY-0.512causes the same to happen to the YZ plane, the Y command doesn't change in relation to X, only Z. -
@deckingman said in rotate/skew/resize coordinate system:
@arhi Is there any way that you could model the object as if it was going to be printed, then use a slicer to rotate it on the build plate and generate the required move co-ordinates?
For any specific situation, everything is possible given time and energy. ATTM I'm thinking theoretically as the "big" mill I have (it's tiny compared to mills out there but it's much bigger than my MF70 conversion
) is ATTM out of operation due to linuxCNC computer that was driving it (via MESA card over ethernet) is dead. So now I have options- [0] ignore it (most probably what's going to happen as I'm pressed with time, but I can "think" about solution in free time)
- [1] rebuild another PC for linuxCNC and reconfigure everything from scratch
- [2] make a small GRBL on STM32F103 (there's a port, ppl say it works nice)
- [3] make a quick smoothieboard compatible board and run smoothie in GRBL mode (as I do for my MF70 conversion but with real smoothieboard), it's easy as I already have big external drivers and power and everything else needed for that CNC
- [4] get duet3 and dump these ugly drivers I have as duet3 can supply required 4A for these motors
1 is something I'm trying to avoid as I don't have room for that PC and monitor and ..
2,3 are cheap and I already have everything I need to make it work but I'm trying to unify as much as I can and since I started migrating stuff to duet..
4 is expensive but makes sense in the long runNow this "rotation" and "resize" I have no clue if this can be done with GRBL/Smoothieware, but would be a good incentive to move to Duet3
So, back to the question, I have e.g. a g-code made for a PCB drilling, there's zero chance I can position that PCB ideally square on the bed so I need to be able to at least rotate but in most cases also to resize coordinate system. Yes I can manually measure, calculate and write a small piece of code to redo the coordinates in the g-code, but that's not practical. I can also do an octoprint plugin to do that on the fly, and if I go smoothieware/grbl way in case they don't support rotation I'll do just that, but no point of running octoprint + plugins with RRF, not a big point of spending the $$$ for duet then
-
@arhi or run RRF on an LPC board (e.g. SKR 1.4 or MKS SGen L) with your external drivers
-
@arhi said in rotate/skew/resize coordinate system:
So, back to the question, I have e.g. a g-code made for a PCB drilling, there's zero chance I can position that PCB ideally square on the bed so I need to be able to at least rotate but in most cases also to resize coordinate system. Yes I can manually measure, calculate and write a small piece of code to redo the coordinates in the g-code, but that's not practical.
i used to have a camera to align to one mounting hole drill, it deep enough to put a dowel pin in it, and align the other corner pivoting one the pin before clamping it down for good. If you can eyeball it without the cam then maybe that'll work?
-
btw linuxCNC for e.g. don't have G68 but has G10
http://www.linuxcnc.org/docs/2.6/html/gcode/gcode.html#sec:G10-L2_
that allow rotating one of the existing coordinate systems around Z axes
-
@bearer said in rotate/skew/resize coordinate system:
i used to have a camera to align to one mounting hole drill, it deep enough to put a dowel pin in it, and align the other corner pivoting one the pin before clamping it down for good. If you can eyeball it without the cam then maybe that'll work?
I still have camera (want to replace it btw) and it works ok when I want to mill the pcb, I do not move the pcb from the bed and all cool, but if I etch the pcb and wanna drill holes and cut slots it's PITA .. can be done but really PITA
... I would like to have it done "properly" with feducials, and with linuxCNC for e.g. G10 L2 will get the job done for rotations. The scaling is not that important but is a nice to have -
flatcam can probaly do the translation on the drill file, and with DSF (on both duet2 and 3 now) you might be able to use https://forum.duet3d.com/topic/13194/dsf-extension-exec-on-mcode-was-shutdown-sbc to automate it?
-
@bearer said in rotate/skew/resize coordinate system:
flatcam can probaly do the translation on the drill file
Not worth it, that's situation where I go to the mill, place pcb there, measure, read measurements, load into flatcam, generate code for that board, put new board, measure, generate new code... not really something I wanna do.
I wanna do openCV recognise feducial - mark, find another one, mark, rotate, size, mill/drill.
Need to check if G10L2 works on smoothie properly, I think it does, and with DSF (on both duet2 and 3 now) you might be able to use https://forum.duet3d.com/topic/13194/dsf-extension-exec-on-mcode-was-shutdown-sbc to automate it?
DSF is IMO long way still.. we'll see
-
@arhi said in rotate/skew/resize coordinate system:
I wanna do openCV recognise feducial - mark, find another one, mark, rotate, size, mill/drill.
thats what I was thinking, using flatcam on the command line to do the rotation should be a walk in the park after having done the other bits.
-
this grbl mode is not very familiar
/me need to go back to school G55 ok b'$G\n' [GC:G0 G55 G17 G21 G90 G94 M0 M5 M9 T0 F200.0000 S0.8000] ok G56 ok b'$G\n' [GC:G0 G56 G17 G21 G90 G94 M0 M5 M9 T0 F200.0000 S0.8000] ok G56 ok b'$G\n' [GC:G0 G56 G17 G21 G90 G94 M0 M5 M9 T0 F200.0000 S0.8000] ok $G [GC:G0 G56 G17 G21 G90 G94 M0 M5 M9 T0 F200.0000 S0.8000] ok G0X5F200 ok b'$G\n' [GC:G0 G56 G17 G21 G90 G94 M0 M5 M9 T0 F200.0000 S0.8000] ok G56 ok b'$G\n' [GC:G0 G56 G17 G21 G90 G94 M0 M5 M9 T0 F200.0000 S0.8000] ok G10 L2 P0 X30 Y60 ok b'$G\n' [GC:G0 G56 G17 G21 G90 G94 M0 M5 M9 T0 F200.0000 S0.8000] ok G0 X10 F200 ok b'$G\n' [GC:G0 G56 G17 G21 G90 G94 M0 M5 M9 T0 F200.0000 S0.8000] ok -
darn thing always return OK no matter if it's supported or not
...anyhow tested G10L2 works for offsets but "rotation around Z" is ignored
on smoothie in grbl mode and on grbl and turbogrbl too
