Back
[07:24:44] <skunkworks> zlog
[08:42:30] <skunkworks> cradek, might get a kick out of
http://bbs.homeshopmachinist.net/threads/66045-It-s-alive-and-ticking!
[08:42:50] <skunkworks> I think the plans were in the digital machinist mag
[09:21:04] <cradek> I like the idea of using magnetic coupling instead of gear teeth
[09:22:58] <cradek> in the (few) days when electric watches had balance wheels, some used magnets for draw to the banking - it works great because magnetic pull is (I think) square law
[09:24:06] <cradek> because of tradition, watch and clock guys usually just think of magnetism as an enemy
[09:25:02] <skunkworks> heh
[09:31:09] <archivist> well magnetism screwed time keeping :)
[09:31:39] <cradek> only if you use traditional materials
[09:57:51] <kwallace1> Does anyone know how the clock above is driven?
[09:58:53] <archivist> see stepper at the bottom
[09:58:57] <pcw_home> looks like a VR step motor
[09:59:01] <cradek> looks just like a stepper motor
[09:59:06] <cradek> oh hey
[09:59:12] <cradek> maybe I'm not the only one who saw that
[09:59:47] <archivist> and a geneva stop work to make the hour hand step around
[10:00:09] <cradek> yeah I didn't understand that
[10:00:18] <cradek> it shows halfway between two hour marks
[10:00:46] <cradek> and a jumping hour hand would make it suck at its primary purpose: letting people read the time on it
[10:01:13] <archivist> http://en.wikipedia.org/wiki/Geneva_drive
[10:01:19] <kwallace1> But I noticed in had no second hand and the minute hand is on a Geneva drive? It seemed the stepper might need to run at high speed on a minute trigger, rather than a constant step stream.
[10:02:04] <cradek> yeah I understand the mechanism
[10:02:10] <archivist> I dont see the need for the geneva either, but some like to make silly clocks
[10:02:25] <cradek> in the photo it's in a locked position, but the hand is halfway between 2 & 3
[10:03:07] <cradek> I guess it locks there for the lower half of the hour, and moves during the upper half
[10:03:32] <cradek> which is interesting and might not make it much harder to read
[10:05:34] <archivist> when I had access to the BHI magazine and when to the institute annual shindigs, there were some strange clocks being make
[10:05:44] <archivist> when/went
[10:06:43] <cradek> my favorite use of weird magnetic coupling in a watch is the omega 1220 (aka megasonic)
[10:08:12] <cradek> and it was probably just for patent avoidance!
[10:08:56] <archivist> the multiple pendulum clock was a mechanical nightmare, loads of interaction
http://ipswichbhi.horo-logical.co.uk/album/projects/108-01.htm
[10:09:49] <cradek> heh wow
[10:10:58] <archivist> I was guarding a display of Harrison clock replicas one weekend, they were nice
[10:12:46] <kwallace1> Oh, now I see the minute hand _is_ driven by the stepper. The Geneva isn't fully digital. The output does move during half of the input motion. My carousel used to have one and it was used step the tool position, but use an induction motor which could coast to a stop in the locked portion of the output.
[10:14:32] <archivist> one of the HP plotters used a geneva mechanism to change the pens
[10:15:29] <cradek> http://ipswichbhi.horo-logical.co.uk/album/projects/038-03.htm
[10:15:47] <cradek> I've mounted my stereo microscope head to mine, but I wonder if this would be easier to use
[10:16:21] <archivist> that is a Lorch like mine
[10:17:43] <archivist> I use a stereo microscope, I think you look in the right direction of the work that way, feels right
[10:24:49] <archivist> hmm I dont have a pic of my own of the double pendulum but do have one of the people who made it (center standing), with george danials in the background seated right on stage)
http://www.collection.archivist.info/archive/DJCPD/PD/2002/2002_10_14_BHI_Millenium_Clock/PA130410.JPG
[10:24:49] <kwallace2> Using a camera like that is a gateway project that can lead to other harder projects.
[11:06:06] <skunkworks> kwallace2, it is hard to get your point across on cnczone..
[11:06:53] <skunkworks> (they actually run velocity step/dir then switch to position step/dir for tapping...) crazy
[11:07:39] <cradek> ?
[11:07:57] <kwallace2> That's all SCrEng had to reply with and it would have cleared it up.
[11:08:21] <skunkworks> http://www.cnczone.com/forums/tormach-personal-cnc-mill/259596-know-discussed-servo-motor-spindle.html
[11:08:59] <kwallace2> Everything SCrEng touches has to be a battle.
[11:09:05] <skunkworks> I get that.
[11:13:06] <cradek> N0950 G04 P1 (delay to ensure breakout switches to A axis)
[11:13:39] <kwallace2> Does Z get locked to C? It seems the LinuxCNC's approach of locking Z to the spindle encoder is better. That way Z can do even a faulty move and the tap stays in synch.
[11:13:41] <cradek> I don't understand what is supposed to make the spindle change into an A axis
[11:14:46] * cradek shrugs
[11:16:01] <cradek> sounds like a lot of expensive extra hardware to compensate for not having tapping in the control, but if that's the method you pick, good for you for making it work
[11:17:10] <cradek> you guys are braver than I am, absorbing abuse while trying to help folks
[11:18:04] <kwallace2> For rigid tapping on a Novakon, rather than add an encoder to the spindle I think they are doing a coordinated move with Z and C (the spindle motor is a stepper like brushless AC), but I think this assumes that they will never lose or bend a any steps. Ugh but I forget they have AC sevos all around.
[11:19:03] <kwallace2> I suppose it could work just fine.
[11:19:16] <cradek> yeah a spindle that can switch into position mode would be nice for other reasons too
[11:20:06] <pcw_home> Not going to have a huge amount of torque though
[11:20:14] <kwallace2> But you can't tap by turning the spindle by hand.
[11:20:15] <cradek> but it seems very hard to get several horsepower at many thousand rpm, and also that
[11:21:01] <pcw_home> Yep this is also why induction motors have advantages for spindles
[11:21:40] <pcw_home> (field weakening allows a wider speed range)
[11:26:59] <seb_kuzminsky> good morning friends
[11:27:30] <kwallace2> Novakon's C axis can't be very accurate or stiff. Plus, the encoder is on the motor so they need a 1 to 1 timing belt which I assume rules out belt changing to shift speed range, oops but they have two modes running and tapping.
[11:30:09] <kwallace2> This sounds like a television circuit design where they get four different functions that work sorta okay from one tube and a few passives.
[12:22:17] <kwallace2> https://twitter.com/sfnet_ops
[12:23:27] <KGB-linuxcnc> 03Dewey Garrett 052.7 cb7c1ee 06linuxcnc 10docs/src/config/images/latency-histogram.png 10scripts/latency-histogram latency-histogram: show linuxcnc version * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=cb7c1ee
[12:24:57] <dgarr> seb_kuzminsky: is revised patch ok for 2.7,
http://www.panix.com/~dgarrett/stuff/v2-hal_lib-change-.time-item-from-parameter-to-pin.patch
[12:56:13] <seb_kuzminsky> dgarr: thanks for that latency-histogram improvement, that was quick!
[12:57:06] <seb_kuzminsky> i'll take a look at it later today
[12:57:14] <seb_kuzminsky> (at the new time pin patch)
[13:00:29] <pcw_home> does the spiral-arc-handling-2.7 branch have the various new TP patches (XY only fixed etc) ?
[13:15:58] <skunkworks> I think there is 2 more bugs rob needs to fix in it. (found some obscure violations at very high accellerations.)
[13:16:46] <skunkworks> (he has it fixed in one of his branches on git hub)
[13:17:21] <skunkworks> But yes - it has the xy only fix and etc
[13:27:06] <mozmck> seb_kuzminsky: Sounds like the TCL stuff is fine as you had it. I made my changes in a separate local branch - should I push it as a new branch or force it back onto your branch?
[14:06:24] <seb_kuzminsky> skunkworks: are you sure that wasn't fixed by this commit?
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=commitdiff;h=88a47e84e442307fe18f9067ef478de7cf412ff1;hp=f545aa44ad9f26b8761bef9cd2f1e93864fb0d54
[14:06:59] <seb_kuzminsky> mozmck: push to a new branch pls, and i'll compare them and remove my old branch
[14:07:21] <skunkworks> seb_kuzminsky, it was fixed this weekend
[14:08:45] <seb_kuzminsky> ok thanks
[14:09:00] <skunkworks> https://github.com/robEllenberg/linuxcnc-mirror/compare/feature/arc-acceleration-fixes
[14:09:13] <seb_kuzminsky> i see
[14:09:29] <seb_kuzminsky> this is relevant to my interests:
http://www.cnet.com/news/graphene-structures-created-with-3d-printing/
[14:09:54] <skunkworks> I will see when he can push it (that on a refactored branch that he didn't want to push)
[14:10:08] <seb_kuzminsky> skunkworks: thanks for being on top of that
[14:10:25] <skunkworks> I just seem to be good at breaking things
[14:11:40] <seb_kuzminsky> dgarr: v2 looks good, please push to 2.7
[14:12:16] <seb_kuzminsky> i think the comment is wrong, but it was wrong before too and it's not worse now, so i wouldn't worry overmuch about it:
[14:12:42] <seb_kuzminsky> + /* note that failure to successfully create the following params & pins does not cause the "export_funct()" call to fail - they are for debugging and testing use only */
[14:13:09] <seb_kuzminsky> well hm, actually it *is* worse now that runtime is a pin
[14:13:57] <seb_kuzminsky> if the hal_param_*_new() call fails, the internal param variables are still valid, but if hal_pin_*_new() fails you can't write to the pin because it'll be a NULL pointer
[14:14:43] <seb_kuzminsky> so i think you *do* have to error out if hal_pin_*_new() fails, unlike hal_param_*_new*() where you can ignore errors
[14:17:49] <dgarr> seb_kuzminsky: ok, i will error out on the hal_pin_s32_newf() before commiting and update comment.
[14:17:55] <seb_kuzminsky> thanks
[14:18:11] <dgarr> i am working on a general purpose tool to histogram hal pins (s32 or float)
[14:18:17] <seb_kuzminsky> dgarr: you've had a busy weekend! lots of improvements :-)
[14:18:41] <seb_kuzminsky> that sounds useful
[14:19:05] <seb_kuzminsky> something like halmeter, maybe hal-histogram?
[14:19:17] <seb_kuzminsky> do we have latency on a pin somewhere?
[14:19:22] <seb_kuzminsky> bbl
[14:19:40] <dgarr> hal_histogram currently, mainly for curiousity but it could help in designing components
[14:59:58] <KGB-linuxcnc> 03Sebastian Kuzminsky 05mozmck/new-deb-conf 357a869 06linuxcnc 10debian/configure 10debian/control.in 10debian/rules.in deb: new debian/configure and debian/control * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=357a869
[14:59:58] <KGB-linuxcnc> 03Sebastian Kuzminsky 05mozmck/new-deb-conf f31bf1d 06linuxcnc 10debian/configure 10debian/rules.in deb: fix the debian/{control/rules} remaking rules * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f31bf1d
[14:59:58] <KGB-linuxcnc> 03Sebastian Kuzminsky 05mozmck/new-deb-conf 6aa914d 06linuxcnc 10src/configure.in dont be so picky about wish and tclsh versions * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6aa914d
[15:00:01] <KGB-linuxcnc> 03Sebastian Kuzminsky 05mozmck/new-deb-conf 544cb8f 06linuxcnc 10debian/configure use python str.replace() instead of shelling out to sed * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=544cb8f
[15:00:05] <KGB-linuxcnc> 03Moses McKnight 05mozmck/new-deb-conf 072547b 06linuxcnc 10debian/configure 10debian/control.in Some minor cleanup and changes to dependencies. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=072547b
[15:01:09] <mozmck> hmm, git told me this: "remote: fatal: bad object 0000000000000000000000000000000000000000" but then went ahead and pushed the new branch
[15:01:25] <cradek> that's "normal" when making a new branch
[15:01:29] <mozmck> ok
[15:13:16] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 7c1427a 06linuxcnc 10src/emc/tp/tp.c Merge remote-tracking branch 'origin/feature/spiral-arc-handling-2.7' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7c1427a
[15:14:36] <kb1kdw> I am in the process of connecting a SPI based stepper drive to my parallel port (ST L6480). I can get commands to it and back in <1ms. I will feed it a velocity command and use its internal pulse counter to get the "real" position back from it. Anyone know for sure that it will or will not work?
[15:15:26] <kb1kdw> 1ms < 0.0005 of travel at 30ipm which I think ought to be okay.
[15:18:05] <skunkworks> kb1kdw, that sounds like a normal setup.. using pid?
[15:19:03] <kb1kdw> I guess I can set it up with a PID loop. Although because I can KNOW its velocity I don't know if I really need it to hunt like a PID would.
[15:19:13] <seb_kuzminsky> mozmck: thanks! i'll check it out
[15:20:46] <seb_kuzminsky> kb1kdw: do you have a realtime component to clock spi bits out the parallel port?
[15:21:21] <kb1kdw> I have written one, although I have not tested it with any hardware yet
[15:21:38] <seb_kuzminsky> cool
[15:22:01] <seb_kuzminsky> how much idle time do you have if you run your comp with a 1 kHz period?
[15:22:59] <seb_kuzminsky> if there's enough time to do the other things linuxcnc needs, it'll probably work
[15:23:12] <kb1kdw> The process itself takes <3600 processor clicks per call. I figure that means I use 1uS on a 3GHz Core 2 Duo
[15:23:36] <seb_kuzminsky> wow, that's quick!
[15:23:53] <kb1kdw> It isn't doing much :)
[15:24:26] <kb1kdw> The commanding process that will feed it what to send will be the real work, I think.
[15:26:39] <kb1kdw> I am struggling a bit to come up with an elegant way to tie everything together. I'm new to the EMC structure. I have done plenty of interrupt driven MCU stuff in the past, but this is all new.
[15:27:02] <pcw_home> kb1kdw: even if you know the velocity, you need to count the pulses and use a feedback loop (PID for example)
[15:27:03] <pcw_home> because of 1. time base differences. 2. imprecise velocity update times
[15:29:12] <pcw_home> 3. velocity quantization
[15:29:17] <kb1kdw> Yes, the time base difference is real and has to be taken up. The rotten chip has a GoToPosition command, but it ignores new position requests until it is done getting there and decellerated.
[15:30:24] <kb1kdw> I wanted to keep feeding new position commands hoping it would interpolate the difference...anyway. With enough therapy I will get over the disappointment :)
[15:31:27] <kb1kdw> Will the position planner ddt output be a reasonable place to pick off the velocity commands, or will I have to loop it into a PID?
[15:31:50] <kb1kdw> It also seems like it might be one update in the past, which could be a problem.
[15:31:53] <pcw_home> typically this is all done via PID
[15:33:30] <pcw_home> Exactly like a velocity mode servo
[15:33:38] <kb1kdw> Yesterday I proved the EVAL6480H board wouldn't catch fire at 12A, so I'm back to working on the software again. 20uH steppers @ 7A.
[15:33:46] <kb1kdw> I will set it up like a servo.
[15:34:12] <kb1kdw> Makes me wonder if I should be jacking with steppers at all.
[15:34:21] <kb1kdw> The lack of feedback gives me the creeps.
[15:45:55] <kb1kdw> Hi Andy - Matt Wortley (yeltrow) here.
[15:59:36] <andypugh> Hi
[16:03:14] <kb1bdw> andypugh: I tried the comp to .c thing you suggested.
[16:04:45] <andypugh> It might not be how you would write it, but at least it gives the “shape” of a driver file.
[16:05:04] <skunkworks> zlog
[16:05:40] <kb1bdw> I was floored by the amount of stuff it through up. I am hoping I can learn enough from it to make a useful driver.
[16:05:59] <kb1bdw> threw up...
[16:06:06] <andypugh> It’s also probably looking at some other hand-written driver files.
[16:07:20] <andypugh> There is an empty driver here:
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob;f=src/hal/drivers/hal_skeleton.c;h=5af19c71d9b3bf342690adbd59913a92f225f91a;hb=HEAD
[16:07:43] <kb1bdw> I just comp --preprocessed zool.comp and it made a LOT of stuff. I will eventually get to the bottom of it.
[16:10:25] <andypugh> some of it only makes sense in the context of the way comp has to work.
[16:11:39] <andypugh> I think that your best starting point might be:
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob;f=src/hal/drivers/mesa-hostmot2/abs_encoder.c;h=97b31dc9750bec3f516b1a97cd74f9d95e9b9e6e;hb=HEAD
[16:12:07] <andypugh> (Your code can even use the hm2_parse_format function to map the HAL pins to bits.
[16:12:12] <kb1bdw> That link looks pretty helpful. I think one thing I am doing that makes it a bit tougher for me is that I am trying to make my spi driver and the driver with the commands completely seperate.
[16:12:42] <andypugh> I don’t entirely know what you mean by that
[16:13:11] <andypugh> We do actually have an SPI driver, but only for the Mesa cards
[16:13:18] <andypugh> And it doesn’t do anything.
[16:13:20] <andypugh> :-)
[16:14:31] <andypugh> But here is a .comp that hooks into it for a specific card:
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob;f=src/hal/drivers/mesa_7i65.comp;h=1fa77cebec60e425abc914cc9a1803dbaf425b54;hb=HEAD
[16:15:04] <kb1bdw> making a generic spi driver and making a master program that changes velocity commands to spi bytes.
[16:16:30] <kb1bdw> I saw your spi driver which is why I looked you up, and then I found your awesome youtube stuff.
[16:17:11] <andypugh> Making a generic driver for the existing Hostmot 2 BSPI driver is trivial. I ought to do it as it is a very small set of extra work on top of ssi etc.
[16:18:27] <andypugh> What do you have in mind as the generic driver layer? I am wondering what hardware has the ability to SPI and a LinuxCNC HAL interface?
[16:19:25] <kb1bdw> I need to switch from my phone to a real keyboard :)
[16:20:33] <kb1bdw> I was planning for the driver to have a multibyte buffer that it would tranmit when the pointer was nonzero.
[16:21:06] <andypugh> I am wondering where the bytes will come from and go to?
[16:21:28] <kb1bdw> it would also have a bufflock to keep another program from reading or writing when things are changing.
[16:22:02] <kb1bdw> I planned for the generic driver to twiddle parallel port pins like the stepper drivers do.
[16:22:06] <kb1bdw> via nets
[16:22:12] <andypugh> TBH if you want to run SPI devices you might as well get a Mesa card and install a firmware that sets up some pins as BSPI. Then you have the bytes there in the buffer to do all you want with.
[16:22:55] <andypugh> Ah, OK. Parport spi.
[16:23:01] <andypugh> Not necessarily a bad idea.
[16:23:38] <kb1bdw> sounds like what a reasonable person would do... but you have seen my cnc torch, I left reason behind a long time ago.
[16:25:35] <andypugh> I still suggest using the code in the hostmot2 driver. The bits that create arbitrary HAL pins from a config string were a _lot_ of work to get right.
[16:26:34] <andypugh> And keeping the same grammar would be useful to people who wanted to later upgrade from parport bit-bashing to Mesa BSPI.
[16:27:12] <pcw_home> Because of the overhead of toggling the clock bits, you might consider wiring N SPI channels to N parallel port data in and out bits
[16:28:16] <andypugh> You mean not using any select lines?
[16:28:24] <kb1bdw> I had considered even sharing the clock lines... it is dirty but could save some pins.
[16:28:30] <andypugh> That probably does make more sense
[16:28:52] <pcw_home> 1 CS 1 Clk N DI N DO
[16:29:54] <kb1bdw> when I get up to 4 drives in parallel, I was going to have their cs lines tied together and maybe their clocks and just have independent di and do lines
[16:30:18] <andypugh> I think that is what PCW is saying in his terse efficient way :-)
[16:30:42] <kb1bdw> spi for the cost of 2 extra lines seemed like a good bargain.
[16:31:08] <kb1bdw> yes :)
[16:31:24] <pcw_home> PP clk rate is likely 250 KHz or so tops
[16:32:30] <kb1bdw> if I issued the report position command in my first byte, it will be clocking out when I amsending my velocity command.
[16:32:55] <andypugh> kb1bdw: I think you can use the code in this function to set your HAL pins according to the config string:
[16:32:56] <andypugh> http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob;f=src/hal/drivers/mesa_7i65.comp;h=1fa77cebec60e425abc914cc9a1803dbaf425b54;hb=HEAD
[16:34:35] <pcw_home> Note that you will likely have to electrically isolate the SPI interface from the drives
[16:35:14] <andypugh> You just need to create a hm2_sserial_remote_t for each channel, populalate the biffers with the data from _your_ driver and then call that function.
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob;f=src/hal/drivers/mesa-hostmot2/sserial.h;h=cd6afcae21de7ba7b36b247809c745fd4a348aaf;hb=HEAD#l193
[16:36:51] <andypugh> The code doesn’t care where the bits came from.
[16:37:43] <kb1bdw> is this session loggeg someplace so I can try the links on my desktop?
[16:38:03] <mozmck> zlog
[16:38:20] <andypugh> kb1bdw: wortley: You should visit here:
http://www.topforge.co.uk
[16:38:28] <mozmck> or logger[psha]
[16:38:43] <mozmck> logger[psha]:
[16:38:43] <logger[psha]> mozmck: Log stored at
http://psha.org.ru/irc/%23linuxcnc-devel/2015-02-16.html
[16:40:06] <wortley> I guess I should check out my namesake forge, heh?
[16:41:03] <wortley> You'll have to forgive my IRC clumsiness while I try to check out the links and maybe even think a little...
[16:41:48] <andypugh> I am going to be absent from the keyboard for a while while I eat
[16:42:07] <wortley> Thanks for the pointers ;)
[16:46:19] <kwallace2> Hello, I'm trying to get the current workspace offsets into the rotate_x function at the bottom of this page:
http://www.wallacecompany.com/machine_shop/LinuxCNC/fourth_axis/ . I'm not up on C++ much and if anyone can point me in the right direction, it would save me some time. The tx (should be ty) and tz formulas there are for a rotation with the center at the machine center. I want to apply the current G5x offsets and assume the A axis ce
[18:05:20] <kb1kdw> ?
[18:06:06] <kb1kdw> q
[18:13:00] <andypugh> ?
[18:29:50] <kb1kdw> andypugh: I scanned through the functions you posted links to -- I didn't see the bitbang spi portion at first glance. Was that what I was supposed to see?
[18:41:27] <andypugh> kb1kdw: There isn’t any bitbang in there. That is the bit that you would need to do.
[18:44:28] <andypugh> The Mesa BSPI firmware in the FPGA does all the low-level stuff. What I am saying is that the code there is all that is needed to a) Take a config string from the HAL loadrt line and create all the HAL pins corresponding to the SPI bitstream (up to 96 bits at least) and b) convert the bitfields received to HAL values and format HAL values into bitfields ready to be sent out.
[18:53:45] <cradek> kwallace2: your message was cut off after "assume the A axis"
[19:01:06] <KGB-linuxcnc> 03Francis Tisserant 05seb/master/po4a e5d27eb 06linuxcnc 10(11 files in 3 dirs) French doc gmoccapy translation with po4a * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e5d27eb
[19:05:56] <kb1kdw> andypugh: Thanks, Andy. I will study up and see what I can stitch together based on your examples.
[19:48:17] <KGB-linuxcnc> 03Dewey Garrett 052.7 9516669 06linuxcnc 10src/hal/hal_lib.c 10src/hal/hal_priv.h hal_lib: change .time item from parameter to pin * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9516669
[20:07:29] <kwallace2> cradek, thanks for looking. The rest is: I want to apply the current G5x offsets and assume the A axis center is touched off to the current G5x.
[20:07:41] <kwallace2> But it's not important.
[20:09:17] <cradek> do I understand right that you ultimately want to make the path rotate by abc instead of the tool cone?
[20:10:35] <cradek> that idea, generalized, is sure interesting: move the entire preview and backplot instead of the tool cone
[20:10:53] <cradek> that's how some machines actually move
[20:11:15] <cradek> (it all seems quite tricky to me)
[20:21:44] <linuxcnc-build> build #1160 of 1405.rip-wheezy-armhf is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/1160 blamelist: Dewey Garrett <dgarrett@panix.com>
[20:30:01] <kwallace2> cradek, Yes, if A moves, I want the existing path to move with and centered on A. My standard setup would be a normal X Y and Z with A being a rotary table flipped up so the A center is parallel with X.
[20:30:57] <kwallace2> Instead of the tool tipping to indicate A position, the tool would stay still as with the real tool.
[20:31:04] <cradek> will the xyz axis pointers spin with it?
[20:31:43] <kwallace2> I had not planned on XYZ moving since they don't in the real world.
[20:32:14] <cradek> well it depends - on a xyzab machine they do (can?) rotate
[20:32:41] <cradek> so if you think of your xyza machine as a somewhat-limited 5 axis machine...
[20:33:01] <cradek> seems like it all depends on what your cam expects the machine to do
[20:33:39] <kwallace2> I'm trying to limit myself to the most common setup and not have compromises from trying to be generic.
[20:34:05] <cradek> an xyzab kins I did for a customer way back when:
https://www.youtube.com/watch?v=aF7C8d4d0nc
[20:35:19] <cradek> haha youtube comments
[20:36:29] <kwallace2> Yeah, in that case the tool does tilt.
[20:37:07] <cradek> for b, not for a
[20:37:21] <kwallace2> In case you missed it:
http://www.wallacecompany.com/machine_shop/LinuxCNC/fourth_axis/
[20:38:20] <kwallace2> Yeah, but if I were working on that setup I would want to see it tilt in the plotter.
[20:39:22] <cradek> I think ideally it would match the machine - z,b,(w) would move the tool and a,x,y would move the backplot and preview
[20:39:22] <andypugh> cradek: It’s like a milling machine, only smaller :)
[20:39:32] <kwallace2> Another issue I had to cheat on was that some paths may not be on a workpiece in A, and these should not rotate.
[20:40:05] <kwallace2> I decided that all paths are on A and fix it later if I can.
[20:40:16] <cradek> a regular xyz bed mill might want Z to move the tool and xy to move the backplot/preview
[20:40:40] <cradek> I think what you want is only one situation of a very useful generic configuration option
[20:41:17] <andypugh> I decided a while ago it was all too hard and that if the backplot gave you enough info to spot when it was egregiously wrong then that was enough.
[20:42:25] <kwallace2> I tend to agree, but I thought I'd give it a try and see what happens.
[20:42:51] <cradek> GEOMETRY is happily generic, and we only came to that after we changed it around half a dozen times because nobody agreed on how it should work
[20:43:23] <cradek> seems like there needs to be two things and the GEOMETRY we have already is one - the other is just the same but moves the backplot/preview instead of the tool
[20:43:59] <cradek> I absolutely hope you get it working too :-)
[20:44:32] <kwallace2> CNC consumers want it.
[20:44:54] <cradek> yay, wants drive progress
[20:45:15] <andypugh> Consumers are very good at knowing what they want, and it is very hard to persuade them what they need.
[20:45:46] <cradek> they often know they want SOMETHING they don't have, but maybe not exactly what it is
[20:47:00] <kwallace2> This could take me quite a while. I'm not sure how long "resources" will hold out.
[20:47:15] <cradek> like for instance if you ask what happens if you add a tool offset in A? they'll say I don't know, who cares.
[20:47:54] <andypugh> Yeah, do we know why we support that, or is it wasted NML space?
[20:47:56] <cradek> what if you rotate the xy plane? does A rotate along with it?
[20:48:34] <cradek> andypugh: consider robot end-effectors
[20:49:01] <cradek> andypugh: also consider that tool offsets were only Z, then only X and Z (to my shame), and then what's the reasonable third implementation!?
[20:49:51] <andypugh> Don’t get me wrong, I approve. But I bet you a bottle of cheap booze that they have never been used.
[20:50:10] <linuxcnc-build> build #2973 of 1200.rip-lucid-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1200.rip-lucid-i386/builds/2973 blamelist: Dewey Garrett <dgarrett@panix.com>
[20:50:57] <kwallace2> I'm only looking at a common setup that my resource sells some of.
[20:53:33] <cradek> andypugh: as generic as possible is good - having unused code paths is bad - software balancing act is hard
[20:54:29] <andypugh> Well, if we were to move the tool data out of NML like sensible folk, it would be a non-issue
[20:54:59] <andypugh> But sensible folk would probably move NML out of computers.
[20:56:02] <linuxcnc-build> build #2972 of 1300.rip-precise-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/2972 blamelist: Dewey Garrett <dgarrett@panix.com>
[20:56:53] <linuxcnc-build> build #2974 of 1306.rip-precise-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/2974 blamelist: Dewey Garrett <dgarrett@panix.com>
[20:58:31] <kwallace2> I really am a blind squirrel with this and really have no business playing with it. With that in mind, I haven't touched anything that had NML on it.
[20:59:30] <kwallace2> So far I looked at linuxcnc.status and gl bits.
[20:59:37] <kwallace2> I've
[21:00:40] <cradek> from your page it looks like you've found the important spots
[21:01:00] <linuxcnc-build> build #1130 of 1400.rip-wheezy-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/1130 blamelist: Dewey Garrett <dgarrett@panix.com>
[21:01:27] <cradek> you found the tool drawing bits - I think you have to find the preview and backplot drawing bits and do another thing that's just exactly like the GEOMETRY thing there
[21:02:16] <cradek> I bet doing the fully generic version will actually be the easiest because you already have that example
[21:02:26] <linuxcnc-build> build #1130 of 1403.rip-wheezy-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1403.rip-wheezy-amd64/builds/1130 blamelist: Dewey Garrett <dgarrett@panix.com>
[21:02:49] <linuxcnc-build> build #2174 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/2174 blamelist: Dewey Garrett <dgarrett@panix.com>
[21:02:56] <kwallace2> Yeah, I got the feeling I haven't gotten into the early plotting bits yet.
[21:03:18] <linuxcnc-build> build #1321 of 1404.rip-wheezy-rtpreempt-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1404.rip-wheezy-rtpreempt-amd64/builds/1321 blamelist: Dewey Garrett <dgarrett@panix.com>
[21:06:07] <linuxcnc-build> build #641 of 1402.rip-wheezy-rtpreempt-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1402.rip-wheezy-rtpreempt-i386/builds/641 blamelist: Dewey Garrett <dgarrett@panix.com>
[21:07:09] <kwallace2> I also tried to follow how a g-code file gets loaded and parsed, hopefully to find where the parsed bits get turned into plot points. This isn't done yet.
[21:08:05] <linuxcnc-build> build #789 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/789 blamelist: Dewey Garrett <dgarrett@panix.com>
[21:12:49] <kwallace2> One thing I like about Python is it seems you can try to print just about anything and it will find sometime useful. The C++ bits won't print Jimmy unless you already know everything before hand.
[21:13:16] <kwallace2> Opps something not sometime
[21:15:10] <cradek> yes print is awfully smart
[21:16:39] <linuxcnc-build> build #2973 of 1202.rip-lucid-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1202.rip-lucid-amd64/builds/2973 blamelist: Dewey Garrett <dgarrett@panix.com>
[21:17:44] <kwallace2> I'm wondering if I should consider just scrapping Gremlin and start something new, even if it's just to learn enough to go back and fix Gremlin.
[21:19:34] <linuxcnc-build> build #2973 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/2973 blamelist: Dewey Garrett <dgarrett@panix.com>
[21:19:35] <linuxcnc-build> build #2983 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2983 blamelist: Dewey Garrett <dgarrett@panix.com>
[23:16:52] <KGB-linuxcnc> 03Dewey Garrett 052.7 250bc40 06linuxcnc 10tests/alias.0/expected 10tests/loadrt.1/expected runtests: update for .time pins * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=250bc40
