00:10:40 did you replace the worn-down dog? 00:12:51 Not yet. We filed out the gouges and used the largest sides. 00:13:14 I think that I'll leave those sorts of things for roland. 03:09:18 Damn the tool mag prox's are binary coded to decimal 12 03:09:57 13 is 00001 03:10:14 and then they add using binary to 24. 03:12:20 it's missing a bit? 03:12:33 er, a nibble 03:13:03 nevermind, brain fog 03:14:32 wierd 03:14:42 not you. 03:14:52 the engineer that put it together. 03:15:43 there are 24 tools? 03:15:53 what is 1? 03:16:53 Have to use this formula assuming that the prox switches are named pos0 through pos5 03:17:37 jmkasunich has joined #emc-mazak 03:18:30 hey ray! 03:18:31 (pos0*1)+(pos1*2)+(pos2*4)+(pos3*8)+(pos4*13) 03:19:38 I'd be willing to bet that there was a design issue with the fanuc control. 03:19:53 Hi John. You made it home okay. 03:19:59 yep 03:20:20 I'm looking at the magazine switches. 03:20:48 trying to convert them to an integer? 03:21:42 yep 03:22:02 I don't think HAL has a block to do that 03:22:10 dunno if CL can do math, I think it can 03:22:25 alex said he though it would be simpler to just make a new hal block than to try to do it in ladder 03:22:28 if needed I could write a bits-to-int hal component pretty easily 03:22:28 I just thought it was really strange that bit five is a 13. 03:22:44 yea 03:22:53 thats how it works out though? 03:23:14 What do you think about the tool prep NMLmessage handling. 03:23:54 that message sends an interger tool number. 03:24:18 the toolchanger needs to rotate the magazine to that position, right? 03:24:28 I'm thinking it may be easier to handle the whole magazine rotation using hal 03:24:50 deciding which way to turn, etc, might be easier to code in C as a HAL component 03:25:09 Seems like it would be. 03:25:46 call the component an indexer, give it two integer inputs, one a command, one a feedback, and two bit outputs, one forward, one reverse 03:26:10 and an in position. 03:26:38 yeah 03:26:59 Can you do that without to much trouble? 03:27:05 did you get all the solenoids working? 03:27:09 I think so 03:27:16 Yes 03:27:24 and the prox switches as well. 03:27:27 cool 03:27:38 I've got the prox signals defined in .hal here. 03:27:40 what was the prob with the soleniods? just misconneced wires 03:27:43 ? 03:27:49 yep. 03:28:06 and a couple had garbage between the ssr and the coil 03:28:38 I have done a tool change by using a tickle set of buttons. 03:28:50 It's a real bitch though. 03:29:19 If we can get the indexer I can write the cl for tool change 03:29:44 I'll see what I can come up with, and commit it 03:29:49 you gonna be there tomorrow? 03:29:55 Yep 03:31:25 ok, it will likely take an hour or two to cook up an indexer 03:31:30 we actually need two things 03:31:41 one takes a collection of bits and turns them into an int 03:31:58 the other takes 2 ints and decides which way to rotate 03:32:29 bitz->int = multiplexer? 03:32:48 not really 03:33:17 It would be more flexible if we assigned a parameter to each bit. 03:33:19 more like out = bit0 + 2*bint1 + 48*int2, etc 03:33:31 a weight, like 2, 4, 8, 13? 03:33:44 That is what I was thinking. 03:34:06 it could be even more complex if they used gray code or something 03:34:06 I suspect that there are changers out there that don't conform to any sort of binary math. 03:34:17 But at least we can say we tried. 03:34:26 looking at the Mazak hole pattern I kinda thought it might be gray 03:34:42 but you've confirmed that it is binary? (except for the 13) 03:35:25 Well I hit 14 of the pockets and read their proximity switches. 03:35:42 but not all 25 yet 03:36:00 no. it's hit and miss right now. 03:36:08 press rotate press stop 03:36:22 seems you need a "rotate by one" 03:36:34 that could be done in a ladder rung or two 03:36:42 isn't there a "in position" sensor? 03:36:51 Yes I do but we can do that in cl, i think 03:37:02 yes there is 03:37:05 exactly 03:37:17 just thought doing it sooner than later would make things easier 03:37:29 You bet it would. 03:37:39 they have a "rising edge" contact don't they? 03:37:46 Got one of those in a back pocket. 03:37:55 yes rising is good. 03:38:30 ---|/\|--------------------------------------(fwd)----- 03:38:49 ----|fwd|------|/inpos|--------------+ 03:39:24 rising edge on the command starts it moving, and it latches until it reaches the next pocket 03:39:32 another one for reverse 03:39:44 let me commit my .hal so you can see what I've done 03:39:48 OK 03:41:29 it's there. 03:41:52 * jmkasunich fetches 03:41:59 I'll need to link the signals into cl 03:42:59 is that a linkps like the two at the top of the cl section. 03:43:33 yeah 03:43:40 oh i see you've got nine there now. 03:43:41 linkps = link pin to signa; 03:43:58 the pin is the CL pin, I8, Q3, etc 03:44:07 and in classic ladder an i## is a pin? 03:44:12 yeah 03:44:21 Inn are inputs to CL, Qnn are outputs 03:44:37 the number of each is determined when the CL module is insmoded 03:44:39 okay. 03:44:45 go up to the top of the file 03:44:49 I see that. 03:44:56 line 88 03:45:04 extra doesn't hurt while testing? 03:45:17 that where you spec how much "stuff" your ladder will have 03:45:20 nope 03:45:31 at some point might run out of HAL memory 03:46:51 bin/halcmd status mem will tell you your memory situation 03:49:43 added magazine-in-position 03:49:53 the sensor? 03:50:09 Now we need something to tell it to rotate. 03:50:27 I was considering a lookup table for the bits to int translator 03:50:36 that would allow arbitrary bit patterns 03:50:52 Oh that would work even better that hokey math. 03:50:58 tradeoff is potentially confusing config data 03:51:11 you'd have to specify the bit pattern for each slot 03:51:17 something like: 03:51:29 sure but it could be read in from a table 03:51:43 slot0=0x01 slot1=0x02 slot3=0x23 03:51:47 etc, etc 03:52:08 why would you do it in hex? 03:52:28 surely it's less error prone to just look at the prox switches and input 01011 etc 03:52:29 could do it in binary 03:53:14 something like 01011=23 03:53:29 remember this is all in kernel modules 03:53:44 they can't read files, and have limited ability to get data from the insmod command line 03:53:57 * CNC_Workshop knows nothing of kernel modules. 03:54:08 all realtime code lives in kernel modules 03:54:24 HAL hides that nastyness, you just say loadrt and the hal component gets loaded 03:54:38 but there are limits to the amount of data that can be passed to a hal comp 03:55:30 Perhaps you'd be better off writing this one now and attempt a generalization later. 03:55:50 might be something to that idea ;-) 03:56:04 one generalization possibility: 03:56:32 this mouse died! brb 03:57:35 at load time, you specify the number of input bits, the number of slots, and whether it is linear or rotary (IOW, whether you can go "up" from max and get back to zero (think turret) or whether you need to go down (think long linear rack of tools, can't wrap around) 03:57:37 give me a clue regarding root passwd on this box. 03:58:09 try roland 03:58:41 or maybe cardinal 03:59:17 i thought you wanted to do it as two separate components 03:59:23 CNC_Workshop has quit 03:59:38 a lookup table/bittoint component and an "indexer" comopnent 03:59:40 so did I, but I think I'm changing my mind 04:00:04 one prob with the lookup is that the prox's are only valid when you are at a slot 04:00:13 CNC_Workshop has joined #emc-mazak 04:00:25 I'm back. 04:00:27 the lookup component won't know that, so it will output zero whenever it is between slots 04:00:32 pw ok? 04:00:51 have an enable input on the lookup component? 04:01:02 with latching output 04:01:07 possible 04:01:16 or maybe have the enable on the indexer component 04:01:33 that makes more sense 04:01:36 Do I start cl using bin/classicladder while emc is running? 04:01:42 yeah 04:01:45 k 04:01:56 or just implement the indexer in CL 04:02:16 don't know how (or if) CL handles things bigger than bits (like tool numbers) 04:02:23 if it can, that would be the way to go 04:02:44 easier to tweak for different machines 04:02:51 i think it would have to understand numbers in order to do temp. control and stuff 04:03:07 maybe your hal module doesnt do that though 04:03:30 documentation for CL is sorely lacking 04:03:40 basically you have to experiment with it 04:05:53 hmmm, there are operations on word vars 04:05:56 cl said the latest release included a manual but I didn't see anything. 04:06:00 cl supports " Compare of arithmetic expressions (since v0.4)" what does that mean? 04:06:02 COMPARE and OPERATE 04:06:11 http://membres.lycos.fr/mavati/classicladder/ 04:06:34 scroll down to "version 0.5.3 snapshot with the new vertical scrollbar" 04:06:44 look a the middle rung 04:08:32 anyway, thinking about a "bit to int" hal comp 04:08:58 insmod params: number of bit input pins, number of int values 04:09:08 for each int value, it would export a param 04:09:14 you would setp the params 04:09:19 for instance: 04:09:36 setp bit2int.0.pattern0 0x00 04:09:51 setp bit2int.0.pattern1 0x30 04:09:53 etc 04:10:13 using hex because (I think) halcmd can already parse it 04:10:26 setp bit2int.0.pattern13 0x01 ? 04:10:43 there would be 25 patterns for this machine 04:10:52 one for each slot 04:11:10 sorry i dont know what the actual slot patterns are 04:11:19 there are 5 prox switches 04:11:32 for each slot, there is a unique pattern of switches on and off 04:12:06 can you fit that many arguments on an insmod line though? 04:12:09 pseudo binary (but not quite, instead of the last bit having a weight of 16, it seems to be 13 04:12:14 that's the point, you don't 04:12:24 insmod just says how many input bits and how many patterns 04:12:38 the patterns themselves are HAL parameters and are set after insmod 04:12:48 Ah and then the patters are set in .hal 04:12:49 excuse my ignorance, how does HAL get the parameters to the kernel modules? 04:13:04 halcmd setp 04:13:06 Okay. That sounds good. 04:13:25 params are variables in shared memory? 04:13:29 yes 04:13:32 ok 04:13:39 the actual mechanism involves the shmem 04:14:02 pins params and sigs all live in shmem so halcmd can manipulate them 04:15:20 hmm... it's easy to write a module that implements one of these bit-to-int translators 04:15:34 not so pretty if you allow more than one (all other hal components do that) 04:16:37 using the insmod command line for hal block config just plain sucks, but for now it's all we got 04:19:49 is the problem with more than one lookup table where to store the second table? 04:20:17 how to tell the module the info about the second table (number of inputs and number of values) 04:20:35 the concept also doesn't scale to large numbers of values 04:20:53 if you wanted to take 10 bits and turn them into a 10bit int, you would have 1024 pattern parameters 04:21:08 that would put a serious dent in the HAL shmem space 04:21:33 this really wants to get it's info from a file 04:21:45 I wonder - could this be a non-RT component instead? 04:22:04 that would really limit its utility 04:22:49 i dont think there's any way around a 10bit lookup table being huge 04:23:09 a 10bit bit-to-int would be simple though 04:23:22 how so? 04:23:40 it is indeed simple if the bits follow a pattern, like straight binary 04:23:46 yeah 04:23:55 yes if we assumed a binary patter or gray or whatever. 04:23:56 then the lookup table is unneeded (and a royal pain in the a$$) 04:24:04 that's what i mean 04:24:12 You just about have to build the math into the mod. 04:24:23 the LUT is only needed when you have strange patterns, like bit N having a weight of 13 04:24:34 Right. 04:25:02 right, and if you have a strange pattern at high resolution, it's always gonna take up lots of memory or require its own algorithm 04:25:36 the thing is, "lots" depends on contect 04:25:47 how big is shmem? 04:25:53 in a file, or a user space program, even thousands of patterns is no big deal 04:26:02 but defining a HAL param for every one gets nasty fast 04:26:06 ~64K 04:26:18 each parameter takes about 40 bytes, mostly for the parameter name 04:27:10 * jmkasunich wonders if the patterns could be slipped into the .tbl file without messing up the rest of EMC? 04:27:20 aside -- do I need more than magazine-in-position and magazine-forward in .hal connected to cl in order to bump the mag by one? 04:27:23 probably not a good idea 04:27:38 I don't think so 04:27:47 you'll need a command signal of course 04:27:55 rising edge on command = move by one 04:28:02 Can I trigger that from cl itself? 04:28:21 dunno if CL has a "set bit" command 04:28:39 I would create a signal called forward-one or something 04:28:40 How would I do that from hal 04:29:01 link it to classicladder.0.in-whatever 04:29:02 newsig and just not link it to io 04:29:11 then do bin/halcmd sets forward-one 1 04:29:26 okay. 04:30:30 * jmkasunich is very tempted to do the indexing in user space 04:30:50 how would that fit into the overall scheme of EMC? 04:31:34 hmmmm, that brings up a point 04:32:00 it doesn't look like iocontrol.cc exports any hal stuff for toolchanger 04:32:49 I see estop, coolant, lube, spindle, no tool 04:33:48 yeah, it fakes it 04:34:08 TOOL_PREPARE immediately returns success 04:34:23 as does TOOL_LOAD 04:35:41 yup 04:35:51 this is messy 04:36:30 seems like toolchanging involves at least three steps (maybe more) 04:36:39 1) fetch a tool (can be done ahead of time) 04:37:02 2) remove old tool from the spindle, stick new one in (must be done with spindle stopped) 04:37:12 3) store old tool (can be done after cutting resumes) 04:37:34 yup 04:37:49 with special cases where there was no old tool, and maybe others 04:38:01 other machines may reverse the process 04:38:36 you are wanting to get rid of some nml messages related to tool loading? 04:38:36 I can imagine one where you must first put the old tool back in it's empty slot, then index to the new tool and load it 04:39:02 heck no... /me doesn't touch NML messages unless truly desperate\ 04:39:38 ray: what do you know about the sequence of NML messages 04:39:43 the ones of interest are: 04:39:56 TOOL_PREPARE 04:40:07 TOOL_LOAD 04:40:12 TOOL_UNLOAD 04:40:32 and maybe TOOL_SET_OFFSET 04:40:52 does the last get executed on each toolchange, or are they used to set the values in the .tbl file? 04:42:12 I know PREP comes first - is there always a PREP message, or can you get a LOAD(n) without a PREP(n) first (where N is the tool number) 04:42:20 i think TOOL_SET_OFFSET is used to pass data from the .tbl file to someone else, maybe motion? 04:42:51 does UNLOAD precede LOAD? or is UNLOAD only used when the goal is to leave the spindle empty? 04:42:57 tool prepare is the one that will initially swing the magazine. 04:43:08 It comes with the numbe of the next tool 04:43:36 tool set offset is only used when commanded with a g43 04:44:06 or g41 or some such in the part file 04:44:11 ick 04:44:14 looks like LOAD doesn't come with a tool number? it uses the number from the preceeding PREP message? 04:44:24 Yes. 04:44:38 It is just a progrm marker that says do it now. 04:44:57 I've got no clue about unload. 04:45:16 that means a LOAD is always preceeded by a PREP, even on machines that can't do anything ahead of time (and in g-code programs that don't give EMC any clues about the next tool until they actually need it) 04:45:37 We will need to add the tool change position variable in the ini so that 04:46:03 task causes that motion just before tool load 04:46:23 yeah, gotta get that spindle retracted 04:46:48 Well the txx message is read during look ahead so a couple hundred lines can come between 04:46:53 damn 04:46:55 even if they are on the same line. 04:47:08 getting late here (I told my wife I'd come to bed an hour ago) 04:47:21 oh, I see 04:47:21 Then you better get there. 04:47:28 catch you tomorrow. 04:47:41 so Txx generates the prep and the load, even tho its only one line, because of lookahead 04:47:43 I've got to find something to eat. 04:47:51 Yes. 04:48:13 I'll think on this, email my thoughts tomorrow 04:48:17 k 04:48:24 thanks for all the work guys. 04:48:31 you're welcome 04:48:55 CNC_Workshop has quit 04:48:57 night all 04:48:59 jmkasunich has left #emc-mazak 08:35:44 alex_joni has joined #emc-mazak 08:35:48 morning guys 08:35:53 rayh: around? 14:48:38 just got here 14:48:46 Hi alex. 14:51:37 alex_joni has quit 15:28:17 CNC_Workshop has joined #emc-mazak 16:29:48 rayh is now known as rayh-away 16:57:39 got ladder rotating the magazine one pocket at a time. 16:58:49 Now we can wire in and setup the door switches for tool loading 18:16:27 rayh-away has quit 18:42:00 alex_joni has joined #emc-mazak 18:42:07 greetings 18:47:58 Hi alex 18:48:03 hello 18:48:07 just reading on the logs 18:48:17 sorry about yesterday evening :) 18:48:19 Getting started on cl and tool change stuff. 18:48:32 got home and fell asleep (about 6PM), woke up this morning :) 18:48:53 No problem. I got on with jmk for a few minutes, 18:49:06 reading that now 18:49:27 does iocontrol pass the tool prep command and tool number to HAL? 18:50:38 not yet, but that I can do 18:50:47 as soon as I figure out under what form it is neede 18:50:49 needed 18:53:59 ok.. back 18:54:28 I mean, finished reading 18:56:21 What does a signal out from EMC look like in .hal 18:56:50 Like flood coolant for example? 18:56:54 yes 18:56:57 it can be 18:57:10 depends on how it's done. but basicly what you need can be exported 18:57:23 even a bit (like coolant), or a float (like spindle-speed) 18:57:27 or any inbetween 18:58:33 Okay. So tool-prepare could be set by emc in HAL 18:58:39 thinking about the whole tool-changing, I see a lot of signals 18:58:47 lets take em one by one 18:58:48 and the numbe of the tool could be an int. 18:58:51 1. tool-prepare 18:59:12 that would require : tool number (as you said int) 18:59:18 I'm going to keep many of them between hal's io and cl. 18:59:43 iocontrol.0.tool-prepare (output to HAL, tells HAL that tool needs to get prepared) 19:00:02 iocontrol.0.tool-number-prep (tool number that needs to get prepared) 19:00:14 That's it exactly. 19:00:23 iocontrol.0.tool-prepared (input from HAL, tells that the tool has been prepared) 19:00:27 Then we will need a change-tool-now 19:00:39 last one will generate the NML message to ack the tool-prep 19:00:44 then we go to step 2 19:00:47 2. tool-change 19:01:11 Oh right. the tool prepared message generates a status change ini EMC. 19:01:21 in emc 19:01:33 iocontrol.0.tool-extract (output to HAL, tells HAL that machine is in position and tool needs to be extracted) 19:02:09 iocontrol.0.tool-extracted (input from HAL, tells iocontrol that tool has been extracted) 19:02:33 On the emc end we get the following sequence. 19:02:43 prepare tool # xx 19:02:48 iocontrol.0.tool-load (output to HAL, tells HAL new tool needs loading, the number is still in iocontrol.0.tool-number) 19:03:00 emc gets a tool prepared reply. 19:03:18 iocontrol.0.tool-loaded (input from HAL, tells emc tool loaded) 19:03:29 emc sees the change tool canonical command 19:03:35 not sure if tool-extract shouldn't be handled only in HAL (no feedback to emc) 19:03:43 moves to ini file's tool change position 19:03:54 issues an IO command to change tool. 19:04:10 get's a reply that says tool change completed. 19:04:12 I hope that part is done already :) 19:04:22 the move to tool change position 19:04:37 Yes it is. I've tested that several times. 19:04:52 coo (really wouldn't have wanted to touch that :D) 19:04:57 If it is in the ini, the machine will move. 19:05:15 Fred P did it for me a couple years ago. 19:05:24 can we add this to the wiki? http://emc.sourceforge.net/cgi-bin/emcinfo.pl?ToolChangerImplementation 19:05:30 some parts are already there 19:06:03 Certainly. I'll try to attack that page after lunch. 19:06:20 ok.. what's your time-schedule? 19:06:25 it's 20:24 here now 19:07:04 I have about 3 hours to spare (_more_ or less) 19:07:50 there is a wiki page for mazak tool change. 19:08:07 I'll grab a bite and be back in about 20 minutes. 19:08:40 ok.. sounds like a plan 19:08:52 I'll see if I can put the logic stuff from toolchangerimplementation into the front of mazak tool 19:08:55 but that mazak_tool_change page is bogus to me :) 19:09:02 right :) 19:09:09 Why is that? 19:09:28 * alex_joni doesn't care about Tool Transfer Arm Solenoid and Limit Switch Table 19:09:39 only detail for a single machine --- right. 19:09:40 I care about the flow of the tool changing 19:09:56 so ToolCHangerImplementation is a lot more interesting :) 19:10:15 Perhaps the general logic of emc's tool change stuff is rightfully in the other page with a link to the specific example. 19:10:25 Got it. 19:10:47 sounds ok to me too, go get smthg to eat.. will think about it till then 19:10:57 catch you later (going away for a bit too) 19:11:07