Re: [Emc-users] and now for something completely different---visualizing EMC2 configurations
On 10/22/2011 10:47 AM, Andrea Montefusco wrote: > Hi Kent, all, > > another example of a software similar to what you are developing is GNU Radio > Companion. > > http://www.joshknows.com/grc > > Albeit it is from a totally unrelated field (digital radio and DSP), this > software too deals with > blocks, wires and so on. > Moreover it generates python code that implements the interconnections that > the user draws, > producing a fully functional Python program. > It is written in Python with pygtk. > > http://gnuradio.org/redmine/projects/gnuradio/repository/revisions/96a20bb09dc6b07b3d2651645e579dff6c3f3a45/entry/grc/ > > Just my 0.02 EU. > > > *am* > Well, nuts. Here I was trying to avoid thinking about graphical programming of emc2 configurations (I just want to document them) AND trying to keep from getting involved in software radio (I was a fledgling amateur radio operator by 15 and sat for my commercial radiotelephone and radiotelegraph license exams before I got out of high school---I left radio behind years ago but still have a yen, in the manner of a 'reformed' smoker). Thanks for the link, Andrea, I think:-) Regards, Kent -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] and now for something completely different---visualizing EMC2 configurations
Hi Kent, all, I found the gnuradio stuff a while back, and put it in the 'cool graphing collection' with others. 1) what IS this idea called?, this gui connected block draggable zoomable concept called? i now its part of graph theory, but this is specialized, its in every eda and plumbing package. it seems there'd be a name for this discipline, something searchable, learnable 2) how do you begin untangling this bit from the main program to make it a standalone tool? (besides its always some new language like LUA or PL3 or C#-+ ;) 3) didja see grasshopper for gmax ( 3D cam behind CNCtoolkit ?) http://modelab.nu/wp-content/uploads/2009/11/ListManagement.jpg theres some wicked guis out there for this connected block stuff i been looking at this graphing for years, part of my love of maps & links regards tomp -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] and now for something completely different---visualizing EMC2 configurations
On Saturday, October 22, 2011 11:24:09 AM Andrea Montefusco did opine: > Hi Kent, all, > > another example of a software similar to what you are developing is GNU > Radio Companion. > > http://www.joshknows.com/grc > > Albeit it is from a totally unrelated field (digital radio and DSP), > this software too deals with blocks, wires and so on. > Moreover it generates python code that implements the interconnections > that the user draws, producing a fully functional Python program. > It is written in Python with pygtk. > > http://gnuradio.org/redmine/projects/gnuradio/repository/revisions/96a20 > bb09dc6b07b3d2651645e579dff6c3f3a45/entry/grc/ > > Just my 0.02 EU. > > > *am* Andrea: This bit of codes ability to graph the connections would, if translated to do the same for ones USB tree, be an informative, handier than bottled beer, utility for linux. We do, or did have, a utility called usbtree that did something similar with tabs and the text output of lsusb, but that seems not to have kept pace with usb development and has been dropped from many distros. I have a copy and its output looks like this: [gene@coyote bin]$ ./usbtree /: Bus 02.Port 1: Dev 1, Class=root_hub, Drv=ohci_hcd/10p, 12M |_ Port 1: Dev 2, If 0, Prod=USB Receiver, Class=HID, Drv=usbhid, 1.5M |_ Port 1: Dev 2, If 1, Prod=, Class=HID, Drv=usbhid, 1.5M |_ Port 9: Dev 3, If 0, Prod=Belkin UPS, Class=HID, Drv=usbhid, 1.5M /: Bus 01.Port 1: Dev 1, Class=root_hub, Drv=ehci_hcd/10p, 480M |_ Port 2: Dev 3, If 0, Prod=, Class=hub, Drv=hub/4p, 480M |_ Port 3: Dev 8, If 0, Prod=USB FAST SERIAL ADAPTER, Class=vend., Drv=ftdi_sio, 12M |_ Port 5: Dev 48, If 0, Prod=USB2.0 Hub, Class=hub, Drv=hub/4p, 480M |_ Port 2: Dev 52, If 0, Prod=EPSON Scanner 010F, Class=vend., Drv=none, 12M |_ Port 4: Dev 49, If 0, Prod=USB2.0 Hub, Class=hub, Drv=hub/4p, 480M |_ Port 3: Dev 51, If 0, Prod=USB2.0 MFP Hi-Speed, Class=vend., Drv=none, 480M |_ Port 3: Dev 51, If 1, Prod=, Class=print, Drv=usblp, 480M |_ Port 3: Dev 51, If 2, Prod=, Class=stor., Drv=usb-storage, 480M |_ Port 6: Dev 53, If 0, Prod=USB 2.0 Hub [MTT], Class=hub, Drv=hub/4p, 480M |_ Port 4: Dev 54, If 0, Prod=USB 2.0 Hub [MTT], Class=hub, Drv=hub/7p, 480M |_ Port 7: Dev 55, If 0, Prod=USB 2.0 Hub, Class=hub, Drv=hub/4p, 480M Usable, but the graphic display would be even nicer. That last, port 6 branch blows me away. I had ordered some "more better" cables to reach some things in the basement, along with a 10 port hub, all USB 2.0, with the cables purportedly to be 5 meters or 16 feet. Which is about 4 feet short to reach the middle of the pile on that desk. Imagine my surprise to see that they were 10 meters long when I opened the $8.95 bag! But that port 6 is one of those 10 meter, 33 foot, cables and its all signing on as 480M connections. IMO someone has been to school and studied up on radio tech involving transmission lines & VSWR to be able to pull that off. What I originally bought 4 or 5 years ago for that job, 15 footers, were flaky at best at 12M. Needless to say, they will be retired as soon as I am healthy again & feel like stuffing cable through holes in floor joists etc. I (& 3 others) arrived in Cinci to tear down & pack that transmitter with the makings of a cold which has since turned into the real thing. The transmitter was only about 12k lbs, which we reduced to under 1000lb pieces we could move with a pallet jack, but we pretty well cubed out a 26' Penski van box & I have a few hundred lbs of copper stuff in the back of my pickup yet. Both rode real well coming home. But we will need a bulldozer tow to get that puny powered van to the top of the hill its headed for. Cheers, Gene -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Positive, adj.: Mistaken at the top of one's voice. -- Ambrose Bierce, "The Devil's Dictionary" -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] and now for something completely different---visualizing EMC2 configurations
Hi Kent, all, another example of a software similar to what you are developing is GNU Radio Companion. http://www.joshknows.com/grc Albeit it is from a totally unrelated field (digital radio and DSP), this software too deals with blocks, wires and so on. Moreover it generates python code that implements the interconnections that the user draws, producing a fully functional Python program. It is written in Python with pygtk. http://gnuradio.org/redmine/projects/gnuradio/repository/revisions/96a20bb09dc6b07b3d2651645e579dff6c3f3a45/entry/grc/ Just my 0.02 EU. *am* - Andrea Montefusco iw0hdvhttp://www.montefusco.com tel: +393356992791 fax: +390623318709 - -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] and now for something completely different---visualizing EMC2 configurations
On 10/17/2011 5:40 PM, Frank Tkalcevic wrote: > >> -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 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. >>> >>> > >> 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. > Frank: You and Tom are so much more ambitious than I. Your screenshot is gorgeous. I mulled a bit about this appro
Re: [Emc-users] and now for something completely different---visualizing EMC2 configurations
> -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 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 " > > 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
Re: [Emc-users] and now for something completely different---visualizing EMC2 configurations
On 15.10.11 23:12, Kent A. Reed wrote: > 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. Being one of them too, my squint at your nifty diagrams might be less than representative, but I thought that those in "Details part 1" are amazingly neat, and it's hard to believe that they're auto-generated. If "2) 5axis (sim)" and the following diagram have any "messiness", then that lies only in the cross-overs, I feel. Since neither 5axisgui nor parport0 have any output edges, is it manageable to flip them out to the left of the diagram, to eliminate the cross-overs? The diagrams would then be even greater works of art than they already are. Mind you, that avenue closes if your utility has already put stuff out there, as would probably begin to happen in the "gnarly" configs that you're looking for. But presumably collision avoidance is already present, for the status quo to work so well? Erik -- People disagree with me. I just ignore them. - Linus Torvalds, regarding the use of C++ for the Linux kernel -- 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
Re: [Emc-users] and now for something completely different---visualizing EMC2 configurations
On 10/16/2011 06:07 PM, Kent A. Reed wrote: > Your comment about hal files possibly being hierarchical or sequential > is spot on. Handling multiple .hal files would be a trivial extension of > my current script (love that Python!). When I first wrote down what I > thought would be a useful set of program options, one option was to > accept an .ini file as the defining entity and let it pull in all > relevant .hal files (handling variable substitution of course). I > haven't gotten around to it. To be honest, once I started extracting > configurations from running EMC2 I didn't feel the need since EMC2 has > already done the work for me. Kent, thank you for the effort to put this together. I'm sure it will be very useful. Using EMC2's output as a predictable and syntactically consistent input seems like a good expedient. An extension, which is probably a fair amount of work, might be to make diagram annotations from the hal files. It could import the hal files directly and parse them for comments of a predefined form. Such comments could wind up as text in a place on the diagram, netlist-wise near to where they were found on the hal file. Karl -- 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
Re: [Emc-users] and now for something completely different---visualizing EMC2 configurations
On 10/16/2011 6:24 PM, andy pugh wrote: > On 16 October 2011 04:12, Kent A. Reed wrote: > >> You can see what I'm up to at >> https://sites.google.com/site/manisbutareed (I apologize for the >> small-ish images. > I am quite impressed. It looks like it could be very useful for > visualising other people's configs when answering queries on the > forum, for example. > (I seem to spend more time than I would like poring over other > people's messy HAL) > Andy, it sounds like you and I are of similar mind about this. One of the things I noticed when I generated my first diagrams is that similarities and differences in the wiring of different axes were easy to spot. Of course, whether these differences result from errors is the color of another horse. Regards, Kent -- 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
Re: [Emc-users] and now for something completely different---visualizing EMC2 configurations
On 10/16/2011 4:42 PM, Thomas Powderly wrote: > Kent, > > On Sat, Oct 15, 2011 at 10:12 PM, Kent A. Reed wrote: >> ... >> 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.) >> >> ... > 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 > > your work with graphviz/dotty is nice, thanks! > > regards > TomP > Tom: Thanks for your observations. gEDA was a suite of tools I looked at several years ago but for the reasons I gave on my website I chose not to go that route. Your comments about breaking large models into sheets reminds me of large data-model work I did in the past. None of the existing tools was very easy to use. Most of your comments have to do with using a graphical tool for design and maintenance of an EMC2 configuration. I both agree with them and reiterate that I don't want to go there. I had too much experience dealing with large, multi-sheet graphical models of data when I was still gainfully employed. None of the tools we had available for generating these models were very comfortable and they were hopeless at modifying an existing one. Bi-directional tools remain the dream rather than the reality. Your comment about hal files possibly being hierarchical or sequential is spot on. Handling multiple .hal files would be a trivial extension of my current script (love that Python!). When I first wrote down what I thought would be a useful set of program options, one option was to accept an .ini file as the defining entity and let it pull in all relevant .hal files (handling variable substitution of course). I haven't gotten around to it. To be honest, once I started extracting configurations from running EMC2 I didn't feel the need since EMC2 has already done the work for me. I have thought briefly about dealing with other aspects of the EMC2 configuration such as threads and parameters but so far my ideas have been very pedestrian. Regards, Kent -- 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
Re: [Emc-users] and now for something completely different---visualizing EMC2 configurations
On 10/16/2011 1:14 PM, Kirk Wallace wrote: > On Sat, 2011-10-15 at 23:12 -0400, Kent A. Reed wrote: > ... snip >> I've often thought it would be nice to be able to gen >> up visualizations of EMC2 configurations easily and quickly. > ... snip > > This may be totally unrelated other than this link also graphs HAL: > http://wiki.linuxcnc.org/emcinfo.pl?Eagle2HAL > > I use a lot of penciled diagrams (and Inkscape) while setting up my > machines, so I would welcome any improvement on this front. It seems HAL > graphing has a lot of appeal, but hasn't had much traction in the past. > Kirk: It may not be an apt analogy, but I'm looking through the other end of the telescope at the moment. I noted on my website the existence of the Eagle2HAL effort, but it's not the direction I choose to go. EagleCAD is great for what is often called "schematic capture" but as you know it's a manual process. I'd just as soon do the manual work via a text editor (like I said, I'm a lexical kind of guy) just as I preferred to write scripts to drive CAD systems I used in research at work despite their cool GUIs for entering data. Regards, Kent -- 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
Re: [Emc-users] and now for something completely different---visualizing EMC2 configurations
On 16 October 2011 04:12, Kent A. Reed wrote: > You can see what I'm up to at > https://sites.google.com/site/manisbutareed (I apologize for the > small-ish images. I am quite impressed. It looks like it could be very useful for visualising other people's configs when answering queries on the forum, for example. (I seem to spend more time than I would like poring over other people's messy HAL) -- atp "Torque wrenches are for the obedience of fools and the guidance of wise men" -- 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
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 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 " > 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 your work with graphviz/dotty is nice, thanks! regards TomP -- 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
Re: [Emc-users] and now for something completely different---visualizing EMC2 configurations
On Sat, 2011-10-15 at 23:12 -0400, Kent A. Reed wrote: ... snip > I've often thought it would be nice to be able to gen > up visualizations of EMC2 configurations easily and quickly. ... snip This may be totally unrelated other than this link also graphs HAL: http://wiki.linuxcnc.org/emcinfo.pl?Eagle2HAL I use a lot of penciled diagrams (and Inkscape) while setting up my machines, so I would welcome any improvement on this front. It seems HAL graphing has a lot of appeal, but hasn't had much traction in the past. -- Kirk Wallace http://www.wallacecompany.com/machine_shop/ http://www.wallacecompany.com/E45/index.html California, USA -- 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
[Emc-users] and now for something completely different---visualizing EMC2 configurations
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 " 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 -- 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
