Back
[00:25:12] <jepler> BigJohnT: better to use "_" instead of " " (space) in cross references, for the sake of cut&paste URLs to individual sections
[00:49:48] <BigJohnT> ok
[00:52:26] <BigJohnT> jepler: is there some place you noticed the space in the cross references?
[01:56:45] <jepler> http://linuxcnc.org/docs/devel/html/gcode_main.html#G10 L1 Set Tool Table
[01:56:48] <jepler> oops, missed him
[01:57:10] <jepler> jmkasunich: did you figure out what you needed with halcmd completion? or can I lend a hand now?
[01:57:34] <SWPadnos> heh - completion was easy - that was the first commit last night :)
[01:57:38] <jepler> oh ok
[01:57:51] <SWPadnos> good job on the framework by the way - it was easier than I thought
[01:57:57] <jepler> neat, glad to hear it
[01:58:09] <SWPadnos> I'm about to add the actual command handler
[01:58:15] <SWPadnos> (s)
[01:58:32] <jmkasunich> I'm gonna work on the hal_lib side, once I stop gabbing
[01:59:25] <SWPadnos> heh
[02:02:12] <jmkasunich> on the hal_lib alias api - I think I'm just gonna have one call
[02:02:27] <jmkasunich> well, 2, pin and param
[02:02:41] <jmkasunich> hal_alias_pin(char *old_name, char *new_name)
[02:02:52] <jmkasunich> if new_name is null, it removes any existing alias
[02:03:10] <SWPadnos> ok, so an unalias command can just call it the right way
[02:03:12] <jmkasunich> old_name will match either the original name OR an existing alias
[02:03:17] <jmkasunich> yes
[02:06:32] <jepler> oh phew -- for a moment I read "pin and signal" when jmkasunich wrote "pin and param", and was trying to imagine why you'd want signal alises
[02:06:35] <jepler> aliases
[02:07:07] <jmkasunich> so if you don't like the first name you picked out, you can pick out a better one!
[02:08:02] <SWPadnos> hmmm. so there's an owner pointer in the alias list, right?
[02:10:13] <SWPadnos> jepler, do you recall if the regex library lets you do substring replacement? (ie, does it have functions that will retain the matched subexpressions)
[02:10:16] <jmkasunich> yes
[02:10:34] <SWPadnos> ok, cool. I kind of remembered talking about it after I typed in the question
[02:10:47] <jmkasunich> I was answering your first question...
[02:11:03] <jmkasunich> don't know nuttin' bout no regex
[02:11:12] <SWPadnos> yeah, I figured that :)
[02:11:36] <jmkasunich> the owner pointer will be needed for "show alias", if nothing else
[02:11:59] <SWPadnos> yep
[02:12:00] <jepler> SWPadnos: not sure
[02:12:06] <SWPadnos> that's what I was thinking about
[02:12:18] <jepler> did I use a regular expression library?
[02:12:34] <SWPadnos> err, maybe it was just the completion/readline lib
[02:12:50] <jepler> I use "fnmatch", which is shell patterns not regular expressions
[02:12:57] <SWPadnos> but you can do stuff like show pin "ppmc*invert"
[02:13:02] <SWPadnos> ah, ok
[02:13:17] <SWPadnos> so the answer is no then :)
[02:13:22] <jepler> shell patterns make more sense for that IMO -- ppmc.*invert is worse
[02:13:35] <SWPadnos> true
[02:13:39] <jepler> it looks like the posix regex library doesn't have a "substitute" function
[02:13:54] <SWPadnos> I was thinking that the alias command (and others, like net) should reject names that have wildcards in them
[02:14:02] <jepler> oh
[02:14:03] <SWPadnos> but I see that the existing commands don't
[02:14:05] <jepler> nothing else does that yet
[02:14:33] <jmkasunich> "setp something* 1" probably doesn't set multiple pins
[02:14:41] <SWPadnos> my reasoning (flawed, again) was that it would be nice to be able to alias ppmc.0* card1.*
[02:14:54] <SWPadnos> or alias pins and params with the same "base name" at the same time
[02:15:14] <SWPadnos> (so stuff like -invert and -in-not come along with the pin)
[02:15:22] <jmkasunich> so you could alias the .in and .in-not pins at the same time
[02:15:26] <jmkasunich> * jmkasunich types slow
[02:15:34] <jepler> SWPadnos: yeah that might be commonly desired
[02:15:34] <SWPadnos> heh
[02:15:53] <jepler> I don't think there's a common library function to do it, though
[02:15:56] <jmkasunich> * jmkasunich works on the function api, which only has to handle one ;-)
[02:16:15] <SWPadnos> but since the existing framework is 99.9% not suited for it, I'll drop the subject until it comes to me as a flash of inspiration again (or someone notices this log)
[02:16:26] <jepler> alias -prefix ppmc.0 card1
[02:16:38] <SWPadnos> sure, that would be cool
[02:16:48] <jepler> it seems like this is most often going to make sense when you want to specify the initial part and leave the final part unchanged
[02:16:49] <jmkasunich> except that nothing is really a prefix
[02:16:58] <SWPadnos> I imagine the full regex libraries will help with that
[02:17:01] <jmkasunich> the use of . to separate parts of a name is merely a convention
[02:17:16] <jepler> except then we have two kinds of patterns, shell and regex
[02:17:17] <SWPadnos> but it's not worth it IMO (at this point anyway)
[02:17:20] <SWPadnos> yep
[02:17:43] <jepler> and users will have trouble with how to actually do it, e.g.: alias -re ppmc.0.\(.\) card1.\1
[02:17:55] <SWPadnos> and there's no $(1) in shell (or whatever it's like in regex) for matched strings
[02:17:57] <SWPadnos> heh
[02:18:05] <jmkasunich> how about a limited (but usefull) case - the * is allowed only at the end
[02:18:05] <SWPadnos> explain that to - err - certain people :)
[02:18:24] <jepler> jmkasunich: sure, that's the same as what my "-prefix" would do
[02:18:25] <SWPadnos> hmmm
[02:18:30] <jmkasunich> it isn't hard to remove all matching text at the beginning, then copy over the rest
[02:18:32] <jepler> I mean, same effect as what I was proposing
[02:18:35] <SWPadnos> yep
[02:19:04] <jmkasunich> jepler: I had a duh moment, and thought that prefix was doing something like "replace up to the first ."
[02:19:25] <SWPadnos> before, after - what's the difference?
[02:19:59] <jmkasunich> SWPadnos: ?
[02:20:10] <SWPadnos> it replaces after the first ..., not before
[02:20:22] <SWPadnos> oh - I missed the "."
[02:20:58] <jepler> (er, my -re example is wrong in several ways if that's what we're talking about)
[02:21:03] <SWPadnos> nope
[02:21:13] <SWPadnos> I think we're talking about the -the prefix example
[02:21:15] <jmkasunich> I agree that full re will just confuse people
[02:21:17] <SWPadnos> -the
[02:21:18] <jmkasunich> (including me)
[02:21:47] <SWPadnos> we could always shell out to sed
[02:21:51] <jmkasunich> I don't think you need the word prefix tho, just allow a * at the end (and only at the end)
[02:22:18] <jepler> jmkasunich: yeah I agree
[02:22:26] <jmkasunich> actually, there are other ways to attack some of the cases that will generate long alias lists
[02:22:37] <SWPadnos> list alias | sed /blah blah/yadda yadda/g >alias_names
[02:22:49] <jepler> so if the first arg has "*" anywhere but the end, it's an error. If it has "*" as the last error, it goes into this "rename many" mode.
[02:23:11] <jmkasunich> while I was walking the dog last night I was envisioning a user space util, python or such, where you tell it "I have a 5i20, on cable 1 there is a 7i33, on cable 2, there is a 7i37", and it spits out a .hal file full of alias commands
[02:23:27] <jmkasunich> that translate from 0-71 pin numbers, to the numbers found on the 7ixx boards
[02:24:13] <SWPadnos> or to actual names like "saddle.PWM.value"
[02:24:28] <jmkasunich> that would require more user input, but sure
[02:24:31] <SWPadnos> yep
[02:25:19] <jmkasunich> that util could do other handy things too
[02:26:30] <jmkasunich> for instance, if you tell it you have a 7i33, generate other boilerplate hal code, like setp -invert if that is needed on an enable pin
[02:26:33] <jepler> just needs a tweak to the 'source' command to read the output of any unix command: source |hm2_renamer hm2_5i20.0 p2 7i33
[02:26:52] <jmkasunich> I was thinking of the renamer as something that you'd run once
[02:26:57] <jepler> why?
[02:27:03] <jmkasunich> why not?
[02:27:09] <jepler> ooh stalemate
[02:27:14] <SWPadnos> since it can make a HAL file, it shouldn't be necessary to run it often
[02:27:27] <jepler> because "source |" turns on this old unix-head?
[02:27:56] <jmkasunich> the util could concievably be a gui thing like stepgen - something that interacts with the user
[02:27:56] <SWPadnos> actually, depending on the driver, it could be useful to do it on the fly
[02:28:06] <jmkasunich> I'm not opposed to improving source....
[02:28:24] <SWPadnos> you blow up a pin and need to move the daughtercard to another connector, so change a couple of numbers and you're running again
[02:28:47] <SWPadnos> (firmware-permitting, of course)
[02:29:37] <jmkasunich> oops, I meant stepconf, not stepgen a few lines ago
[02:29:45] <jepler> I read it as stepconf
[02:29:51] <SWPadnos> heh, funny. I read stepconf too :)
[02:30:04] <SWPadnos> IRC channeling
[02:30:20] <jmkasunich> context sensitive spellchecking
[02:31:43] <jepler> I volunteer to write the "*" handling for alias when it gets to that point
[02:31:54] <jepler> but maybe SWPadnos will continue to be on fire for this little project
[02:31:57] <jepler> and that's OK too
[02:32:01] <SWPadnos> heh
[02:32:19] <SWPadnos> I'll be happy to get the command in there for now
[02:32:53] <SWPadnos> strangely I'm now dealing with several jobs for 3 clients (with 3 others waiting for me)
[02:32:58] <SWPadnos> which is a good thing
[02:34:57] <cradek> yay for hm2
[02:35:00] <cradek> yay for the upcoming alias
[02:35:06] <cradek> * cradek <- easily excited
[02:35:07] <jmkasunich> lathe working good?
[02:35:10] <cradek> yes
[02:35:27] <cradek> Z has lost its tune a bit, it occasionally goes over .001 ferror on rapids - probably all my new caps settling
[02:35:38] <cradek> so I'm going to dink with it a bit
[02:35:56] <cradek> but it's a nice machine, and emc works great
[02:36:39] <jepler> so as soon as we finish this alias thing we can release emc 3.0, right?
[02:36:47] <jmkasunich> 2.3 maybe
[02:36:49] <jepler> "emc 3.0: it's got a lot of little stuff -- look how big that list is"
[02:36:53] <cradek> surely you mean 2.3
[02:36:53] <SWPadnos> as long as you remember to fix and add all the other stuff
[02:37:27] <SWPadnos> well, come on. a HAL refactor should be do-able in a weekend
[02:37:41] <SWPadnos> nobody has anything to do the week of Thanksgiving, right?
[02:37:43] <jepler> hal is perfect, I don't see why we'd want to refactor
[02:38:12] <jmkasunich> there are a bunch of little annoyances
[02:38:17] <cradek> after reading the BOSS docs about cutter comp, I'm tempted to say we can use my new code and we just have to write a list of all the stuff that it doesn't get right, and call it documentation
[02:38:20] <jmkasunich> like - pins vs params
[02:38:48] <jmkasunich> even if we decide to keep params, I should have made the two share a namespace - no pins and parasm with the same name
[02:39:20] <jepler> we can make that an error anytime you want, and I doubt it'll cause problems
[02:39:59] <jmkasunich> thats not the issue - the reason for doing it would be to let us get rid of a lot of semi-duplicated code, and simplify some commands
[02:40:12] <jmkasunich> instead of "alias pin foo bar", it would just be "alias foo bar"
[02:40:34] <jepler> ...like I did with 'setp' at some point...
[02:40:48] <jmkasunich> another biggie is newinst
[02:40:49] <jepler> well, from the user point of view
[02:47:09] <cradek> ~g0g53x0
[02:47:16] <cradek> ha
[02:47:39] <jmkasunich> ~?
[02:47:54] <cradek> F5
[02:49:17] <SWPadnos> well, of course. now it all makes sense
[02:50:30] <SWPadnos> incidentally, does anyone get the feeling that Aram is trying to change the limits on the fly? he keeps using the word "volume" (I do not think it means what he thinks it means)
[02:51:03] <jmkasunich> I cannot understand what he wants to do (and am not really trying to)
[02:52:38] <jmkasunich> hmm, I think I just found a bit of a bug
[02:52:52] <cradek> I have no idea - Stuart thought he saw a bug - I think he was mistaken (probably misunderstood something aram told him) - so I asked for more information
[02:54:18] <jmkasunich> I did, I did found a bug
[02:54:32] <jmkasunich> newsig fooooooooooooooooooooooooooooooooooo
[02:54:36] <jmkasunich> newsig fooooooooooooooooooooooooooooooooooooooooooooooo
[02:54:40] <cradek> bonk
[02:54:49] <jmkasunich> bit FALSE fooooooooooooooooooooooooooooooooooooooo
[02:54:49] <jmkasunich> bit FALSE fooooooooooooooooooooooooooooooooooooooo
[02:54:59] <cradek> oh
[02:55:02] <SWPadnos> newsig fooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooolish-person
[02:55:02] <jmkasunich> we don't truncate before testing for duplicates
[02:55:17] <cradek> I was hoping for a big kaboom! </marvin>
[02:55:17] <SWPadnos> I'd error instead, I think
[02:55:20] <jmkasunich> so the test fails, we create the new sig (and truncate at that point)
[02:55:38] <jmkasunich> winding up with two that have the same name
[02:56:17] <SWPadnos> I'd just error saying the name is too long - don't even check for duplicates at that point
[02:56:31] <jmkasunich> yeah, that makes more sense
[03:00:08] <jmkasunich2_> regarding that length check
[03:00:18] <jmkasunich2_> the api doesn't print messages, it just returns error codes
[03:00:38] <jmkasunich2_> should I add another for HAL_NAME_TOO_LONG, or just use HAL_INVAL (invalid argument)
[03:00:42] <SWPadnos> sure, halcmd would need to print the appropriate message
[03:00:52] <SWPadnos> the more descriptive the better IMO
[03:01:08] <SWPadnos> HAL_YOUAREANIDIOT
[03:01:54] <jmkasunich2_> http://pastebin.ca/1261074
[03:01:56] <jmkasunich2_> existing list
[03:02:37] <jmkasunich2_> HAL_BADVAR duplicate or not-found variable name <-- seems like a good candidate
[03:02:46] <jmkasunich2_> just change the comment to include "too long"
[03:03:21] <jmkasunich2_> note that users never create pins or params, drivers or components do
[03:03:48] <jmkasunich2_> the bug exists for everything, but I think the only thing users name is sigs (and aliases)
[03:04:52] <jmkasunich2_> HAL_LONGNAME? HAL_NAME2LONG?
[03:05:53] <jmkasunich> duh, wtf and I doing
[03:06:05] <jmkasunich> hal_lib _does_ print messages
[03:06:17] <jmkasunich> the code is staring me in the face
[03:06:38] <jmkasunich> that settles it, I'll print a message saying too long, and return HAL_INVAL
[03:09:50] <SWPadnos> that sounds fine to me
[03:10:15] <SWPadnos> is the length checked for pin/param creation?
[03:10:23] <SWPadnos> (or module names, for that matter)
[03:11:51] <jmkasunich2_> no length checks anywhere
[03:12:03] <jmkasunich2_> working on that how
[03:12:21] <jmkasunich2_> we use strnxxx everywhere, so there are no buffer overflow risks
[03:12:32] <jmkasunich2_> but truncating names can lead to dups
[03:21:08] <cradek> can we just rot-13 the var file or something?
[03:25:19] <jmkasunich2_> arg, I changed the hal version number and recompiled without realizing that rtapi and hal were loaded
[03:25:22] <jmkasunich2_> now I can't unload
[03:25:52] <SWPadnos> change it back and recompile :)
[03:26:11] <jmkasunich2_> the changes were yesterday
[03:26:13] <SWPadnos> but save and sync first :)
[03:26:27] <jmkasunich2_> save, sync, reboot ;-)
[03:26:54] <SWPadnos> hmmm, so it's just the special unlock function that ignores the version?
[03:27:20] <jmkasunich> I dunno
[03:27:32] <jmkasunich> the version is there for a good reason - key structures changed
[03:28:00] <jmkasunich> the instances sitting in shmem, and the "templates" that the new halcmd would overlay on them, would NOT match
[03:29:11] <jmkasunich> grr, too many boots without fsck, check forced
[03:30:33] <SWPadnos> heh. always when you're watching it :)
[03:31:52] <cradek> the problem is in changing volume.
[03:32:08] <cradek> can anyone guess what this means?
[03:33:25] <SWPadnos> turn it up to 11
[03:33:47] <SWPadnos> I don't know, but it sounds like he's trying to change the work envelope
[03:34:09] <cradek> do you think that only because of the word volume, or are there other clues to support that?
[03:34:24] <SWPadnos> only because of the repeated use of the word
[03:34:27] <cradek> I think he might mean origin
[03:34:44] <SWPadnos> he may mean "the work volume as displayed in AXIS", which would be the origin
[03:34:49] <SWPadnos> (more or less)
[03:34:50] <cradek> but ... that stuff works right
[03:34:58] <cradek> I'm pretty sure he's using tkemc
[03:35:16] <SWPadnos> oh, in that case I have nfc
[03:35:25] <SWPadnos> but I can ask :)
[03:35:33] <cradek> he might mean origin, or dro, or maybe something else
[03:37:57] <cradek> I carefully rewrote that part of the manual - if he would read it and understand each of the words, I think he'd be set
[03:38:11] <CIA-38> EMC: 03jmkasunich 07TRUNK * 10emc2/src/hal/hal_lib.c: report names that are too long (no buffer-overflow risk, but could result have resulted in duplicates after truncation)
[03:40:17] <jmkasunich> now, where was I
[03:53:59] <CIA-38> EMC: 03seb 07TRUNK * 10emc2/docs/man/man9/hm2_7i43.9: note EPP 1.9 is required for the 7i43
[04:11:36] <SWPadnos> ugh. I'll have to do this stuff later. I'm not thinking clearly this evening
[04:11:56] <SWPadnos> I may actually go to bed before midnight - like now
[04:11:59] <SWPadnos> night guys
[04:12:01] <jmkasunich> I'm about to commit the the alias function, totally untested (bedtime coming soon)
[04:12:06] <SWPadnos> ok, sool
[04:12:07] <SWPadnos> cool
[04:12:14] <jmkasunich> I'll test tomorrow
[04:12:19] <SWPadnos> do you have a "find alias" function?
[04:12:33] <SWPadnos> or is it (to be) incorporated in find_x_by_name?
[04:12:42] <jmkasunich> no, but I've extended "find_pin_by_name" to match either name or alias
[04:12:48] <jmkasunich> ditto for find_param_by_name
[04:12:50] <SWPadnos> ok
[04:13:10] <jmkasunich> it will take a carefull search to find places that do searches without calling those functions
[04:13:25] <CIA-38> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/firmware/7i43/ (SV8B.BIT SV8S.BIT SVST4_4B.BIT SVST4_4S.BIT SVST4_6B.BIT):
[04:13:25] <CIA-38> EMC: New firmware from Mesa. Peter says:
[04:13:25] <CIA-38> EMC: All updated to Max EPP filter time = EPP 1.9 only
[04:13:25] <CIA-38> EMC: All incorporate USB fix
[04:13:25] <CIA-38> EMC: USB fix allow USB powered EPP devices to enumerate without causing
[04:13:28] <CIA-38> EMC: a bus conflict between the USB FIFO chip and the EPP data bus
[04:13:33] <SWPadnos> like the pin_generator functions for completion ...
[04:13:35] <CIA-38> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/firmware/src/ (7i43.ucf IDParms.vhd i43hostmot2.vhd):
[04:13:35] <CIA-38> EMC: New firmware from Mesa. Peter says:
[04:13:35] <CIA-38> EMC: All updated to Max EPP filter time = EPP 1.9 only
[04:13:37] <CIA-38> EMC: All incorporate USB fix
[04:13:39] <CIA-38> EMC: USB fix allow USB powered EPP devices to enumerate without causing
[04:13:43] <CIA-38> EMC: a bus conflict between the USB FIFO chip and the EPP data bus
[04:14:07] <jmkasunich> yes, and also the code that adds a new pin to the pin list
[04:14:32] <jmkasunich> right now, pin_new allocates the pin struct, then does list insertion - if it runs into a dup during the search, then it aborts and frees the new struct
[04:14:51] <jmkasunich> I might want to do a find_by_name first to detect dups and quit early
[04:15:16] <jmkasunich> in fact, I think I have to do it that way
[04:15:24] <jmkasunich> hmm, this is gonna be interesting for "show"
[04:15:28] <SWPadnos> it makes sense anyway
[04:15:39] <SWPadnos> heh, yeah
[04:15:47] <jmkasunich> the pin list is ordered by original name, and right now I have no intention of re-ordering it when an alias is added
[04:16:07] <SWPadnos> right - the only thing that will change is that aliased pins won't be sorted correctly
[04:16:18] <SWPadnos> which could be a PITA, for sure
[04:16:20] <jmkasunich> which will be annoying
[04:17:13] <jmkasunich> I wonder if it should re-order
[04:17:22] <jmkasunich> unlink from list, relink in proper location based on alias
[04:17:28] <SWPadnos> it only has to on creation and deletion of an alias
[04:17:43] <jmkasunich> right - the code I just wrote ;-/
[04:17:48] <jmkasunich> remove_alias would have to do the same
[04:18:25] <jmkasunich> what I have compiles and should be safe, since there's no way to call it at the moment
[04:18:25] <SWPadnos> heh
[04:18:39] <jmkasunich> I'm gonna commit it and worry about the re-order tomorrow
[04:18:50] <SWPadnos> yep. add a to-do or something :)
[04:21:09] <jmkasunich> done
[04:21:53] <SWPadnos> cool. sorry I didn't get the halcmd part done today. too much going on
[04:21:58] <CIA-38> EMC: 03jmkasunich 07TRUNK * 10emc2/src/hal/ (hal.h hal_lib.c): incremental progress on 'alias' command - untested, but no way to invoke it at the moment, should be safe
[04:21:59] <jmkasunich> no worries
[04:22:26] <jmkasunich> I'll be out much of tomorrow evening, if I do the re-order thing, I won't even be ready to test until thursday
[04:22:37] <SWPadnos> heh - no worries :)
[04:22:46] <jmkasunich> probably will leave that as is for now, just get it working without the re-order
[04:23:02] <jmkasunich> goodnight
[04:23:06] <SWPadnos> night
[04:23:11] <SWPadnos> right, I'm still here??
[12:55:23] <CIA-38> EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/config/ini_config.lyx: add a bit of info about the VAR file
[12:56:56] <CIA-38> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/config/ini_config.lyx: add a bit of info about the VAR file
[14:02:37] <jepler> 3) Earlier G540 REV3s require a 5kHz or more Mach3 compatible square-wave watchdog timer (charge pump) signal to be present to enable. It is designed to be . Other CNC programs may not generate this signal at all or it may not meet the Mach3 standard.
[14:02:43] <jepler> hah the "mach 3 standard"
[14:44:25] <cradek_> http://cnczone.com/forums/showpost.php?p=527558&postcount=72
[14:44:30] <cradek_> cradek_ is now known as cradek
[15:01:27] <jepler> on the one hand there might well be some kind of bug or misunderstanding about the stepconf charge pump feature
[15:01:45] <jepler> but it's hard to take the hardware seriously when all we're really told is that it implements the "mach3 standard"
[15:03:16] <SWPadnos> translation: "a 5KHz (or so) or more relatively square-ish output with acceptable random jitter"
[15:04:01] <cradek> he fiddled with the knobs on the Z drive and it got better
[15:04:08] <cradek> he changed some timings in stepconf and it got better
[15:04:19] <cradek> he doesn't say what version of emc he's using, except that it's a year old
[15:04:26] <jepler> ffs
[15:04:36] <jepler> there were a *hell of a lot* of bugs in stepconf that long ago
[15:04:39] <cradek> his idea of troubleshooting is to run a 1.5 hr program and look at how screwed up the part is this time
[15:04:51] <SWPadnos> there definitely seem to be some misconceptions about what the "Sherline" settings are in stepconf
[15:05:20] <SWPadnos> (I say that because I thought I saw soemwhere that he's using a Sherline machine)
[15:06:10] <SWPadnos> people don't seem to understand that one page says "TIMING" on it
[15:06:29] <cradek> I admit to getting bored halfway through the thread
[15:06:30] <SWPadnos> so you don't need to select sherline if you have a sherline machine, only if you have a sherline driver
[15:06:32] <SWPadnos> heh
[15:06:47] <SWPadnos> I'm bored halfway (or less) through the first post ;)
[15:09:04] <jepler> hah
[15:09:29] <SWPadnos> I wonder what RASTA patterns are :)
[15:09:44] <SWPadnos> hey mon, mill dis part here den
[15:10:01] <skunkworks_> heh
[15:10:04] <jepler> * jepler contemplates whether it would be possible to get a 5kHz square wave out of a pluto_step system
[15:10:26] <jepler> you can't get it out of the step generators as-is, and you can't get it from a dumb I/O unless you run a 10kHz servo cycle
[15:10:33] <jepler> oh well, nobody should use that POS anyway
[15:10:34] <jepler> :-P
[15:10:37] <SWPadnos> heh
[15:10:52] <SWPadnos> it's what, 13 bits for the divider?
[15:11:09] <skunkworks_> jepler: it does work... You did a great job. Just doesn't work on all computers.
[15:11:11] <jepler> you can get 5kHz but not square
[15:11:24] <SWPadnos> ah
[15:11:29] <SWPadnos> step length is too short
[15:11:33] <jepler> right
[15:11:56] <SWPadnos> then use pluto_servo ;)
[15:59:31] <alex_joni> how about from a parport?
[15:59:46] <alex_joni> setting up a 10kHz thread shouldn't be a problem, then just toggling a bit in there
[16:01:07] <jepler> if you have a second parport to use, sure
[16:06:57] <alex_joni> anyways, I bet Mariss would provide better specs for the g540 if asked
[16:07:19] <SWPadnos> I was thinking that
[16:07:37] <alex_joni> on their page it's stated" 10kHz chargepump signal
[16:07:41] <SWPadnos> he seems ambivalent towards EMC though
[16:07:58] <SWPadnos> kind of like "Mach works, so why bother with anything else"
[16:08:09] <SWPadnos> it's a solved problem for him
[16:08:12] <alex_joni> Pin 16 CHARGE PUMP (>10kHz)
[16:08:19] <SWPadnos> 16?
[16:08:26] <SWPadnos> that's odd - should be 17 I think
[16:08:45] <alex_joni> http://www.geckodrive.com/upload/G540%20REV3%20MANUAL.pdf
[16:12:23] <SWPadnos> looking at some other docs (like the PMDX-122 manual), it seems that pin 17 is more common
[16:12:24] <CIA-38> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/ (encoder.c hostmot2.c hostmot2.h):
[16:12:24] <CIA-38> EMC: This adds a simple constant-time velocity estimator for hostmot2 encoders.
[16:12:24] <CIA-38> EMC: Better velocity estimation coming soon.
[16:12:25] <SWPadnos> strange
[16:12:41] <cradek> neato
[16:12:50] <SWPadnos> yeah, woohoo!
[16:12:55] <CIA-38> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/stepgen.c: safer conversion macro
[16:13:04] <SWPadnos> now all we need is that PID that has a V input pin :)
[16:13:32] <cradek> you have the source, don't you, you big whiner?
[16:13:33] <CIA-38> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/TODO: Note removal of my old obsolete drivers from TRUNK in Jan 2009
[16:13:38] <SWPadnos> :P
[16:13:43] <SWPadnos> I don't need PID yet though ;)
[16:13:48] <alex_joni> velocity heh
[16:13:56] <alex_joni> err.. s/velocity//
[16:34:04] <BigJohnT> the charge pump on the 540 can be bypassed...
[16:45:04] <cradek> seb's velocity estimator looks like it will freak at index - wonder if he will keep that in mind for the "coming soon" one
[16:48:06] <Lerman_____> Lerman_____ is now known as Lerman
[16:48:54] <alex_joni> hmm.. anyone plans to take seb's offer for coverty?
[16:50:17] <SWPadnos> I probably will. I had talked to them before and I think it's a good idea to use them
[16:51:58] <cradek> I'd like to see the results, but I don't care to register with them, so I guess I won't.
[16:52:20] <alex_joni> * alex_joni was thinking something along the same lines
[16:52:30] <alex_joni> but at least one of us should have access..
[16:52:48] <cradek> it's good enough for me that seb cares to do it
[17:05:17] <jepler> yeah I'd rather just see a text copy or a screenshot of a scan report. I don't care to sign up for a website
[17:05:27] <jepler> it's more curiosity than anything
[17:51:06] <SWPadnos> hmmm. interesting "issue" with doublestep. what if you have drives with different timing requirements on different axes
[17:51:37] <SWPadnos> I suppose you could use the longest requirement to set reset-time
[17:52:18] <SWPadnos> anything that needs to be longer than one BASE_PERIOD (or the reset-time limit) wouldn't use the reset feature, just use it in "normal" mode
[18:45:40] <SWPadnos> jepler, do you recall about when you changed AXIS so it discards older backplot data?
[18:45:51] <SWPadnos> (or such that it limits backplot data size)
[18:46:23] <SWPadnos> and is that settable by the user, or does it require a change to axis.py / togl / something else?
[19:02:34] <jepler> SWPadnos: it is not user-tunable
[19:02:57] <SWPadnos> ok
[19:03:11] <jepler> I'm sure it's been in all 2.2.x, probably not in any 2.1.x but I'm not sure
[19:03:42] <cradek> jepler: I think the issue was that we had a log slider that didn't get set by anything but the user, and some non-log sliders that did, and I tried to slather the two together, while all the time being somewhat clueless about what I was doing.
[19:05:00] <jepler> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/emc/usr_intf/axis/extensions/emcmodule.cc#rev1.11
[19:05:08] <cradek> jepler: take my ~/emc2/configs/sim directory and run lathe.ini from it - it has a vcp readout and some vcp buttons that change the value
[19:05:48] <jepler> cradek: on lucky? OK.
[19:05:57] <cradek> yes
[19:06:01] <jepler> cradek: I won't look at it 'till tonight when I'm at home
[19:06:07] <jepler> feel free to ping me about it again
[19:06:09] <cradek> ok
[19:09:48] <SWPadnos> the guy having problems with the G540 pointed out a sowdown after a long time machining
[19:09:54] <SWPadnos> slowdown
[19:10:06] <cradek> of the gui, yes
[19:10:13] <SWPadnos> I'm responding to that thread, and will point out that the GUI doesn't affect RT anyway
[19:10:15] <cradek> did he ever say what emc version?
[19:10:39] <SWPadnos> no, but Alan Condit gave him an update procedure - I'll check that again
[19:10:42] <cradek> did he ever say if he gets 'unexpected realtime delay' errors?
[19:10:48] <SWPadnos> I'm not sure which one he has now
[19:11:31] <SWPadnos> no, but he did say that the latency test showed around 15k (149xx, I don't remember exactly), with some games and lots of other programs running
[19:11:35] <SWPadnos> dunno if he tried glxgears
[19:11:51] <SWPadnos> also don't know if he's using the nv, nvidia, or vesa video driver
[19:13:29] <cradek> are you going to tell him he should quit running his hour-long program that makes ruined parts, and troubleshoot instead?
[19:13:37] <SWPadnos> yes, several times :)
[19:13:48] <SWPadnos> hmmm. O repeat isn't in 2.2.x, is it
[19:13:54] <cradek> no
[19:14:05] <SWPadnos> I was going to give him a loop to run
[19:14:07] <SWPadnos> hmmm
[19:14:10] <SWPadnos> that makes it uglier :)
[19:14:20] <cradek> yep that's why I wrote repeat
[19:14:47] <SWPadnos> ok, it looks like Alan told him to get
http://www.linuxcnc.org/emc2/dists/dapper/emc2.2/binary-i386/emc2_2.2.7_i386.deb
[19:15:01] <cradek> that's not how you update
[19:15:09] <cradek> you update following the instructions on the wiki
[19:15:12] <SWPadnos> it is for non-net-connected machines
[19:15:14] <cradek> (if changing major versions)
[19:15:24] <SWPadnos> he went on to explain how to install the .deb
[19:15:30] <cradek> oh he's non-net-connected?
[19:15:44] <cradek> joy.
[19:15:45] <SWPadnos> the emc machine is non-net-connect^Wisolated
[19:16:05] <cradek> if it's currently 2.1 maybe there are new dependencies - I don't remember
[19:16:07] <SWPadnos> it seems maybe there should have been an RT kernel update or something
[19:16:15] <cradek> if it's currently 2.0 ...
[19:16:15] <SWPadnos> yeah, don't know
[19:16:17] <SWPadnos> heh
[19:16:23] <cradek> yes the kernel will probably be wrong
[19:16:48] <cradek> I'd like to buy the world a network cable, in perfect harmony
[19:16:49] <jepler> I thought somewhere in there he said he's using stepconf, which makes it 2.2.
[19:17:01] <cradek> ahh
[19:17:14] <SWPadnos> oh, good deal then :)
[19:21:07] <cradek> are you going to tell him that if he thinks he has an emc problem, for god's sake, come to the emc mailing list?
[19:21:35] <cradek> well maybe I don't want that.
[19:21:42] <cradek> everyone ignore the guy in the corner
[19:22:46] <SWPadnos> I may mention that CNCZone isn't the primary support channel for EMC
[19:23:05] <jepler> hah "support"
[19:23:12] <jepler> there's no primary support channel for EMC
[19:23:33] <SWPadnos> it is interesting though - I looked through the G250, G251, and G540 docs, and there is no timing information in any of them, except for "1 us step pulses"
[19:23:53] <BigJohnT> all volunteer supporters
[19:23:54] <SWPadnos> no mention whether rising or falling edge is important
[19:24:07] <BigJohnT> SWPadnos: it is the same as the G203v
[19:24:28] <SWPadnos> or the G201 or G210 or ...
[19:24:39] <BigJohnT> not the same as the 201!
[19:24:49] <SWPadnos> that's my point, they're all different :)
[19:25:19] <BigJohnT> the 203, 250, 251, 540 are the same
[19:25:50] <SWPadnos> I think you're right, since they all use a CPLD. do you have an authoritative source that specifies that though?
[19:26:13] <BigJohnT> I asked Mariss once
[19:26:18] <cradek> SWPadnos: I'm surprised he doesn't have that in the specs. I thought he was good about that.
[19:26:20] <SWPadnos> hhe
[19:26:21] <SWPadnos> heh
[19:26:29] <SWPadnos> yeah, it should be there. I'll mention it
[19:26:37] <BigJohnT> the 203 manual is the best I think
[19:26:43] <SWPadnos> I may ask Mariss for a G540 so I can make an EMC config for it
[19:27:46] <BigJohnT> http://www.geckodrive.com/upload/G203V-REV-6-MANUAL.pdf
[19:28:13] <SWPadnos> I have that manual up now, I'm more concerned about the equivalence of the G203 to the G542/250/251
[19:28:37] <BigJohnT> for timing or other issues?
[19:28:47] <SWPadnos> yes
[19:28:49] <SWPadnos> I'll email Mariss
[19:29:06] <BigJohnT> that is the best place :)
[19:33:50] <BigJohnT> well, I'm off to the other shop
[19:35:00] <alex_joni> SWPadnos: keep me posted
[19:35:06] <SWPadnos> will do
[22:45:32] <CIA-38> EMC: 03cmorley 07TRUNK * 10emc2/src/hal/classicladder/protocol_modbus_master.c: change the mapping of modbus coils/inputs that are read from slave from, physical inputs (%i) to memory bits (%B) because Hal will overwrite physical inputs
[22:56:08] <CIA-38> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py:
[22:56:08] <CIA-38> EMC: mostly make the max velocity slider behave.
[22:56:08] <CIA-38> EMC: remaining problem: rounded value may show differently than in halui (91.9 vs
[22:56:08] <CIA-38> EMC: 92.0 when actual value is 1.5333333333333319*60=91.999999999999915) -- why is
[22:56:08] <CIA-38> EMC: the rounding bad?
[22:56:09] <CIA-38> EMC: 03jepler 07TRUNK * 10emc2/share/axis/tcl/axis.tcl:
[22:56:13] <CIA-38> EMC: mostly make the max velocity slider behave.
[22:56:15] <CIA-38> EMC: remaining problem: rounded value may show differently than in halui (91.9 vs
[22:56:17] <CIA-38> EMC: 92.0 when actual value is 1.5333333333333319*60=91.999999999999915) -- why is
[22:56:19] <CIA-38> EMC: the rounding bad?