I was just typing that
OK .. but I'm not sticking around long tonight
I don't care if the first version writes out a new .hal file and makes you restart before changes are seen
even 10-15 mins would be a good discussion
(btw, right now there is no editing ability)
right, I understand that
adding editing (ignore these other issues) is a major task isn't it?
detecting what object you clicked on, deciding whether you want to drag it, delete it, modify it
if a net, might also want to add a pin to it, read its value, etc
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
routing as in layout on the page, right>
but it would not be hard to add a 'reload' button
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
3. let the user enter halcmd commands to create signals or link pins
how did you manually neaten up the drawing?
do you have the ability to drag blocks around already?
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
its funny, your approach to the editor is about 180degrees away from what I was thinking
you start with a hal and make a drawing from it
I was starting with a drawing and making a hal from it
your step 3 would create a new signal by having the user issue halcmds, then regenerate the drawing, and reposition as needed for clarity
instead of drawing the new signal, then issue the halcmd
I can see how that greately reduces the gui code
it still doesn't address the safety issues
other than indirectly
by making it less convenient for the user to change interconnections, he's less likely to do it
there's no way to atomically change a number of HAL items, is there
less is relative to clicking and drawing, its basically the same as doing it with halcmd
you can have the lock, but that doesn't mean it is guaranteed to happen before the base thread runs again...
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
in fact a thread can run right in the middle of changing even a single item
but hal_lib does the changes in a way that tolerates that
thats good to know about the shapes.
does the existing code avoid coincident lines and corners for signals>
no, it's very dumb
dammit, thats about the 10th time I've hit > for ?
each net is a line, so you can't have a "Y"-shape except by covering part of the Y twice
huh and it won't run on my home system for some reason I don't yet fathom
you lost me
oh duh -- wrong halcmd in PATH
are you referring to a net as a pin-to-pin connection?
net == signal
you mean, when it initially draws things, is it the slightest bit smart? no, it's dumb
but if a signal connects pins A, B, and C, that is inherently a wye
No, it's a line from A to B to C
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>
not a T or a Y
ok I think I understand
the initial layout is hallelujah2.png .. pretty dumb, with lots of overlapping lines
oh, it allows angled lines
kinda like a ratsnets for a PCB
then you move around the parts
and after the parts are happy you square up the lines
if axis works on your system, this probably will too: http://emergent.unpy.net/index.cgi-files/sandbox/halgui.py
you are thinking of storing the block locations, and the corners, etc, for the lines?
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
yes, but I don't know where I'll store that stuff
I changed it not to show the parameters, but now it's a bit funny looking
is it in cvs? or do I need to download it
not in cvs yet
one possibility for saving is to store the halcmds needed to create the config, along with the geometrical hints in comments
yeah I've considered that
any form of halcmd save loses ini file references that might have been in the original hal file
"setp pid.0.igain [AXIS_0]IGAIN" becomes "setp pid.0.igain 35"
If I stored it in the ini I'd probably have #BEGIN and #END, only changing that part
hm but if they change anything...
duh.... I completely missed when you posted the url for the code...
any particular place I should put it? (doing RIP)
you can put it where you like
oh sorry .. I thought about repeating it but didn't
I was being blind
it'll probably be the weekend before I have time to work on this much more
so many ideas
so little time
I know the feeling
I'll be thinking about some of the issues
maybe we can talk more tomorrow
SWPadnos: do you know if homing to index works on motenc?
unfortunately, I don't know
I haven't really looked at the motenc driver
I think there might be a small issue with polarity of the index pulse or latch as well.
Don't know if the param can invert that output as well.
you can invert using a HAL block though
Sure that would work.
I think the only one doing homing right is the sim
other drivers don't follow the recent design
you mean the encoder module?
* alex_joni is a bit dizzy
youdidn't get my cold, did you?
SWPadnos: no, was watching a movie
reading back now :)
better than a cold
too much info at once :)