On 12/08/13 23:21, Gregg Eshelman wrote:
On 12/8/2013 9:47 AM, Charles Steinkuehler wrote:
I'm working on a non-Cartesian 3D printer controlled with LinuxCNC, and
rather than level the print bed mechanically, I would like to measure a
few points and transform the G-Code in roll/pitch/yaw to
On 9 December 2013 12:47, Charles Steinkuehler char...@steinkuehler.net wrote:
So, the options are to add mechanical complexity simply to provide a way
to get the bed level enough to print on
On the Simpson it looks like that mechanism is 6 more nuts.
I spend most of my working life
On 12/9/2013 6:55 AM, andy pugh wrote:
On 9 December 2013 12:47, Charles Steinkuehler char...@steinkuehler.net
wrote:
So, the options are to add mechanical complexity simply to provide a way
to get the bed level enough to print on
On the Simpson it looks like that mechanism is 6 more
On 9 December 2013 13:38, Charles Steinkuehler char...@steinkuehler.net wrote:
Yes, Leveling the bed on the Simpson is easy...what I expect will be
hard is getting the plane of the physical bed to exactly match up with
the XY plane of the arm movement.
It looks like it should be easy. But I
On Sun, Dec 08, 2013 at 11:21:19AM -0600, Charles Steinkuehler wrote:
Also, the math only
needs to happen on the endpoints, not every mS as the machine is moving
along the commanded path.
This is only true in a very limited situation: if you expect the
table to be planar (what if it's a
On 12/09/13 08:40, Chris Radek wrote:
On Sun, Dec 08, 2013 at 11:21:19AM -0600, Charles Steinkuehler wrote:
Also, the math only
needs to happen on the endpoints, not every mS as the machine is moving
along the commanded path.
This is only true in a very limited situation: if you expect
On 12/9/2013 5:47 AM, Charles Steinkuehler wrote:
BTW: I'm currently working on a Wally, but this applies also to the GUS
Simpson I'm starting on next:
http://www.conceptforge.org/
Looks like they could use shims under the build plate corners. Get it
level and it should stay level.
The
On 12/9/2013 6:38 AM, Charles Steinkuehler wrote:
Yes, Leveling the bed on the Simpson is easy...what I expect will be
hard is getting the plane of the physical bed to exactly match up with
the XY plane of the arm movement. I have yet to see how well the homing
switches will work for
On 12/9/2013 7:40 AM, Chris Radek wrote:
In the general case of compensating for a non-square non-orthogonal
machine (whose geometry changes randomly from one day to the next?)
and running fully-featured gcode, it's inadequate, and a full kins
solution that runs at every servo cycle is more
I'm working on a non-Cartesian 3D printer controlled with LinuxCNC, and
rather than level the print bed mechanically, I would like to measure a
few points and transform the G-Code in roll/pitch/yaw to compensate for
the real-world plane of the work surface.
I went looking through the G-Code
On 8 December 2013 16:47, Charles Steinkuehler char...@steinkuehler.net wrote:
I went looking through the G-Code reference, but only saw stuff to deal
with simple translations or maybe rotate around Z.
https://code.google.com/p/grecode/
Seems to offer an option to tilt (last operation in the
On 12/08/13 10:53, andy pugh wrote:
On 8 December 2013 16:47, Charles Steinkuehler char...@steinkuehler.net
wrote:
I went looking through the G-Code reference, but only saw stuff to deal
with simple translations or maybe rotate around Z.
https://code.google.com/p/grecode/
Seems to
On 12/08/13 11:06, Charles Steinkuehler wrote:
I really don't want to have to process the gcode file. The 3D printer
folks are getting around the limitations of their 8-bit micro-controller
based machine control systems by running pre-processors on the G-code.
If I was happy doing that, I'd
On 8 December 2013 17:21, Charles Steinkuehler char...@steinkuehler.net wrote:
I disagree. G-code works in idealised cartesian space, and the output
should be idealised cartesian too.
Then why, exactly, are there all the various coordinate offsets
(including rotation around Z) already
Hi Charles!
On 12/08/2013 06:21 PM, Charles Steinkuehler wrote:
...
Yes, that's how I'll do it if there's nothing in existing gcode to
support tilting, but I'd still rather run a 3D rotation in a user-space
thread vs. tying up cycles in a real-time thread. Also, the math only
needs to
On 8 December 2013 17:21, Charles Steinkuehler char...@steinkuehler.net
wrote:
I disagree. G-code works in idealized cartesian space, and the output
should be idealized cartesian too.
My understanding is that if you have a particular geometry of a CNC
machine is non-idealized cartesian,
On Sunday 08 December 2013 12:39:46 andy pugh did opine:
On 8 December 2013 16:47, Charles Steinkuehler char...@steinkuehler.net
wrote:
I went looking through the G-Code reference, but only saw stuff to
deal with simple translations or maybe rotate around Z.
On Sunday 08 December 2013 13:03:31 andy pugh did opine:
On 8 December 2013 17:06, Charles Steinkuehler char...@steinkuehler.net
wrote:
I'll add the processing to the kinematics if I need to, but it seems
like it should really be in the gcode processor.
I disagree. G-code works in
On 12/8/2013 9:47 AM, Charles Steinkuehler wrote:
I'm working on a non-Cartesian 3D printer controlled with LinuxCNC, and
rather than level the print bed mechanically, I would like to measure a
few points and transform the G-Code in roll/pitch/yaw to compensate for
the real-world plane of the
On 12/8/2013 10:21 AM, Charles Steinkuehler wrote:
clip
I'm simply surprised a simple 3D
transform is apparently beyond was provided for in the gcode language. :-/
It's a product of the early electronic era, made for machines built to a
certain level of precision and rigidity. G Code has its
20 matches
Mail list logo
