Back
[07:15:32] <alex_joni> morning all
[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.