Back
[07:19:19] <skunkworks> still running!
[07:21:32] <Tom_itx> stop and take a breath
[07:29:23] <skunkworks> :)
[09:03:02] <cradek> people sure have feelings about goto
[09:03:21] <cradek> I guess it's a bike-shed thing, no surprise
[09:06:51] <skunkworks> entertaining...
[09:07:23] <skunkworks> cradek, did you see my comment about m19 spindle orient?
[09:07:42] <skunkworks> Do you think it is a bug or feature by design?
[09:07:53] <cradek> nope
[09:08:36] <cradek> oh without R it does nothing, but it should assume zero?
[09:08:47] <cradek> does the nml message get sent? (turn on "task issue" debug)
[09:08:50] <skunkworks> that is what I think it should do..
[09:08:54] <skunkworks> no message..
[09:09:00] <skunkworks> oh - I can do that.
[09:09:22] <cradek> are you in 2.6?
[09:09:55] <skunkworks> yes - what you guys installed.. so not the latest.. 2.6.something_pre
[09:10:01] <skunkworks> I should update that now
[09:10:03] <cradek> for shame
[09:10:07] <skunkworks> :)
[09:10:27] <skunkworks> I should switch to wheezy and see how that works.
[09:16:22] <skunkworks_> just m19
[09:16:26] <skunkworks_> Issuing EMC_TASK_PLAN_EXECUTE -- (+509,+280, +24,m19,)
[09:16:28] <skunkworks_> mdi_execute_hook: MDI command 'm19' done (remaining: 0)
[09:16:50] <cradek> (the Q argument to M19 is odd - why would this not be a thing you set once in the ini?)
[09:17:11] <skunkworks_> m19r0
[09:17:14] <skunkworks_> Issuing EMC_TASK_PLAN_EXECUTE -- (+509,+280, +26,m19r0,)
[09:17:14] <cradek> if you do it with an R word, what gets sent?
[09:17:15] <skunkworks_> Issuing EMC_SPINDLE_ORIENT -- (+1317,+40, +0,0.000000, +0,)
[09:17:17] <skunkworks_> mdi_execute_hook: MDI command 'm19r0' done (remaining: 0)
[09:17:17] <cradek> aha
[09:17:23] <cradek> so you do get no message
[09:17:30] <skunkworks_> right
[09:17:58] <skunkworks_> (that was in master on my laptop)
[09:18:41] <skunkworks_> but it does work with the R - it is nice then that m3,4,5 cancel it.
[09:18:46] <cradek> it only sends it if you specify p inclusive-or q
[09:19:23] <cradek> so if you specify m19 q1 it'll not issue an orient command, but will wait for it to complete
[09:19:32] <skunkworks> yeck
[09:19:47] <cradek> that was probably not on purpose?
[09:19:54] <cradek> I wonder if he was thinking of hand-orient or something
[09:21:17] <cradek> R Position to rotate to from 0, valid range is 0-360 degrees
[09:21:25] <cradek> I don't understand "rotate to from 0"
[09:21:53] <cradek> I can easily fix this to do what I expect, but I wonder if my expectations are wrong
[09:21:59] <skunkworks> maybe whatever 0 is - index?
[09:23:01] <skunkworks> I didn't look at it that close - I just wanted it to initiate.
[09:23:47] <skunkworks> there is an ini setting that is an offset to the '0'
[09:24:38] <skunkworks> (I had tried that first to see if that made it so I didn't have to secify a R
[09:24:46] <cradek> if you don't specify Q does it not wait for completion?
[09:25:23] <skunkworks> I don'tt think so.. (things don't hang - I can run mdi's and such)
[09:25:47] <cradek> that's bad
[09:25:56] <cradek> why would you ever want to not wait?
[09:28:00] <cradek> well, I'm guessing missing R not defaulting was a typo/bug because of indentation level in the C
[09:28:22] <cradek> the Q thing I think is working as designed, I just don't agree with the design
[09:28:45] <skunkworks> well - I did try to loop my spindle_is_locked to motion.spindle-locked and it didn't work as expected. It instantly cleared the motion.spindle-orient
[09:29:17] <cradek> I think the behavior is weird if you don't specify Q
[09:29:19] <cradek> I haven't dug in
[09:30:10] <skunkworks> so - the spindle would orient -> motion.spindle-locked would be set true -> motion.spindle-orient would go false and the spindle would unlock.
[09:30:57] <skunkworks> I would have to try a Q to see if it works as expected.
[09:31:14] <skunkworks> I would think motion.spindle-orient would stay true until m3,4,5
[09:31:59] <skunkworks> or the specified time out expired..
[09:32:30] <skunkworks> I don't think too many have tested it
[09:32:32] <cradek> unspecified Q should probably wait forever for the orient
[09:32:37] <skunkworks> right
[09:33:24] <skunkworks> (and I am 99% sure it doesn't)
[09:33:26] <cradek> I think the timeout should be in the ini file (with a suitable default if unspecified) and this Q stuff shouldn't be there at all. I don't understand the point.
[09:34:39] <cradek> remote: The following commits are not signed-off. By policy, all commits
[09:34:42] <cradek> ha
[09:35:12] <KGB-linuxcnc> 03Chris Radek 05cradek/m19-without-r-defaults 510097e 06linuxcnc 10docs/src/gcode/m-code.txt 10src/emc/rs274ngc/interp_convert.cc Make M19 without a specified R word (target) default to 0 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=510097e
[09:35:22] <cradek> seb_kuzminsky: ^ recommend for 2.6
[09:35:28] <skunkworks_> cool!
[09:35:47] <cradek> um, I didn't test it, but it's a one-liner
[09:35:49] <skunkworks_> let me try that.
[09:35:54] <cradek> thanks
[09:38:37] <skunkworks_> I will test the is-orented also. (I think it should wait but doesn't) and the second is oriented goes true - I think spindle_locked goes false. (so the spindle unlocks)
[09:39:05] <skunkworks_> it should be unlocked by m3,4,5 if that makes sense
[09:39:19] <cradek> thanks for testing all of it
[09:39:26] <cradek> I'm glad you'll be using it
[09:39:42] <skunkworks_> it is nice - m100/m101 was getting old... ;)
[09:39:59] <skunkworks_> cradek: how to you orient your spindle?
[09:40:03] <skunkworks_> manually
[09:41:28] <cradek> skunkworks_: a switch on the panel goes into ladder, which does it
[09:41:54] <cradek> turns off the spindle, waits for stop, orients
[09:42:14] <cradek> I mostly use it to tighten albrect chucks, haha
[09:42:43] <skunkworks> heh
[09:42:44] <cradek> I flip that switch when loading the probe too, for safety and best probe results
[09:43:38] <skunkworks> I orient the spindle when probing also.. That is mainly what I use the orient for.
[09:44:06] <skunkworks> If I shift the transmission to gear 0 - it works well for tightneing things.. :)
[09:44:17] <cradek> it's been years since I touched the ladder on jr
[09:44:23] <cradek> it all works very rightly
[09:44:24] <skunkworks> same here..
[09:44:34] <skunkworks> I would be afraid to now...
[09:44:38] <skunkworks> :)
[09:44:39] <cradek> heh
[09:44:42] <cradek> I know how you feel
[09:45:49] <skunkworks> There are some improvements that oculd be made.. It was done and not much thought into error recovery. But it is no worse than the original control.. Tool chaange failed? turn the machine off and remove the tools from the arm. turn back on.
[09:46:14] <cradek> yeah
[09:46:26] <skunkworks> But - I can't remember a fail tool change since first setting it up.
[09:46:26] <cradek> mine has some failure modes that are irritating and might require removing covers
[09:46:35] <cradek> like if the arm is down and in the middle of a swing, and you estop
[09:47:13] <skunkworks> right
[09:47:14] <cradek> although the one time that happened (jam on tool change) I poked the right contactor with a screwdriver after unjamming it
[09:47:28] <skunkworks> heh - that is cheating
[09:47:31] <cradek> that's happened like once
[09:47:39] <cradek> wouldn't want to write much ladder to make that recovery easy
[09:48:03] <skunkworks> The tool change is 1000 times more consistant than it was..
[09:48:04] <cradek> overengineering is bad, because you have a bunch of unused/untested stuff
[09:50:32] <skunkworks> sure
[09:52:36] <skunkworks> cradek, that didn't seem to fix anything. M19 just shows
[09:52:51] <skunkworks_> Issuing EMC_TASK_PLAN_EXECUTE -- (+509,+280, +18,m19,)
[09:52:53] <skunkworks_> mdi_execute_hook: MDI command 'm19' done (remaining: 0)
[09:53:59] <linuxcnc-build> build #638 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/638 blamelist: Chris Radek <chris@timeguy.com>
[09:54:08] <skunkworks_> v2.6.3-772-g79cb463
[09:54:32] <cradek> v2.6.3-55-g510097e
[09:54:35] <cradek> what on earth
[09:54:39] <skunkworks_> hmm
[09:54:45] <skunkworks_> I did a git pull
[09:54:54] <cradek> you're on master maybe?
[09:54:54] <skunkworks_> let me try it again
[09:55:04] <skunkworks_> oh - duh
[09:55:05] <cradek> git checkout cradek/m19-without-r-defaults
[09:55:05] <skunkworks_> yes
[09:55:16] <linuxcnc-build> build #638 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/638 blamelist: Chris Radek <chris@timeguy.com>
[09:55:19] <skunkworks_> sorry - didn't notice that
[09:55:45] <cradek> oh hey, I changed a behavior that had a test
[09:56:13] <skunkworks_> sorry
[09:57:04] <cradek> ok, those new results are what I expected
[09:57:10] <linuxcnc-build> build #295 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/295 blamelist: Chris Radek <chris@timeguy.com>
[09:57:20] <cradek> M19 and M19Q1 were both doing nothing, now they're doing the default orient
[10:00:09] <KGB-linuxcnc> 03Chris Radek 05cradek/m19-without-r-defaults 2d5e258 06linuxcnc 10tests/interp/m19/expected Fix M19 test; M19 and M19Q1 now issue default orients * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2d5e258
[10:07:45] <linuxcnc-build> build #2482 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/2482 blamelist: Chris Radek <chris@timeguy.com>
[10:08:32] <linuxcnc-build> build #2480 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/2480 blamelist: Chris Radek <chris@timeguy.com>
[10:09:34] <linuxcnc-build> build #2481 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/2481 blamelist: Chris Radek <chris@timeguy.com>
[10:10:08] <linuxcnc-build> build #2481 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/2481 blamelist: Chris Radek <chris@timeguy.com>
[10:11:02] <linuxcnc-build> build #1682 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/1682 blamelist: Chris Radek <chris@timeguy.com>
[10:15:14] <linuxcnc-build> build #2481 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/2481 blamelist: Chris Radek <chris@timeguy.com>
[10:15:15] <linuxcnc-build> build #2489 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2489 blamelist: Chris Radek <chris@timeguy.com>
[10:17:31] <skunkworks> cradek, that seems to work as expected now. I think the loopback works too, well - no the wait for lock, -orient goes false but -locked goes true.
[10:18:20] <skunkworks> I do think it should wait for is-oriented to come true even if there is no time specified - like you say - it should wait indefinatley..
[10:20:40] <cradek> I don't understand the point of the motion.spindle-locked output
[10:20:48] <cradek> wouldn't it be the same as the is-oriented input?
[10:30:50] <skunkworks> Well that is what I thought..
[10:31:33] <skunkworks> (and How I hooked it up initally..) but once is-oriented input goes true - the orient goes false.
[10:32:55] <cradek> so you're supposed to orient on rising edge of -orient, and unorient on falling edge of -locked?
[10:33:40] <skunkworks> I would think (in my mind ) M19 called -> orient goes true -> pause until is-orented goes true -> continue on until M3,4,5 or whatever else turns is-oriented off..
[10:34:02] <cradek> I think you mean m3/4/5 turns -orient off
[10:34:15] <skunkworks> right
[10:34:26] <cradek> that's how the other loopbacks (toolchange, locking) work
[10:34:33] <skunkworks> I thought so!
[10:34:40] <skunkworks> but was too lazy to check...
[10:35:03] <cradek> but there's no way for those to report a failure, they just have to never succeed, and let the user abort
[10:35:12] <skunkworks> sure
[10:35:19] <PetefromTn_> Man this is the next hurdle for my Cincinatti I am glad you guys are discussing it. I need to understand it here somehow.LOL
[10:35:21] <cradek> I would have done the same for this, but I didn't design it
[10:35:38] <cradek> whether to fix it to be like the others is a question to consider
[10:35:53] <skunkworks> question for -devel list?
[10:36:10] <cradek> probably so
[10:36:29] <PetefromTn_> is you speaking in the context of classic ladder or a remap here?
[10:36:35] <cradek> I'd remove the Q and always wait, either forever, or for an ini-file setting of seconds
[10:36:36] <skunkworks> PetefromTn_, only using basic functionally of m19...
[10:36:54] <PetefromTn_> okay
[10:37:08] <skunkworks> PetefromTn_, is your drive a vector drive?
[10:37:16] <PetefromTn_> yeah sensorless vector
[10:37:35] <PetefromTn_> it is a Hitachi WJ200-LF
[10:37:58] <skunkworks> ok - i talked to a guy at work that does some of this stuff and he said a sensorless vector drive should work well for simple orient.
[10:38:22] <PetefromTn_> thats good to hear
[10:38:41] <skunkworks> my question is - you may have to switch to analog input vs modbus.. I am thinking that modbus is too slow or inconsistant for a position loop - but that might be a question for others.
[10:39:45] <PetefromTn_> I had it hooked up that way before but switched to the modbus control for simple addition of things like spindle load metering etc.
[10:40:36] <PetefromTn_> if it needs be I can switch it back and wire it up again that way.
[10:40:43] <skunkworks> can you use both I wonder? modbus for metering and analog for control? I don't know enough about these new fangled drives ;)
[10:40:57] <PetefromTn_> I have no idea
[10:43:22] <PetefromTn_> I have been reading thru the orient page ssi linked to me
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Closed_Loop_Spindle_Speed_Control
[10:44:53] <PetefromTn_> I wish I understood better how to program this stuff. From what I read there it seems to have been setup on a parallel port scheme and that is not going to be directly applicable of course
[10:45:33] <PetefromTn_> I need to try to figure out how to get it to work with either input and MESAnet stuff.
[10:58:17] <skunkworks> I wish I had time to set one up. I don't think it is that bad.
[10:59:45] <pcw_home> just change the names...
[12:18:43] <skunkworks> aww - john is going
[12:20:25] <PetefromTn_> yeah my problem is I don't know what to change the names to LOL
[12:22:18] <Connor> I think you can do both Modbus and analog same time.. because the analog could be used for local powe control.. modbus for remote.
[12:23:07] <PetefromTn_> I have no idea I suppose it is possible but the drive may not do both.
[12:23:25] <Connor> I think I remember reading that it does.
[12:26:28] <skunkworks> guy at work said a normal v/f vfd would probably work ok - but some don't go down to 0hz..
[12:27:34] <Connor> skunkworks His VFD has a pre-programmed position setup.. but.. the VFD only takes A/B encoder input.. no index..
[12:28:29] <skunkworks> I read a little bit - I read it as position mode for positioning say a conveyor..
[12:29:15] <PetefromTn_> I thought we were supposed to have the encoder into the Mesa 7i77 and linux do the PID stuff
[12:29:30] <skunkworks> not nececarly for postioning in 1 rotation..
[12:29:40] <skunkworks> PetefromTn_, that is how I would do it
[12:29:56] <PetefromTn_> what is how you would do it?
[12:30:05] <skunkworks> what you said
[12:30:22] <PetefromTn_> okay that is how it is wired up now.
[12:30:47] <PetefromTn_> encoder into MESA which we pretty much have to have for the index masking for my 180 out double index pulse.
[12:30:56] <Connor> Yea, I was just saying.. his VFD should be able to do it..
[12:31:18] <PetefromTn_> I REALLY wish I understood this stuff more so I can help myself here.
[12:32:05] <PetefromTn_> this HAL programming is confusing to me. Looking at that link I posted and trying to figure out how to make it work for mesa I don't know where to begin.
[12:32:13] <PetefromTn_> it is quite frustrating
[12:35:36] <Tom_itx> what link?
[12:36:33] <Connor> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Closed_Loop_Spindle_Speed_Control
[12:37:00] <Tom_itx> using a regular encoder?
[12:37:08] <Connor> yes. but with VFD
[12:37:20] <Connor> and.. his is modbus.
[12:37:21] <PetefromTn_> its a differential 500 line encoder
[12:37:39] <Tom_itx> so that goes to an encoder input on your card
[12:37:46] <PetefromTn_> we already have the encoder working and registering the correct speed and index
[12:37:55] <skunkworks> maybe modbus is fast enough - cool
[12:37:58] <skunkworks> worth a shot
[12:38:23] <PetefromTn_> I don't see why we need to be fast here it is not like we are going to try to orient at 12k RPM
[12:38:23] <Connor> yea.
[12:38:38] <Tom_itx> yeah there's probably not one answer because everybody's setup is different
[12:38:39] <Connor> PetefromTn_: No.. But.. reaction time is critical.
[12:38:57] <Connor> and modbos is SLOW compared to analog voltage change.
[12:39:03] <Tom_itx> you want it to stop when you tell it stop
[12:39:09] <Tom_itx> so the orient is correct
[12:39:26] <Tom_itx> is it gonna orient in clockwise only or both?
[12:39:36] <Connor> It can do either..
[12:39:37] <PetefromTn_> as I understand it we will be slowing the spindle down from speed to say 100 or less RPM and THEN orienting right?
[12:39:49] <Tom_itx> you're probably better off sticking with clockwise
[12:39:59] <Tom_itx> PetefromTn_ probably so yes
[12:40:06] <PetefromTn_> I could give a rats ass which direction it orients really
[12:40:16] <Tom_itx> you certainly couldn't expect it to orient at cutter speeds
[12:40:24] <Tom_itx> think of it as homing your axis
[12:40:57] <Tom_itx> in terms of rate
[12:43:24] <Tom_itx> those that have tool changers.. do you use a subroutine to orient or a custom M code or something else?
[12:44:21] <Tom_itx> or remap the M6 to a custom tool change routine?
[12:44:48] <Tom_itx> that would be the sexiest probably
[12:45:11] <Connor> Some don't have to orient.. others have a hardware to handle it.. very few from what I seen do it like pete needs.
[12:45:27] <Connor> I think we're kinda breaking new ground with his setup..
[12:45:35] <Tom_itx> what's special about his?
[12:45:47] <Connor> Using REMAP with M6 + Spindle Orient
[12:45:47] <Tom_itx> *different
[12:46:42] <Connor> Well.. someone used custom M codes to do it.. other have use Classic Ladder... and I have NO idea what they've done for orient if they needed it..
[12:47:48] <Connor> PetefromTn_: What did the other guy do with a Cincinnati ? He would run his spindle down to very low RPM, then let it free spin and the engage some sort of spring loaded spindle lock ?
[12:48:14] <PetefromTn_> To be honest with you I am surprised it has not been done before this is the most basic of toolchangers and a typical umbrella style with moving head. Just like every fadal cincinatti you name it that does not have a side mount.
[12:48:47] <PetefromTn_> It does not matter what he did even he wants to get it working the right way and is watching my progress to see what we can come up with.
[12:48:51] <Tom_itx> it probably has but the problem is they didn't take the time to share it
[12:49:37] <PetefromTn_> now SSI is going to need the same situation as well now that he has the VMC in his shop.
[12:50:53] <Tom_itx> http://linuxcnc.org/docs/html/remap/structure.html#_remapping_toolchange_related_codes_t_m6_m61
[12:51:09] <Tom_itx> i'm sure you've looked that over already
[12:51:23] <Connor> Tom_itx: I already have his toolchanger code for remap written.
[12:51:41] <Connor> and working under simulator.. I just needed the final part.. which was the spindle orientation...
[12:51:59] <Connor> and.. I do plan on sharing it.
[12:52:01] <Tom_itx> S1 and wait for the index to trigger and stop
[12:52:29] <Connor> Still going to have overrun.
[12:52:33] <Tom_itx> just stop when the index pulse is reached and orient it so that it's in the right position for the collet dogs
[12:52:34] <cradek> the first vmc running with emc2 did orient with a spindle encoder and pid running a plain vfd
[12:52:38] <cradek> it is not new ground
[12:52:56] <cradek> it's new that there's an M code for orient, but so what, unless you need to orient from your gcode.
[12:53:12] <Tom_itx> you shouldn't need to really
[12:53:30] <Connor> cradek: No need for the G-code.. just a way to orient the spindle.
[12:53:37] <cradek> I can imagine you might need it for back-side boring or something unusual like that
[12:54:13] <PetefromTn_> we have no need to orient from G code just the M6 command
[12:54:38] <Tom_itx> does it have a brake?
[12:54:52] <Tom_itx> and is it on a separate pin?
[12:55:03] <PetefromTn_> no brake
[12:55:20] <Connor> I think you can break using the VFD though ?
[12:55:44] <Tom_itx> S1 .. wait for index pulse .. S0 and brake
[12:55:45] <cradek> VFDs are bad at holding a position (which is the very worst case of low speed torque)
[12:55:59] <Tom_itx> or S whatever
[12:56:22] <cradek> yeah a mechanical brake would be better
[12:56:24] <PetefromTn_> that is precisely how it worked before
[12:56:46] <PetefromTn_> no brake whatsoever
[12:57:31] <Tom_itx> S1 M3 .. wait for pulse M5
[12:57:38] <PetefromTn_> as far as I know Fadals also do not have a brake
[12:57:43] <skunkworks> that is also how the matsura works.
[12:58:04] <skunkworks> no brake - it is 'mushy' but is good enough for a tool change
[12:58:18] <Tom_itx> especially if you run it at minimal RPM
[12:58:22] <Connor> We'll get it sorted out.. We can do some experiments with a few things and see..
[12:58:48] <Tom_itx> experiment with different tools
[12:58:56] <Tom_itx> make sure the mass doesn't affect it
[12:59:01] <Connor> Tom_itx: Oooh Good point.
[12:59:07] <Tom_itx> ie 5" shell mill opposed to a 1/4" em
[12:59:25] <Tom_itx> why i asked about a brake
[12:59:37] <Connor> I'll bring my boring head.. it has some mass too it.
[13:00:44] <skunkworks> https://www.youtube.com/watch?v=Kh4YD0d071c&list=UUHk52YjGT8HryRYmJKSl-lg
[13:02:09] <Tom_itx> at low rpm it won't be nearly as critical
[13:02:22] <Connor> That's such a bad a$$ machine
[13:02:58] <PetefromTn_> this machine will never have a very fast toolchange cycle and it never did before so orientation at low rpm is not going to be an issue here.
[13:04:19] <Tom_itx> you could mod the M5 to stop on the index
[13:04:30] <Tom_itx> then it would be oriented right to begin with
[13:05:03] <PetefromTn_> the problem is not when it orients but how to make it orient
[13:07:17] <Connor> https://www.youtube.com/watch?v=16naCRilR08 OKay.. that's just cute.. a way cover for the vise.
[13:09:52] <PetefromTn_> my Kurt 6" came with a way/screw cover for the vise
[13:11:14] <Tom_itx> i can see that little pee hole nozzle getting plugged up right away
[13:11:20] <skunkworks> and even another example..
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob_plain;f=configs/attic/demo_mazak/demo_mazak.hal;hb=HEAD
[13:17:29] <archivist> you know you got the tool change right when you can beat this one
https://www.youtube.com/watch?v=4XYakTeQahA
[13:17:34] * archivist ducks
[13:19:57] <cradek> https://www.youtube.com/watch?v=yj_PsRyRGM0
[13:22:24] <PetefromTn_> Honestly right now that speed would be fine with me as long as it worked reliably LOL
[13:22:47] <archivist> I like how the tool rack bends
[13:22:57] <skunkworks> spring loaded!
[13:25:49] <skunkworks> still get a kick out of this
https://www.youtube.com/watch?v=vGTfVlsA9Ww
[13:27:53] * archivist falls over laughing
[13:29:28] <cradek> I didn't mean to make fun of hossmachine. that's clever homemade stuff. it's just not fast (and I bet he knows this and is ok with it)
[13:30:59] <archivist> it is withing the limitations of mach :)
[13:31:04] <archivist> within
[13:31:07] <cradek> yeah
[13:33:28] <PetefromTn_> limitations is precisely why I moved away from MACH3 but sometimes I find the need to be a freakin' pro level programmer it's own limitation in LinuxCNC
[13:38:58] <skunkworks> and now you sound like a mach fanboy ;)
[13:40:12] <PetefromTn_> NEVA!!
[13:40:30] <PetefromTn_> how dare you curse me in this manner LOL
[13:43:02] <cradek> I'm always surprised at what kinds of knowledge people think they should need and shouldn't need to put a control in a machine like a vmc and use it
[13:44:37] <PetefromTn_> perhaps I made a mistake trying this then?
[13:45:07] <cradek> well I wasn't really talking about you in particular, sorry I wasn't clear
[13:46:03] <cradek> it's really a complicated task
[13:47:40] <cradek> but I do kind of wonder what you mean by pro-level programmer
[13:48:04] <skunkworks> PetefromTn_, honestly - you have really done a good job with your setup. When you first showed up and took the changed the drives you got from machmotion to analog from step/dir AND got them working - it is impressive.
[13:48:23] <PetefromTn_> I mean that so far the two guys who have helped me the most getting thru this retrofit are both professional programmers and there have been things that stumped even them.
[13:49:05] * skunkworks doesn't make sense today
[13:49:20] <cradek> ok then being a professional programmer is not sufficient -- probably not necessary either :-)
[13:49:30] <PetefromTn_> skunkworks Thank you for the compliments but really I have just been blessed to have help from some very knowledgeable folks.
[13:50:14] <PetefromTn_> the machine is currently running very well and making me some money so I have them to thank for that exclusively.
[13:50:25] <cradek> being able to wire up stuff in a way that makes it work and not burn up is a skill that you need, but programmers generally don't have
[13:50:36] <PetefromTn_> them and those that have built linuxCNC to what it is today.
[13:50:58] <PetefromTn_> well for the most part the mechanical and wiring stuff I did myself so far
[13:51:12] <cradek> cool
[13:51:23] <cradek> don't underestimate your contribution to the success then
[13:51:31] <PetefromTn_> to be clear I NEVER figured this would be simple or easy
[13:51:40] <cradek> heh, realism helps too
[13:51:54] <PetefromTn_> I just did not realize the level of programming necessary to accomplish this toolchanger thing
[13:52:17] <cradek> do you consider hooking things together in hal to be programming?
[13:52:23] <cradek> I'm still trying to understand what you mean
[13:52:27] <PetefromTn_> Perhaps some of that comes from my previous build and watching videos like you just posted.
[13:52:28] <skunkworks> well - they did need to do a remap
[13:52:53] <cradek> ok, that's writing gcode, some do consider that programming (but most programmers I bet wouldn't)
[13:53:05] <PetefromTn_> actually yes hooking things together in hal is essentially programming and that is in addition to the other hurdles.
[13:53:23] <cradek> interesting, I see that *exactly* the same as running wires
[13:53:25] <PetefromTn_> I mean PCW had to make a custom firmware upgrade to get my spindle encoder to mask the input
[13:54:35] <cradek> I wonder why -- we've had index mask for years. must've gotten lost from the firmwares somewhere along the way
[13:54:52] <cradek> but yeah making custom firmwares is certainly wizard level
[13:55:31] <skunkworks> that is a great service pcw does..
[13:55:49] <PetefromTn_> yes immensely...
[13:56:26] <PetefromTn_> which is why whenever anyone asks about what boards to buy I always recommend them and him without question
[13:57:08] <cradek> a wizard level mechanic would have solved the encoder problem in a different way (mechanically, not in software) - either way it was complex enough to need some wizardry to handle
[13:58:27] <archivist> dont some vfds have dc injection braking that could be used for the orient ?
[14:00:30] <archivist> I like how the wizardry get passed around on irc
[14:01:26] <cradek> yeah it's nice
[14:01:43] <cradek> we used to have more machinist wizardry talk - but that was usually jmk's fault
[14:02:31] <skunkworks> I miss him yelling at me for not stating my questions clear enough ;)
[14:02:37] <cradek> haha
[14:03:01] <archivist> has he finished his pcb mill yet
[14:03:22] <cradek> truly doubt it
[14:03:35] <cradek> I visited him a couple? years ago and it was still looking the same
[14:03:52] <archivist> I understand taking ones time about projects :)
[14:06:11] <skunkworks> PetefromTn_, your 2 issues (spindle orient with vfd and tool change) are not trivial. just a few years ago with no re-map the physical tool change would have been a lot harder.
[14:06:12] <PetefromTn_> Wow just finished machining the first side of a new prototype I designed and ran thru the program without changes first time LOL AMAZING for me.
[14:06:26] <cradek> you wizard programmer
[14:06:30] <PetefromTn_> yes I understand that
[14:06:31] <skunkworks> :)
[14:06:54] <PetefromTn_> part looks gorgeous..
[14:07:52] <PetefromTn_> I did forget a second drilling operation for the thru hole on six holes I need to tap tho LOL Just gotta add that op in there and run just that part of the program again.
[14:08:11] <PetefromTn_> God I love this freakin' machine...
[14:08:50] <skunkworks> so stop bitching and get the tool changer and spindle orient finished!
[14:08:58] <skunkworks> :)
[14:09:25] <skunkworks> my wife would say 'Just do it alread!'
[14:10:48] <archivist> only took me 5 years to get the hobbing machine part done
[14:11:17] <PetefromTn_> Ya know while I was just sitting here watching it run thru the program I was thinking... If the toolchanger was working and I got rigid tapping integrated with the G33.1 into my cam software so I could use it It would almost feel just like I had a brand new HAAS machine delivered here...ALMOST
[14:11:40] <PetefromTn_> skunkworks If I KNEW how to do it, it would already be done ;)
[14:12:15] <Connor> Doing the Toolchanger Remap was a tad like programming.. it has subroutines and logic checks. But as for HAL.. that's not programming to me.. that's more like configuring.. compiling the driver for the VFD.. that was programming.
[14:14:41] <Connor> Honestly, it's been fun.. not many people get to work on a full sized VMC.. I've gotten allot of knowledge from working on your PetefromTn_
[14:15:56] <PetefromTn_> http://i.imgur.com/8UYnzps.jpg
[14:16:21] <cradek> what is it?
[14:16:39] <cradek> klingon weapon of some kind?
[14:16:39] <PetefromTn_> Connor Honestly it has been a pleasure meeting you and SSI I have learned a great deal from both of you and I hope I have been able to help you guys as well along the way.
[14:17:13] <PetefromTn_> It is another design of my Steyr Custom droop compensated riser rails I make only this one is considerably shorter
[14:17:20] <Connor> upgrading my CNC with ballscrews and extra travel is next up. also going to add a stepper to that little rotary table. :)
[14:17:42] <cradek> nice finish on those vertical walls
[14:17:43] <Connor> PetefromTn_: You rigid tapped anything but air yet ?
[14:18:13] <PetefromTn_> nope I have just played with the cycle in air.
[14:18:30] <PetefromTn_> I have to figure out how to add teh G33.1 cycle to my CAM so I can just program it.
[14:18:41] <PetefromTn_> Sure wish it was jsut G84 instead
[14:18:45] <PetefromTn_> just
[14:19:25] <Connor> What's the diff between G84 and G33.1 ?
[14:19:47] <PetefromTn_> not sure
[14:19:51] <cradek> g84 doesn't have a way to specify the pitch directly, it's calculated from the spindle speed
[14:20:00] <cradek> g84 does let you do repeats like all the other canned cycles
[14:20:16] <cradek> I don't know what g84 in linuxcnc currently does
[14:20:26] <Connor> can you not repeat with G33.1 ?
[14:20:29] <PetefromTn_> is it even supported?
[14:20:33] <cradek> nope
[14:20:59] <PetefromTn_> no it is not supported or no it does not repeat>
[14:21:12] <cradek> it's accepted as valid gcode
[14:21:18] <cradek> I don't know what it does, if anything
[14:21:28] <cradek> it needs someone to love it and care for it
[14:21:52] <PetefromTn_> LOL it needs to be implemented because most major cam programs that I have seen use it.
[14:22:13] <PetefromTn_> what exactly do you mean by repeats?
[14:22:23] <Connor> CamBam doesn't look to support either..
[14:22:30] <PetefromTn_> like peck tapping
[14:22:32] <cradek> the L word that lets you run several cycles with one command
[14:22:56] <cradek> there was an example on the list recently, of doing a bolt hole circle with one command
[14:23:15] <PetefromTn_> so how did you program that tooling plate video you made?
[14:23:26] <PetefromTn_> does it not just use the same code at different positions?
[14:23:27] <Connor> Oh. okay. G33.1 doesn't do that.. cause L isn't a option
[14:23:45] <cradek> right
[14:24:10] <cradek> oh I probably used o-repeat and g91 mode, that's my tool of choice because it's so simple to get right
[14:24:54] <cradek> o100 repeat[10]; g91 g0 x1; g90 g33.1 z-whatever kwhatever; o100 endrepeat
[14:25:00] <Connor> calculating the K value is that hard part with g33.1
[14:25:11] <cradek> what!
[14:25:17] <Connor> hehe. :)
[14:25:24] <cradek> it's the pitch! it couldn't possibly be simpler
[14:26:11] <PetefromTn_> My machinist friend came by recently and he worked in the shop I used to work in.
[14:26:21] <PetefromTn_> They had all HAAS mills and they programmed with mastercam
[14:26:35] <PetefromTn_> He had his thumb drive with him
[14:26:59] <Connor> 24 TPI is a odd bird..
[14:27:05] <PetefromTn_> we took one of the programs he had on it and put it in the machine setting everything to crawl and set zero in the center of travel
[14:27:06] <cradek> k[1/24]
[14:27:28] <PetefromTn_> then we tried to install the program
[14:27:44] <PetefromTn_> LinuxCNC did not like the tapping cycles and threw an error
[14:27:54] <PetefromTn_> we removed them and everything else worked fine.
[14:28:01] <PetefromTn_> Which was very inspiring to see
[14:28:21] <Connor> Just need a post processor to convert those to something linuxcnc likes
[14:28:24] <cradek> basic gcode g0/1/2/3 is pretty portable
[14:28:34] <cradek> except when it's no
[14:28:35] <cradek> t
[14:28:38] <PetefromTn_> Getting G84 working as in the HAAS and basically any other CAM software would be tits
[14:28:39] <Connor> CamBam doesn't look like it supports any tapping
[14:28:55] <PetefromTn_> yeah CAMBAM it needs to be done the hard way.
[14:29:03] <PetefromTn_> Funny thing is Sheetcam had tapping..
[14:29:09] <PetefromTn_> rigid and otherwise
[14:29:29] <PetefromTn_> God what I would not do to be able to afford Mastercam
[14:29:36] <PetefromTn_> It just plain kicks ass...
[14:30:14] <PetefromTn_> so you think my new prototype rail looks like a Klingon batliffe then? that is a good thing I believe LOL
[14:30:49] <PetefromTn_> bat'leth
[14:30:52] <PetefromTn_> actually
[14:34:36] <skunkworks> couldn't you do a remap - making g84 using g33.1 and some magic?
[14:35:11] <Connor> what is the R value in G84 ?
[14:35:13] <skunkworks> sorry wizardry..
[14:35:21] <PetefromTn_> probably retract
[14:35:21] <Connor> FeedRate?
[14:36:53] <skunkworks> retract
[14:38:13] <PetefromTn_> http://www.helmancnc.com/g84-tapping-cycle-example-cnc-program/
[14:38:23] <PetefromTn_> that is a short explanation of G84
[14:38:31] <PetefromTn_> R is the retract plane height I think.
[14:39:17] <Connor> So, need something to translate the Feed rate.. into the pitch
[14:39:50] <Connor> then.. it could be remapped to G33.1
[14:40:09] <PetefromTn_> It looks like G33.1 would be programmed with a simple Z depth and thread pitch. How does it know where to go back to other than starting point>
[14:40:40] <PetefromTn_> I noticed in the example on the linuxCNC literature the previous line takes the tool to .1 above the part at the location X and Y.
[14:40:49] <PetefromTn_> then the G33.1 is inserted
[14:41:11] <Connor> I think it goes back to previous location
[14:41:33] <PetefromTn_> probably.
[14:41:51] <PetefromTn_> Spindle speed is setup previously and the cycle just adjusts feed accordingly
[14:42:17] <Connor> okay. So what would the feed/speed for 1/4 20 using G84 be ?
[14:44:02] <PetefromTn_> 1/4 x 20 at 500 RPM the IPM would be 500*.05=25. X,Y,Z and R are programmed the same as in the drilling cycles
[14:44:25] <PetefromTn_> just found that online when talking about G84
[14:46:31] <PetefromTn_> looks like rigid tapping is actually G84.2
[14:46:45] <PetefromTn_> G74 would be reverse tap
[14:47:31] <Connor> M29 S1800
[14:47:31] <Connor> G84 Z-0.50 R0.0 F0.03125
[14:47:31] <Connor> G80
[14:47:40] <Connor> That's what someone is using for 10-32's
[14:48:46] <PetefromTn_> it really seems like G84.2 would be simple to get from G33.1 but again not a programmer here.
[14:49:28] <Connor> What's the params for G84.2 ?
[14:50:29] <PetefromTn_> http://www.cnczone.com/forums/g-code-programing/68797-g84-amp-g74-tapping-cycle.html
[14:50:46] <PetefromTn_> that is a simple discussion about programming that code in mastercam.
[14:50:54] <PetefromTn_> but it relates I think.
[14:51:56] <Connor> I think that's easy enough to translate to G33.1
[14:52:34] <Connor> I'm not sure how F and Q work
[14:53:01] <PetefromTn_> where did you get Q
[14:53:24] <PetefromTn_> oh nevermind Q is peck depth for peck rigid tapping.
[14:53:33] <PetefromTn_> Not even sure if LinuxCNC can do that or not.
[14:53:38] <PetefromTn_> Would be awesome tho.
[14:53:41] <Connor> we iqnore that.
[14:53:52] <Connor> So, the F would be the the pitch...
[14:54:01] <PetefromTn_> yeah or feedrate same thing
[14:54:12] <Connor> F is feed rate.. which translates to pitch.
[14:54:37] <Connor> G84.2 X1 Y1 Z-0.50 R0.0 F0.03125
[14:55:00] <PetefromTn_> yup
[14:55:15] <PetefromTn_> but that won't work in linuxCNC because it is not supported yet.
[14:55:19] <Connor> would translate too... G33.1 Z-0.50 K0.03125
[14:55:48] <Connor> with a G0 X1 Y1 before it.
[14:56:18] <PetefromTn_> not sure if you can put the position in the line or not. Mostly it is before it anyways based on how cam works it seems.
[14:56:27] <PetefromTn_> going from tapped hole to tapped hole anyways
[14:56:38] <Connor> not with G33.1
[14:56:46] <Connor> looks like you can with G84.2
[14:56:57] <PetefromTn_> no important I think really
[14:57:02] <PetefromTn_> not
[14:57:26] <PetefromTn_> like I said cam would probably input the hole location movement as a rapid before each hole anyway
[14:57:31] <Connor> http://www.cnczone.com/forums/cambam/103686-tapping-cambam.html
[14:58:11] <Connor> Looks like you might be able to make you own canned cycle in CamBam for it..
[14:58:44] <PetefromTn_> yeah but it does not include the proper synchronization I think let alone any dwell.
[15:00:24] <PetefromTn_> but that is basically how I will need to do it until I can afford something else
[15:00:45] <PetefromTn_> It is either that or make two programs one in CamBam and one in sheetcam which supports tapping cycles.
[15:00:54] <PetefromTn_> or hand code the damn thing.
[15:01:13] <PetefromTn_> either way it beats manually tapping it every time ;)
[15:08:47] <PetefromTn_> just reading the G33.1 doccumentation.
[15:09:01] <PetefromTn_> apparently the X and Y movements are optional
[15:09:44] <PetefromTn_> not sure if that means they can be called in the same line or before.
[15:09:52] <PetefromTn_> The example shows them before
[15:13:06] <ssi> hey guys
[15:13:10] <PetefromTn_> hey ssi
[15:13:11] <skunkworks> well - if you have x and y moves on the same line - it will run the pitch along the hypotinuse..
[15:13:23] <PetefromTn_> really... thats not good.
[15:13:41] <PetefromTn_> unless you enjoy breaking taps that is ;)
[15:13:42] <skunkworks> I think...
[15:14:00] <skunkworks> well - maybe not. I was thinking of g33
[15:14:03] <ssi> PetefromTn_: I'm pretty sure my motors have encoders on them
[15:14:09] <ssi> https://pbs.twimg.com/media/BzDBFDrIMAARcUP.jpg:large
[15:14:39] <PetefromTn_> looks like fanuc red top?
[15:14:50] <ssi> yep
[15:14:54] <PetefromTn_> nice
[15:15:00] <Connor> Pete. Very easy to do in cambam.
[15:15:03] <PetefromTn_> might be able to use your new drives and keep the old motors
[15:15:06] <ssi> I'm hoping
[15:15:08] <Connor> Use the Drill Cycle.. and run custom script.
[15:15:09] <skunkworks> never mind - I am mistaken
[15:15:42] <Connor> Custom Script is. G33.1 X$x Y$y Z$z K$f
[15:15:44] <PetefromTn_> Connor yeah like I said that is what I am going to have to do.
[15:16:14] <Connor> then use plunge feedrate tp specify the thread pitch.. so, for 20tpi you use .05
[15:16:22] <PetefromTn_> would like to be able to use G84.2 tho for future cam systems or if my friend wants to make a part using his software.
[15:16:30] <Tom_itx> are the spindle and Z axis sync'd using the rigid tapping?
[15:16:39] <PetefromTn_> yeah
[15:16:49] <PetefromTn_> gotta be
[15:17:51] <PetefromTn_> SSI I would consider making new cables for the motors and encoders tho or at least inspect yours to ensure there are not any pinch points or damage anywhere along the run.
[15:18:50] <PetefromTn_> That is one of the things Rob Varney told me about the old machines... a lot of problems come from guys not cleaning out chips and them getting smashed into places they should not be and damaging the cables.
[15:19:22] <PetefromTn_> even tho they should never get anywhere near them it apparently happens. That and just years of movement can wear them past the shielding.
[15:19:42] <Tom_itx> yes it does
[15:19:57] <ssi> I'll try to inspect them at least
[15:20:01] <PetefromTn_> This is a major reason why I chose to gut my machine and start over with brand new motors drives and cables.
[15:20:08] <ssi> everything looks pretty good tbh
[15:20:19] <ssi> if I can use these motors and cables with my gemini drives I'll be a happy, happy man
[15:20:21] <PetefromTn_> have you torn into it I guess.
[15:20:27] <ssi> not really
[15:20:31] <ssi> I just finished leveling it
[15:20:43] <ssi> btw that odd man out pad is actually a pad for the electronics enclosure
[15:20:47] <ssi> and I'm missing a main pad
[15:21:04] <PetefromTn_> take all the table covers off and clean the living shit out of that whole area underneath.
[15:21:09] <Connor> ssi huh ?
[15:21:15] <PetefromTn_> Oh yeah mine has a pad for the electronics enclosure too.
[15:21:20] <PetefromTn_> it is much smaller tho.
[15:22:10] <ssi> mine's not MUCH smaller
[15:22:25] <ssi> th eround part is about the same, but it has a smaller hole for a smaller screw, and the flatbar on the bottom is the same width but not as long
[15:22:28] <PetefromTn_> well mines not either but it is narrower diameter
[15:22:50] <ssi> so it's on five pads right now, and dead ass level in X and Y
[15:22:57] <PetefromTn_> I am sure there are more than a few dissimilarities between our machines.
[15:23:02] <ssi> I have a 0.00005"/10" machinists level
[15:23:06] <PetefromTn_> dead ass?
[15:23:20] <ssi> and it's within .2 of a graduation of level on that
[15:23:26] <ssi> I'm calling it good :)
[15:23:37] <PetefromTn_> Bring that bitch level up here so I can use it LOL
[15:23:41] <ssi> heheh
[15:24:08] <PetefromTn_> we were discussing the orient problem here earlier.
[15:24:13] <ssi> any progress?
[15:24:23] <PetefromTn_> NO LOL
[15:24:31] <ssi> I'm wondering if it'd be possible to get an appropriate spindle drive which is true vector drive
[15:24:43] <PetefromTn_> mine is vector drive
[15:31:34] <ssi> does it have encoder feedback to the drive?
[15:31:56] <PetefromTn_> yeah but they are saying it is better to get it thru the 7i77
[15:32:13] <PetefromTn_> it is the Hitachi WJ200-LF
[15:32:16] <ssi> that wasn't kimk's opinion the other day
[15:32:26] <PetefromTn_> what was?
[15:32:37] <ssi> that true vector drive would be a better option
[15:33:00] <PetefromTn_> it is a true vector drive..
[15:33:42] <ssi> not without feedback!
[15:33:50] <ssi> without feedback it's sensorless vector drive
[15:35:46] <ssi> Open Loop is actually a misnomer because it is actually a closed loop system, but the feedback loop comes from within the VFD itself instead of an external encoder. For this reason there is a trend to refer to them as "Sensorless Vector" drives. The mP creates a mathematical "model" of the motor operating parameters and keeps it in memory. As the motor operates, the mP monitors the output current (mainly), compares it to the model and determines f
[15:36:02] <ssi> zero speed is exactly where spindle orient happens
[15:37:00] <ssi> my internet out here is spotty
[15:37:10] <PetefromTn_> http://driveswarehouse.com/documentation/Hitachi/WJ200R.pdf
[15:37:37] <PetefromTn_> page 43
[15:37:53] <ssi> how big of a vfd did you put on your coolant pump
[15:38:23] <PetefromTn_> it discusses simple positioning with encoder input there.
[15:39:32] <ssi> so why haven't you done it?
[15:39:35] <ssi> you have everything you need :)
[15:39:52] <PetefromTn_> do I
[15:40:06] <ssi> looks like it
[15:42:14] <PetefromTn_> no idea how to make that work
[15:42:36] <PetefromTn_> no idea what to hookup to it
[15:42:54] <PetefromTn_> no idea how to make linuxCNC control it.
[15:45:49] <ssi> talk to pcw about feeding the '77 and the vfd from the same encoder
[15:45:57] <ssi> connor showed me a card mesa makes which is a Y splitter for encoder signals
[15:46:10] <ssi> it's hard to tell from tha quick reference but it looks like it's expecting single-ended encoder signals
[15:46:49] <PetefromTn_> I don't see what advantage that would give me over using linuxCNC to control the orient
[15:47:43] <ssi> if you have a way to do so, then do it
[15:48:05] <ssi> the advantage that I'm thinking is there, is if the drive can use feedback from the motor and adjust the commutation more finely based on it
[15:48:12] <ssi> then it may be able to run more accurately at low speed
[15:48:41] <PetefromTn_> do you plan to use the original spindle drive on your machine?
[15:48:49] <ssi> not if I can avoid it
[15:48:58] <ssi> I'd rather not run any of the old electronics
[15:49:04] <ssi> the motors I don't mind, motors haven't changed much in 20 years
[15:49:06] <ssi> but the drives have
[15:49:08] <PetefromTn_> understand that.
[15:49:32] <PetefromTn_> well this hitachi is the most reasonable choice based on price and capability that I was able to find
[15:50:10] <ssi> yeah and if it can use encoder feedback for more accurate commutation, that'll be awesome
[15:50:37] <ssi> CaptHindsight: are you around, by chance?
[15:50:49] <PetefromTn_> well I don't know enough about it to be able to really say.
[15:50:57] <PetefromTn_> you are probably right.
[15:51:07] <PetefromTn_> and if it means I need another board to make it work so be it.
[15:51:28] <ssi> I think connor said it was a $30 board
[15:51:42] <CaptHindsight> ssi: sort of
[15:52:18] <ssi> CaptHindsight: I'm trying to figure out if I can run the fanuc red cap motors on this wmc with the gemini drives I have
[15:52:22] <ssi> two things I'm unclear on
[15:52:38] <ssi> one: the motors may not have hall effects, hopefully these drives can run a motor without halls because it can take the encoder signals
[15:52:54] <ssi> two: the drives are spec'd as 170V drives, but can they run lower voltage motors?
[15:54:43] <CaptHindsight> I never tried either condition. The manual for the drives should list what works. I know it's hundreds pages to dig through
[15:54:50] <ssi> ya
[15:54:52] <ssi> heheh
[15:55:08] <ssi> and I haven't even found specs on the motors yet... I'm hoping I can find info in the books, and not have to pull a motor to look at the nameplate
[15:55:11] <CaptHindsight> the mesa servo drive can operate with HALL
[15:55:29] <ssi> the geminis can too, but I think I have no hall
[15:55:37] <CaptHindsight> I'm not sure if the Gemini can just use the encoders
[15:55:46] <CaptHindsight> sorry meant without HALL
[15:55:48] <PetefromTn_> pulling these motors or at least accessing them on the machine is simple.
[15:56:02] <ssi> I can get at the Y motor easily... that's the cap I pulled
[15:56:09] <ssi> but the motor is buried 14" deep in the column
[15:56:20] <ssi> so I can't see the nameplate, and I'm not ready to pull one yet
[15:56:21] <PetefromTn_> from the back.
[15:56:43] <PetefromTn_> The X motor if it is anything like mine takes two covers to remove to access it.
[15:56:43] <ssi> btw the book says the Y travel is only 381mm
[15:56:46] <ssi> 15", not 20
[15:56:49] <PetefromTn_> The Z is right out in the open.
[15:56:59] <ssi> yeah Z is out in the open but it's 9' in the air :)
[15:57:00] <PetefromTn_> WOW no shit that kinda sucks.
[15:57:19] <PetefromTn_> get used to climbing on the machine man.. you will be doing a lot of that.
[15:57:28] <ssi> ya
[16:04:07] <ssi> hm might be a 9kw spindle tho
[16:04:50] <ssi> 12hp, 8000rpm
[16:06:08] <PetefromTn_> damn that is nice...
[16:06:44] <ssi> maximum theoretical power consumption: 24KVA
[16:07:36] <Tom_itx> i wonder if you should move this back to the main channel?
[16:08:10] <ssi> oh we're not in the main channel? :P
[16:11:47] <cradek> I just made the mistake of sending a "can we all calm down?" to -users
[16:11:50] <cradek> now I'll be the lightning rod
[16:12:06] <Tom_itx> that's just what happens
[16:14:31] <PetefromTn_> huh?
[16:17:35] <PCW> I think we should ban jumps in CPU architectures
[16:18:32] <ssi> seems like a good idea
[16:18:51] <PCW> since GOTO is bad, lets get rid of the root cause
[16:25:58] <CaptHindsight> ssi: I don't anything in the manuals for disabling HALL sensors, only to invert the signals
[16:26:11] <CaptHindsight> don't see
[16:26:20] <ssi> rats
[16:30:04] <CaptHindsight> ssi: DHALL is the command to disable HALL sensor checking on the Parker drives
[16:30:12] <ssi> ah!
[16:30:39] <CaptHindsight> you'll have to check the programming manual for your drive to see of is supports that command
[16:30:50] <ssi> which drive's manual are you looking at?
[16:30:56] <CaptHindsight> of is/ if it
[16:31:28] <CaptHindsight> GV-U6E
[16:31:38] <ssi> yea that's what I have
[16:31:47] <ssi> I have three U6E and three U12E
[16:33:22] <CaptHindsight> ssi: when you hook up the cable and connect the programming software you'll see if it's supported
