Re: gEDA-user: On integrating simulator in gschem
I've added a link to oscopy, gsim and dataplot to the wiki: http://geda.seul.org/wiki/geda:data_plotting_improvements#draft4a_new_plotting_application Thanks Werner! Here is the new the homepage of oscopy: http://somewhere-in-the-space.no-ip.org/wiki/doku.php?id=oscopy Arnaud. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: On integrating simulator in gschem
Hi Arnoud and all, On Samstag, 13. März 2010, Arnaud Gardelein wrote: The question of integrating into gschem a simulator (namely gnucap) was recently discussed here. With the help of Ivan I'm writing a viewer, oscopy (http://repo.or.cz/w/oscopy.git) based draft #4 of this page: http://geda.seul.org/wiki/geda:data_plotting_improvements Although far from being completed, oscopy support running a netlister and a simulator, I mean there is a menu option FileRun netlister and simulate... where you can specify which command to use. It run both, and then automagically update the loaded signals, recursively for the maths-based ones. Since basic support for updating through DBus is also implemented, I wrote a small scheme script to integrate it within gschem, like pcb does. Maybe this could be a first start to what is described here: http://geda.seul.org/wiki/geda:circuit_simulation_improvements I've added a link to oscopy, gsim and dataplot to the wiki: http://geda.seul.org/wiki/geda:data_plotting_improvements#draft4a_new_plotting_application The symbols of the gsim and it's output looks promising. Unfortunatly I can't read the slovakian text. http://kiwiki.fmtnuni.sk/mediawiki/index.php/Description_of_gsim The example list looks great, too: http://kiwiki.fmtnuni.sk/mediawiki/index.php/Pr%C3%ADklady_a_%C3%BAlohy_pre_gsim Regards Werner ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: On integrating simulator in gschem
Arnaud Gardelein wrote: Would you think a GUI layout similar to digital oscilloscope would help, I mean having a graphical menu on the side of the graph to access those functions ? Sure, that would be welcomed by experienced and newbie alike. It's good form to allow menus to be customized or rearranged, then users familiar with different DSO brands could make or choose a button layout according to their likes. LeCroy Tek Agilent... or none of them, but several different data and derived data layouts for the same time range in the current window. John -- Ecosensory Austin TX ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: On integrating simulator in gschem
On Mar 15, 2010, at 6:35 PM, Dan McMahill wrote: I spend a *lot* of time looking at simulator output and some of the things which are used over and over again are easy interactive zoom in/out, panning at a fixed zoom, putting cursors on waveforms that will lock onto the actual datapoints, having delta cursors, and having a flexible and *extensible* waveform calculator. The types of postprocessing range from the very simple (out_plus - out-minus) to more complex but standard like an fft to fairly complex custom functions. Good heavens. That's the sort of stuff I do with a digitizing oscilloscope. I could never imagine doing that with simulator output. I think your 2nd sentence hits the nail on the head. Simulator output can be for 2 things. 1) presentation like in a design review or a paper. When you get here, you're supposed to be done 2) this one is where the majority of the time is typically spent. debugging! Is the circuit hooked up right? Is it performing right? Why isn't it working right, why isn't it performing at the level you want. So think of the simulator and waveform viewer as a scope and a spectrum and network analyzer. The interactivity needs to be as easy in a waveform tool as it is in a scope. Since you have the disadvantages of model inaccuracies and simulation time being much longer than real time you want to further disadvantage yourself and you should take advantage of the zero-capacitance voltage probes, ideal current probes, gnucaps ability to access internals like diode junction current versus the charging current, etc. so why not do this with simulator output? This makes perfect sense of course. It's just that I've never even dreamed of doing that with a simulator. The concept just makes my head spin...in a good way. :) -Dave -- Dave McGuire Port Charlotte, FL ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: On integrating simulator in gschem
Ivan Stankovic wrote: On Mon, Mar 15, 2010 at 04:47:05PM -0500, John Griessen wrote: Al wants more info than you get with SPICE netlist formats. So Verilog-ams level of function is possible. While we're at it, was there a consensus on using verilog-ams as the format of choice for Al's translation system? Consensus? Not yet. Al does ask for two way translatable formats, so including enough info to recreate a schematic is implied, but not how exactly appearance matching it will be. I'm thinking of graphic elements as only the generic rectangular boxes at first, then by way of text attributes, add more later. the detailed info to recreate schematic appearance is not needed for effective translation purposes, just connectivity. A reasonable goal is to capture data that assists in putting back a schematic as it was, but not doing the layout part of a schematic. A big assist would be to keep any unique identifiers from schematic symbols until a symbol is changed for simulation purposes. Then one could relate the simulation netlist points to the original schematic points for cross probing, even when the sim netlist is a subset or different in part from the original. Then you could do a process of back annotating, deleting schematic symbols not found in the sim netlist, and saving the modified schematic as an aid to simulation displaying. With a small amount of symbol layout time, your new schematic for cross-probing purpose would be a one-to-one match with the simulation. Al asked for a format for electric/electronic netlists that can include any simulator's or schematic/netlist capture program's circuit information. John -- Ecosensory Austin TX ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: On integrating simulator in gschem
On Tue, Mar 16, 2010 at 11:58 AM, kai-martin knaak grace has them all and more. It doesn't support waveform formats produced by popular analog and digital simulators. It doesn't make it easy to browse a (sometimes very large) signal database, select signals and quickly apply some common EE-specific operations on them. Finally, it wasn't optimized for processing 2 weeks' worth of simulation results efficiently. Those are features that some of good waveform viewers have. Unfortunately none of them is open source and such tool would indeed be very useful, regardless of what the rest of the design flow looks like. Grace and gnuplot are good tools in their own domains. And yes, they are useful for an EE too (e.g. for preparing publication quality plots). IMHO, you underestimate the effort to get were grace and gnuplot already are. I had a look at oscope and it seams fairly well designed. Authors have done a pretty good job so far so I wouldn't be worried about their qualifications. I would certainly not discourage them from further work on their tool. -r ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: On integrating simulator in gschem
kai-martin knaak wrote: [ctrl + ] for zoom, [ctrl - ] for unzoom. panning at a fixed zoom, a) left mouse butten click'n drag in both directions b) scrollwheel vertical, ctrl+scrollwheel horizontal c) drag dedicated scrollbars putting cursors on waveforms that will lock onto the actual datapoints, these are called trackers in xmgrace something must be broken with my grace-5.1.22 install because none of this works for me. -Dan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: On integrating simulator in gschem
On Tue, 16 Mar 2010 07:51:51 -0400, Dan McMahill wrote: something must be broken with my grace-5.1.22 install because none of this works for me. This is probably because I use grace 6, aka v5.99.1 The versioning system sounds familiar to pcb users ;-) ---(kaimartin)--- -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmkop=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: On integrating simulator in gschem
kai-martin knaak wrote: Dan McMahill wrote: So I'd say that especially in the opensource area, a good waveform viewer is not reinventing the wheel. It is time to make a round one instead of the existing square ones! IMHO, you underestimate the effort to get were grace and gnuplot already are. The existing wheel is not square, but a fully functional sports utility vehicle. You just need to add a few extra levers and you have an ideal versatile simulation waveform viewer plus the benefit to produce publication quality printouts. Upon further reflection, I think my analogy was not so good. I want a band saw and have been presented with a table saw. Both are useful, both do their respective jobs well, but one may not do the others job so well. The fact that they are both saws may not make them sufficiently similar to warrant modifying one. This was certainly my conclusion when looking at matlab as a waveform tool (the graphics were just too fundamentally presentation-only) even though it has very power processing. I'll have to try out oscopy and it looks to me like they really are not reinventing everything from scratch anyway. Between dbus for IPC and matplotlib for graphics and python for a language, it looks like there is a lot done already. -Dan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: On integrating simulator in gschem
Dan McMahill wrote: I'll have to try out oscopy and it looks to me like they really are not reinventing everything from scratch anyway. Between dbus for IPC and matplotlib for graphics and python for a language, it looks like there is a lot done already. Seems like matplotlib is full of the wanted features and it's not too far off to get cursors. The oscopy authors aren't reinventing, they're coming from a design viewpoint and reusing solid existing programming. They're already more installable than gwave2 -- I could not get that compiled on debian. python-vte is one of the dependencies before configure will complete. John ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: On integrating simulator in gschem
On Mon, Mar 15, 2010 at 04:47:05PM -0500, John Griessen wrote: So, have you done some translation from gschem primitives to gnucap native format? Or is it just gnetlist spice-sdb backend to gnucap native format? It's the latter, that way was much easier. Al wants more info than you get with SPICE netlist formats. So Verilog-ams level of function is possible. That would be nice to have, yes. In fact, it can be implemented independently of any waveform viewer, given enough time and effort. :) While we're at it, was there a consensus on using verilog-ams as the format of choice for Al's translation system? -- Ivan Stankovic, poke...@fly.srk.fer.hr Protect your digital freedom and privacy, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm; ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: On integrating simulator in gschem
On Mar 17, 2010, at 5:54 AM, Ivan Stankovic wrote: While we're at it, was there a consensus on using verilog-ams as the format of choice for Al's translation system? The format has to have a way to represent graphics. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: On integrating simulator in gschem
On Mar 16, 2010, at 2:00 PM, John Doty wrote: On Mar 17, 2010, at 5:54 AM, Ivan Stankovic wrote: While we're at it, was there a consensus on using verilog-ams as the format of choice for Al's translation system? The format has to have a way to represent graphics. How about embedded SVG? John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: On integrating simulator in gschem
On Mar 17, 2010, at 6:30 AM, Steven Michalske wrote: On Mar 16, 2010, at 2:00 PM, John Doty wrote: On Mar 17, 2010, at 5:54 AM, Ivan Stankovic wrote: While we're at it, was there a consensus on using verilog-ams as the format of choice for Al's translation system? The format has to have a way to represent graphics. How about embedded SVG? The problem there is that it's physically meaningless. No distinction, for example, between nets and mere graphical lines. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: On integrating simulator in gschem
On Mar 17, 2010, at 8:34 AM, John Doty wrote: On Mar 17, 2010, at 6:30 AM, Steven Michalske wrote: On Mar 16, 2010, at 2:00 PM, John Doty wrote: On Mar 17, 2010, at 5:54 AM, Ivan Stankovic wrote: While we're at it, was there a consensus on using verilog-ams as the format of choice for Al's translation system? The format has to have a way to represent graphics. How about embedded SVG? The problem there is that it's physically meaningless. No distinction, for example, between nets and mere graphical lines. Oh, and of course another problem is that there's no standard way to embed it in Verilog. But in those cases where it matters, we have a well defined way to embed Verilog in .sch files, using attributes. So by making Verilog the exchange format, we would substitute a difficult to parse inflexible format for something more suitable that we're already using... John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: On integrating simulator in gschem
On Mar 16, 2010, at 4:34 PM, John Doty wrote: On Mar 17, 2010, at 6:30 AM, Steven Michalske wrote: On Mar 16, 2010, at 2:00 PM, John Doty wrote: On Mar 17, 2010, at 5:54 AM, Ivan Stankovic wrote: While we're at it, was there a consensus on using verilog-ams as the format of choice for Al's translation system? The format has to have a way to represent graphics. How about embedded SVG? The problem there is that it's physically meaningless. No distinction, for example, between nets and mere graphical lines. Ahh, I think were on different pages. I was thinking of representing the symbols, not an interconnection layout. If it's just symbols then you need not have interconnection info. Though SVG can add arbitrary attributes to elements, so a line with a netname tag might do the trick, for interconnect. e.g. path d=M 100 100 L 300 100 L 200 300 z stroke=blue stroke- width=3 netname=this_nets_name / Steve ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: On integrating simulator in gschem
On Monday 15 March 2010, Dave McGuire wrote: On Mar 15, 2010, at 12:32 AM, Dan McMahill wrote: With the help of Ivan I'm writing a viewer, oscopy (http://repo.or.cz/w/oscopy.git) based draft #4 of this page: http://geda.seul.org/wiki/geda:data_plotting_improvements IMHO, there are already very mature open source data plotters out there. Think gnuplot, or grace. What is the rationale in rolling your own? unless I'm missing some key feature of gnuplot and grace, they stink for plotting simulator output. I spend a *lot* of time looking at simulator output and some of the things which are used over and over again are easy interactive zoom in/out, panning at a fixed zoom, putting cursors on waveforms that will lock onto the actual datapoints, having delta cursors, and having a flexible and *extensible* waveform calculator. The types of postprocessing range from the very simple (out_plus - out-minus) to more complex but standard like an fft to fairly complex custom functions. Good heavens. That's the sort of stuff I do with a digitizing oscilloscope. I could never imagine doing that with simulator output. Because you have never used a good simulator/schematic combination. What Dan describes is not only doable, it is what is needed to be taken seriously. Nothing less will do. The functionality of a digital oscilloscope is the minimum. Build that as a base, then you can start to think of what is really needed. I use gwave. It is the best so far, but there is a lot of room for improvement. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: On integrating simulator in gschem
unless I'm missing some key feature of gnuplot and grace, they stink for plotting simulator output. I spend a *lot* of time looking at simulator output and some of the things which are used over and over again are easy interactive zoom in/out, panning at a fixed zoom, putting cursors on waveforms that will lock onto the actual datapoints, having delta cursors, and having a flexible and *extensible* waveform calculator. I've used Ploticus for the output of a datalogger for some Coal Mining equipment. I had it set up to zoom-in on selected time points in 24 hour graphs of 200 HP motors, such as temperature and current, overload curves etc. It is not directly interactive. My program ran Ploticus to create each graph as it was requested. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: On integrating simulator in gschem
On Mar 15, 2010, at 12:32 AM, Dan McMahill wrote: With the help of Ivan I'm writing a viewer, oscopy (http://repo.or.cz/w/oscopy.git) based draft #4 of this page: http://geda.seul.org/wiki/geda:data_plotting_improvements IMHO, there are already very mature open source data plotters out there. Think gnuplot, or grace. What is the rationale in rolling your own? unless I'm missing some key feature of gnuplot and grace, they stink for plotting simulator output. I spend a *lot* of time looking at simulator output and some of the things which are used over and over again are easy interactive zoom in/out, panning at a fixed zoom, putting cursors on waveforms that will lock onto the actual datapoints, having delta cursors, and having a flexible and *extensible* waveform calculator. The types of postprocessing range from the very simple (out_plus - out-minus) to more complex but standard like an fft to fairly complex custom functions. Good heavens. That's the sort of stuff I do with a digitizing oscilloscope. I could never imagine doing that with simulator output. But perhaps it's just too early in the morning. ;) -Dave -- Dave McGuire Port Charlotte, FL ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: On integrating simulator in gschem
Dan McMahill wrote: Kai-Martin Knaak wrote: On Sat, 13 Mar 2010 23:34:17 +0100, Arnaud Gardelein wrote: With the help of Ivan I'm writing a viewer, oscopy (http://repo.or.cz/w/oscopy.git) based draft #4 of this page: http://geda.seul.org/wiki/geda:data_plotting_improvements IMHO, there are already very mature open source data plotters out there. Think gnuplot, or grace. What is the rationale in rolling your own? unless I'm missing some key feature of gnuplot and grace, they stink for plotting simulator output. I got the CLI-view-launcher demo test to work fine on a debian unstable installation. The script to generate various kinds of sim run results windows is just text, to quickly set up what you want. The Matplotlib this is based on seems very complete, so maybe all the wish list functions can be done easily. The GUI-view-launcher demo test stopped without running the script because I didn't understand where the command line was. It's not in the area that looks like a terminal window, but in a text dialog box below that at the bottom border of the window. When I got that right, it runs a little differently, it waits until the command to run the simulator, then puts up the 5 various window displays as in the CLI-view-launcher demo. The command window shows progress as below: ** List of figures Figure 1: horiz Graph 1 : (linear) vgs Figure 2: quad Graph 1 : (linear) iRD Graph 2 : (linear) vgs Graph 3 : (linear) vds vgs Graph 4 : (linear) vds Figure 3: horiz Graph 1 : (linear) vout Figure 4: horiz Graph 1 : (linear) vsqu Graph 2 : (linear) vsqufft Graph 3 : (linear) v1 * Figure 5: horiz Graph 1 : (linear) vs *** Now plotting everything Plot command disabled in UI *** Now change C value in schematic and rerun gnetlist + gnucap Pause command disabled in UI *** Updating *** Now look at figure 3 Plot command disabled in UI Each of the windows has pan, zoom, a list of right click options to change that probably comes from matplotlib. My first exploration of pan did some good, but right mouse zoom, (as documented by hover mouse help popups), got the whole app to freeze. Pretty good overall! I'll help test this further Ivan and Arnaud. John -- Ecosensory Austin TX ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: On integrating simulator in gschem
Dave McGuire wrote: On Mar 15, 2010, at 12:32 AM, Dan McMahill wrote: I spend a *lot* of time looking at simulator output and some of the things which are used over and over again are easy interactive zoom in/out, panning at a fixed zoom, putting cursors on waveforms that will lock onto the actual datapoints, having delta cursors, and having a flexible and *extensible* waveform calculator. The types of postprocessing range from the very simple (out_plus - out-minus) to more complex but standard like an fft to fairly complex custom functions. Good heavens. That's the sort of stuff I do with a digitizing oscilloscope. I could never imagine doing that with simulator output. But perhaps it's just too early in the morning. ;) Hmmm I've had some coffee, gotten the demo to run some more, and it DOES do some of that... zoom right mouse functions after going through a right mouse menu popup and escaping out of that... cursors that snap to datapoints is not implemented...yet... John -- Ecosensory Austin TX ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: On integrating simulator in gschem
On Mon, Mar 15, 2010 at 10:23:02AM -0500, John Griessen wrote: Dave McGuire wrote: On Mar 15, 2010, at 12:32 AM, Dan McMahill wrote: I spend a *lot* of time looking at simulator output and some of the things which are used over and over again are easy interactive zoom in/out, panning at a fixed zoom, putting cursors on waveforms that will lock onto the actual datapoints, having delta cursors, and having a flexible and *extensible* waveform calculator. The types of postprocessing range from the very simple (out_plus - out-minus) to more complex but standard like an fft to fairly complex custom functions. Good heavens. That's the sort of stuff I do with a digitizing oscilloscope. I could never imagine doing that with simulator output. But perhaps it's just too early in the morning. ;) Hmmm I've had some coffee, gotten the demo to run some more, and it DOES do some of that... zoom right mouse functions after going through a right mouse menu popup and escaping out of that... cursors that snap to datapoints is not implemented...yet... Right, there are many things that need to be done, but at least it's a start... What I'd really like to see is a nice integration with gschem and I think the approach outlined at http://geda.seul.org/wiki/geda:circuit_simulation_improvements is very sensible. Imagine having simulation objects with attributes that define simulation type and parameters. Many attributes could be simulator-independent so we could, in theory, support any simulator just by writing a simple script that would convert attributes to simulator-specific directives. The basic idea in lame ASCII art: gschem (schematic) simulator X --- output X \ | |--- oscopy \-- simulator Y --- output Y / The simulator output could then be read, displayed and manipulated by oscopy, which itself is simulator-independent (it's very easy to write a reader for your favorite simulator output format). Oscopy has an additional advantage in that it uses numpy so things like doing arithmetic with signals and FFT are easy to implement. Within gschem, we could support various simulator-specific flows by having custom menus that bring up nice GTK dialogs with additional simulator options etc. The beauty of all this is that most of it doesn't require any changes to gschem and can be implemented almost entirely via plugins and external scripts. -- Ivan Stankovic, poke...@fly.srk.fer.hr Protect your digital freedom and privacy, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm; ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: On integrating simulator in gschem
Ivan Stankovic wrote: The basic idea in lame ASCII art: gschem (schematic) simulator X --- output X \ | |--- oscopy \-- simulator Y --- output Y / The simulator output could then be read, displayed and manipulated by oscopy, which itself is simulator-independent (it's very easy to write a reader for your favorite simulator output format). Oscopy has an additional advantage in that it uses numpy so things like doing arithmetic with signals and FFT are easy to implement. Within gschem, we could support various simulator-specific flows by having custom menus that bring up nice GTK dialogs with additional simulator options etc. The beauty of all this is that most of it doesn't require any changes to gschem and can be implemented almost entirely via plugins and external scripts. Al Davis has been asking for a translator that is external so progress can be made soon and not have to rewrite gschem. What is the plugin status of gschem? Is it anything like pcb's plugin writing? Here's what Al has been asking for in outline form: http://www.geda.seul.org/wiki/glue-projects John ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: On integrating simulator in gschem
On Mon, Mar 15, 2010 at 12:44 PM, John Griessen j...@ecosensory.com wrote: Al Davis has been asking for a translator that is external so progress can be made soon and not have to rewrite gschem. What is the plugin status of gschem? Is it anything like pcb's plugin writing? Here's what Al has been asking for in outline form: http://www.geda.seul.org/wiki/glue-projects Here's a more detailed description of Al's proposed translator: http://www.geda.seul.org/wiki/geda:format_translation Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: On integrating simulator in gschem
On Mon, Mar 15, 2010 at 02:44:05PM -0500, John Griessen wrote: Ivan Stankovic wrote: Within gschem, we could support various simulator-specific flows by having custom menus that bring up nice GTK dialogs with additional simulator options etc. The beauty of all this is that most of it doesn't require any changes to gschem and can be implemented almost entirely via plugins and external scripts. Al Davis has been asking for a translator that is external so progress can be made soon and not have to rewrite gschem. What is the plugin status of gschem? Is it anything like pcb's plugin writing? It's basically a scheme script, oscopy.scm, which is installed to $prefix/geda/share/gEDA/scheme. So you can just 1. download oscopy (for now just clone from the git repo and run autogen.sh) 2. ./configure --prefix=the same prefix you used for libgeda, gschem... 3. make install 4. add (load-from-path oscopy.scm) to your gschemrc and you should see the oscopy menu when you next start gschem. Admittedly, the current usage has many rough edges, but it demonstrates that the idea works. And the four step process described above can hardly be simpler. Here's what Al has been asking for in outline form: http://www.geda.seul.org/wiki/glue-projects Yes, that's exactly how it was done with oscopy. DBUS proved actually very useful and simple to work with. -- Ivan Stankovic, poke...@fly.srk.fer.hr Protect your digital freedom and privacy, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm; ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: On integrating simulator in gschem
Le dimanche 14 mars 2010 à 12:56 +, Kai-Martin Knaak a écrit : IMHO, there are already very mature open source data plotters out there. Think gnuplot, or grace. What is the rationale in rolling your own? In the introduction of the manual, there is some rationale. To sum it up, each data plotter has its own strengths and weakness, but none do gather everything mentioned on the geda plotting improvement page. For example, although gnuplot can do math, AFAIK there is no cursors, and no update through DBus. A year and a half ago, I tried to work on gwave, but there was a dependency problem on guile-gnome and I did not find info gwave2. Then I took the decision for go for my own, taking the geda plotting improvement page as specifications. I designed the oscopy framework to be easily extendable, i.e. adding data import/export filters (Readers/Writers), Graphs, Cursors... I plan to use it also to view results exported by electronic instruments like scopes etc, also to support smith charts, etc... Arnaud. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: On integrating simulator in gschem
Ivan Stankovic wrote: Here's what Al has been asking for in outline form: http://www.geda.seul.org/wiki/glue-projects Yes, that's exactly how it was done with oscopy. DBUS proved actually very useful and simple to work with. So, have you done some translation from gschem primitives to gnucap native format? Or is it just gnetlist spice-sdb backend to gnucap native format? Al wants more info than you get with SPICE netlist formats. So Verilog-ams level of function is possible. John ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: On integrating simulator in gschem
Geoff Swan wrote: I've seen commercial tools that have some predefined grids like rectangular, polar, smith but so far none have taken it to the next level of letting you add custom ones or the custom readout. Just in case you missed it - qucs has a number of plotting outputs including a Smith chart. I don't recall how good it is in terms of the interactivity with datapoints on the various graphs. Having a built in smith chart is better than nothing but having a way for the user to define his/her own types of gridlines and cursor readouts is much better. Smith charts aren't the only ones you might want. -Dan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: On integrating simulator in gschem
Dave McGuire wrote: On Mar 15, 2010, at 12:32 AM, Dan McMahill wrote: With the help of Ivan I'm writing a viewer, oscopy (http://repo.or.cz/w/oscopy.git) based draft #4 of this page: http://geda.seul.org/wiki/geda:data_plotting_improvements IMHO, there are already very mature open source data plotters out there. Think gnuplot, or grace. What is the rationale in rolling your own? unless I'm missing some key feature of gnuplot and grace, they stink for plotting simulator output. I spend a *lot* of time looking at simulator output and some of the things which are used over and over again are easy interactive zoom in/out, panning at a fixed zoom, putting cursors on waveforms that will lock onto the actual datapoints, having delta cursors, and having a flexible and *extensible* waveform calculator. The types of postprocessing range from the very simple (out_plus - out-minus) to more complex but standard like an fft to fairly complex custom functions. Good heavens. That's the sort of stuff I do with a digitizing oscilloscope. I could never imagine doing that with simulator output. I think your 2nd sentence hits the nail on the head. Simulator output can be for 2 things. 1) presentation like in a design review or a paper. When you get here, you're supposed to be done 2) this one is where the majority of the time is typically spent. debugging! Is the circuit hooked up right? Is it performing right? Why isn't it working right, why isn't it performing at the level you want. So think of the simulator and waveform viewer as a scope and a spectrum and network analyzer. The interactivity needs to be as easy in a waveform tool as it is in a scope. Since you have the disadvantages of model inaccuracies and simulation time being much longer than real time you want to further disadvantage yourself and you should take advantage of the zero-capacitance voltage probes, ideal current probes, gnucaps ability to access internals like diode junction current versus the charging current, etc. so why not do this with simulator output? -Dan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: On integrating simulator in gschem
IMHO there are three results in any project: 1. What you want 2. What you asked for 3. What you got Simulators are good for making sure #1 and #2 match (does your design do what you want?). Scopes are good for making sure #2 and #3 match (does the circuit function as designed?). ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: On integrating simulator in gschem
On Mar 15, 2010, at 3:03 PM, Dan McMahill wrote: Geoff Swan wrote: I've seen commercial tools that have some predefined grids like rectangular, polar, smith but so far none have taken it to the next level of letting you add custom ones or the custom readout. Just in case you missed it - qucs has a number of plotting outputs including a Smith chart. I don't recall how good it is in terms of the interactivity with datapoints on the various graphs. Having a built in smith chart is better than nothing but having a way for the user to define his/her own types of gridlines and cursor readouts is much better. Smith charts aren't the only ones you might want. matplotlib allows you to apply generic coordinate transformations to the axis. The readout cursor then applies that same transformation. On a side note. It is a very robust plotting package and I believe it hold it own very easily with gnuplot. When I dive down into plotting with it I can get even better results with matplotlib than with gnuplot, because I can run python code against the graphics that the plots generate. Steve ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: On integrating simulator in gschem
Dan McMahill wrote: IMHO, there are already very mature open source data plotters out there. Think gnuplot, or grace. What is the rationale in rolling your own? unless I'm missing some key feature of gnuplot and grace, they stink for plotting simulator output. I used grace quite a bit, both as an interactive GUI and integrated into the data software of my physics experiment. So let's see: I spend a lot of time looking at simulator output and some of the things which are used over and over again are easy interactive zoom in/out, [ctrl + ] for zoom, [ctrl - ] for unzoom. panning at a fixed zoom, a) left mouse butten click'n drag in both directions b) scrollwheel vertical, ctrl+scrollwheel horizontal c) drag dedicated scrollbars putting cursors on waveforms that will lock onto the actual datapoints, these are called trackers in xmgrace having delta cursors, and having a flexible and extensible waveform calculator. see this page for a cursory list of functions: http://plasma-gate.weizmann.ac.il/Xmgr/doc/trans.html Note, the list of features that can be automatically extracted at the bottom of the page. The types of postprocessing range from the very simple (out_plus - out-minus) to more complex but standard like an fft to fairly complex custom functions. grace has them all and more. My experience with things like gnuplot, matlab, octave (which uses gnuplot), scilab, grace, etc. is that they are no where nearly as interactive as you'd really like for efficiently processing and interacting with simulator data. A powerful feature of grace is the grace_np library. With it a c program can remote control almost all aspects of the GUI, while the GUI is still responsive to user input. That is, you can zoom, pan and inspect data points while the results slowly come pouring in from the simulation. http://plasma-gate.weizmann.ac.il/Grace/doc/UsersGuide.html#ss6.2 other important features like the ability to define custom grid lines (think Smith chart, Nichols chart, and I have at least one that as far as I know only I use) There you've got a point. According to the user manual Smith charts have not yet been ported from xmgr, and Nichols charts are not even mentioned. However, I reckon, it would be easier by orders of magnitude to add the desired custom grid lines to grace than rolling your own fully featured waveform application with GUI, inter process communication and all. Another important feature in a general purpose simulation waveform viewer is to be able to define custom cursor readout transformations. Again, compared to what is already there, this is a minor feature. So I'd say that especially in the opensource area, a good waveform viewer is not reinventing the wheel. It is time to make a round one instead of the existing square ones! IMHO, you underestimate the effort to get were grace and gnuplot already are. The existing wheel is not square, but a fully functional sports utility vehicle. You just need to add a few extra levers and you have an ideal versatile simulation waveform viewer plus the benefit to produce publication quality printouts. That's the beauty of open source -- No need to start from scratch if an application does almost, but not quite fulfill your requirements. ---(kaimartin)--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: On integrating simulator in gschem
On Sat, 13 Mar 2010 23:34:17 +0100, Arnaud Gardelein wrote: With the help of Ivan I'm writing a viewer, oscopy (http://repo.or.cz/w/oscopy.git) based draft #4 of this page: http://geda.seul.org/wiki/geda:data_plotting_improvements IMHO, there are already very mature open source data plotters out there. Think gnuplot, or grace. What is the rationale in rolling your own? Maybe this could be a first start to what is described here: http://geda.seul.org/wiki/geda:circuit_simulation_improvements Any progress toward the goal described in this draft will be greeted with a big cheer by me! An easily accessible simulation would greatly improve the value of the geda suite. ---(kaimartin)--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: On integrating simulator in gschem
IMHO, there are already very mature open source data plotters out there. Think gnuplot, or grace. There is also Ploticus: http://ploticus.sourceforge.net/doc/welcome.html Not as well known as the two you mention. It does a lot of different style graphs. Also better suited to use on web servers. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: On integrating simulator in gschem
Arnaud Gardelein wrote: Although far from being completed, oscopy support running a netlister and a simulator, I mean there is a menu option FileRun netlister and simulate... where you can specify which command to use. It run both, and then automagically update the loaded signals, recursively for the maths-based ones. A python scripted wave viewer seems good to me. I couldn't get it to run yet though... ./oscopy_ui.py [1] 31087 j...@toolbench:/moredata/src-geda-others/oscopy$ Traceback (most recent call last): File ./oscopy_ui.py, line 14, in module import oscopy File /moredata/src-geda-others/oscopy/oscopy/__init__.py, line 3, in module from figure import Figure File /moredata/src-geda-others/oscopy/oscopy/figure.py, line 45, in module import matplotlib.pyplot as plt ImportError: No module named matplotlib.pyplot ./oscopy_app.py [1] 31094 j...@toolbench:/moredata/src-geda-others/oscopy$ Traceback (most recent call last): File ./oscopy_app.py, line 5, in module import oscopy File /moredata/src-geda-others/oscopy/oscopy/__init__.py, line 3, in module from figure import Figure File /moredata/src-geda-others/oscopy/oscopy/figure.py, line 45, in module import matplotlib.pyplot as plt ImportError: No module named matplotlib.pyplot John -- Ecosensory Austin TX ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: On integrating simulator in gschem
I did not have all the dependencies installed. Will do that and report to gEDA list when I get it. John ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: On integrating simulator in gschem
On Sun, Mar 14, 2010 at 01:27:39PM -0500, John Griessen wrote: A python scripted wave viewer seems good to me. I couldn't get it to run yet though... ./oscopy_ui.py [1] 31087 j...@toolbench:/moredata/src-geda-others/oscopy$ Traceback (most recent call last): File ./oscopy_ui.py, line 14, in module import oscopy File /moredata/src-geda-others/oscopy/oscopy/__init__.py, line 3, in module from figure import Figure File /moredata/src-geda-others/oscopy/oscopy/figure.py, line 45, in module import matplotlib.pyplot as plt ImportError: No module named matplotlib.pyplot The README file lists the following dependencies: * python * python-numpy * python-matplotlib * python-dbus The above error says that Python can't find matplotlib. -- Ivan Stankovic, poke...@fly.srk.fer.hr Protect your digital freedom and privacy, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm; ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: On integrating simulator in gschem
Kai-Martin Knaak wrote: On Sat, 13 Mar 2010 23:34:17 +0100, Arnaud Gardelein wrote: With the help of Ivan I'm writing a viewer, oscopy (http://repo.or.cz/w/oscopy.git) based draft #4 of this page: http://geda.seul.org/wiki/geda:data_plotting_improvements IMHO, there are already very mature open source data plotters out there. Think gnuplot, or grace. What is the rationale in rolling your own? unless I'm missing some key feature of gnuplot and grace, they stink for plotting simulator output. I spend a *lot* of time looking at simulator output and some of the things which are used over and over again are easy interactive zoom in/out, panning at a fixed zoom, putting cursors on waveforms that will lock onto the actual datapoints, having delta cursors, and having a flexible and *extensible* waveform calculator. The types of postprocessing range from the very simple (out_plus - out-minus) to more complex but standard like an fft to fairly complex custom functions. My experience with things like gnuplot, matlab, octave (which uses gnuplot), scilab, grace, etc. is that they are no where nearly as interactive as you'd really like for efficiently processing and interacting with simulator data. Also, I'm not sure if any of these plotting tools provide some of the other important features like the ability to define custom grid lines (think Smith chart, Nichols chart, and I have at least one that as far as I know only I use). Another important feature in a general purpose simulation waveform viewer is to be able to define custom cursor readout transformations. Again, a good example is a Smith chart. You might like to have the cursor readout tell you reflection coefficient but you might prefer normalized impedance, or perhaps resistance plus inductance/capacitance, etc. I've seen commercial tools that have some predefined grids like rectangular, polar, smith but so far none have taken it to the next level of letting you add custom ones or the custom readout. So I'd say that especially in the opensource area, a good waveform viewer is not reinventing the wheel. It is time to make a round one instead of the existing square ones! -Dan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: On integrating simulator in gschem
I've seen commercial tools that have some predefined grids like rectangular, polar, smith but so far none have taken it to the next level of letting you add custom ones or the custom readout. Just in case you missed it - qucs has a number of plotting outputs including a Smith chart. I don't recall how good it is in terms of the interactivity with datapoints on the various graphs. Geoff ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: On integrating simulator in gschem
The question of integrating into gschem a simulator (namely gnucap) was recently discussed here. With the help of Ivan I'm writing a viewer, oscopy (http://repo.or.cz/w/oscopy.git) based draft #4 of this page: http://geda.seul.org/wiki/geda:data_plotting_improvements Although far from being completed, oscopy support running a netlister and a simulator, I mean there is a menu option FileRun netlister and simulate... where you can specify which command to use. It run both, and then automagically update the loaded signals, recursively for the maths-based ones. Since basic support for updating through DBus is also implemented, I wrote a small scheme script to integrate it within gschem, like pcb does. Maybe this could be a first start to what is described here: http://geda.seul.org/wiki/geda:circuit_simulation_improvements Arnaud. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
