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 mor
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 Si
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/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 yo
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 h
On 9 December 2013 13:38, 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.
It looks like it should be easy. But I might be missing some
On 12/9/2013 6:55 AM, andy pugh wrote:
> On 9 December 2013 12:47, Charles Steinkuehler
> 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 mos
On 9 December 2013 12:47, Charles Steinkuehler 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 compensating for bad hardware des
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
On 12/8/2013 10:21 AM, Charles Steinkuehler wrote:
> 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 roo
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 t
On Sunday 08 December 2013 13:03:31 andy pugh did opine:
> On 8 December 2013 17:06, Charles Steinkuehler
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 idealised cartesian spac
On Sunday 08 December 2013 12:39:46 andy pugh did opine:
> On 8 December 2013 16:47, Charles Steinkuehler
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 t
> On 8 December 2013 17:21, Charles Steinkuehler
> 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, you use the kin
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 t
On 8 December 2013 17:21, Charles Steinkuehler 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 available? :)
They sti
On 12/08/13 11:12, andy pugh wrote:
> On 8 December 2013 17:06, Charles Steinkuehler
> 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 idealised cartesian space, and the output
>
On 8 December 2013 17:06, Charles Steinkuehler 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 idealised cartesian space, and the output
should be idealised cartesian too.
Have you seen:
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,
On 12/08/13 10:53, andy pugh wrote:
> On 8 December 2013 16:47, Charles Steinkuehler
> 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 t
On 8 December 2013 16:47, Charles Steinkuehler 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 list)
--
atp
If you c
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 refere
22 matches
Mail list logo
