00:00:41 I'd think that the m6 would have to wait for the tool prepped reply. 00:01:12 I agree.. but I don't know of a way that a NML message might do that 00:01:34 maybe if task keeps it, and doesn't send it till Tx returns.. but it doesn't seem like that 00:02:00 I'm guessing that what you are seeing is bridgeportio or minimillio setting the tool prepped status 00:02:01 hm, wouldnt you make the PLC wait with the toolchange until the tool is ready? 00:02:12 as soon as they get the tool prep command. 00:02:12 yes.. 00:02:58 why do you need to have a nml mesage back saying it's ready? 00:03:14 because you do 00:03:20 there is some motion involved 00:03:26 move to tool-load position, etc 00:03:30 If you used tkio and added an after 5000 in the line with the status message I'd bet you'd see it. 00:04:02 say again? 00:04:15 alex_joni: ah, yeah.. 00:04:29 But I don't know that the move to tool change position waits for tool prepped status. 00:05:49 All of the IO commands are handled by bpt, mini, or tkio 00:06:04 or iocontroller now 00:06:08 bpt doesn't do sh*t 00:06:12 All of these have no tool change logic in them. 00:06:17 right 00:06:19 Ah but they do. 00:06:32 yup, just simple (=stupid) logic 00:06:40 They switch status when they get an IO message 00:06:44 get NML, ack it 00:07:06 If that did not happen, then other parts of the system would wait. 00:07:46 forever 00:08:01 yes.. but it shouldn't just Ack 00:08:56 No but does bpt or mini or tkio run with the HAL? 00:09:16 nope 00:09:22 and it won't ever 00:09:27 bpt and mini are gone 00:09:31 :) 00:09:32 So HAL has to take over the ack functions. 00:10:05 nope 00:10:12 maybe I wasn't clear 00:10:21 Somebody does. 00:10:29 emc->(NML TOOL_PREPARE) -> iocontroller 00:10:42 iocontroller->(HAL pins) -> HW 00:10:52 HW -> (ack) -> iocontroller 00:11:01 iocontroller -> (NML ack ) -> emc 00:11:04 right? 00:11:08 that's it. 00:11:23 but there is a slight problem in here 00:11:34 Quick put that in the wiki. 00:11:46 problem 00:12:06 somebody (not sure if task or gui), isn't waiting for the iocontroller -> (NML ack) -> emc 00:12:18 but instead it sends out the M6 NML message 00:12:24 so the Ack's get mixed 00:12:27 get my point? 00:12:37 hm, handling multiple ack 00:12:40 's? 00:13:00 isnt the ack's encoded as anything(contain identifiers) 00:13:15 Well the ack is really a status change NML and carries the thing it's changing with it. 00:14:22 I definately don't want to do that 00:14:22 looking who's sending the M6 before the time has come 00:14:40 yes.. but if there are 2 messages .. for which one is the status change? 00:14:52 I send RCS_DONE on one, and RCS_EXEC on the other 00:15:29 You are getting way past my understanding of these things. 00:16:03 I know.. I'm getting way past mine... 00:16:09 At Matt's this spring, I set up the tool changer on his Harding Lathe. 00:16:23 It was a tkio that I modified. 00:16:37 is it in cvs? 00:16:41 the modified one? 00:17:01 No. Only at his place. 00:17:26 when the interpreter got a txx it sent a tool prep message with the number. 00:17:45 I saved the number and sent a tool prepped status immediately. 00:18:16 Then when it got the tool-change it looked at the saved next tool number 00:18:23 and did the change. 00:18:41 when the change was completed it sent the tool-changed message. 00:18:45 ahh.. so you didn't do the tool-prep 00:18:50 just faked it 00:19:02 and did it during the tool-change instead 00:19:09 There is no way there it is a single too indexer table. 00:19:14 tool 00:19:16 I see 00:19:30 alex_joni: did you read what I wrote in #emc? 00:19:45 But I'm certain that if I had not sent the tool prepped message it would have stalled out on the tool change command. 00:20:00 I know... this is what I'm experiencing here 00:20:00 Where is that. 00:20:12 anonimasu: answered 00:35:09 sorry I wish I could help but I need to sleep 00:35:16 night all 00:35:34 Catch you later. Thanks for the help 00:35:47 night an0n 01:06:41 alex_joni: ioControl.cc is what you worked on this evening? 01:06:50 yes 01:07:05 Got it and will compile now. 01:07:14 and it works to the point that you need to tel commands finish before issuing new ones 01:07:25 issue Tx, wait for it to finish 01:07:27 then M6 01:07:41 make sure you get feedback from CL that tool-prepped 01:07:45 and tool-changed 01:08:39 Okay. 01:09:35 Then is ioControl.cc the place where we will have to test status of tool prepped and hold tool change until prepped is finished? 01:10:04 I'd have thought that was a task sort of thing. 01:11:48 well.. task does it actually 01:11:48 but iocontrol reports back that it's in RCS_EXEC state 01:11:48 not in RCS_DONE 01:20:40 okay. 01:36:50 YAY.. it seems to work now 01:50:09 Fantastic. 01:52:12 not fully though.. still needs some debuggin :((( 01:52:21 found some cases when it locks 02:27:34 ok.. figured out why, now to fix it 02:27:53 I simply know I'm gonna regret this tomorrow :D (it's almost 4am here) 02:30:47 tomorrow-- it's already tomorrow. 02:32:38 yeah :D 02:49:40 it should work as promised now 02:50:35 let me know how it works for you.. 02:51:17 * alex_joni is beat, and goes to bed 02:51:20 g'night 02:55:48 anonimasu has quit 02:56:01 alex_joni has left #emc-mazak 02:58:21 anonimasu has joined #emc-mazak 03:22:47 CNC_Workshop has quit 06:12:39 mshaver has quit 06:13:04 mshaver has joined #emc-mazak 06:27:27 mshaver has quit 06:27:51 mshaver has joined #emc-mazak 10:51:17 alex_joni has joined #emc-mazak 11:43:54 greetings.. anyone around? 15:12:10 alex_joni has quit 15:28:52 CNC_Workshop has joined #emc-mazak 16:35:06 Hi guys. 18:00:35 updated the mazaklog and mazakretro wiki pages 18:03:14 alex_joni has joined #emc-mazak 18:03:19 greetings 18:10:11 Hi alex 18:10:21 hey Ray 18:10:24 how's it going? 18:11:28 Good but then that is just my opinion. 18:11:41 heh, why is that? 18:11:59 Is their a way to re-read a .hal file while the system is running? 18:12:16 bin/halcmd -f < file.hal 18:12:30 Oh that will save time. 18:13:02 I find I'm working between mazak_rf.hal and classicladder a lot. 18:13:13 right 18:13:24 what happens if the file I try to read in fails? 18:13:31 nothing 18:13:42 it displays an error message 18:13:43 stays with the old? 18:13:47 yes 18:14:00 but also.. you can't load stuff over existing stuff 18:14:11 so if you have a signal already defined you can't load that again 18:14:27 you'll get errors that that signal is already defined 18:14:44 okay. I can live with that level of protection for now. 18:15:11 also.. on the first error it will bail out 18:17:55 Another question is there an easy way to show the details of something like the component iocontrol 18:18:18 sure.. what do you want? pins? 18:18:24 I usually do this: 18:18:34 watch --interval=0 bin/halcmd show pin iocontrol 18:18:37 pins are good. 18:18:46 you know watch, I think.. 18:18:57 No I don't 18:19:15 it repeats a message over and over again 18:19:16 repaints the result 18:19:28 watch --interval=0 18:19:34 just repeats the command as fast as it can 18:19:44 should update quite a few times / second 18:19:51 Okay. 18:20:07 you can run any command after watch 18:20:20 bin/halcmd show pin -> lists all pins in the system 18:20:31 k I see a bunch of stuff. 18:20:35 yup 18:20:58 there are some spindle related pins 18:21:04 some lube, coolant, brake 18:21:08 ah that is awesome. 18:21:12 also the tool-* you'd need 18:21:21 just like having a lot of halmeters 18:21:40 Fantastic. Thanks. 18:22:00 np 18:22:02 ;) 18:26:12 Ray, you there? 18:26:17 Now I can see what you are saying about waiting on tool prepare 18:26:24 Hi Matt. 18:26:43 Hey! Howsitgoin? 18:26:49 hello Matt 18:26:59 Hi Alex! 18:27:19 * fenn lurks 18:27:40 I see that the tkemc reset button does NOT reset these sorts of things. 18:27:59 tool prepare is still true. 18:28:17 I've seen a bunch of emc2 & HAL commits which look like a lot of progress has been made, practical stuff which is good. 18:28:18 Hi Ben 18:28:19 hmm.. tell me how it should be 18:28:43 CNC_Workshop: this stuff is new to emc, wasn't there in bpio or mini 18:28:54 so if you got requests, ideas.. let me know 18:28:57 I'm not certain how it should be. 18:29:08 It looks like you guys are in the middle of something, so I'll stay quiet for now... 18:29:20 This is a good topic with Matt. 18:29:24 mshaver: feel free to come up with ideas :) 18:29:27 here. 18:30:00 hmm, i'll have to read back a bit to see "ideas about what?" 18:30:04 Hey mshaver -- this stuff needs to be practical. I'm sitting at the machine it has to run. 18:30:27 I issued a t3 command a few seconds ago. 18:30:37 rubber, meet road. road, rubber... 18:31:00 CNC_Workshop: ok, and you should have seen 2 pins changing 18:31:09 iocontrol.0.tool-prepare (turned TRUE) 18:31:12 That gets picked up by iocontrol and it turns iocontrol.0.tool-prepare true 18:31:22 and iocontrol.0.tool-prep-number turned 3 18:31:28 iocontrol.0.tool-prep-number changes to 3 18:31:44 ok.. now it hangs there till iocontrol.0.tool-prepared will also turn TRUE 18:31:59 Now I press machine off, estop on, and it is still there. 18:32:06 if you look at Diagnostics (which was GREAT helplast night), you'll see that status is still there 18:32:12 and it shouldn't? 18:32:13 genau 18:32:28 * alex_joni wonders how it should be 18:32:50 estop should basicly reset tool-actions? 18:33:05 might leave the tool-arm in an unidentified position.. I don't know 18:33:10 I've seen lots of times where the status stuff retains the last batch of settings 18:33:15 :/ 18:33:40 This is really a high level issue. 18:34:04 don't get me wrong, I can reset it.. I just wonder what the proper way is.. 18:34:07 IMO reset ought to bring status a long way back to an initial startup condition. 18:34:19 inside Task you mean 18:34:33 also synched with IO of course 18:34:35 I understand that Alex. Yes in task exactly. 18:34:54 But there isn't enough in task to do all of that. 18:34:56 I think it even gets reset there.. 18:35:12 1. Estop needs to stop all motion immediately, including the TC. 2. This might leave the carosel in between positions, or the arm partway around. 18:35:23 right 18:35:28 Yes it does. 18:35:31 3. Do you "home" the TC? 18:35:31 what happens then matt? 18:35:58 It uses five prox switches -- think absolute encoder. 18:36:20 No home for it was rather far from my thinking. 18:36:35 However I do have a brief setup 18:36:40 brb 18:37:00 OK, so if emc comes up and the pattern of prox inputs is invalid, then you move the arm & carousel to get it in a known state? 18:37:29 that's part of the login in CL 18:37:31 or should be 18:37:53 CL logic starts, rotates the carousel (if it's safe), and locks to a position 18:38:10 So it's done when CL is initializing 18:38:17 during a tool change, CL gets a tool-number from emc, and rotates the carousel till the numbers match 18:38:30 it might get done at a later stage too 18:38:37 how about the arm? 18:38:44 afaik it's not done at all right now.. not sure 18:38:49 * alex_joni is miles away 18:38:59 a few thousand :) 18:39:15 latency is about 50 ms greater for you than for us 18:39:27 probably :) 18:39:28 * mshaver is too, but not that far 18:40:50 i dont have iocontrol.tool anything... is this stuff in cvs? 18:41:04 since last night 18:41:06 what i'm saying is that after an estop iocontrol.toolchanger(init) or whatever it's called needs to be run to make sure the position of the arm & carousel are known and valid 18:41:28 I see, I would do that at machine_on 18:41:34 now that you mention it 18:41:43 maybe wait on it? 18:41:48 yep, thats a good place for it 18:41:54 yes, wait 18:42:07 how about the most machines which don't have it? 18:42:10 got a show-and-tell going here. 18:42:16 maybe even time out with an error 18:42:19 show-and-tell us 18:42:26 we want a webcam! 18:42:30 :P 18:42:51 no, full immersion VR 18:43:02 right 18:43:09 i want java-enabled control of the mazak from my cellphone 18:43:31 activeX 18:43:32 we are great wanters... 18:43:48 fenn: btw, there is an emc ActiveX control :P 18:44:03 really? 18:44:30 so I've seen/heard 18:44:49 btw, had a conversation with steve stallings about puppy-emc, he seems to like the idea 18:44:57 who is cncuser? 18:45:05 "EMC Plug-in source demonstrates using an ActiveX component to talk to an EMC machine controller." 18:45:15 cncuser=some guy from austria 18:45:21 pretty new around here 18:45:41 some guy? 18:45:54 don't know more than that :/ 18:46:05 don't all you guys on that side of the world know each other? ;) 18:46:15 not really.. 18:46:25 same here... 18:46:54 mshaver: http://www.isd.mel.nist.gov/projects/omacapi/ (who else could do such weird stuff with emc) 18:47:47 i'll have to look at that 18:48:08 not very important.. just the ActiveX I mentioned 18:48:15 back to tool-changing stuff 18:48:33 so you guys say that on estop machine should go into a "safe state" 18:48:53 lube off? coolant off? spindle? toolchanger stopped... 18:49:19 brakes on servos 18:49:47 i wonder if estop would cause the Z to drop and then you have a following error when you start up again 18:49:49 that's not part of iocontrol 18:49:52 yep, all power is removed (electrical, pneumatic, mechanical) 18:50:33 which might leave things like the tool changer in a "part way there" state 18:50:53 axes aren't a problem since we can keep monitoring position 18:51:20 but things that go from prox to prox may be in between 18:51:58 what if you stored a variable containing the last state of the prox switches 18:52:18 so, when you come out of estop (i like "machine on" for this) you need to put things in a known state 18:52:40 fenn: no good, someone could manually move things 18:52:42 re-put? (I mean restore a saved configuration?) 18:53:15 well, an estop will abort the program 18:53:54 so, if the tool carousel is moved, it's not necessary to move it back to the pocket it was on, only to know where it is currently 18:54:19 you need to know if the arm is holding a tool though 18:54:40 if not, return it to the "out of the way" position 18:55:11 if it is (and the possibility exists that the carousel could have been rotated manually... 18:55:40 we need to be able to either put the tool back, or put it in the spindle, or something... 18:56:32 I'm back 18:56:40 reading 18:56:51 when we start up from a cold boot, do we assume that there's no tool held in the arm? 18:57:31 * anonimasu nods 18:58:57 i can't remember, is this a single tool arm, or a two tool arm (one held in each end, where they swap real quick) 18:59:16 like a Kitamura has... 18:59:33 they swap 19:00:25 how do you know which tool is in the spindle? 19:00:31 so you know where to put it back 19:00:42 I guess what i'm saying is that when you do a "machine on" the tool changer needs to be "synced" 19:00:54 assume ass of you and me? 19:01:07 :P 19:01:10 two arm tool changer. 19:01:33 fenn: I don't know, I think some systems either make you take it out manually & put it back, or it asks you a question 19:01:54 I'm tending to favor the ask the operator. 19:02:21 That will be a bitch to write 19:02:31 But there are so many variables. 19:02:38 when you do t1m06, what is the variable that contains the value of the old tool? 19:02:51 The tool holder does not carry with it any identifier. 19:02:53 You could say"Please remove all tools from the arm, and enter the tool # that's in the spindle. Use zero (0) for no tool." 19:03:36 Right. 19:03:52 Some of the conditions can be read from prox switches. 19:03:54 we could chicken out and say"Please remove all tools from the arm & spindle and put them back in the carousel. Press any key to continue...". 19:04:03 max pocket number 19:04:08 mag in psotiion 19:04:08 that needs further NML messages to pass this info through.. I think 19:04:24 transfer arm up or down or in between. 19:04:25 mshaver: like that approach :) 19:04:55 I've never run a machine with a tool changer, bit I can ask around to see how it's done. 19:05:09 With halcmd, many if not all of these things can be attacked from a tickle program. 19:06:07 ClassicLadder could handle a lot of reset but there is little chance for human intervention. 19:06:13 calling a friend now... 19:06:44 jmk, alex and I spent some time thinking about what we called runlevels. 19:06:57 mostly jmk & ray 19:07:05 using the obvious example 19:07:17 Right now we have two. 19:07:23 estop off and machine on 19:07:54 We were proposing levels of startup or restart up 19:08:25 and like linux, they would have identifiable, configurable elements 19:08:37 just talked to a buddy who has seen this 19:08:55 Estop would drop you very near the lowest level 19:10:04 restore to running condition could have stuff ranging from automatic do it to "ive got a big jsck up here" 19:10:14 fsck up 19:10:35 mshaver: where? 19:10:36 he said that what you're supposed to do (if you estop in the middle of a tool change) is to remove all tools from the arm & spindle manually, then manually move the arm back to it's home position, and manually rotate the carousel to a pocket position, THEN turn on the machine 19:10:52 ok 19:11:06 Mazak has a page for just such stuff. 19:11:38 With the runlevels notion, it would not move to the next until the preconditions had been met. 19:11:40 CNC_Workshop: My buddy Keving who was a formean in a shop with Haas, Fadal, & some japanese machines 19:12:22 That is the kind of experience we need as we think through revision. 19:12:27 heh, "formean". i meant foreman 19:12:34 although.... 19:12:39 either works 19:12:49 ;) 19:12:50 seen both 19:13:00 me too 19:13:50 I really like the idea of check lists and check boxes for this sort of configuration. 19:14:15 unless there are sensors that tell the machine that a tool is in the spindle or arm, and that a certain pocket is empty, we need the operator to have some brains 19:14:16 * alex_joni already sees tickle all over the place 19:14:29 darn alex. I really like watch. 19:14:55 mshaver: and it that case I think it's the best to tell the operator to remove all tools from the arm 19:15:06 should be ok with any brains he posesses 19:15:16 you could move the Z up and down really quick and calculate the moment of inertia, and see if there's any extra mass in the spindle :) 19:15:47 uh.... yes you could. 19:15:50 yeah, or maybe figure out that those gas-dampeners don't have pressure in them 19:15:54 yep, that's a good idea (Alex's idea that is) 19:15:56 and you just boiled your motor :) 19:16:20 * alex_joni has too many ideas... 19:16:25 which one do you mean? :D 19:16:38 ask the operator to remove all tools 19:16:50 right.. seems like the way to go on decision processes 19:17:24 it's more likely to work out ok (a lot more likely than the user beeing able to identify tool number and the such) 19:17:29 CL can make sure that the arm is home and the carousel is on a station 19:17:35 perhaps you should save a "in the middle of a toolchange" variable so that you dont accidentally start it up and slam some tools together 19:17:39 CL won't move if it's not 19:17:58 fenn: no need to 19:18:02 classicladder (as like any PLC) won't work if conditions aren't met 19:18:18 so it would simply hang there till the initial conditions are met 19:18:18 :9 19:18:27 or until the action times out ;) 19:18:30 and throws a error 19:18:38 CL has no timers yet 19:18:46 :/ 19:18:57 but it doesnt know if there's a tool in the arm so you're relying on the (unreliable, faulty human) to remove the tool 19:19:16 so, as it is now, if something blocks the arm for example, it just sits forever 19:19:33 yup.. but a lot better than relying on the faulty human to tell you that it's tool #3 in the arm 19:19:41 *yeah 19:19:55 in a nice world the plc would know what tool is and where.. 19:20:09 fenn: without sensors, there's nothing else to do, there will never be "CNC for Dummies" 19:20:22 anonimasu: they make toolholders with RFI chips in them 19:20:23 yeah, maybe RFID tags on the tools :) 19:20:34 fenn: yeah but the price ;) 19:20:58 or even smarter chips inside, could tell you how many hours the tool has worked, if it's still ok, if the TCP has changed, etc 19:21:00 the problem is that even storing variables doesn't help if someone changes things manually while the machine is off 19:21:06 but that's mostly wishfull thinking :) 19:21:24 mshaver: I see the easiest approach like this: 19:21:28 mshaver: you cant counter that . 19:21:37 there is a certain sequence to be followed at start up 19:21:49 because the initial conditions are given 19:21:53 mshaver: whoever that moves tools around on estop are a fool.. and will probably break stuff.. 19:22:10 I say: on estop-go back to initial conditions (and tell the user to replicate those on external devices) 19:22:31 would it be impossible to check if all tools are in the magazine? 19:22:53 to check of all tool pockets are empty on startp? 19:22:59 err if any 19:23:05