Back
[02:37:39] <cradek> I was just typing that
[02:37:40] <jepler> OK .. but I'm not sticking around long tonight
[02:37:56] <jepler> I don't care if the first version writes out a new .hal file and makes you restart before changes are seen
[02:38:00] <jmkasunich2> even 10-15 mins would be a good discussion
[02:38:14] <jepler> (btw, right now there is no editing ability)
[02:38:31] <jmkasunich2> right, I understand that
[02:39:02] <jmkasunich2> adding editing (ignore these other issues) is a major task isn't it?
[02:39:30] <jmkasunich2> detecting what object you clicked on, deciding whether you want to drag it, delete it, modify it
[02:39:53] <jmkasunich2> if a net, might also want to add a pin to it, read its value, etc
[02:40:01] <jepler> as I see it, I'm close to having a tool that would produce a schematic of the HAL configuration, which you improve by routing the signals
[02:40:22] <jmkasunich2> routing as in layout on the page, right>
[02:40:25] <jepler> yes
[02:40:31] <jepler> but it would not be hard to add a 'reload' button
[02:41:07] <jepler> so the next stages of functionality that I imagined were: 1. save/load the bends in a net 2. re-load the information from halcmd and reflect it in the running schematic
[02:41:23] <jepler> 3. let the user enter halcmd commands to create signals or link pins
[02:41:47] <jmkasunich2> how did you manually neaten up the drawing?
[02:42:00] <jmkasunich2> do you have the ability to drag blocks around already?
[02:42:02] <jepler> yes
[02:42:17] <jepler> you can move a block by clicking on the white, add a bend by dragging on a wire, or move a bend by dragging it
[02:42:27] <jmkasunich2> ok
[02:42:46] <jmkasunich2> its funny, your approach to the editor is about 180degrees away from what I was thinking
[02:42:54] <jmkasunich2> you start with a hal and make a drawing from it
[02:43:02] <jmkasunich2> I was starting with a drawing and making a hal from it
[02:44:07] <jmkasunich2> your step 3 would create a new signal by having the user issue halcmds, then regenerate the drawing, and reposition as needed for clarity
[02:44:12] <jepler> right
[02:44:20] <jmkasunich2> instead of drawing the new signal, then issue the halcmd
[02:44:48] <jmkasunich2> I can see how that greately reduces the gui code
[02:45:12] <jepler> it still doesn't address the safety issues
[02:45:36] <jmkasunich2> no
[02:45:49] <jmkasunich2> other than indirectly
[02:46:07] <jmkasunich2> by making it less convenient for the user to change interconnections, he's less likely to do it
[02:46:11] <jepler> hah
[02:46:40] <jepler> there's no way to atomically change a number of HAL items, is there
[02:46:48] <jmkasunich2> less is relative to clicking and drawing, its basically the same as doing it with halcmd
[02:46:52] <jmkasunich2> not today
[02:46:59] <jepler> you can have the lock, but that doesn't mean it is guaranteed to happen before the base thread runs again...
[02:47:16] <jmkasunich2> right
[02:47:53] <jepler> I agree that it would be nice to have special shapes for some things, and I think it would not be too hard to add. The "part library" would be something written in Python that would create Canvas items, and give them the appropriate tags
[02:47:53] <jmkasunich2> in fact a thread can run right in the middle of changing even a single item
[02:48:08] <jmkasunich2> but hal_lib does the changes in a way that tolerates that
[02:48:12] <jepler> right
[02:49:22] <jmkasunich2> thats good to know about the shapes.
[02:51:04] <jmkasunich2> does the existing code avoid coincident lines and corners for signals>
[02:51:22] <jepler> no, it's very dumb
[02:51:22] <jmkasunich2> dammit, thats about the 10th time I've hit > for ?
[02:51:44] <jepler> each net is a line, so you can't have a "Y"-shape except by covering part of the Y twice
[02:51:56] <jepler> huh and it won't run on my home system for some reason I don't yet fathom
[02:52:08] <jmkasunich2> you lost me
[02:52:09] <jepler> oh duh -- wrong halcmd in PATH
[02:52:27] <jmkasunich2> are you referring to a net as a pin-to-pin connection?
[02:52:38] <jepler> net == signal
[02:52:42] <jmkasunich2> right
[02:52:53] <jepler> you mean, when it initially draws things, is it the slightest bit smart? no, it's dumb
[02:52:59] <jmkasunich2> but if a signal connects pins A, B, and C, that is inherently a wye
[02:53:24] <jepler> No, it's a line from A to B to C
[02:53:28] <jmkasunich2> are you saying that it draws that as a line from A to B, and another from B to C, and parts of the two may overlap>
[02:53:30] <jepler> not a T or a Y
[02:53:50] <jmkasunich2> ok I think I understand
[02:53:59] <jepler> the initial layout is hallelujah2.png .. pretty dumb, with lots of overlapping lines
[02:54:35] <jmkasunich2> oh, it allows angled lines
[02:56:43] <jmkasunich2> kinda like a ratsnets for a PCB
[02:56:48] <jmkasunich2> then you move around the parts
[02:57:03] <jmkasunich2> and after the parts are happy you square up the lines
[02:57:20] <jepler> yes
[02:58:42] <jepler> if axis works on your system, this probably will too:
http://emergent.unpy.net/index.cgi-files/sandbox/halgui.py
[02:58:44] <jmkasunich2> you are thinking of storing the block locations, and the corners, etc, for the lines?
[02:59:08] <jepler> just make sure the right halcmd on your PATH and run it with 'python halgui.py axis.3 axis.4 ...' where you name the stuff you DO NOT want to see
[02:59:18] <jepler> yes, but I don't know where I'll store that stuff
[02:59:54] <jepler> I changed it not to show the parameters, but now it's a bit funny looking
[03:00:26] <jmkasunich2> is it in cvs? or do I need to download it
[03:00:47] <jepler> not in cvs yet
[03:01:30] <jmkasunich2> one possibility for saving is to store the halcmds needed to create the config, along with the geometrical hints in comments
[03:02:08] <jepler> yeah I've considered that
[03:03:19] <jmkasunich2> any form of halcmd save loses ini file references that might have been in the original hal file
[03:04:09] <jmkasunich2> "setp pid.0.igain [AXIS_0]IGAIN" becomes "setp pid.0.igain 35"
[03:05:19] <jepler> If I stored it in the ini I'd probably have #BEGIN and #END, only changing that part
[03:05:40] <jepler> hm but if they change anything...
[03:05:54] <jmkasunich2> duh.... I completely missed when you posted the url for the code...
[03:05:57] <jmkasunich2> downloading now
[03:06:52] <jmkasunich2> any particular place I should put it? (doing RIP)
[03:07:03] <jmkasunich2> emc2/bin/ maybe?
[03:07:29] <jepler> you can put it where you like
[03:07:43] <jepler> oh sorry .. I thought about repeating it but didn't
[03:07:56] <jmkasunich2> I was being blind
[03:09:32] <jepler> it'll probably be the weekend before I have time to work on this much more
[03:09:42] <jepler> so many ideas
[03:09:44] <jepler> so little time
[03:09:53] <jmkasunich2> I know the feeling
[03:10:06] <jmkasunich2> I'll be thinking about some of the issues
[03:10:17] <jmkasunich2> maybe we can talk more tomorrow
[03:10:53] <jepler> ok
[03:10:58] <jepler> see you
[03:11:23] <jmkasunich2> goodnight
[19:11:57] <cradek> SWPadnos: do you know if homing to index works on motenc?
[19:12:08] <SWPadnos> unfortunately, I don't know
[19:12:20] <SWPadnos> I haven't really looked at the motenc driver
[19:15:25] <rayh> I think there might be a small issue with polarity of the index pulse or latch as well.
[19:15:52] <rayh> Don't know if the param can invert that output as well.
[19:16:08] <SWPadnos> you can invert using a HAL block though
[19:16:19] <rayh> Sure that would work.
[19:24:32] <alex_joni> I think the only one doing homing right is the sim
[19:24:45] <alex_joni> other drivers don't follow the recent design
[19:25:16] <cradek> you mean the encoder module?
[19:25:23] <alex_joni> yeah
[19:25:27] <alex_joni> * alex_joni is a bit dizzy
[19:26:02] <SWPadnos> youdidn't get my cold, did you?
[19:27:30] <alex_joni> SWPadnos: no, was watching a movie
[19:27:32] <alex_joni> reading back now :)
[19:27:35] <SWPadnos> heh
[19:27:41] <SWPadnos> better than a cold
[19:27:47] <alex_joni> too much info at once :)