01:32:15 <rayh_away> rayh_away has quit
07:15:32 <alex_joni> morning all
14:36:15 <rayh> rayh has joined #emc-devel
14:59:54 <alex_joni> hey ray..
15:00:00 <alex_joni> got them motors humming ;)
15:03:52 <rayh> Fantastic.
15:04:20 <alex_joni> yeah, but I am a bit concearned that one of them is making a bit more noise than the other
15:04:46 <rayh> there is a midband tuning pot on the gecko?
15:04:56 <alex_joni> yes
15:05:11 <alex_joni> I did tune it the best I could, but it's still a bit like grinding
15:05:42 <rayh> That isn't right.  Did you try swapping motors between drives?
15:06:18 <alex_joni> trying now
15:06:32 <rayh> Oh.  You've got them there.
15:06:52 <alex_joni> the issue is moving with the gecko
15:06:59 <alex_joni> so it's not motor related
15:07:26 <rayh> Your emc tuning is the same for both?
15:08:07 <alex_joni> yup
15:08:22 <alex_joni> but I can swap X/Y in hal
15:09:10 <rayh> and ?
15:09:25 <alex_joni> same problem
15:09:43 <rayh> Stays with the gecko?
15:10:06 <alex_joni> yup
15:10:28 <alex_joni> I'll have to open them both up, and check jumpers
15:10:55 <rayh> So what's left is the wiring, the grounding, the current limit resistor, or jumper
15:11:42 <rayh> could swap the step and direction signals at the gecko.
15:12:09 <alex_joni> what for?
15:12:35 <rayh> see if it's noise from the parport or wiring.
15:13:30 <alex_joni> hmm.. I might do that
15:13:33 <alex_joni> but I doubt it
15:16:05 <rayh> Univstep puts a lot less load on this box than demo_step_cl
15:57:16 <alex_joni> it seems to be working pretty ok now..
15:57:22 <alex_joni> still some noise at low speed
15:57:27 <alex_joni> only on that one gecko
15:57:39 <alex_joni> I swapped it with the other one, and the problem stays with the gecko
15:57:49 <alex_joni> even swapped the resistor and all cabling, motor
15:58:07 <alex_joni> it's always that one gecko.. but at higher speed it's not noticeable
15:58:23 <alex_joni> btw, I'm running at 10mm/sec (meaning 20kHz pulses)
15:58:40 <alex_joni> with emc2 & BASE_PERIOD=0.000025
15:59:00 <SWP_Away> SWP_Away is now known as SWPadnos
15:59:08 <SWPadnos> hi there
15:59:14 <SWPadnos> steppers or servos?
16:00:26 <alex_joni> steppers
16:00:30 <SWPadnos> ok
16:00:38 <alex_joni> sherline ;)
16:00:43 <SWPadnos> eeewwww :)
16:00:49 <alex_joni> what?
16:00:53 <alex_joni> they seem nice ;)
16:00:54 <SWPadnos> too small
16:00:59 <SWPadnos> ;)
16:01:00 <rayh> Adjust the midband while running at that most noisy speed.
16:01:02 <alex_joni> heh.. for plotting it's ok :P
16:01:14 <rayh> Morning Steve
16:01:15 <alex_joni> rayh: I did adjust to the smallest possible noise
16:01:21 <alex_joni> ok.. going home ;)
16:01:25 <alex_joni> I'll send some pics lateron
16:01:46 <rayh> If you need a new gecko holler.
16:01:49 <SWPadnos> err - Ray - did you add stepgen_maxvel to the .hal files as well (or was it already there?)
16:02:31 <alex_joni> rayh: don't think so..
16:02:37 <rayh> must have been there.  got an error message during startup
16:02:39 <alex_joni> it's humming a bit harder, but it's ok
16:02:43 <SWPadnos> ok
16:02:47 <alex_joni> circles do sound very exciting :D
16:02:52 <SWPadnos> hehe
16:03:05 <alex_joni> and 20kHz from emc2 is also very nice
16:03:10 <rayh> don't they.
16:03:17 <alex_joni> I think I still have lots left in my laptop
16:03:24 <alex_joni> but I don't want to crank it up higher
16:03:28 <rayh> You bet that is great.
16:03:41 <alex_joni> it's a 1.4GHz centrino laptop ;)
16:03:54 <alex_joni> rayh: I had some issues starting the geckos :D
16:04:02 <alex_joni> on the G340 I use common ground
16:04:15 <rayh> SWPadnos: Question.  What would it take to make a parallel universe to halcmd.
16:04:17 <alex_joni> but there it's selectable (common ground or common Vcc)
16:04:29 <rayh> The 201 uses common +5
16:04:33 <alex_joni> over here it's only common Vcc
16:04:37 <alex_joni> yeah.. I figured :D
16:04:38 <SWPadnos> rayh, one that does what?
16:04:43 <alex_joni> so I took +5V from USB :D
16:04:43 <rayh> and no way round it.
16:04:57 <alex_joni> so it's a parport/USB setup (lol)
16:05:05 <rayh> Yep.  Done the usb trick.
16:05:17 <SWPadnos> but USB is too slow ;)
16:05:18 <rayh> even used it to get around the computer off estop problem/
16:05:27 <alex_joni> SWPadnos: 500mA is not too slow
16:05:43 <alex_joni> rayh: connect to the enable ?
16:05:45 <rayh> only the +5 which comes on when pc power is up.
16:05:45 <alex_joni> nice
16:05:59 <alex_joni> * alex_joni goes home
16:06:00 <SWPadnos> somebody should make an ATX connector breakout, that takes the POWER_GOOD signal to the outside world
16:06:11 <rayh> looks damn stupid to have the extra cable
16:06:11 <alex_joni> it's friday 18:08.. way to late to be at work :D
16:06:31 <rayh> catch you later alex_joni
16:06:37 <SWPadnos> see ya
16:06:52 <alex_joni> laters everyone
16:06:59 <rayh> SWPadnos: the parallel universe is a sort of status reporter.
16:07:14 <SWPadnos> ok - "halstat"
16:07:33 <rayh> every pin param sig and thread heartbeat.
16:08:00 <SWPadnos> that's doable, by stripping out most of halcmd and renaming it ;)
16:08:08 <rayh> pass it a string of "names" and it passes back a string of values.
16:08:45 <rayh> no formatting, no name replies, just the value.
16:09:15 <rayh> Would you update it using a fast loop or only when a demand is made of it?
16:09:32 <SWPadnos> oke problem - you can have a pin, a signal, a component, and a function with the same name
16:09:45 <SWPadnos> s/oke/one/
16:10:06 <rayh> right.  that's why I appended the name to the type
16:10:23 <rayh> like pin+axis.0.enable
16:10:38 <SWPadnos> no sense checking in a fast loop, if the "caller" can't display that fast.  it should be asked (possibly with just a newline)
16:10:40 <SWPadnos> ok
16:10:52 <rayh> That is how I produced the nodes and leaves for the tree.
16:11:25 <SWPadnos> ok
16:11:35 <rayh> something other than + could be used.
16:11:55 <SWPadnos> + is OK, I think it's illegal in the HAL names (not sure though)
16:12:08 <rayh> I'd have a fight on my hands if we used a "."
16:12:19 <SWPadnos> why?
16:12:43 <rayh> split + v split "."
16:13:33 <rayh> spose i could use scan and dot separation
16:13:35 <SWPadnos> in C, I'd find the first '.', and be done with it
16:13:37 <SWPadnos> phone
16:13:47 <rayh> k
16:40:18 <SWPadnos> heh - got a friend who wants to export lots of mail from Groupwise to (something else)
16:45:39 <rayh> Is that mbx or individual files?
16:45:44 <SWPadnos> no
16:45:51 <SWPadnos> neither, I think
16:46:51 <rayh> some sort of binary file encripted using 256 bit xxx
16:47:58 <SWPadnos> it's some database format, I think
16:49:42 <SWPadnos> no - it appears to be encrypted individual files
16:49:51 <cradek> does this guy have groupwise or just the data?
16:49:54 <SWPadnos> ah well - saved for a later time
16:49:58 <SWPadnos> he has GroupWise
16:50:31 <cradek> I know it does some fancy things - for instance an attachment sent to 100 people is only stored once
16:50:33 <SWPadnos> and they run a Novell server (fairly obviously)
16:50:51 <SWPadnos> yep.  it's a very powerful groupware tool
16:51:19 <cradek> too bad it's not open source, since he would still have his data then
16:51:51 <SWPadnos> yep.
16:51:53 <cradek> I wonder if businesses will eventually learn that putting their data in inaccessible closed formats is bad
16:52:03 <SWPadnos> Novell is headed that way, but probably not with GW
16:52:10 <SWPadnos> it's not bad for them
16:52:13 <SWPadnos> (yet)
16:52:27 <cradek> yeah, it's only really bad once in a while.
16:52:29 <SWPadnos> I have the same problem with the PCD / schematic programs
16:52:33 <SWPadnos> PCB
16:52:56 <SWPadnos> and 3D cad (unless you think dxf is viable, which I don't)
16:53:09 <cradek> there are lots of open-ish formats for 3d data
16:53:18 <cradek> typically cad pacakges can export to one or many of them
16:53:34 <cradek> often, they suck, but at least they are simple
16:53:36 <SWPadnos> they rarely contain the design information, just the results
16:53:41 <cradek> yeah.
16:53:48 <SWPadnos> parasolid is close
17:15:27 <SWPadnos> so - Ray, back to "halval" (if you like)
17:16:58 <rayh> you bet I like.
17:17:19 <rayh> I was imagining it a bit like NML status for HAL
17:17:25 <SWPadnos> is the main purpose to increase speed, or to reduce the tcl communications complexity?
17:17:39 <rayh> speed
17:17:44 <SWPadnos> ok
17:18:03 <rayh> The tcl stuff can be worked through
17:18:20 <SWPadnos> there are a couple of issues:
17:18:50 <SWPadnos> 1) all connections in HAL are determined by strings (ie, I have to look at the names of things to figure out if they're interesting or not)
17:19:26 <SWPadnos> 2) if I decide to bypass that (after the first tiem), and just keep a pointer to the data, then it might go away if e.g. a signal is deleted and I don't know about it
17:19:30 <rayh> and that slows the process at that end.
17:19:43 <SWPadnos> it slows the process regardless of where the work is done
17:20:09 <SWPadnos> I think you always have to ask for data by name, simply because the connections and elements may change at any time
17:20:33 <rayh> Sure.  That was my thinking when I built the tree
17:20:52 <rayh> refresh does a complete reread of what is available
17:21:18 <SWPadnos> we can only eliminate at most one set of string manipulation - in the top level (now tcl) program
17:21:44 <SWPadnos> we still have to have the data selectively retrieved by string compares at the low level
17:23:00 <SWPadnos> I suppose that the program could look at the component list before each scan, and insure that the components are still there (same for signals)
17:23:29 <SWPadnos> as long as the comps haven't been unloaded, the pins and params will be valid, even if the values are meaningless
17:23:41 <SWPadnos> (may be meaningless, that is)
17:25:01 <SWPadnos> actually, there is a speedup that can be done, but it would be partly in the "query language"
17:25:54 <SWPadnos> if you want several things from one component (not necessarily with the same name, like the motion pins), you can look up the component ID once, then look for the number in the pin/param scan, rather than checking the name every time
17:26:03 <SWPadnos> I'm not sure how halcmd does this now
17:28:01 <rayh> phone
17:28:23 <SWPadnos> ok - I'm checking things now anyway
17:46:33 <SWPadnos> (reply when you get a chance - I'll blather away until then)
17:46:34 <rayh> back
17:46:40 <SWPadnos> ok - no need to blather
17:47:07 <SWPadnos> so - this program should only be able to return things with values that may change - pins, params, and sigs, right?
17:47:21 <rayh> I think so.
17:47:39 <SWPadnos> all right.  and the returned values should be "user-readable" text
17:47:44 <SWPadnos> (ie, no float conversion crap)
17:48:15 <rayh> I presume that conversions of that sort are quicker in c than tcl.
17:48:45 <SWPadnos> it'll be a savings regardless, since C is already printing x.yyyE+zzz
17:49:00 <SWPadnos> making that 4500.000 is no more work
17:49:21 <SWPadnos> so, you don't use this to find out what's there, just to get the values back (so I eliminate list xxx)
17:49:27 <rayh> okay.  I like that.
17:49:47 <SWPadnos> there will still need to be different commands, like "add, del, refresh"
17:50:17 <SWPadnos> so, you open this up, and send "add pin.name.1 pin.name.2 ..."
17:50:27 <rayh> I presume that it takes no longer to answer TRUE v FALSE than 1 v 0
17:50:33 <SWPadnos> eventually, you may send a "del pin.name.useless"
17:50:41 <SWPadnos> yes it does, but not appreciably more
17:51:08 <SWPadnos> and probably less than the total C print "0" and the TCL if "0" print "FALSE"
17:51:21 <rayh> Tickle doesn't type so it makes no difference
17:51:43 <SWPadnos> it does, everythign is a string, which is inherently a bit worse than "binary" types
17:51:59 <SWPadnos> but, TCL probably has very well optimized string manipulation because everything depends on that
17:52:11 <rayh> if 0 $canvas.xx config -fill
17:52:21 <rayh> true.
17:52:26 <SWPadnos> whichever you want
17:52:51 <rayh> so you are thinking that the front end will say to this halxxx add this pin to the list
17:53:00 <SWPadnos> yes
17:53:11 <SWPadnos> this will be meant only for a script or interactive mode
17:53:39 <rayh> then is essence a request for the value of pin xx is a pointer to it's current value.
17:53:47 <SWPadnos> (I think - it could be done such that you could cat "listfile" | this program, and get the values instead of the names
17:54:16 <rayh> That is efficient.
17:54:38 <SWPadnos> that's where the speed increase comes.  I think pins are guaranteed to exist as long as the owning comp isn't unloaded
17:54:53 <SWPadnos> so I look up the name once, and keep a pointer to the data, plus the ID number of the comp
17:55:20 <SWPadnos> when asked for a refresh, the program looks at the comp list, and if the parent no longer exists, outputs "N/A" instead of the value
17:55:33 <SWPadnos> that keeps the order as expected by the caller
17:55:49 <SWPadnos> the same for signals, since those can go away at any time
17:56:07 <SWPadnos> those may need to be string compares though, since I'm not sure if HAL reuses ID numbers
17:56:07 <rayh> and listfile is as long or short as the currently needed values
17:56:11 <SWPadnos> yee
17:56:13 <SWPadnos> yes
17:56:20 <SWPadnos> but you don't want to do it that way
17:56:33 <SWPadnos> you want to use it in script mode, or you get no speedup
17:56:41 <SWPadnos> it can't retain the data pointers across invocations
17:56:48 <SWPadnos> mutiple invocations
17:56:52 <rayh> sure
17:57:23 <SWPadnos> so you would still need to add and del the watch items
17:57:32 <rayh> The fastest would be to open, set up the list of vars to watch and return all each request.
17:57:39 <SWPadnos> and ask for the data whenever you want it
17:57:42 <SWPadnos> yep
17:57:44 <SWPadnos> that's the idea
17:57:59 <SWPadnos> and you add or delete watch vars by name
17:58:14 <rayh> That works well for me.
17:58:19 <SWPadnos> (hmmm - maybe "halwatch" is better than "halval")
17:59:01 <rayh> send it a string of variable names and it prepares those for reads.
18:00:08 <SWPadnos> "+pin.name.of.pin" to add, "-pin.name.of.pin" to remove
18:00:22 <SWPadnos> you can use '.' - I don't mind
18:00:29 <rayh> halwatch might imply that the loop is initiated in the c rather than in the calling program.
18:00:34 <SWPadnos> true
18:00:53 <rayh> phone
18:00:57 <SWPadnos> that can be done as well
18:02:48 <SWPadnos> ok.  signals will have to be string compares - no way around that
18:04:18 <rayh> phone again
18:04:22 <SWPadnos> np
18:07:04 <SWPadnos> bummer - HAL reuses component IDs
18:22:40 <rayh> ??  signals will have to be string compares - no way around that
18:23:03 <SWPadnos> there's no "number" asociated with a signal, like the parent ID for a pin or param
18:23:39 <rayh> right.  but once that signal is included in the list of pointers
18:23:55 <rayh> watch can return it that way?
18:23:59 <SWPadnos> it may disappear, and be reused with a different name (and type) later
18:24:34 <rayh> You mean if a delsig or newsig is issued.
18:24:39 <SWPadnos> so the name still has to be checked
18:24:45 <SWPadnos> yes, by anyone
18:25:37 <rayh> but it would not need to be checked on every iteration of the watch.
18:26:13 <SWPadnos> yes it would - this program wouldn't be notified that some other HAL user has removed the original sig, and replaced it with another one
18:26:49 <rayh> Well that is just a true of my tree.
18:27:03 <rayh> I could open another term and send a halcmd
18:27:17 <rayh> and the tree would not see it until another refresh.
18:27:19 <SWPadnos> but it would likely still be faster, since it can be checked without going through the full list of sigs (unless it doesn't match, in which case you go through the "setup" phase again)
18:27:23 <SWPadnos> ok
18:27:32 <SWPadnos> that's an issue, of course :)
18:31:15 <rayh> HAL can be a slippery thing to keep hold of.
18:31:32 <SWPadnos> yes - it's almost too configurable
18:31:49 <rayh> It's almost like we need a global set of flags.  I've changed a value or I've changed a link or I've changed a var.
18:32:21 <SWPadnos> true, but changed since when (and in what way)?
18:32:45 <SWPadnos> halwatch doesn't care if the connections change, only if the value changes (or the validity of the item)
18:32:59 <SWPadnos> your tcl program cares if the connections change (sometimes)
18:33:08 <rayh> That is as far as we need to go for my configuration stuff.
18:33:12 <SWPadnos> heh
18:33:48 <rayh> I see the list of pins, params. and sigs to be very temporary.
18:34:23 <rayh> I click out a set from the tree, submit it, and every second I get an update to all of em.
18:35:02 <SWPadnos> this program would be faster most of the time, and about the same the rest of the time, so it can't be worse than halcmd (I mean that in a nice way ;) )
18:35:19 <rayh> Yes.
18:35:38 <SWPadnos> it just needs to check for things like the data no longer being valid
18:35:59 <rayh> yes.
18:36:01 <SWPadnos> but at least it would usually avoid the scanning through *everything* like halcmd does
18:36:33 <rayh> and it would certainly clean up a lot of the stuff on the tcl end
18:37:15 <rayh> And I can create standard lists of "tuning
18:37:15 <SWPadnos> yep.  if it can remove a lot of the tcl string parsing, that would be a good thing as well
18:37:22 <rayh> stuff for it.
18:37:27 <SWPadnos> yep
18:37:48 <rayh> show me axis 0 tuning
18:38:20 <SWPadnos> well - that's one thing I considered as a speedup - pass in a hierarchical list of thing to look at:
18:38:36 <SWPadnos> axis.0.{P,I,D}
18:38:43 <rayh> the whole bunch of names at once.
18:38:53 <SWPadnos> yep - sort of regexp-like
18:39:16 <rayh> I'd want them to be returned in the order sent.
18:39:27 <rayh> random order.
18:39:35 <SWPadnos> but also ppmc.0.{encoder.{count,index},stepgen{maxvel,scale}}
18:39:43 <SWPadnos> yes
18:40:36 <rayh> * rayh shuffles a bit.
18:40:41 <SWPadnos> I'll have to look at how the HAL data is stored.  I think it's a flat array, with pointers to the parent comp, rather than a hierarchy that you can get to via the comps
18:41:19 <rayh> If we think graphically for a moment,
18:41:49 <rayh> I build a set of widgets, some are leds some are numerical displays
18:42:05 <rayh> and I build them from first to last around the canvas
18:42:41 <rayh> It is easiest if I associate a HAL name with each but reference their values from first to last.
18:43:22 <SWPadnos> the order is critical if the names aren't returned as well, so the ordering will be as you request
18:43:23 <rayh> That way any user can make the display look the way they want rather than the way I want.
18:43:40 <rayh> Yep.
18:44:03 <SWPadnos> you'll get a response line like "true 5.001 false 220 16.5 false true true"
18:44:13 <SWPadnos> you'd better know what's what ;)
18:44:18 <rayh> exactly
18:44:33 <SWPadnos> oh yeah, and throw in the occasional "N/A" as well
18:44:55 <rayh> a test for N/A is fairly easy.
18:45:22 <SWPadnos> it would always be the same, and only if the item doesn't exist
18:45:42 <rayh> and done right, tcl ignores any logics after it.
18:45:42 <SWPadnos> (so you can have a list of things to watch, and don't get screwed if some component isn't loaded)
18:46:43 <rayh> In fact, we could look to see if iocontrol is available and if not gray out anything that needs it.
18:47:01 <SWPadnos> you'd have to do that with halcmd though
18:47:04 <rayh> In these standard tuning or watching lists.
18:47:14 <rayh> Yes.
18:47:21 <SWPadnos> (since this wouldn't have a show or list command)
18:47:32 <rayh> The tree does that during refresh.
18:51:10 <SWPadnos> well - let me poke around a little with this - I've started ripping stuff out of halcmd (in a new file of course)
18:52:03 <rayh> k  I'll work at making right and left click work on the canvas.
18:52:12 <SWPadnos> heh - OK.
22:15:45 <logger_devel> logger_devel has joined #emc-devel
22:15:45 <kornbluth.freenode.net> topic is: "Welcome to the Enhanced Machine Control development place. | Regular Developers' meetings 24/7 !"
22:15:45 <kornbluth.freenode.net> Users on #emc-devel: logger_devel rayh anonimasu SWPadnos alex_joni LawrenceG cradek jtr_ @ChanServ 
23:04:09 <rayh> rayh has quit