> -----Original Message----- > From: Thomas Powderly [mailto:tomp4...@gmail.com] > Sent: Monday, 17 October 2011 7:43 AM > To: Enhanced Machine Controller (EMC) > Subject: Re: [Emc-users] and now for something completely different--- > visualizing EMC2 configurations > > Kent, > > On Sat, Oct 15, 2011 at 10:12 PM, Kent A. Reed <knbr...@erols.com> wrote: > > Gentle persons: > > > > You've kindly put up with me bloviating on all manner of subjects for > > some years now. I owe you a more direct contribution. > > > > Despite the fact that I'm a lexical kind of guy who believes in the > > Tao of Unix (everything should be text that can be piped through > > filters / yada yada yada), I've often thought it would be nice to be > > able to gen up visualizations of EMC2 configurations easily and quickly. > > > > Like most (perhaps all?) my thoughts, this one is not original to me. > > For example, back in 2008 Kirk Wallace wrote to this list "[i]t would > > be nice to have a way to diagram existing HAL files." Later the same > > year, Jon Elson mentioned in regard to a configuration involving his > > PPMC "[s]omeday, I probably need to make a 'wiring' diagram of the hal > > signals and pins." > > > > In response to Kirk, John Kasunich wrote > > > > "The problem with any HAL to schematic (or netlist to schematic) > > program is that it will most likely generate hideous schematics. When > > a circuit designer draws a schematic, he knows what the circuit does. > > He lays out the circuit on the page to clearly convey that information. > > > > "A program that is reading a circuit netlist or a HAL file has no idea > > what the circuit does, so all it can do is plop things down at random > > and draw lines between them. The result might be easier to understand > > than the original file, but I wouldn't count on it. It will almost > > certainly need radically rearranged to make it clear and easy to > > understand." > > > > John was absolutely right but but recently I've been intrigued by the > > thought that "[t]he result might be easier to understand than the > > original file...." > > > > I have spent some of my copious free time (which is actually almost no > > time for reasons I won't go into here) seeing how far I had to go to > > create easier-to-understand visualizations of EMC2 configurations. I'm > > not done but I figured I should show my hand. > > > > You can see what I'm up to at > > https://sites.google.com/site/manisbutareed (I apologize for the > > small-ish images. As soon as I figure out how to implement "click to > > enlarge" on a Google site, I'll do it.) > > > > I expect some will accept nothing less than Manhattan routing (e.g., > > diagrams laid out like a street map of mid-town Manhattan) and I can't > > scratch their itch (although I've got an inkling of an idea). > > > > For those who can live with the (sometimes not so) "aesthetic" routing > > produced by the Graphviz software package I've been experimenting > > with, I have a request. > > > > I'd like to test my experimental hal2html script against potentially > > 'killer' configurations to see if I can break it and all I've got are > > the examples in the EMC2 distribution. > > > > If you have a particularly gnarly configuration running in EMC2, would > > you consider saving it from halcmd using the "save neta <filename>" > > command, dropping the resulting file somewhere accessible to me, and > > notifying me via email? If my script can process it successfully, > > you'll get the results; if it can't, I'll get an idea of what I need to do next. > > > > Thanks in advance. > > > > Regards, > > Kent > > > nice work > i tried same in gEDA > some things for thought > > user may want to hilight a signal and see where it goes > > schematics may get quite large and need 'sheets' ( sub-schematics ), this > necessitates 'off-schema signals' ( like 'continued on page 12a') > > hal files may be hierarchical or sequential in the ini ( like includes or multiply > sequential entries ) > > the ability to move elements would be tricky in html, so a 'frozen' > schematic may be a difficulty/expectation for some > > the library of elements (widgets/comps ) needs an editor > > bi-direction... the ability to start with text or graphs and create the other > > the ability to attach to threads ( micges & i created thread widgets with > prioritized pins ) > > the setting of constants
I played around with something like this when I had a lot of spare time and was learning Qt. Here's a screen shot... http://www.franksworkshop.com.au/img_bin/visualhal.png The plan was to build an editor. Something that could either edit .ini and .hal files, or connect to a live hal environment to edit and monitor live pins and signals (using a probe shaped cursor). There's a component editor to create custom shapes for components (actually, it just imports .svg images and allows you to place the pins). It can call loadrt/loadusr to create a component instance and copy the pins/params directly. Components that didn't have a custom shape are generated based on the pin/param use. Some of the pin's type and direction values are determined from what it was connected to. There are smarts to find name patterns, eg mux.0.in0, mux.1.in0 are treated as separate components, mux.0 and mux.1. Layout is still manual. This is saved as a separate file which is reloaded when editing or viewing. One thing that stopped me (apart from how poorly the code evolved, and no time) was being able to see the direction of the program and how it could/should be used. As a visualisation tool, all it needs is a nice way to layout the components and wires. Same if using it as a monitor. But as an editor, I wasn't happy with what was being presented. Just adding a new component or signal - which hal file should it go into? Splitting up a configuration into multiple hal files doesn't really break them up at all. In the end it is still one big hal file - pins/signals/components are global constructs within the set of hal files. What I was thinking is the need to be able to define a "high-level" component in a hal file - or halx file. Internal to the halx file, all signals, pins, components (loadrt and loadusr) are private, unless they are marked as public. This way it is easier to design a layout visually. It is also easier to share .hal configurations. Of course, this means a lot of work to support these configurations in emc. Emc will need to preprocess the files, rationalise the component use and dynamically create signals and pin mappings based on the halx component name/instance. Of course, after saying all that, maybe it just needs to handle separate hal files as different bound regions on the screen. That's where my brain went off on a tangent. I haven't touched the code for a couple of years. It needs a refactor. It needs some design decisions about what to display on a component, how to handle threads, and parameters. ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
