Back
[01:04:08] <ChanServ> [#emc] "This is the #emc channel - talk related to the Enhanced Machine Controller and general machining. Website:
http://www.linuxcnc.org/, wiki at
http://wiki.linuxcnc.org/"
[01:04:10] <SWPadnos> thanks
[01:07:54] <skunkworks_> SWPadnos: mo - thank you :)
[01:08:06] <SWPadnos> heh
[01:08:50] <skunkworks_> dad keeps me up on these things. ;)
[01:27:05] <jmkasunich> PeterW_: a hardware pin configured as "capture all encoder counts into latches and set a flag" would be handy
[01:27:24] <jmkasunich> * jmkasunich thinks of things like CMMs
[01:27:56] <SWPadnos> it's still useful for probing
[01:28:14] <jmkasunich> of course
[01:28:28] <SWPadnos> it just doesn't allow you to go at breakneck (breakprobe) speeds - only fast enough that you can slow down arther than one count per servo period
[01:28:40] <SWPadnos> faster, not arther (??!?)
[01:29:00] <SWPadnos> oh, rather - aha, I now know waht I said! :)
[01:29:04] <SWPadnos> gah!
[01:29:48] <jmkasunich> you simply have to go slow enough that you can stop within the probe's compilance
[01:29:56] <SWPadnos> yeah, that's what I meant :)
[01:30:29] <jmkasunich> but if your probe has 1/2" compliance, you can probe much faster than one count per servo cycle
[01:30:54] <SWPadnos> hmmm. does probing always use absolute coordinates? (ie, ignoring G90/G91)
[01:31:03] <jmkasunich> no clue, I've never done probing
[01:31:07] <SWPadnos> hmmm
[01:31:16] <SWPadnos> me either (never really done much G-code actually)
[01:31:29] <jmkasunich> anyway, taking advantage of the proposed hardware change would be the hard part
[01:32:00] <jmkasunich> EMC uses the position values it is seeing when the probe input goes active - to get captured values into the motion controller would take a whole 'nother set of pins
[01:32:06] <jmkasunich> on the motion module
[01:32:12] <jmkasunich> which I don't really want to do
[01:33:07] <SWPadnos> hmmm. yeah
[01:35:59] <SWPadnos> it would also be useful for homing
[01:37:57] <PeterW_> HM2 already has latch on index (in addition to clear on index) I would share the count latch
[01:37:59] <PeterW_> since it seems unlikely you would home and probe at the same tine
[01:39:45] <SWPadnos> yes, one would expect homing then probing
[01:46:36] <jmkasunich> the problem isn't the hardware implementation - you can do whatever you want as long as the driver writer figures it out
[01:46:48] <jmkasunich> the hard part is the interface that the driver presents to the rest of the system
[01:54:23] <PeterW_> Sure, but its cheap to add, and it does not interfere with the existing driver( which doesn't use the count latch at all)
[01:54:25] <PeterW_> We has a customer request for this in another design so I thought Ii would add the (minimal) hardware
[01:55:02] <PeterW_> (had)
[01:55:55] <jmkasunich> nothing wrong with that
[01:56:25] <jmkasunich> I wasn't at all discouraging the hw addition
[02:00:28] <PeterW_> OK. It might even be of some use without driver support (using HM2s raw mode)
[02:02:45] <jmkasunich> it might behoove us (emc folks) to examine our "canonical encoder interface" and see if it might want some optional extensions
[02:03:41] <cradek> the driver could lie to motion for the one servo cycle when it reports the probe has hit
[02:03:56] <jmkasunich> PeterW_:
http://www.linuxcnc.org/docview/html//hal_general_ref.html#sec:CanonEncoder
[02:04:15] <jmkasunich> oh, use the capture register instead of the current count?
[02:04:17] <cradek> probing is slow - the lie would be small
[02:04:25] <cradek> the small lie wouldn't disturb pid too much
[02:05:01] <cradek> just a thought...
[02:05:01] <jmkasunich> so, the change to the canon model would simply be to add a "capture-enable" input?
[02:05:13] <cradek> yes something like that - I haven't thought it through
[02:05:36] <jmkasunich> if the driver has a capture enable input, it should also have a "captured-value" or similar output
[02:05:52] <SWPadnos> I like a separate output and latch pin(s)
[02:05:54] <cradek> ok, maybe it's not very hard to do it right
[02:06:16] <cradek> SWPadnos: seems like a r/w pin like index would be most consistent
[02:06:17] <jmkasunich> not at all hard to do it "right" in the driver, where right is what a canon encoder "should" do
[02:06:22] <SWPadnos> yes
[02:06:32] <jmkasunich> the hard part is motion
[02:06:46] <jmkasunich> you either add another set of pins and make the user connect them, or you do a hack
[02:07:10] <cradek> I'll have a probe on a mesa machine one of these days...
[02:07:13] <SWPadnos> the hack would be needed in several places
[02:07:20] <SWPadnos> probing and homing at least
[02:07:50] <jmkasunich> well, homing currently works without a hack
[02:08:29] <SWPadnos> with incremental encoders
[02:08:44] <cradek> PeterW_: By the way, I like your cards. I had zero problems in my lathe retrofit. I'll be buying more for the mill one of these days - and the reason I chose them is the GPL firmware and your constant helpful cooperation here.
[02:08:47] <jmkasunich> there are two models for index - 1) when index arrives, reset count, and 2) when index arrives, capture count
[02:09:04] <SWPadnos> if we want to add absolute, we move the hack into the encoder driver, since we can't expect a reset
[02:09:11] <jmkasunich> PeterW_: ditto
[02:09:40] <PeterW_> Thanks cradek! always good to hear...
[02:09:58] <cradek> PeterW_: I bet you usually only hear when there are problems... I didn't have any.
[02:11:11] <cradek> I touched probing last - I'll try to help if you guys want to do this.
[02:11:19] <PeterW_> Cradek: yes, but in general the 5I20 has been pretty trouble free
[02:11:26] <jmkasunich> we haven't sufficiently defined "this" yet
[02:11:42] <cradek> heh
[02:12:53] <SWPadnos> having index and latch inputs (and two position outputs) allows for both index models
[02:13:16] <jmkasunich> that's nice for mesa
[02:13:28] <SWPadnos> it works for stepgen too, and for software encoder
[02:13:30] <jmkasunich> but for EMC life just gets more compex
[02:14:19] <SWPadnos> yes, a bit more complex on the HAL signals side
[02:14:23] <cradek> the driver of capture-on-index hardware can easily pretend to be reset-on-index
[02:14:33] <PeterW_> The HM2 counter can clear on index, latch on index (or both at once)
[02:14:36] <PeterW_> It also has a quadrature sequence error flag but I guess theres no
[02:14:38] <PeterW_> way to pass this up the pipe
[02:17:13] <PeterW_> One advantage of latch on index is that it does not muck up the N/T velocity estimation
[02:18:03] <PeterW_> (which Sebastian has not implemented yet)
[02:18:45] <SWPadnos> is there a downside to latching the count just before resetting?
[02:19:24] <SWPadnos> essentially you'd have two latch inputs, latch and latch with reset
[02:19:28] <cradek> hmmm good velocity output would make me switch to hm2
[02:20:13] <jmkasunich> the reason EMC2 (really me) chose to use reset-on-index is that the driver can emulate that if the hw is capture on index
[02:20:20] <jmkasunich> doesn't work the other way around
[02:20:26] <cradek> (well, need index mask too)
[02:20:59] <jmkasunich> actually, if I was the HW designer, I'd never reset the count
[02:21:04] <jmkasunich> use capture always
[02:21:10] <jmkasunich> and let the driver emulate reset-on-index
[02:21:31] <jmkasunich> that way velocity outout is never disrupted
[02:21:38] <jmkasunich> and the hardware is actually simpler
[02:21:46] <jmkasunich> (not a lot, but...)
[02:21:54] <cradek> more communication required though?
[02:22:06] <SWPadnos> you need to read two sets of registers
[02:22:13] <jmkasunich> driver/HW comms you mean?
[02:22:13] <SWPadnos> latched count and current count
[02:22:19] <cradek> yes
[02:22:21] <jmkasunich> real hardware uses PCI, comms are fast
[02:22:29] <SWPadnos> don't count on that
[02:22:29] <jmkasunich> * jmkasunich is a snob, no parport for me
[02:23:02] <SWPadnos> it's faster than parport due to the width, but that embedded box I have has terrible (!) PCI performance
[02:23:15] <SWPadnos> unless someone makes a DMA framework, PCI can be a dog
[02:26:32] <jmkasunich> dog = what? 500nS per transfer?
[02:26:39] <SWPadnos> something like that
[02:26:47] <SWPadnos> for sequential reads
[02:26:57] <PeterW_> Sebastian is looking at DMA (The TRAM stuff isn't just for EPP))
[02:27:09] <jmkasunich> TRAM?
[02:27:15] <SWPadnos> transfer RAM array
[02:27:24] <SWPadnos> similar to what we did with the PPMC
[02:27:29] <jmkasunich> ah
[02:27:57] <jmkasunich> upside = speed, downside is no conditional accesses
[02:28:02] <SWPadnos> at least that's my understanding
[02:28:09] <jmkasunich> (read foo only when required, etc)
[02:28:12] <SWPadnos> also potential problems with waiting for completion
[02:28:22] <PeterW_> Translation RAM so block DMA (or burst mode on 5I20) can use sequential incrementing 32 bit addresses
[02:29:57] <PeterW_> But completion of 20or so DMA tranfers takes only a little longer than a single non-DMA transaction
[02:30:28] <SWPadnos> the question is how we get notification of DMA completion from within an RT context
[02:33:07] <PeterW_> Either poll DMA controller (slow but still faster than doing all the I/O by hand) or DMA a flag into memory
[02:33:44] <SWPadnos> I'm not sure if we can twiddle he DMA controller directly or if we need the kernel to handle it
[02:34:19] <SWPadnos> if the kernel needs to handle it, I suspect it's done with a completion thread (similar to a bottom-half interrupt handler)
[02:36:57] <PeterW_> With the 5I22/5I23 and one wait state (HM2 has one ws) you get about 20 transfers per uSec so its not a lot of time...
[02:37:21] <jmkasunich> I see nothing wrong with busywaiting during the transfers
[02:37:31] <SWPadnos> I'll have to check that on my otherwise-good-but-apparently-dog-slow-PCI system :)
[02:37:46] <SWPadnos> except that you need to tweak a system resource to do it (the DMA controller)
[02:37:54] <jmkasunich> PeterW_: isn't the PCI clock 33MHz?
[02:38:08] <jmkasunich> then 1 ws = 33/2 = 16.5 transfers/uS
[02:38:51] <PeterW_> Yes but the local bus clock on the 5I22 is 50 MHz (and the ws is one 50 MHz ws)
[02:38:56] <jmkasunich> SWPadnos: simpler would be to write zero to the last word of the buffer in ram, then trigger the DMA, and make sure the hardware returns non-zero in that word
[02:39:03] <jmkasunich> busyloop reading that word
[02:39:22] <jmkasunich> oh, the DMA is throttled by the local clock, not the PCI clock?
[02:39:29] <PeterW_> (Yes JMK and much faster as well)
[02:39:33] <SWPadnos> sure, but AFAIK you have to fiddle with DMA controllers that are managed by the kernel
[02:40:02] <PeterW_> JMK: yes
[02:40:04] <jmkasunich> oh, duh, you're not talking about the "completion test", you're talking about setting up the transfer and initiating it in the first place
[02:40:17] <SWPadnos> right
[02:40:37] <SWPadnos> I'm not sure if you can set up a master transfer by only fiddling with HM2 registers
[02:40:53] <SWPadnos> (which may not be the same as a DMA request either ...)
[02:41:06] <SWPadnos> I'd have to study up on those a bit
[02:41:19] <jmkasunich> I'll let seb do that ;-)
[02:41:27] <SWPadnos> oh yeah, good idea! :)
[02:41:37] <PeterW_> SWP; yes you can (using the DMA controller, its quite easy)
[02:41:43] <jmkasunich> I hope to do some 5i20 stuff over the holidays
[02:41:54] <jmkasunich> I have something like 12 days of vacation left
[02:42:22] <SWPadnos> PeterW_, do you mean the chipset/motherboard DMA controller, or something on the 5i20/5i22 ...?
[02:42:41] <jmkasunich> with holidays and weekends, I think I'll be off from about december 11 to Jan 5 ;-)
[02:42:50] <SWPadnos> nice
[02:42:56] <PeterW_> (oops I meant not HM2 registers but 9054 registers...)
[02:44:13] <PeterW_> The 9054 has a nice DMA controller with block and demand modes and even descriptor blocks in memory or FPGA space
[02:44:13] <SWPadnos> ok, so by messing with something that Linux doesn't deal with, we can tell the HM2 to initiate a multi-word master transfer?
[02:44:19] <SWPadnos> ok, cool
[02:44:30] <PeterW_> Yep
[02:44:45] <SWPadnos> so the only thing we have to deal with there is whether some other PCI card is doing a transfer when we want to do one :)
[02:44:50] <jmkasunich> 9054 is 5i22 only, right? can the 5i20 do something similar?
[02:46:59] <PeterW_> (5I22,5I23 only) 5I20 is PCI9030 based=slave only, but it can be sped up by a factor of 2-3 by using burst transfers
[02:47:01] <PeterW_> This is why I intend to add the TRAM to the 5I20 as well
[02:55:35] <PeterW_> g'night all...
[02:55:58] <SWPadnos> see you PeterW_
[02:56:03] <jmkasunich> goodnight
[07:17:02] <Fisia> i ve seen mesa that connect on PCI & LPT port... but using servo, hows is it works?
[07:17:22] <Fisia> they sending enc. data to PC right?
[07:31:33] <Rap2>
[07:31:40] <alex_joni> Fisia: the mesa boards read the encoders
[07:31:46] <alex_joni> and send encoder counts to the PC
[07:32:16] <alex_joni> the PC also sends velocity prescriptions to the mesa board, which sets a certain voltage at the output stage (usually through a PWM + filter)
[07:33:40] <Fisia> :) thats whats i want to know...
[07:34:32] <Fisia> so basicly mesa read the enc. count and sending the position to PC right?
[07:35:12] <Fisia> and on realtime PC send direction+velocity to mesa
[07:35:37] <Fisia> :)
[07:36:54] <Fisia> is it HAL doing this to mesa? what files containing this description on EMC2 source? please..
[07:37:59] <Fisia> i need to know how much time they doing the calc on each processing...
[07:39:21] <alex_joni> Fisia: there are currently more than one driver in emc2 for mesa cards
[07:39:24] <Fisia> in realtime of PC
[07:39:38] <alex_joni> but the things you want to look at are in src/hal/drivers/hostmot2 I think
[07:39:59] <Fisia> how about mesa that doing these on PCI and LPT port? 2 cards of them
[07:40:18] <Fisia> 5ixx and 7ixx
[07:40:48] <Fisia> (im a bit forgot... but its on a low cost)
[07:41:39] <Fisia> im still imagine it how such a data (alot of data including encoder) could be fit on LPT also
[07:42:01] <Fisia> fit on meaning of speed of time
[07:42:35] <Fisia> :)
[07:43:48] <Fisia> 20Khz?
[07:45:22] <Fisia> ah, i read u... thxs
[07:46:05] <Fisia> ^_^
[07:54:11] <anonimasu> morning
[07:54:20] <Fisia> i have suggestion on replacing mesa for stepper controlling, by using 8255 on PCI, we could address alot more stepper motor !
[07:54:26] <Fisia> morning. :)
[07:55:06] <Fisia> wonderfull day isnt it..
[07:55:36] <Fisia> 5 stepper. 8, 10, 15 stepper ... u name it
[07:56:02] <anonimasu> 8255 is what card?
[07:56:30] <Fisia> 8255 is an IC
[07:57:13] <anonimasu> well, I guess it depends if you prioritize the build or the final machine
[07:57:21] <micges> good morning
[07:57:22] <Fisia> old IC from Old-PC on your junk yard, u still could fine it on your local IC store
[07:57:38] <Fisia> good day :)
[07:58:20] <Fisia> all u need is an paralel 8255 and address encoder for each of them
[07:58:56] <anonimasu> _all you need_
[07:59:02] <Fisia> each 8255 has 8bitx3 port
[07:59:10] <Fisia> yup
[07:59:26] <anonimasu> I've heard that before from people spending 2 years on building their own stepper drivers..
[07:59:31] <Fisia> eh... except programming parts
[07:59:35] <anonimasu> because the comercial ones are exepensive.
[08:00:50] <Fisia> they do not understand What is Stepper and how to connect em... the fun part of Stepper was, how to TEST them
[08:01:15] <alex_joni> Fisia: you can put stepgens inside the mesa cards
[08:01:31] <alex_joni> the latest 5i23 I think has something like 20 stepper controller inside
[08:02:06] <Fisia> i think with 8255 u could do it 50 stepper
[08:02:17] <Fisia> haha...
[08:02:21] <alex_joni> Fisia: nope
[08:02:25] <alex_joni> I mean, probably you can
[08:02:40] <Fisia> :) nop? please explain..
[08:02:43] <alex_joni> but it's a pain, you need a PCI chip, as the 8255 needs special HW to connect to PCI
[08:02:56] <alex_joni> you can probably put 3 x 8255 on one PCI board
[08:03:31] <alex_joni> that means you get maybe 36 stepper conneciton on one card
[08:03:43] <alex_joni> so you need more than one card to control 50 steppers
[08:03:57] <Fisia> NO... PCI already has address+data, u just have to connect em to address-cicuit thats connect to 8255's lot of
[08:03:59] <alex_joni> but the problem with 8255 is that you need to set the bits for each step/dir
[08:04:10] <Fisia> true
[08:04:21] <alex_joni> Fisia: that doesn't work.. you can connect an 8255 directly to an ISA bus with address decoding
[08:04:24] <alex_joni> but not to PCI
[08:04:53] <alex_joni> PCI is a lot more complicated, you need to account for DMA, timeouts, handshakes, whatnot
[08:05:19] <alex_joni> (no expert in this really, but I've seen PCI boards with 8255 on them, and they _all_ used some special chip for PCI access/connection)
[08:05:45] <alex_joni> anyways, that is doable, but the rate to update the 8255 chips will be way lower than a solution like 5i22 + hostmot2 + stepgens inside
[08:06:29] <alex_joni> you can probably go to 50kHz or so step pulses with 8255 & PCI card
[08:07:03] <anonimasu> brb
[08:07:04] <anonimasu> :)
[08:07:32] <Fisia> .. i see, i think i miss calculate it, on different ISA and PCI...
[08:09:50] <Fisia> (i guess PC on today really cut mechanic creativity on thats ...)
[08:10:06] <alex_joni> ISA is easy to do, just a bunch of address decoding, and you're done
[08:10:18] <alex_joni> but the way to do it imo, is the way hostmot2 does it
[08:10:27] <alex_joni> you have the stepgen (step generator) inside the board
[08:10:38] <alex_joni> emc2 sets velocity/position prescriptions
[08:10:45] <alex_joni> and the hardware generates the pulses
[08:10:57] <alex_joni> I think you can go up to hundreds of kHz for step rates
[08:11:01] <alex_joni> on 20 steppers at once
[08:11:39] <Fisia> :>
[08:14:21] <Fisia> (yes, im gonna read on what u suggest point as a starts.. since im still curious on it, all of it)
[08:15:00] <Fisia> (puzzle, but good reading)
[08:15:12] <Fisia> (for linux beginner)
[08:18:30] <alex_joni> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?HostMot2
[08:20:20] <Fisia> :) thx
[08:24:02] <alex_joni> so I guess it's 5i22, and 24 stepgens + 8 servo channels
[08:24:18] <alex_joni> I don't think there is anyone out there who might need more, but if they do, they can always plug in a second board
[08:25:50] <Fisia> ...true, hehe..
[08:26:28] <Fisia> thats more than enough i guess
[08:27:21] <Fisia> mesa rule ones again
[08:34:37] <alex_joni> Fisia: mesa is just one example of the HW that works with emc2
[08:34:42] <alex_joni> there are certainly others
[08:35:00] <alex_joni> like the Motenc :
http://www.vitalsystem.com/web/motion/motionLite.php
[08:35:03] <alex_joni> for servos
[08:36:59] <Fisia> :)
[08:41:27] <Fisia> the best in low cost Cards,opto,servo ampl. or EMC2 hardware cards, is it still on mesa?
[08:44:24] <Fisia> MOTENC-Lite PCI 4-Axis Motion Board (8DAC,8ADC,4ENC,48 Digi IO) ...$595.00 ...fiuh.
[08:47:14] <Fisia> is it servo ampl. already?
[08:49:27] <alex_joni> what do you mean?
[08:50:06] <alex_joni> you still need to buy/have servo amps and motors+encoders
[08:50:36] <Fisia> :>
[08:51:47] <alex_joni> btw, you probably don't need the one with 8ADC's
[08:52:37] <Fisia> so it connect on 4enc + 48 digi IO yes
[09:03:58] <anonimasu> iab
[09:19:28] <Fisia> :)
[09:43:22] <Fisia> :) need to go, have a nicest days to all of u, ok.
[11:49:59] <BigJohnT> how do I make it so when I type a command in the termainal window linux knows where the script is?
[11:50:24] <BigJohnT> I think I have to put it in a certian directory ...
[11:51:20] <BigJohnT> I have a program fop that does not show up in the package manager and only has a download the file and run the script thing
[11:51:37] <archivist> or set the user $path which is set in one of the . files in the user dir
[11:51:53] <archivist> * archivist remembering the old unix way
[11:52:24] <BigJohnT> * BigJohnT looking
[11:58:58] <BigJohnT> hmmm don't see anything except maybe .bashrc but it don't look like it
[11:59:21] <fragalot> BigJohnT: /user/share/bin
[11:59:23] <fragalot> iirc
[11:59:47] <fragalot> sorry /usr/bin
[12:00:25] <BigJohnT> fragalot: you had me looking frantly for it :0
[12:00:36] <archivist> .bashrc that is it, your personal environment settings
[12:01:27] <archivist> ages since I played with it though
[12:01:37] <BigJohnT> I see that some of the files in /usr/bin are links to shell scripts, how do I do that?
[12:02:10] <archivist> man ln
[12:02:32] <BigJohnT> tnks
[12:02:43] <fragalot> BigJohnT: ln -s <FROM> <TO>
[12:03:29] <BigJohnT> thanks
[12:04:42] <fragalot> yw
[12:04:47] <fenn> i always get that backwards
[12:04:51] <fragalot> me too
[12:04:52] <fragalot> lol
[12:07:38] <BigJohnT> do I need to be in the directory of the file then do the ln -s /usr/bin fop ?
[12:08:11] <fragalot> yes, or you can do ln -s /usr/bin/fop /home/bigjohn/fop
[12:08:24] <fragalot> (note, /usr/bin/fop and not /usr/bin)
[12:08:28] <BigJohnT> ok thanks
[12:10:41] <fragalot> http://www.dealextreme.com/details.dx/sku.8113
[12:10:46] <fragalot> I FOUND A PARALLEL CABLE! YAY!
[12:10:47] <fragalot> :p
[12:12:23] <anonimasu> uh, they are plenty everywhere )
[12:12:24] <anonimasu> :)
[12:13:19] <archivist> parallel is becoming rare
[12:13:42] <fragalot> anonimasu: Can't find them anymoer arround here
[12:13:57] <fragalot> last time i asked one in a store they raised an eyebrow and said "son.. Theres something called USB now"
[12:15:22] <archivist> them who have stock dont realise whats happening out in the real world
[12:16:09] <anonimasu> I'd be rude if they told me that
[12:16:22] <BigJohnT> I went into office depot the other day and asked the computer guru for a floppy drive... he got a big smile and why yes we have them... it was a usb floppy :(
[12:16:32] <anonimasu> -_-
[12:16:40] <BigJohnT> went to flea bay and had one in a couple of days
[12:16:51] <anonimasu> my store here stocks paralell cables :)
[12:16:53] <BigJohnT> actually ordered two for $10 each
[12:16:54] <archivist> EMC world needs to get used to USB
[12:16:55] <anonimasu> and parport cards
[12:17:19] <anonimasu> heh my parport card supports vista 64 :p
[12:17:28] <anonimasu> it dosent seem like paralell is dead yet
[12:17:56] <fragalot> i can't fit a PCI card in any of my computers, lol
[12:18:04] <archivist> my local stores dont have parallel any more
[12:18:12] <fragalot> they're all packed, so i'm looking arround for a 2nd hand pc, or an intel atom based one
[12:18:20] <anonimasu> why packed?
[12:19:01] <fragalot> full of other things
[12:19:22] <fragalot> one has tv tuners, extra usb ports, bigass gpu blocking another port, firewire,......
[12:20:06] <fragalot> the other only has one pci port, but it's blocked because of the 7950GX2, the other 5 are laptops, the other one doesn't even have PCI, and the other box is a server..
[12:24:16] <anonimasu> ok
[12:27:01] <BigJohnT> I finally got it it was "sudo ln -s /home/jet/emcdocs/fop/fop /usr/bin
[12:27:31] <BigJohnT> WEEE it works!
[12:36:40] <fragalot> should have been sudo ln -s /home/jet/emcdocs/fop/fop /usr/bin/fop but if it worked,.. ok
[12:37:52] <fenn> you could also add /home/jet/emcdocs/fop/ to your $PATH
[12:38:02] <fragalot> or not
[12:38:03] <fragalot> :p
[12:38:05] <fenn> meh
[12:40:57] <anonimasu> ya
[12:41:06] <anonimasu> yay.. my serialport works in vista 64..
[12:41:10] <BigJohnT> somewhere on line it said the second one just needed to be the directory
[12:41:14] <anonimasu> with the plc programming software without signed drivers
[12:43:38] <anonimasu> and no, I dont have a option, I need to run somekindof windows on my workstation
[12:43:46] <fragalot> BigJohnT: i think if it spots it's a dir, it creates a file in that dir with the same name as the source file
[12:44:00] <fragalot> that's how mv and cp work
[12:44:40] <BigJohnT> must be as it worked :)
[13:08:40] <fragalot> so
[13:08:43] <fragalot> BigJohnT: what does "fop" do ? :;p
[13:08:44] <fragalot> :p
[13:09:30] <BigJohnT> fragalot: Formatting Objects Processor
[13:09:41] <archivist> fragalot_obfuscatingProgram
[13:10:18] <BigJohnT> turns xsl-fo to pdf and xml + xsl to pdf
[13:11:12] <fragalot> omg
[13:11:16] <fragalot> I see
[13:11:22] <fragalot> I just found a box in my house that has a parallel port!
[13:11:35] <fragalot> >.< my router,...... but it's not of much use to me for EMC, lol
[13:13:29] <BigJohnT> now I have to learn how to make stylesheets :/
[15:37:07] <jymm> SWPadnos: EtherLite32
http://www.digi.com/products/serialservers/etherlite.jsp
[15:37:46] <archivist> RS232! that went out with the ark
[15:45:43] <jymm> archivist: Yeah, bite me =)
[15:46:42] <jymm> But... I do wonder if it could control serial motor drivers
[15:47:03] <jymm> as each port shows up as a dev under nix
[15:47:03] <SWPadnos> I wouldn't place any bets on timing with one of those
[15:47:03] <archivist> I have a bunch of modem concentrators here :)
[15:47:19] <SWPadnos> ethernet is waaaaay fast enough so you shouldn't have to worry about it, but you never know what their software is like
[15:47:42] <jymm> archivist: This one is a bit different, wehn you install the drivers, each port shows up as a /dev/ under nix
[15:48:32] <SWPadnos> this is one of the ones I like:
http://www.digi.com/products/embeddedsolutions/digiconnectme.jsp
[15:48:34] <jymm> SWPadnos: Well, SOMEBODY has to start on getting CNC control over ethernet somehow!
[15:48:44] <SWPadnos> it exists, but it's not free
[15:48:46] <SWPadnos> by far
[15:48:47] <archivist> I think mine does something similar (years since I read the manual)
[15:49:17] <archivist> * archivist not considering RS232 at all
[15:49:27] <jymm> SWPadnos: What you mean it exists? Does emc support it?
[15:49:32] <SWPadnos> nope
[15:50:00] <jymm> SWPadnos: Then it's not good for very much now is it =)
[15:50:10] <SWPadnos> but when you get to the level of $10k and up controllers/software, you can buy ethernet-connectd devices without a problem
[15:50:20] <SWPadnos> not to me anyway
[15:51:05] <archivist> us poor folk need usb or cheap ethernet
[15:51:26] <SWPadnos> well, get coding!
[15:51:27] <jymm> SWPadnos: Hmmm, not to be a smartass, but why are we still dealing with paraport? Most machines these days don't come with one, usb sucks, but ethernet remains constant
[15:51:48] <archivist> although the PCIe for next year looks interesting
[15:52:06] <piasdom> g'mornin all
[15:52:07] <SWPadnos> because the parallel port is a very simple device, and is still available for almost every computer made (excepting those without expansion ports, of course)
[15:52:25] <jymm> SWPadnos: like craptops? ;)
[15:52:32] <SWPadnos> :P
[15:53:07] <jymm> SWPadnos: Ok, 10mbps ehternet chips are pretty cheap, is it really that difficult to come up woth something?
[15:53:21] <SWPadnos> actually, mu laptop has an expansion port, I just don't care to buy a parallel port for it
[15:53:35] <SWPadnos> somewhat difficult, though a lot of the work is done
[15:53:38] <jymm> SWPadnos: (I know, just pulling your chain as usual)
[15:53:58] <SWPadnos> first off, you can't use the normal ethernet drivers for RTNet, you need an RT driver for each chip you want to support
[15:54:21] <SWPadnos> second, the netowrk can't be connected to anything that doesn't support RTNet
[15:54:22] <jymm> SWPadnos: And they exist already?
[15:54:31] <jymm> the drivers I mean
[15:54:38] <SWPadnos> so you can't just connect a couple of doodads to your existing network
[15:54:41] <SWPadnos> some do
[15:54:42] <jymm> Switches are cheap
[15:54:47] <SWPadnos> you can't use switches
[15:54:52] <jymm> hub only?
[15:54:53] <SWPadnos> unless you know what you're doing
[15:55:05] <jymm> I havne't seen a hub in decades
[15:55:14] <jymm> do they still exist?
[15:55:23] <jymm> other than blackbox $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
[15:55:29] <SWPadnos> unless you know the exact packet delay for your switch, or you can tell it to make a virtual hub on a couple of ports, you're in trouble
[15:55:52] <jymm> vlan or vhub?
[15:56:01] <SWPadnos> I'm sure switches are usable, but I don't know how difficult it is to do so
[15:56:12] <SWPadnos> hub, vlan would be terrible
[15:56:42] <SWPadnos> RTNet uses TDMA basically - each device gets a time slice in which it can transmit
[15:56:46] <jymm> ok, anyhow something exists already
[15:56:49] <SWPadnos> so ther eare no collisions
[15:57:08] <SWPadnos> sure, some stuf exists, and the software could be made to work with EMC
[15:57:20] <SWPadnos> too bad there are no motor drivers that use RTNet (that I know of)
[15:57:29] <SWPadnos> so there's a hardware problem as well
[15:57:47] <jymm> http://www.amazon.com/Netgear-EN104TP-4-Port-Ethernet-Uplink/dp/B00000J4M9
[15:57:58] <SWPadnos> the existing USB/FireWire/Ethernet devices generally use proprietary protocols
[15:58:01] <anonimasu> netgrear -_-
[15:58:12] <anonimasu> not high reliability
[15:58:28] <SWPadnos> or protocols for which we'd have to pay $$$$ to get access to the spec, and we wouldn't be able to make GPL software even if we had the spec due to NDA problems
[15:59:15] <jymm> SWPadnos: well, what about jsut iface step/dir or cw/ccw to any existing driver
[15:59:29] <SWPadnos> that made no sense
[15:59:32] <SWPadnos> to me anyway
[16:00:05] <jymm> SWPadnos: Ok some module that has ethernet on one side, then step/dir or cw/ccw as the output
[16:00:18] <anonimasu> uh.. and you get realtime from where?
[16:00:20] <SWPadnos> like the G-Rex?
[16:00:38] <jymm> SWPadnos: I thought grex was usb thing
[16:00:41] <SWPadnos> yep, you end up with data turnaround problems
[16:00:46] <SWPadnos> USB or ethernet
[16:00:49] <jymm> ah
[16:01:33] <jymm> SWPadnos: what about that digi module you mentioned you like?
[16:02:02] <jymm> ConnectME
[16:02:02] <SWPadnos> it's an ethernet-connected computer with a serial port on it
[16:02:15] <SWPadnos> they used to run Linux, not sure nowadays
[16:02:59] <jymm> Hmmm, maybe I could get an eval unit
[16:04:05] <anonimasu> :/
[16:04:29] <jymm> anonimasu: ?
[16:04:43] <anonimasu> connectme is cute but realtime?
[16:05:05] <SWPadnos> it's got an ARM chip in it, you could probably do something with it
[16:05:27] <anonimasu> isnt the only way to get realtime like that to feed the next n changes of speed
[16:05:44] <anonimasu> and then have a sync that keeps modules/drivs advancing where they should be..
[16:05:44] <SWPadnos> or use something like IEEE1588
[16:06:00] <SWPadnos> that's certainly one way of doing it
[16:06:26] <anonimasu> though there's a pile of nasty things when doing it like that :)
[16:09:51] <jymm> Well if the big boys are doing it, I'm sure that something could be done
[16:10:21] <anonimasu> the big boys uses custom hardware
[16:10:31] <jymm> ok
[16:10:44] <jymm> so what's custom abut it?
[16:10:52] <SWPadnos> and charge $5000 for the controller, $1500 for each drive, and a bunch more for the PC software to run it all
[16:10:55] <archivist> we need cheap custom :)
[16:11:27] <jymm> archivist: Again, what is custom about it? they they created it inhouse?
[16:11:41] <archivist> the realtime part!
[16:11:44] <SWPadnos> who knows, they're not telling and I'm not about to buy some so I can try to find out
[16:11:51] <jymm> archivist: which is what ?
[16:11:57] <jymm> compared to somethign else
[16:12:03] <anonimasu> http://embedded-system.net/ethercat-ethernet-for-xilinx-fpgas.html
[16:12:59] <archivist> * archivist could see the word IP meaning a price?
[16:13:32] <jymm> Well many of you guys muck around with FPGA's as it is.
[16:13:43] <anonimasu> www.bechhoff.com
[16:13:47] <anonimasu> call them up and ask for a price
[16:13:54] <anonimasu> they sell ethercat piggyback boards :)
[16:14:01] <anonimasu> but they are probably too expensive anway.
[16:14:07] <SWPadnos> that's a slave controller, it has nothing to do with the master
[16:14:15] <SWPadnos> except that it's a slave of course :)
[16:14:20] <anonimasu> yeah
[16:14:51] <anonimasu> the ip licence is probably $$$$$$$$$$$$$$$$$$$$
[16:15:26] <SWPadnos> they sell a couple of ASICs as well
[16:15:53] <jymm> SWPadnos: Got electron microscope? =)
[16:15:58] <SWPadnos> nope
[16:16:24] <jymm> SWPadnos: Well, wth not?!
[16:16:30] <SWPadnos> ?????
[16:16:35] <SWPadnos> err, $$$$$$$
[16:16:47] <anonimasu> :)
[16:17:03] <jymm> SWPadnos: Oh, is that all... just go borrow one from a Univ
[16:17:19] <jymm> they wont mind
[16:17:23] <SWPadnos> I'm sure
[16:17:24] <anonimasu> jymm: the reason there isnt free fast realtime is probably $$$$$$$ and that the people that are smart enough to realize something like that already works in the industry
[16:17:40] <SWPadnos> I don't think that's it
[16:18:03] <SWPadnos> there is free good realtime, but there aren't any low-cost hardware products based on it
[16:18:11] <SWPadnos> that I know f
[16:18:13] <SWPadnos> of
[16:18:42] <anonimasu> I wonder why then
[16:18:54] <archivist> I wish I had time and some money to develop some cheap stuff
[16:18:55] <jymm> My issue is that I don't know the timing specs like SWPadnos does, so I can't glance at specs and say "this could work"
[16:18:58] <SWPadnos> well, developing hardware isn't as easy as software
[16:19:07] <SWPadnos> there is a lot more of an investment (scopes, etc)
[16:19:11] <archivist> you need kit!
[16:19:17] <SWPadnos> yep
[16:19:25] <archivist> logic analysers etc
[16:19:31] <SWPadnos> and there aren't anywhere near as many potential contributors and testers
[16:19:55] <anonimasu> well, it boils down to cost then
[16:19:57] <anonimasu> pretty much :/
[16:19:59] <SWPadnos> you get slow development in niche markets anyway, and when there's hardware involved it gets even worse
[16:20:02] <archivist> I have a couple logic analysers
[16:20:03] <SWPadnos> more or less
[16:20:06] <jymm> "All we need is love..... all we need is love.... all we need is love, love, love, love is all we need, love is all we need..."
[16:20:45] <SWPadnos> so anyone who wants to do this is likely to say "well, I have to have all this equipmnet, I might as well charge for my stuff", at which point a lot of potential contributors will bow out, since they're not getting paid
[16:21:05] <SWPadnos> (and someone else is)
[16:21:13] <anonimasu> * anonimasu drools at the ethercat plc cycletimes
[16:22:28] <jymm> SWPadnos: I dun know, maybe get a chip mfg to sponsor the project.
[16:22:34] <anonimasu> 100 nanoseconds of responsetime is good
[16:22:47] <SWPadnos> jymm, let me know when you find one. I'll contrubute for sure :)
[16:22:50] <anonimasu> :)
[16:23:07] <jymm> SWPadnos: You know Atmel is only 3 miles from me =)
[16:23:21] <jymm> SWPadnos: Maxim is 2
[16:23:38] <SWPadnos> they can start by sending me a permanent license for their Linux and Windows-based tools
[16:23:48] <archivist> * archivist thinks there is mileage in the USB fifo Jon Elson mentioned
[16:23:53] <jymm> Digi USED to be 1/2 mile away but it looks like they might have moved out of state
[16:24:13] <jymm> SWPadnos: which Atmel?
[16:24:17] <jymm> ,
[16:24:42] <SWPadnos> oh, I was thinking Altera. nevermind
[16:24:57] <SWPadnos> same for Atmel though, they make programmable logic too
[16:25:05] <anonimasu> brb
[16:27:40] <jymm> =)
[16:29:39] <toastatwork> has anyone ever tried using OpenFOAM
[16:30:47] <archivist> had to google to find out what it is
[16:31:53] <toastatwork> open source cfd
[16:36:21] <jymm> toastatwork: FOAF = Friend of a friend, a social network thingy
[16:36:32] <jymm> oh, you said foam, nm
[16:56:30] <toastatwork> it looks like a pretty robust solver, but it also looks like it's as complicated as a robust solver needs to be
[16:56:48] <toastatwork> it says fluid dynamics, but it does all sorts of things like stress, etc
[16:58:21] <anonimasu> toastatwork: hey how's things?
[16:58:44] <toastatwork> good!
[16:58:59] <toastatwork> et tu
[16:59:43] <anonimasu> hai genki desu
[17:00:00] <toastatwork> i have no idea what you just said
[17:00:03] <toastatwork> but good!
[17:00:07] <anonimasu> yes good :)
[17:00:29] <anonimasu> * anonimasu has to wikipedia "et tu" :p
[17:00:44] <toastatwork> lol, "and you"
[17:00:48] <anonimasu> procrastinating doing math homework and waiting for dinner
[17:00:58] <toastatwork> hot
[17:01:18] <anonimasu> need some energy first
[17:01:22] <toastatwork> i am waiting for the rush to subside for lunch
[17:07:55] <anonimasu> I see
[18:03:44] <BigJohnT> who is chester88 on the zone?
[18:04:15] <Poincare> where can I find a clear explanation about those co-ordinate systems in emc2?
[18:04:51] <cradek> is there something unclear in the documentation?
[18:05:24] <BigJohnT> or you can't find it in the documentation?
[18:05:35] <Poincare> it's not clear to me
[18:05:42] <cradek> then ask a question
[18:07:44] <cradek> I see in the user manual there is a "Coordinate Systems" section - it is very short - maybe we can clarify something that is unclear
[18:08:19] <Poincare> yeah, i'm re-reading it first
[18:08:30] <cradek> ok
[18:08:43] <Poincare> at the moment i don't even know how write my question :-)
[18:09:10] <anonimasu> hm, maybe you should write what you know
[18:09:40] <Poincare> or try to describe my problem...
[18:10:17] <cradek> just try - it's ok if the question is not perfect
[18:10:19] <fragalot> sometimes, that helps
[18:11:06] <Poincare> I have generated a g-code from eagle (pcb cad software). If I load it in emc2 and make a test run, interrupt it and reload it, it moves the design
[18:11:37] <Poincare> very nice if you just milled the contours and want to load the file to drill the holes and your design is half an inch of
[18:11:43] <cradek> does the gcode use G92?
[18:12:31] <Poincare> no, i use it to set the zero co-ordinates
[18:12:57] <SWPadnos> does the G-code use G91?
[18:13:02] <cradek> what GUI are you using? If it's AXIS (the default) you should use touch off, not G92
[18:13:13] <Poincare> aha
[18:13:16] <Poincare> i'm using axis
[18:13:29] <cradek> first program G92.1 to clear any G92 offset
[18:13:58] <cradek> then jog an axis where you want zero, poke touch-off, enter the new value you want (0), you will see the program move
[18:14:49] <Poincare> ok, and what is the difference between G90 and G91 then?
[18:15:04] <Poincare> the program sets G90
[18:15:19] <cradek> click Applications/CNC/Gcode quick reference
[18:15:23] <cradek> see G90,G91 there
[18:15:35] <cradek> for more details, you can click on them to see the more verbose documentation
[18:15:40] <Poincare> ok thanks
[18:15:53] <cradek> I have been using EMC for years and I still use the quick ref all the time
[18:16:39] <Poincare> i'm using it about 8-9 months now, first time I use someone else his code and I run into many problems :-)
[18:16:41] <archivist> I touch off and never use the g9x offsets yet
[18:17:06] <Poincare> I'll check it out. If you don't hear from me the next 5 months, then it's working :-D
[18:17:41] <cradek> good enough
[18:18:30] <jepler> the reason that your origin shifted is that our gcode standard says that M2 decativates G92 offsets like G92.2. If emc read ahead in your gcode program to the end, then the offset is reset.
[18:18:56] <jepler> that's why cradek suggests using g54 offsets via "touch off": they do not have this behavior, but stay the same from run to run
[18:27:01] <fragalot> Beep.
[18:27:31] <archivist> BSOD
[18:28:07] <fragalot> Fail
[18:28:34] <archivist> not had a kernel panic for a while
[18:29:37] <fragalot> kernel panic != BSOD
[18:30:21] <archivist> I like the disk full kernel panic, sending mail to root filling the disk...
[18:31:06] <fragalot> lol
[18:31:07] <archivist> try getting into a system in that state to clear a bit of space
[18:31:22] <fragalot> livecd
[18:31:57] <archivist> nah was on Unix svr3 on an Altos 386
[18:36:27] <archivist> fragalot, hint leave a terminal open on any unix like system thats near full
[18:37:12] <fragalot> archivist: hehe, always
[18:37:33] <alex_joni> archivist: I had a nice one once
[18:37:46] <archivist> my headless bot box has terminals waiting :)
[18:37:48] <alex_joni> someone set up a serial console, which caused some timeouts/errors
[18:37:55] <alex_joni> and it filled up /var/log with files
[18:38:14] <alex_joni> couple million of them, one for each attempt.. filled up for 1-2 years I think
[18:38:15] <fragalot> right
[18:38:22] <archivist> hehe
[18:38:25] <alex_joni> until it couldn't write anything to disk.. ti ran out of inodes
[18:38:26] <fragalot> i need to make a line following robot for µC class
[18:38:31] <fragalot> any1 got a suggestion for a chassis?
[18:38:41] <alex_joni> fragalot: old shoe
[18:39:18] <alex_joni> I'm sure you'll win a prize for out-of-the box thinking :D
[18:39:23] <archivist> plimsole then it can follow the plimsole line
[18:39:41] <alex_joni> oh, you can find old ones with a hole in the sole
[18:41:10] <SWPadnos> a roller skate may be closer to ideal
[18:41:13] <fragalot> lol
[18:41:23] <alex_joni> I know.. do a rollerblade
[18:41:27] <fragalot> alex_joni: some of the guys in my class bought a Wall-E toy (big) and are modding it
[18:41:30] <alex_joni> that'll get you fame :D
[18:41:32] <fragalot> a rollerblade..
[18:41:35] <fragalot> that.. sounds doable
[18:41:44] <alex_joni> it's hard to balance it :D
[18:42:00] <SWPadnos> make a big one, on a skateboard
[18:42:10] <SWPadnos> with a car battery for power
[18:42:16] <toastatwork> brb
[18:42:19] <SWPadnos> (go big, dude)
[18:42:37] <archivist> heh follow the yellow brick road
[18:43:05] <alex_joni> rofl @ archivist
[18:43:37] <fragalot> haha
[18:43:47] <fragalot> alex_joni: oldschool rollerblades
[18:43:52] <toastatwork> oops, wrong window
[18:43:55] <alex_joni> archivist: I just _hope_ you reference the wizard of ozz
[18:44:02] <alex_joni> fragalot: those are rollerscates
[18:50:44] <alex_joni> archivist: and not this:
http://www.youtube.com/watch?v=OrUatLDxNZ0
[19:26:32] <fragalot> alex_joni: both got wheels under 'm
[19:31:26] <alex_joni> fragalot: yeah, but it's a bit different if you have 4 in a row, or 2 x 2
[19:32:26] <fragalot> meh ;)
[19:34:46] <alex_joni> they did try to make a motorcycle work for the grand challenge
[19:34:54] <alex_joni> and it worked .. for some small values of worked
[19:39:33] <fragalot> lol
[19:45:42] <anonimasu> :)
[19:49:19] <fragalot> http://www.youtube.com/watch?v=oUH3m6ZyW-g&eurl=http://www.botjunkie.com/
[19:49:22] <fragalot> hahaha thats awesome
[19:56:38] <izua> Hi. I want to learn more about generating paths and accelerations.
[19:56:47] <izua> I'm not exactly an emc user, but I assume you guys know.
[19:57:28] <izua> My final purpose is to make portable CNC controller, which will take GCode files on a SD Card and interpret them on the fly
[19:57:31] <alex_joni> we know emc2 does it right :)
[19:57:54] <izua> heh
[19:58:12] <alex_joni> izua: do you plan to make it open source?
[19:58:15] <cradek> izua: if your product/software will be GPL, you can use parts of the EMC2 code
[19:58:34] <jepler> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Simple_Tp_Notes
[19:58:43] <izua> well, it's a personal project.
[19:59:04] <izua> but it might catch some interest among former clients, so yes, it might also end up as an open-source product
[19:59:09] <cradek> then that's ok too, if you don't distribute it
[19:59:45] <izua> I'm sure that i won't get filthy rich out of it
[19:59:54] <izua> so making it o/s will probably be better
[20:00:03] <izua> basically, i've done something like this before
[20:00:28] <izua> but it sucks donkeyballs - it converts everything from DXF to lines (arcs, circles, etc)
[20:00:35] <cradek> it's important to decide first, so you know whether you can use existing GPL code
[20:00:43] <izua> and there is no acceleration/decceleration profile
[20:01:01] <izua> most are used for foam cutting, so it's not really a problem, but still, it hurts my ego as a programmer :P
[20:01:12] <cradek> haha
[20:01:21] <jepler> lines and circles are exactly the same, except for their shape
[20:01:40] <izua> well, at first it will be a personal experiment
[20:01:51] <izua> I'm not sure if it ever has to be released
[20:01:57] <jepler> (they're the same in this respect: the obvious parameterization is equal length per 't')
[20:02:08] <izua> heh :)
[20:02:37] <jepler> starting with emc source code would require you to release it under a gpl license if you ever wanted to release it to others.
[20:03:19] <izua> I don't mind releasing source code, really.
[20:07:11] <jepler> that simple_tp_notes page gives pretty good overview of one way to plan with a trapezoidal motion profile.
[20:08:05] <jepler> together with a constant-length parameterization of each primitive (line, arc) you want to do, you're well on your way to an exact stop motion planner that respects velocity and acceleration limits
[20:08:25] <izua> I'm actually looking to understand the math behind it
[20:08:42] <izua> simply using existing code is fine, although i'd really preffer to understand what happens
[20:09:02] <jepler> emc's "blending" works by overlapping the acceleration phase of the next move with the deceleration phase of the prior move, either "as soon as possible", or when the distance from the programmed endpoint reaches a user-settable tolerance parameter
[20:09:33] <izua> so, basically, if you have a few lines
[20:09:43] <izua> you blend last dec with next acc..?
[20:09:57] <izua> isn't this bad for small lines, say, a circle?
[20:10:19] <izua> if I'm making a circle at a very high resolution, for instance
[20:10:51] <jepler> yes, it sucks in that case. that's why you should plan arcs directly, rather than cutting them up into lines.
[20:12:24] <jepler> (other parts of emc are concerned with taking "lots of short lines" and converting them into something that stays within user-specified tolerance while making it better for the trajectory planner)
[20:13:06] <izua> so what does emc does in this case?
[20:13:13] <izua> i know arcs should be interpreted as arcs
[20:13:26] <izua> but what happens if the file actually contains a lot of lines that define an arc?
[20:14:52] <jepler> If your gcode says "go to A, then to B, then to C", and you turn on tolerance mode, and B is within tolerance of the line between A and C, emc is free to turn the original motion A-B-C into A-C
[20:15:12] <jepler> if you have output from naive cam software that has lots of short lines, enabling this mode is often enough to get good contouring speed
[20:16:50] <jepler> but you are right that just using the simple blending algorthm, you'll get utterly terrible performance with short segments
[20:23:34] <izua> what happens with acc/dec
[20:23:39] <izua> how is it calculated exactly?
[20:23:49] <izua> consider we have two connected lines
[20:24:01] <izua> in once case, they form 90 deg, in another case, just 30
[20:24:09] <izua> I'm sure the acc/dec isn't the same
[20:24:15] <izua> are they calculated individually for each line?
[20:24:21] <izua> and then blended?
[20:24:30] <izua> ore somehow "on the fly" ?
[20:24:36] <cradek> yes each line gets half the allowed acceleration
[20:27:40] <izua> can you recommend me something to read on the subject?
[20:28:30] <cradek> the link jepler already gave you, and the source code
[20:29:01] <cradek> http://www.google.com/search?q=trapezoidal+velocity+profile
[20:29:08] <izua> i was looking for a paper, or something similar. but ok, i'll check the source code too.
[20:29:10] <cradek> hey, an emc link is first
[20:29:29] <cradek> most papers will be for much more complex designs
[20:29:43] <cradek> trapezoidal is extremely simple compared to what a lot of people are studying
[20:30:29] <izua> i assumed there are other motion profiles, too
[20:30:39] <izua> what advantages do others provide, though?
[20:30:40] <alex_joni> S-shaped is the next one
[20:30:56] <alex_joni> trapezoidal has limited accel
[20:31:08] <cradek> this is one I've studied
http://www.mech.ubc.ca/~caris/pubs/theses/sonja.pdf
[20:31:10] <alex_joni> the d(accel) called jerk is not limited though
[20:31:29] <alex_joni> S-shaped (like in sonja's paper) is jerk limited
[20:32:02] <izua> you mean, an S 90 degrees left ?
[20:32:24] <alex_joni> izua: no, the trapezoidal and s-shaped usually refer to velocity profile
[20:32:28] <alex_joni> _
[20:32:31] <alex_joni> \
[20:32:37] <alex_joni> didn't work :D
[20:32:44] <izua> heh
[20:32:45] <alex_joni> ____
[20:32:49] <alex_joni> / \
[20:33:00] <alex_joni> anyways.. trapezoidal means:
[20:33:08] <alex_joni> the velocity rises constantly up to cruise speed
[20:33:19] <izua> yes, I know a little about that
[20:33:23] <alex_joni> then it proceeds at cruise speed, and decelarates constantly
[20:33:41] <izua> I've been using Mach3 for a while (a rough equivalent of emc for windows)
[20:33:41] <alex_joni> ok, that's trapezoidal, where you have a certain value of accel
[20:33:57] <alex_joni> ok.. but
[20:34:13] <izua> but?
[20:34:21] <alex_joni> when it goes from 0 velocity to velocity increasing there is a discontinuity
[20:34:28] <alex_joni> accel goes from 0 to a certain value
[20:35:03] <alex_joni> that causes jerk to be unlimited
[20:35:11] <alex_joni> on most machines you don't care about jerk much
[20:35:23] <alex_joni> but if you have a big gantry pulling a couple of g's, then you care
[20:35:24] <alex_joni> :)
[20:35:39] <izua> you mean, acceleration should slowly decrease instead of dropping it cruise speed?
[20:36:08] <alex_joni> yes
[20:36:12] <izua> when it reaches*
[20:36:17] <izua> ah
[20:36:19] <izua> so that's the S profile
[20:36:20] <alex_joni> accel should slowly increase in the accel phase
[20:36:32] <alex_joni> and decel should slowly decrease at the end
[20:37:17] <alex_joni> http://eestud.kku.ac.th/~u4316562/images/scurve.jpg
[20:38:27] <alex_joni> this is trapezoidal:
http://zone.ni.com/cms/images/devzone/tut/a/ce36be30697.gif
[20:38:27] <izua> ah yes.
[20:38:45] <alex_joni> and this:
http://people.mech.kuleuven.be/~bruyninc/blender/pictures/trapvel.png
[20:38:50] <izua> same control exerted over speed by acc, should be done to acc itself
[20:40:07] <alex_joni> right
[20:40:16] <alex_joni> but as I said.. for most machines you don't need to do it
[20:40:20] <alex_joni> and emc2 doesn't do it
[20:40:31] <alex_joni> the concept is not that complicated, but coding it gets messy fast
[20:40:46] <alex_joni> izua: you might want to read something like this
http://zone.ni.com/devzone/cda/tut/p/id/3367
[20:41:16] <izua> i was actually aiming for an option where users can set their own motion profiles
[20:41:46] <izua> but eh, don't think that will ever be necessary
[20:42:05] <izua> ah
[20:42:11] <izua> that's exactly the kind of paper I'm looking for!
[20:56:43] <christel> [Global Notice] Hi all, In about five (5) minutes two of our client servers will be going down for maintenance, the downtime window is set to one hour, but in reality it should be significantly less. Affected users ~1200. Thank you for using freenode and have a great day!
[21:00:31] <toastatwork> .
[21:00:44] <izua> right.
[21:00:47] <izua> i was just thinking.
[21:00:56] <izua> if acc/decs are actually blended together
[21:01:11] <izua> doesn't that make an arc where two lines should join at 90 deg?
[21:01:20] <SWPadnos> yes
[21:01:25] <cradek> not an arc
[21:01:32] <cradek> but some rounded shape
[21:02:01] <SWPadnos> you must either have a rounded corner or you must stop at the endpoint, that's physis
[21:02:04] <SWPadnos> physics
[21:02:19] <anonimasu> or you do a highspeed curve..
[21:02:28] <izua> a highspeed curve?
[21:02:40] <anonimasu> err tangential curve or whatever they call it..
[21:02:47] <SWPadnos> high speed curve = rounded corner
[21:02:51] <izua> i assume the arc is somehow tolerated, as setting a maximum radius it should have
[21:02:52] <anonimasu> nope
[21:02:55] <SWPadnos> low speed curve = smaller rounding
[21:02:57] <anonimasu> you do a loop..
[21:03:04] <SWPadnos> yes, outside the work
[21:03:08] <anonimasu> yep
[21:03:10] <SWPadnos> I was just typing that in, but stopped :)
[21:03:24] <izua> well, it makes sense in a way
[21:03:47] <izua> you have to slow drive when driving, to take a right turn (or left)
[21:03:53] <jepler> I believe emc's blending gives a parabolic shape, because during the blend the acceleration is constant in magnitude and direction.
[21:03:56] <SWPadnos> any cusp (corner) requires acceleration, so to get the corner as programmed, you either have to stop or you need infinite acceleration
[21:04:21] <izua> heh
[21:04:26] <fenn> but machine tools dont have wheels to redirect the momentum, so doing a loop simply means you dont have to slow down while in contact with the work
[21:04:47] <izua> i assume lines which form very sharp angles are even more stinky
[21:05:01] <anonimasu> yep
[21:05:04] <izua> complete decceleration, change of direction
[21:05:06] <anonimasu> and you get sharp corners
[21:05:10] <izua> heh
[21:05:17] <izua> i get this somehow
[21:05:24] <izua> can't evision the code for it, yet..
[21:05:46] <anonimasu> nothing you would hand code :)
[21:06:07] <fenn> someone's gotta code it
[21:06:09] <izua> i *think* that in a perfect world (open loop control)
[21:06:10] <toastatwork> commercial machines do it by reading X number of lines ahead and calculating the individual accelerations at each junction
[21:06:29] <izua> the software toys with acceleration and checks position
[21:06:34] <anonimasu> izua: no. in a world where physics dosent rule.
[21:06:50] <izua> why is that?
[21:07:03] <izua> i dropped the perfect world thing to drop the errors/need for closed loop control
[21:07:20] <izua> anonimasu: well, the point is that i want to code it. and not for a PC, for an MCU.
[21:07:38] <cradek> in emc2 you can specify the tradeoff between rounding and slowing down (using a path tolerance setting)
[21:07:45] <anonimasu> yep
[21:07:57] <fenn> by "hand code" i think he meant g-code
[21:08:07] <anonimasu> yep
[21:08:12] <izua> ah.
[21:08:18] <fenn> * fenn throws anonimasu a cookie
[21:08:20] <izua> i meant the source-code to control such a thing
[21:08:37] <anonimasu> you dont, there's nothing differnet from it then normal arc blending
[21:08:40] <izua> (offtopic: is it me, or kornbluth went down too?)
[21:08:42] <anonimasu> different..
[21:09:10] <fenn> irc server went down for maintenance
[21:09:52] <izua> ah. haven't seen the notice :)
[21:10:09] <izua> well.. right, and all this can be computed on the fly
[21:10:41] <izua> the % where the two lines will start blending i think will determine the actual corner
[21:11:02] <anonimasu> if you do a normal sharp corner that'll happen yes
[21:11:06] <izua> but that has to be translated back in steps (which will be input as a unit)
[21:11:25] <christel> [Global Notice] Hi all, the upgrades went fine, both servers are now back in rotation -- it went a lot quicker than expected, you'd never guess we run gentoo! Apologies for the inconvenience caused and have a nice day!
[21:12:42] <izua> ok
[21:12:46] <izua> i think i got the line thing
[21:12:48] <izua> what happens with arcs?
[21:13:12] <izua> let's say we got a single arc (or better yet, a circle) for our drawing
[21:13:41] <izua> (i assume line-arc and arc-arc crossings are bad, you'll probably have to take a segment over which to calculate acc/dec)
[21:14:27] <alex_joni> good night all
[21:14:32] <anonimasu> sonight alex
[21:15:45] <anonimasu> all direction changes are bad I guess if you look at it like that
[21:22:27] <jepler> izua: well, on the pc there's plenty of CPU power to use as many sin and cos calls as you want to find points on a circle. probably very different on a microcontroller!
[21:22:53] <anonimasu> you are missing the point
[21:23:18] <jepler> anonimasu: that happens all the time
[21:23:24] <anonimasu> you dont handle thoose cases differently then a normal arc blend(when you have highspeed toolpaths that does a outside curve at corners)
[21:24:04] <izua> yes, but, how is it handled?
[21:24:14] <izua> i mean, you do a lot of intermediate points, draw lines between them
[21:24:31] <izua> and apply the same blend algo as above? i assumed we decided this is a bad idea
[21:24:58] <anonimasu> I dont know, blending and trajectory planning is hard enough as it is even if you have enough cpu power
[21:25:56] <jepler> izua: circles and lines are almost the same in terms of the velocity profile and blending (trapezoidal velocity profile and blending by overlapping decel and accel phases)
[21:26:27] <jepler> the difference is that a line is x(t) = x0 + dx * t y(t) = y0 + dy * t
[21:26:50] <izua> so, you will actually split a circle into a lot of lines
[21:26:56] <jepler> and a circle is x(t) = (something in terms of the center, radius, start and end theta where each "t" is one arc distance)
[21:27:20] <izua> I'm sorry. What's t?
[21:27:27] <jepler> t is "time" or "distance"
[21:27:33] <izua> right.
[21:28:20] <jepler> (for many curves, such as splines, there is not a direct relationship between 't' and the length; there is for arcs and lines)
[21:30:00] <izua> yes, of course.
[21:30:20] <izua> time is proportional with the curve defined between the two points in the case of a curve, not a direct line
[21:31:01] <jepler> right, it's the arc length
[21:33:56] <jepler> so you don't have 4 blending cases (line-arc, line-line, arc-arc, arc-line), you just have one case and two pieces of code to give you a position after moving 't' along the given line-or-arc
[21:38:55] <anonimasu> wow!
http://www.emugedownloads.com/videos/v_max-hsc-bearbeitung_de.wmv
[21:39:23] <anonimasu> 25m/min :p
[21:39:31] <anonimasu> in cut
[21:40:15] <anonimasu> for thoose interested in more
http://www.emuge-franken.de/english/medien/videos.html
[21:44:37] <izua> that sounds sweet. the drill, i mean
[21:46:36] <izua> although, the video is a very good tutorial on how to waste material pointlessly :D
[21:49:13] <toastatwork> pointlessly?
[21:51:02] <izua> there is no end product, or I see none
[21:51:20] <Paragon> Hello All... This may be biting off to much than I can chew but here goes... A while back we where discussing rotary tables employing direct drive. How difficult would it be to roll ones own brushless DC motor using rare earth magnets and winding the strator (on a lathe)?
[21:52:35] <SWPadnos> time
[21:52:42] <SWPadnos> oops
[21:53:38] <Paragon> These guys are doing it on a smaller scale ...
http://www.gobrushless.com/shop/index.php?app=ccp0&ns=catshow&ref=stators
[21:54:37] <anonimasu> Paragon: damn hard
[21:54:42] <jepler> I suspect it would be a lot of work to get a good homemade motor. not something to be undertaken to save money.
[21:55:48] <Paragon> I agree but I thinking along the lines of a project and self satisfaction...
[21:56:23] <anonimasu> I think the satisfaction will be pretty low
[21:56:25] <fenn> Paragon: check out pancake motors
[21:56:35] <anonimasu> when comparing against comercial motors
[21:56:43] <anonimasu> motor design is non trivial
[21:56:58] <fenn> oops that's not brushless, nevermind
[21:57:06] <SWPadnos> some are
[21:57:10] <SWPadnos> servodiscs
[21:57:22] <fenn> is it? now i'm all confuzzled
[21:57:34] <SWPadnos> I think the ones I saw were AC brushless
[21:57:41] <SWPadnos> or DC brushless, I don't know
[21:57:49] <SWPadnos> but they weren't brushed, I do know that
[21:57:58] <jepler> http://www.endless-sphere.com/forums/viewtopic.php?f=2&t=6762&start=0&st=0&sk=t&sd=a
[21:57:59] <SWPadnos> (and they had 2M count encoders O_O )
[21:58:05] <anonimasu> hm, I cant say that servodiscs are really easy either -_-
[21:58:18] <fenn> i'm thinking of
http://fennetic.net/pub/irc/kolmorgen_servodisc.pdf
[21:58:24] <jepler> this is apparently a homebrew brushless (2 phase) pancake motor ("does not self start, not a problem in this setup")
[21:58:26] <SWPadnos> yep
[21:58:32] <jepler> http://www.endless-sphere.com/forums/viewtopic.php?f=2&t=6762&start=0&st=0&sk=t&sd=a
[21:59:17] <SWPadnos> oh hey, some of those are DC (according to the lesser god eBay)
[21:59:21] <Paragon> DC and AC are essentially the same except on 2 phases are driven at any one time in a BLDC motor as opposed to all three phases being driven in an AC brushless... Well that how I've read it ;-)
[21:59:32] <fenn> extremely low inductance, so no kickback = no brush wear = regular slip rings instead of carbon brushes
[21:59:56] <Paragon> What the hell did I just write ? ;-)
[22:00:19] <fenn> Paragon: i think the difference is BLDC is trapezoidal waveform and AC is sinusoidal
[22:00:42] <Paragon> Thats what I just wrote ;-)
[22:01:27] <anonimasu> I think it's alot of work for something that wont work as well as you thought for a start
[22:01:30] <anonimasu> :)
[22:01:33] <Paragon> I beleive the wye winding would be more benificial for the intended application also.
[22:01:38] <anonimasu> (just my 5c)
[22:01:49] <anonimasu> just like stepper drivers
[22:02:14] <Paragon> anonimasu: I think your probably right there.
[22:03:29] <anonimasu> time spent somehow has to be reflected in the result(atleast for me)
[22:03:46] <Paragon> One of the main issues I think is with regards to the laminated iron component.
[22:04:35] <anonimasu> well, time to sleep
[22:04:36] <anonimasu> night!
[22:04:43] <Paragon> anonimasu: Nite
[22:07:33] <fenn> Paragon: many motor designs dont have any iron laminations
[22:07:49] <fenn> look at cd-rom for example
[22:12:56] <izua> hmm
[22:13:03] <izua> I think i'm starting to understand the blend thing
[22:13:21] <izua> I'll make a simulator or something to play around with it
[22:13:32] <Paragon> fenn: one of the ideas I had was wind the coils on to bolts using the cnc lathe. Mill and tap a steel ring of which the bolts (coils) would screw into. the coils would be pointing towards the center. The actuator would be milled and drilled to accept the rare earth magnets and sit in bearings. The profile would be aprox 1-2 inch high and say aprox 100mm x 100mm sq.
[22:15:53] <izua> so a trapezoidal profile is fine for most small-to-medium machines?
[22:16:11] <izua> i'm talking stuff from foam cutting to drilling pcbs and maybe milling aluminium
[22:16:35] <jepler> izua: our experience is that emc works fine for all those tasks you mentioned (though I don't know much about foam cutting)
[22:16:59] <izua> ah
[22:17:03] <izua> it's very light, and 2D only
[22:17:15] <izua> you basically have a nickeline wire, heated, run through foam. and it melts.
[22:17:22] <izua> the foam, not the wire
[22:17:33] <jepler> if the wire melts you did it wrong, I suppose
[22:17:44] <SWPadnos> that's simple. it's the machines where you have the two ends independently controlled where it gets interesting
[22:17:54] <izua> ah yes, to make conical sections
[22:17:57] <SWPadnos> so you can cut angles instead of just shapes
[22:18:05] <SWPadnos> wing profiles
[22:18:05] <izua> it's great for airmodels
[22:18:08] <izua> exactly!
[22:18:17] <izua> but using a fixed length wire
[22:18:21] <izua> is a bitch, cause it breaks
[22:18:48] <SWPadnos> EMC can control those too, because most of the special stuff is in the G-code
[22:18:58] <izua> well, yes
[22:19:04] <izua> but the problem is making the wire not break :)
[22:19:13] <izua> cause it will have a maximal tension
[22:19:17] <SWPadnos> sure
[22:19:21] <izua> i tried designing a mechanism to feed/retract wire
[22:19:29] <izua> depending on the external points
[22:19:40] <izua> waaay to complex then i initially thought of
[22:19:48] <izua> and in the end, i don't evne do foam cutting :P
[22:19:55] <SWPadnos> well, a tensioner is one way, but if you can jog one endpoint closer/further from the work, then EMC2 can also compensate
[22:19:59] <SWPadnos> heh
[22:20:37] <SWPadnos> (you can use the HAL to find the the distance between the XY and UV endpoints, and move in or out to keep a fixed length)
[23:21:37] <robh> hi, any one know a way i can extend the mark pulse on an incoder? dont mind external chip
[23:22:14] <SWPadnos> not really. it's especially complex if you want to extend it for travel in both directions
[23:23:54] <jepler> I am sure there are many circuits based around a chip like the 555 that can lengthen a pulse
[23:25:58] <SWPadnos> you can sure extend the pulse to some minimum width, but you lose the guarantee that the index output is only high at one spot
[23:26:25] <SWPadnos> also, the index position will vary depending on which direction the encoder is rotating
[23:26:53] <SWPadnos> (it always varies by one count anyway, since the rising edge will be on one side or the other of the index mark depending on direction)
[23:36:59] <robh> hmm very true
[23:38:06] <jepler> it's hard to imagine where this would matter. for instance, the index is unimportant during the reversal in a rigid tapping cycle, and in a threading cycle you always use the index going the same direction
[23:38:22] <robh> old encoder on lathe had exstended mark pulse , when we got a replacement we asked them for extended version but never got it so screw cutting is limited to few hundred rpm
[23:43:19] <toastydeath> does anyone know the preferred modeling program to build cars for CFD?
[23:44:09] <toastydeath> solidworks is horrible for the purpose
[23:44:37] <SWPadnos> is CFD like FEA?
[23:44:54] <toastydeath> yes
[23:45:03] <toastydeath> it's fea for fluids
[23:45:19] <SWPadnos> ok, Complex Fluid Dynamics?
[23:45:26] <toastydeath> computational fluid dynamics.
[23:45:28] <SWPadnos> ah
[23:45:38] <SWPadnos> thinking about liquid cars?
[23:45:49] <toastydeath> no, thinking about modeling the airflow around cars
[23:45:51] <toastydeath> (close)
[23:45:55] <SWPadnos> heh
[23:46:21] <SWPadnos> it seems that something like SW would just be used as a UI so you could export to IGES or something like that
[23:46:21] <toastydeath> CATIA seems pretty capable of it
[23:46:40] <toastydeath> solidworks just generates the model
[23:47:04] <toastydeath> which you put through another meshing program, and then run a solver on the mesh to get some pretty graphics and numbers out of it
[23:47:10] <SWPadnos> sure
[23:47:12] <toastydeath> the problem is solidworks is not very good
[23:47:20] <SWPadnos> not very good at what?
[23:47:28] <toastydeath> modeling things for CFD
[23:47:31] <toastydeath> cars, especially
[23:48:01] <SWPadnos> I suppose the sketch-based approach may not be best suited to big curvy shells like cars
[23:48:09] <toastydeath> well, it's the whole program
[23:48:25] <toastydeath> the lofting/etc doesn't have the same capability of the more high end programs like pro/e and catia
[23:48:47] <toastydeath> i just don't know a "better" direction to go without guessing haphazardly
[23:48:47] <SWPadnos> then I suggest a program like Pro/e or Catia
[23:48:58] <toastydeath> "without guessing haphazardly" =)
[23:49:47] <SWPadnos> SW is capable of making models of things like cars, so it boils down to whichever user interface you or your CAD folks prefer
[23:50:19] <toastydeath> even the producers of solidworks admit solidworks isn't good enough to do cars.
[23:50:22] <SWPadnos> it's similar to word processors - any of the big CAD programs are likely to be able to model your part, it's a question of what the steps are to convince them to do so
[23:50:37] <toastydeath> you can make something that looks like a car, but you can't modify the geometry in a meaningful way.
[23:50:43] <SWPadnos> I imagine the assemblies would be about 37GB, but ... ;)
[23:51:05] <toastydeath> like i said, solidworks lacks the ability to define the surfaces
[23:51:07] <SWPadnos> SW is a bit like Word with regards to file size
[23:51:28] <SWPadnos> hmm. I thought I had seen models of a car or motorcycle on the SW site
[23:51:40] <BigJohnT> what do you mean sw lacks the ability to define the surfaces?
[23:51:41] <SWPadnos> maybe I'm thinking of something else
[23:51:41] <toastydeath> yeah, but that's a pure "design" thing, and it takes years to do
[23:52:01] <toastydeath> bigjohnt: modify the surfaces in a aerodynamically meaningful way
[23:52:45] <BigJohnT> as in automagically?
[23:52:48] <toastydeath> no
[23:52:54] <toastydeath> as in, you can make something that looks like a wing
[23:52:58] <toastydeath> but you cannot make it preform like a wing
[23:53:22] <toastydeath> because you don't have the ability to control the definition of the solid in a way that allows you to have precice control over it
[23:53:31] <toastydeath> you can just do bulk deforms/freehand stuff
[23:53:42] <BigJohnT> as in aerodynamic testing?
[23:53:51] <toastydeath> yes
[23:54:10] <BigJohnT> it is not designed for that I suppose
[23:54:13] <robh> i think ur getting down to CAD packages deisgn to do a task and a task at hand, i would say SW is more mechanical package, than a all design and analize it
[23:54:46] <toastydeath> right, i've established that
[23:54:58] <toastydeath> the original question is what package IS the best at doing that
[23:55:01] <BigJohnT> mechanical and assemblies are the strong suite of sw
[23:55:08] <toastydeath> not "can solidworks do it"
[23:55:27] <toastydeath> catia keeps coming up
[23:55:45] <toastydeath> and some other 3d animation packages can apparently handle that kind of geometry
[23:56:03] <BigJohnT> you might have to nose around in the aero community...
[23:56:47] <SWPadnos> blender can probably generate the models, but I don't know how much longer it would take than modeling it manually
[23:56:54] <BigJohnT> just so you know I use sw every day
[23:56:55] <SWPadnos> (out of marble, with a chisel)
[23:57:41] <toastydeath> blender was actually mentioned
[23:57:58] <SWPadnos> I think blender is pretty non-numerical
[23:57:59] <toastydeath> apparently it's easier in blender/maya/etc because they're used to handling really complicated geometry
[23:58:01] <robh> how about CATIA that was made to design aircraft, french cad system started as
[23:58:08] <SWPadnos> ie, "deform this a little more, like I'd do with clay"
[23:58:27] <robh> http://en.wikipedia.org/wiki/CATIA
[23:58:45] <toastydeath> robh: yes, that's one of the ones that is frequently mentioned
[23:58:48] <toastydeath> and probably is the thing to use
[23:59:01] <SWPadnos> blender and the like won't allow you to go back and edit later though, like a parametric modeler will
[23:59:39] <toastydeath> yeah =/
[23:59:41] <SWPadnos> (you can edit, but not e.g. change a base dimension and have the later features change based on the new value)
[23:59:43] <toastydeath> kinda defeats the purpose
