#linuxcnc-devel | Logs for 2016-05-24

Back
[00:19:14] -!- KimK_laptop [KimK_laptop!~Kim@helixmachine.com] has joined #linuxcnc-devel
[00:22:41] -!- rob_h has quit [Ping timeout: 240 seconds]
[00:23:40] <PCW_> what host hardware?
[00:25:19] <mozmck> PCW_: I believe it's a Dell with intel nic - not sure of the cpu. We have used a lot of these though without problems.
[00:26:32] <PCW_> yeah, I dont think ive seen that error for a long time (and I think it was do to a setup error)
[00:27:37] <mozmck> Huh. I wonder if putting a switch in between the PC and 7i92 could do that? I didn't think to ask him that.
[00:28:28] <PCW_> possibly, especially if it ever drops packets
[00:30:35] <PCW_> I have used a GigE switch to run 4 Ethernet cards at once at 2 KHz so a switch thats dedicated doesn't have to hurt
[00:31:12] <PCW_> if there is other traffic, all bets are off
[00:33:11] <mozmck> I'll ask the guy. I know one user had some problems when using a wireless mouse, but I think that was realtime errors. This one won't even start most of the time he says.
[00:38:54] -!- CaptHindsight has quit [Read error: Connection reset by peer]
[00:39:01] -!- wibblewobble has quit [Remote host closed the connection]
[00:43:19] -!- wibblewobble has quit [Remote host closed the connection]
[00:45:05] -!- BeachBumPete [BeachBumPete!~IceChat9@2601:585:8200:7a40:d0d5:13c1:9dae:52c] has joined #linuxcnc-devel
[00:45:48] -!- BeachBumPete [BeachBumPete!~IceChat9@2601:585:8200:7a40:d0d5:13c1:9dae:52c] has parted #linuxcnc-devel
[00:49:41] <PCW_> yeah, thats strange
[00:50:29] -!- kingarmadillo has quit [Ping timeout: 250 seconds]
[00:53:05] -!- skunkworks__ [skunkworks__!~skunkwork@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[00:57:18] <skunkworks__> zlog
[00:57:18] <zlog> skunkworks__: Log stored at http://tom-itx.no-ip.biz:81/~tom-itx/irc/logs/%23linuxcnc-devel/2016-05-23.html
[01:19:42] -!- wibblewobble has quit [Remote host closed the connection]
[01:21:22] -!- wibblewobble has quit [Remote host closed the connection]
[02:43:13] -!- pandeiro has quit [Remote host closed the connection]
[03:17:13] -!- Roguish has quit [Remote host closed the connection]
[03:18:07] -!- skunksleep has quit [Ping timeout: 260 seconds]
[03:18:53] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[03:28:04] -!- skunksleep has quit [Ping timeout: 240 seconds]
[04:24:03] -!- ve7it has quit [Remote host closed the connection]
[04:51:06] -!- hm2-buildmaster has quit [Remote host closed the connection]
[04:51:07] -!- linuxcnc-build has quit [Remote host closed the connection]
[05:08:28] -!- hm2-buildmaster [hm2-buildmaster!~hm2-build@174-29-189-86.hlrn.qwest.net] has joined #linuxcnc-devel
[05:08:33] -!- linuxcnc-build [linuxcnc-build!~linuxcnc-@174-29-189-86.hlrn.qwest.net] has joined #linuxcnc-devel
[05:18:04] -!- racicot has quit [Ping timeout: 240 seconds]
[05:31:25] <seb_kuzminsky> linuxcnc-build: force build --branch=master 0000.checkin
[05:31:26] <linuxcnc-build> build #4168 forced
[05:31:26] <linuxcnc-build> I'll give a shout when the build finishes
[05:35:55] -!- zeeshan has quit [Read error: Connection reset by peer]
[05:38:30] -!- zeeshan [zeeshan!~kvirc64@CPE84948c379051-CM84948c379050.cpe.net.cable.rogers.com] has joined #linuxcnc-devel
[06:03:34] -!- CaptHindsight [CaptHindsight!~2020@unaffiliated/capthindsight] has joined #linuxcnc-devel
[06:04:14] -!- Mathnerd314 has quit [Ping timeout: 244 seconds]
[06:14:05] -!- johtso has quit [Ping timeout: 260 seconds]
[06:16:59] -!- amatecha has quit [Ping timeout: 260 seconds]
[06:18:44] -!- almccon_ has quit [Ping timeout: 260 seconds]
[06:20:29] -!- SkramX has quit [Ping timeout: 260 seconds]
[06:22:14] -!- calvinmetcalf has quit [Ping timeout: 260 seconds]
[06:27:29] -!- msantana has quit [Ping timeout: 260 seconds]
[06:27:46] -!- msantana [msantana!marcelo@unaffiliated/darkstar] has joined #linuxcnc-devel
[06:27:58] <linuxcnc-build> Hey! build 0000.checkin #4168 is complete: Success [3build successful]
[06:27:58] <linuxcnc-build> Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4168
[06:31:22] -!- alex_joni has quit [Ping timeout: 252 seconds]
[06:31:56] -!- alex_joni [alex_joni!~alex_joni@emc/board-of-directors/alexjoni] has joined #linuxcnc-devel
[06:31:57] -!- mode/#linuxcnc-devel [+v alex_joni] by ChanServ
[06:46:54] -!- skunkworks has quit [Ping timeout: 250 seconds]
[06:48:13] -!- persina has quit [Ping timeout: 250 seconds]
[06:59:47] -!- teepee_ [teepee_!~teepee@unaffiliated/teepee] has joined #linuxcnc-devel
[07:01:04] -!- teepee has quit [Ping timeout: 244 seconds]
[07:01:05] teepee_ is now known as teepee
[07:01:07] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[07:04:51] -!- kwallace [kwallace!~kwallace@162.222.30.254] has parted #linuxcnc-devel
[07:05:28] -!- skunksleep has quit [Ping timeout: 252 seconds]
[07:05:49] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[07:06:24] -!- gaute has quit [Ping timeout: 250 seconds]
[07:11:04] _Patang is now known as Patang
[07:13:35] -!- rob_h [rob_h!~robh@2a02:c7f:5603:bc00:c032:81d3:1b2c:6610] has joined #linuxcnc-devel
[07:17:39] -!- skunksleep has quit [Ping timeout: 260 seconds]
[07:29:32] -!- Komzpa has quit [Ping timeout: 260 seconds]
[07:35:43] -!- kalxas has quit [Changing host]
[07:39:48] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[07:44:29] -!- skunksleep has quit [Ping timeout: 260 seconds]
[07:52:45] -!- Komzpa has quit [Ping timeout: 260 seconds]
[08:21:49] -!- Komzzpa has quit [Ping timeout: 260 seconds]
[08:55:05] -!- b_b has quit [Changing host]
[08:57:10] -!- Komzzpa has quit [Ping timeout: 244 seconds]
[10:27:46] -!- skunkworks__ has quit [Ping timeout: 244 seconds]
[11:04:40] -!- asteroid has quit [Changing host]
[11:29:38] <jepler> 18:45:09 <seb_kuzminsky> i think that means hm2_eth tried to read a packet, but none was available
[11:29:41] <jepler> yes seb is right
[11:30:39] <jepler> the recv() call has timed out instead of receiving a UDP packet with 44 bytes
[11:32:45] <jepler> in 2.7.4, the timeout is very big, 200*1000*1000ns = 200ms, but if this is before 'loadrt hm2_eth' has finished then the code is not running in realtime mode yet so a possible but unlikely cause would be something causing a 200ms delay from sending the packet to trying to receive it
[11:33:11] <jepler> in the past I have started linuxcnc 10000s of times and not received this error once
[11:34:05] <jepler> I have a branch where I have been working on resilience against lost packets, but that is only when running realtime; I haven't done anything about packet loss during startup
[11:35:31] <jepler> I have found that you can 'tcpdump' packets on the hm2 ethernet port without compromising real-time performance, doing that will tell you if the packet is lost (as far as linux is concerned) or just came in too late
[11:50:20] -!- skunkworks__ [skunkworks__!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[13:15:55] -!- txp has quit [Quit: Leaving]
[13:53:36] <mozmck> thanks jepler. I'll be getting the pc and 7i92 so I can do some of that testing.
[13:54:54] -!- skunkworks__ has quit [Ping timeout: 260 seconds]
[14:35:59] -!- kwallace [kwallace!~kwallace@162.222.30.254] has joined #linuxcnc-devel
[14:37:42] -!- skunkworks__ [skunkworks__!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[14:42:38] -!- racicot has quit [*.net *.split]
[14:42:39] -!- KGB-wlo has quit [*.net *.split]
[14:42:39] -!- Gaston|Home has quit [*.net *.split]
[14:42:39] -!- dnaleromj has quit [*.net *.split]
[15:27:04] -!- Daerist has quit [Quit: Leaving]
[15:32:08] -!- ivansanchez has quit []
[15:35:57] -!- dnaleromj has quit [*.net *.split]
[15:40:20] -!- KGB-wlo [KGB-wlo!~kgb-wlo@174-29-189-86.hlrn.qwest.net] has joined #linuxcnc-devel
[15:40:21] -!- Gaston|Home [Gaston|Home!~quassel@rosie.office.tw.ly] has joined #linuxcnc-devel
[15:40:21] -!- dnaleromj [dnaleromj!~dnaleromj@user-69-1-6-88.knology.net] has joined #linuxcnc-devel
[16:30:03] -!- kingarmadillo has quit [Ping timeout: 276 seconds]
[16:35:17] -!- JT-JA14 [JT-JA14!~john@198.45.191.246] has joined #linuxcnc-devel
[16:36:26] -!- jthornton [jthornton!~john@198.45.191.246] has joined #linuxcnc-devel
[16:40:11] -!- JT-Shop [JT-Shop!~john@198.45.191.246] has joined #linuxcnc-devel
[17:07:32] -!- ktchk [ktchk!~eddie6929@n219079227118.netvigator.com] has joined #linuxcnc-devel
[17:10:30] -!- Mathnerd314 [Mathnerd314!~quassel@supertux/Mathnerd314] has joined #linuxcnc-devel
[17:19:08] <mozmck> I'm having a little trouble parsing the flow of the RUN command. The NML message has the type EMC_TASK_PLAN_RUN_TYPE, and that winds up getting issued as an immediate command as far as I can tell.
[17:20:08] <mozmck> But in emcTaskIssueCommand() for that type, it simply sets several variables.
[17:21:32] <mozmck> As far as I can tell the next thing is emcTaskExecute(), and I'm assuming the task.execState will be EMC_TASK_EXEC_DONE.
[17:22:08] -!- ktchk has quit [Quit: ktchk]
[17:32:21] -!- Komzpa has quit [Ping timeout: 246 seconds]
[17:41:44] <mozmck> But then I'm getting a bit lost.
[17:48:08] -!- md-2 has quit [Quit: Leaving...]
[18:44:26] <PCW_> you lost a bit?
[18:47:34] <mozmck> yeah, or two
[18:52:59] -!- KimK has quit [Ping timeout: 260 seconds]
[19:02:54] -!- kingarmadillo has quit [Ping timeout: 260 seconds]
[19:06:09] -!- KimK [KimK!~Kim__@ip68-102-66-31.ks.ok.cox.net] has joined #linuxcnc-devel
[19:16:25] -!- zeeshan-shop has quit [Remote host closed the connection]
[19:18:04] -!- skunkworks__ has quit [Ping timeout: 252 seconds]
[19:18:28] -!- zeeshan-shop [zeeshan-shop!~zeeshan@CPE84948c379051-CM84948c379050.cpe.net.cable.rogers.com] has joined #linuxcnc-devel
[19:21:40] -!- zeeshan-shop has quit [Remote host closed the connection]
[19:22:48] -!- zeeshan-shop [zeeshan-shop!~zeeshan@CPE84948c379051-CM84948c379050.cpe.net.cable.rogers.com] has joined #linuxcnc-devel
[19:24:15] -!- b_b has quit [Remote host closed the connection]
[19:25:51] -!- zeeshan-shop has quit [Client Quit]
[19:34:33] -!- zeeshan-shop [zeeshan-shop!~zeeshan@CPE84948c379051-CM84948c379050.cpe.net.cable.rogers.com] has joined #linuxcnc-devel
[19:45:54] -!- skunkworks__ [skunkworks__!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[20:09:09] -!- skunkworks__ has quit [Ping timeout: 246 seconds]
[20:17:33] -!- kingarmadillo has quit [Ping timeout: 276 seconds]
[20:36:10] -!- andypugh [andypugh!~andypugh@cpc14-basl11-2-0-cust1010.20-1.cable.virginm.net] has joined #linuxcnc-devel
[20:37:01] <andypugh> Sometimes a job grows and grows.
[20:38:06] <andypugh> I am looking at adding spindle homing to the homing sequence. Which rather needs a struct to hold the spindle homing sequence, direction and offset. At which point there might as well be many spindles.
[20:38:28] <andypugh> (There does seem to be an occasional request for multi-spindle support).
[20:39:46] <andypugh> I think I can see where I need to interfere for the simple stuff. I propose adding an optional P-word to the M3 M4 an M5 commands.
[20:41:34] <andypugh> But then you get into the minutiae of spindle-synched motions, canned cycles, CSS etc.
[20:41:38] <cradek> tricky - I think the M commands don't currently claim/handle any other words
[20:41:51] <cradek> for instance I bet M3 G4 P1 is handled predictably
[20:42:03] <cradek> maybe M3 for all the spindles, M3.1, M3.2, M3.3 etc for individual ones?
[20:42:15] <cradek> err I wonder if there are decimalled Ms yet
[20:42:20] <andypugh> That was my original idea, but there are no decimal M-codes
[20:42:25] <cradek> TO THE BAT CAVE err CODE
[20:42:28] <cradek> ah, hmm
[20:42:45] <cradek> wonder which scheme is less terrible to add
[20:43:04] <andypugh> Good question.
[20:43:05] <cradek> wonder how other controls handle multiple spindles
[20:43:57] <andypugh> My initial question was whether it seems reasonable to simply ignore the clever stuff for the extra spindles, they just get a speed output in HAL and nothing more?
[20:44:36] <cradek> oh you mean like sync?
[20:44:55] <andypugh> Yes. And rigid tapping..
[20:46:07] <andypugh> I suspect that mutli-spindle rigid-tapping s just too hard a problem to consider, and nobody wants it anyway.
[20:46:16] <cradek> is multi-spindle useful without multiple motions/axes? (not that I want to grow your project more - I'm just wanting to understand the use case)
[20:46:35] <andypugh> I don’t really know.
[20:47:05] <andypugh> It just seemed odd to create a “spindles” struct with only one member, really.
[20:48:29] -!- kingarmadillo has quit [Ping timeout: 260 seconds]
[20:48:47] <andypugh> Incidentally, I looked at M31, M32 for extra spindles, and that’s OK clockwise but rather not-OK anticlockwise. :-)
[20:48:58] <cradek> haha ouch
[20:50:19] <cradek> I wonder how/if any other controls do multi-spindles
[20:50:24] <andypugh> Maybe I should ask on the users list? The problem then is that there becomes as expectation of introduction, and it is harder to just quietly give up on the project.
[20:51:27] <andypugh> Todd Zuercher first appeared on the forum with a gang-router question, though that probably doesn’t need individual speed control.
[20:51:54] <andypugh> I think quite a few people run live tooling on their lathes.
[20:52:19] <cradek> I recommend you don't in any way ask for a spec, but maybe ask for a use-case
[20:53:19] <andypugh> And the lathes that pick-up a workpiece in a second chuck to finish the machining are quite cool.
[20:56:10] <andypugh> Hmm. https://www.youtube.com/watch?v=UQiOYbX5fJo does rigid-tapping with live-tooling.
[21:00:09] <mozmck> hmm, so a lathe with live tooling would be multi-spindle? I hadn't thought of that.
[21:00:40] <mozmck> Machine shop down the road has some lathes with a rear spindle to finish machining - it is very neat.
[21:08:09] -!- asteroid has quit [Quit: Leaving.]
[21:09:54] <andypugh> cradek: Guess what M64 P1 G4 does?
[21:10:36] <cradek> heh I don't even know what M64 does
[21:10:52] <andypugh> Turns on a digital output
[21:11:11] <cradek> oh dear
[21:11:20] <cradek> I'd rather it would error than do whatever it does
[21:11:32] <andypugh> It turns on the output, and waits 1 second
[21:11:44] <cradek> that's ... elegant
[21:11:57] <mozmck> Isn't that what it should do?
[21:12:07] <andypugh> Yeah, that could be quite neat, if that is exactly what you wanted
[21:12:16] <cradek> it should error because since they both require P, you shouldn't be able to have them on one line
[21:12:44] <mozmck> huh, why not M64 P1 G4 P2 ?
[21:12:52] <cradek> because you can't have two P words on one line
[21:13:09] <cradek> remember the order of the things on the line means nothing in gcode
[21:13:14] <mozmck> I see, it used the P from before the G4
[21:13:41] <cradek> yeah there's not really a "before" - they both use the P value from that line
[21:13:52] <mozmck> I didn't know the order was irrelevant
[21:14:10] <cradek> yeah, for better or for worse, it is
[21:14:22] <andypugh> So, I started by wanting to home spindles, and now I am thinking that a necessary precursor is a check of G-codes that are not allowed to share a block…
[21:14:50] <cradek> traditionally the control reads in the words and puts them in the control's registers, and then runs the "block" (file line)
[21:15:02] <cradek> that's still pretty much the model
[21:16:32] <mozmck> I see.
[21:16:33] <cradek> http://www.linuxcnc.org/docs/html/gcode/overview.html#_item_order
[21:16:46] <cradek> except with comments and variables it's slightly trickier than that
[21:16:55] <cradek> we do actually document it, yay!
[21:16:57] <andypugh> Well, I guess I can introduce M4 P1 and not worry, I won’t make things any _more_ broken :-)
[21:17:43] <andypugh> I am likely to make an unqualified M5 stop all spindles.
[21:17:47] <cradek> andypugh: what a rabbit hole
[21:19:36] -!- penpen has quit [Quit: Leaving.]
[21:20:06] <cradek> I have used a control where multiple same words are allowed, and the order was important: for instance drill cycles could have several Z words, for the various heights in the operation
[21:20:32] <cradek> I think there were also some things like "cut a rectangle" which would take two XY corners or somesuch
[21:20:42] <mozmck> I *think* I'm gradually understanding the run and run-from-line. In order to make a simple rfl, it looks like I might need to have the interpreter skip to that line, instead of task skipping through the code as is done currently.
[21:20:50] <cradek> very limited memory, so they had a lot of cycles that saved you a few lines
[21:23:39] <cradek> mozmck: that seems plausible to me too
[21:23:43] <andypugh> For reference, I am currently basing this work on JA14
[21:26:22] <mozmck> Is there anything really preventing us merging JA into master now?
[21:27:28] <andypugh> In practical terms it means replacing Master with JA, I think. It’s not really a manageable merge I don’t think, not that I have tried.
[21:31:59] <jepler> fear of regressions. from a git standpoint, there appears to be a single merge conflict between master and ja14, and it's just irritating (it looks like one side reformatted code but I'm not sure yet from 30 seconds looking)
[21:34:46] <andypugh> OK, that’s good news. Dewey has been rebasing JA on master occasionally (hence the 14 versions).
[21:34:52] <mozmck> Isn't each new JA made by re-basing it on master?
[21:35:11] <mozmck> heh, answered before I hit enter!
[21:35:30] <mozmck> So it should not be too far off since ja14 is pretty recent
[21:36:54] <mozmck> There were concerns over some issues with JA a while back I remember, but it seems like dewey and others have fixed at least some of those issues.
[21:38:15] <jepler> yes, dewey has been very responsive fixing issues that seb has been reporting trying to use the gantry at his hackspace, and I think the results are getting better
[21:38:51] <jepler> I don't think there's a master list of known issues with ja, aside from what I am certain dgarr has in his head.
[21:43:48] <andypugh> I think that there are currently fewer problems with JA than with Master, as several things work better in JA than master, and I don’t know of anything that works worse. I run JA3 (I think) on my mill and the only thing I am not sure about is Y-axis rigid-tapping. That was “funny” when I tried it. But reading the docs, that might be expected.
[21:49:25] <jepler> yes, dgarr has chosen to fix certain bugs that came to his attention on JAx only and not on master, even though they affect both.
[21:49:56] <mozmck> :-) all the more reason to merge it to master soon!
[21:51:28] -!- kingarmadillo has quit [Ping timeout: 264 seconds]
[22:07:53] -!- ve7it [ve7it!~LawrenceG@S010648f8b3c3bc3b.pk.shawcable.net] has joined #linuxcnc-devel
[22:15:35] <andypugh> Bother! M19 already uses P.
[22:27:58] <andypugh> Does M3 E5 seem OK?
[22:31:39] <jthornton> E5?
[22:36:48] -!- BeachBumPete [BeachBumPete!~IceChat9@2601:585:8200:7a40:d0d5:13c1:9dae:52c] has joined #linuxcnc-devel
[22:38:46] -!- BeachBumPete [BeachBumPete!~IceChat9@2601:585:8200:7a40:d0d5:13c1:9dae:52c] has parted #linuxcnc-devel
[22:40:34] <andypugh> What would you prefer?
[22:44:21] -!- dnaleromj has quit [Ping timeout: 244 seconds]
[22:45:08] -!- dnaleromj [dnaleromj!~dnaleromj@user-69-1-6-88.knology.net] has joined #linuxcnc-devel
[22:56:50] -!- che_ [che_!7a95e475@gateway/web/freenode/ip.122.149.228.117] has joined #linuxcnc-devel
[22:58:45] -!- che_ has quit [Client Quit]
[23:01:28] -!- gaute has quit [Ping timeout: 250 seconds]
[23:03:24] <cradek> andypugh: do you think it might be important to turn on several spindles simultaneously?
[23:03:41] <cradek> again I really have no idea how they're used, but I think a lathe can sometimes hold a part from both ends
[23:04:04] <andypugh> How simultaeous would it have to be?
[23:04:08] <mozmck> Looks to me like the entire 400+ line contents of the function emcFormat() in emc.cc can be replaced with this: ((EMC_CMD_MSG*)buffer)->update(cms); return 1;
[23:04:10] <cradek> in that case, maybe you'd want to turn them both on together? M3.1 M4.2?
[23:04:37] <cradek> again I don't know
[23:04:53] <cradek> if that matters, I think you'd want to be able to put several on one line
[23:04:54] <andypugh> Yes, perhaps that is the way to do it.
[23:05:11] <cradek> if it doesn't matter, it doesn't matter
[23:05:45] <andypugh> Successive G-code lines are likely to be simultaneous _enough_ though, I suspect.
[23:06:26] <cradek> yeah it seems like if you're holding a part on both ends you need a much stronger guarantee than just turning the VFDs on at the same time
[23:06:33] <cradek> maybe it doesn't matter at all
[23:06:54] <cradek> pardon my thinking out loud
[23:07:03] <andypugh> In your M3.1 scheme, how does one set a spindle speed?
[23:07:33] <andypugh> One way is to associate the S-word with the most-recent M3 / M4
[23:08:06] <cradek> oh, good question
[23:08:20] <cradek> have you looked to see how any other control does it? (or do they?)
[23:09:22] <andypugh> I did a bit of google searching, but mainly found unanswered questions.
[23:11:07] <Tom_itx> they do do it but i can't say how
[23:11:16] <andypugh> Using E works out sort-of OK, because M3 S1000 E4 would work just the same as M3 E4 / S1000 M4
[23:11:32] <andypugh> I mean M3 E4 / S1000 E4
[23:13:09] <andypugh> The Wikipedia page on G-code says “S Defines speed, either spindle speed or surface speed depending on mode Data type = integer. In G97 mode (which is usually the default), an integer after S is interpreted as a number of rev/min (rpm). In G96 mode (CSS), an integer after S is interpreted as surface speed—sfm (G20) or m/min (G21). See also Speeds and feeds. On multifunction (turn-mill or mill-turn) machines,
[23:13:10] <andypugh> which spindle gets the input (main spindle or subspindles) is determined by other M codes.”
[23:13:24] <archivist> ask rob_h, he has a citizen sliding head, dunno if he has the one with second spindle plus live tooling on both
[23:14:04] <Tom_itx> looking at the okuma lathe book i have here, M12 M-tool spindle stop
[23:14:15] <Tom_itx> M13 M-tool spindle cw
[23:14:21] <Tom_itx> M14 ccw
[23:14:41] <andypugh> Yes, I just noticed that those M-codes are free
[23:15:05] <andypugh> The Wiki page says that M13 is spindle on + coolant on.
[23:15:14] <Tom_itx> i could scan these pages if it would be of any use
[23:15:20] <Tom_itx> just the g & m codes
[23:15:35] <rob_h> archivist, it has sub spindle yes well has 3 spindles as power tooling is classed the same address as main spindle
[23:15:51] <Tom_itx> there are 5 pages of M codes
[23:17:38] <rob_h> S1=3000 M04 (main spindle) S2=3000 M23 (sub Spindle)
[23:18:16] <Tom_itx> M23 is chamfer on (for thread cutting cycle) on the okuma
[23:18:21] <rob_h> M58 S3=3000 Power Tooling
[23:18:37] <andypugh> It looks like we could use M4/M4/M5, M13/M14/M15 M23/M24/M25 M33/M34/M35 for 4 spindles, but could only orient (M19) one of them.
[23:18:43] <Tom_itx> M58 chuck low air pressure
[23:18:45] <rob_h> yea well Mcodes can be what ever realy just what Citizen had free in the mitsubishi control i guess
[23:18:52] <Tom_itx> right
[23:20:09] <rob_h> i know M58 on our matsuura is coolant presure selection
[23:20:11] <andypugh> Unless there is a very well-established standard I think I prefer to use E-words. That works with M19, G76 etc.
[23:20:32] <andypugh> I don’t mean G76, do I?
[23:20:41] <rob_h> E to do?
[23:20:52] <Tom_itx> seems like M words are more common use
[23:21:04] <Tom_itx> even though they support a variety of functions
[23:21:17] <mozmck> According to SMID, M13/M14 or M103/M104 is used to control rotating tools (live tooling) in a lathe
[23:21:44] <Tom_itx> that's what the okuma uses here
[23:21:45] <rob_h> M14 and M13 on one lathe we had hardinge use to be Spindle and coolant on
[23:21:51] <andypugh> M100+ are defined as user m-codes in LinuxCNC though.
[23:22:12] <Tom_itx> http://www.editcnc.com/GandMcodes.html
[23:22:14] <Tom_itx> https://diy.haascnc.com/m-codes-lathes
[23:22:21] <Tom_itx> a couple just for reference
[23:22:58] <rob_h> as long as its a some what common sence sceem to follow
[23:23:54] <Tom_itx> http://okumacnc.blogspot.com/2011/03/list-of-m-codes-fanuc-control-m-codes.html
[23:24:01] <Tom_itx> fanuc supported
[23:24:17] <rob_h> well more so what the control builder does
[23:24:26] <rob_h> as any and all Mcodes and G codes can be changed
[23:24:37] <andypugh> Hmm, to allow multi-spindle threading (or, to put it a better way, to not exclude the possibility of multi-spindle threading) I think that the spindle-selector word would need to be D
[23:24:39] <rob_h> just a simple remap on the control to tell it what todo/use
[23:25:19] <rob_h> erm on citizen you have to do a Mcode sync which put spindles at same speed, does a phase match and then main is the master and sub has to follow very close
[23:25:41] <rob_h> if you want both spindles to sync , IE you pickup and want to use CSS or thread etc
[23:25:41] <mozmck> I could probably get some info from the shop nearby with a dual spindle lathe. I believe it's mori seiki
[23:26:28] <rob_h> but also the drives are digial linked. so control does not do much smart side just drives must sync each other and tell control its synced.. and drives take care of how much error there is if too much they alarm out
[23:26:43] <andypugh> I am trying to think of a scheme that isn’t limited to 2 spindles (in which scenario M13/14/15 is the easy way.
[23:27:09] <archivist> a multi spindle cnc wickman could be a target to think about too
[23:28:32] <rob_h> spindles can be power tooling also, so lathe with two spindles prob have two turets with live on each... and they are probly servo driven so can do tapping etc and are commaned same way any spindle is
[23:29:16] <andypugh> Well, if I decide on M3 D99 to start the 99th spindle we can have any number of spindles wthout running out of M-codes, at the expense of not being very standard. But it seems that there are few standards anyway,
[23:30:12] <andypugh> rob_h: Exactly, which is why you might want to at least leave the way clear for G33.1 D12 to rigid-tap with your 12th spindle...
[23:31:07] <rob_h> D is speed limit in CSS@?
[23:31:15] <rob_h> in G96
[23:31:22] <andypugh> Ah, yes, so it is.
[23:31:29] <andypugh> That’s a problem.
[23:32:02] -!- kingarmadillo has quit [Ping timeout: 244 seconds]
[23:32:09] <rob_h> but yes the concept seems valid/wise one to me if D or what ever is missing its assumed you mean main spindle (ie spindle 1)
[23:32:31] <andypugh> rob_h: Yes, it needs to be that way to not break existing code
[23:33:10] <andypugh> But if I can’t use D to say which spindles are CSS and I can’t use E to say which spindle we are threading with, it gets a bit intractable.
[23:34:10] <rob_h> yea becasue when have sub spindle now days, you are multipath control so its abit more easy to track spindle use
[23:35:28] <andypugh> I guess we would just need to be inconsistent, with E setting the spindle number in M3, M19, G96 and D being used (as the only spare letter) in G76
[23:36:08] <rob_h> plus when pickup with a sub. have to be running opasit direction to main rember as its other way around ;) so need M3 and M4 on same line if want to run both spindles at the same time
[23:37:21] <andypugh> Not possible.
[23:38:13] <andypugh> Synching spindles together would need to be a whole separate command.
[23:38:57] <mozmck> Can you use two letters? ie. SP?
[23:39:10] <andypugh> Something like M33 E1 D3 to synch spindle 1 to 3
[23:39:28] <rob_h> but dont need to be "synced" to do a pickup as such.. just running close to each spindle speed is good enouth to do a pickup.. only time to sync is if u want to phase Z match for threads or Caxis alinements. or zero mark the part (you gety zero or very little rub on unsynced)
[23:39:28] <mozmck> or even: M3 SPINDLE1
[23:39:58] <andypugh> mozmck: The only way to do that would be with “magic comments”
[23:40:19] <mozmck> ok
[23:40:26] <rob_h> something that seems easy at first is abit more tricky under the hood
[23:41:01] <andypugh> M3 SPINDLE1 would error when it tried to interpret PINDLE1 as a spindle speed
[23:41:16] <mozmck> bummer
[23:42:09] <Tom_itx> M3 HEAD1 M3 HEAD2
[23:42:39] <rob_h> can not do S1= S2= etc.. but if its just Sxxx then its the main(S1)
[23:42:43] <andypugh> “Unknown word beginnign with E”
[23:43:14] <andypugh> S1 is 1rpm.
[23:43:16] <cradek> CORRECT SOURCE AND RESUBNIT
[23:44:31] <cradek> (today I learned alt.lang.intercal still gets several posts every year)
[23:44:35] <andypugh> Every letter in G-code is a command. You can’t combine them in words. Well not wthout re-writing the entire interpreter, and if you were doing that you would use something better than Gcode.
[23:45:19] <mozmck> Is there something better than Gcode for this purpose in existence already?
[23:46:19] <Tom_itx> http://cnc.im/library/ftp/fanuc/a/A-79114E_01_050120.pdf
[23:46:26] <Tom_itx> dunno if that helps
[23:47:21] <rob_h> how to set the spindle selection paramiter i think that is
[23:49:25] <andypugh> mozmck: StepNC might be better than G-code
[23:49:50] <mozmck> hmm, seems like I've heard the name. I'll look it up.
[23:52:34] <andypugh> Tom_itx: That actually seems to hint that using the P-word to select spindles is an option.
[23:52:49] <Tom_itx> http://dl.mitsubishielectric.com/dl/fa/document/manual/cnc/ib1500269/ib1500269engf.pdf
[23:53:00] <Tom_itx> andypugh, i was also seeing that in the spindle section there
[23:53:06] <andypugh> Unfortunately M19 already uses P for something else.
[23:53:10] <Tom_itx> around P120ish
[23:54:11] <rob_h> Q prob not used alot
[23:54:34] <Tom_itx> could it be reused in context?
[23:55:35] <andypugh> Tom_itx: That uses the S1=1000 S2=750 syntax, but that isn’t something handles by the LinuxCNC parser
[23:56:41] <andypugh> rob_h: Q is not used much, but is used by G76 and M19
[23:56:56] <Tom_itx> http://cnc.im/library/ftp/fanuc/a/A-90046E_02_050722.pdf
[23:57:02] <Tom_itx> another version of fanuc's method
[23:59:21] <andypugh> Tom_itx: I don’t understank their documentation format
[23:59:54] <rob_h> its paramiters for spindle over ride i think