Running 2 time synchronized Qspice simulation, then pass the signal from one sch to the other sch and plot using socket communication.
Long term goal: Cosimulation of a few complex circuit with relatively weak coupling (i.e. PFC + LLC or other system level multi converter sim).
For this one, I wrote the C side code (its very simple modification from the template).
On the python server code, I write the very primitive version of Python server code (loop back the data from one sim to the same sender (same port) which was just a simple modification from the template).
Then use Gemini to place the code into thread, run two threads to serve two different ports (10004 for sine_side and 10005 for tri_side), tell tell it to block the message loop back until the python receive message from two sides, then lastly tell it to cross the input from sine and send it to tri side and vice versa. Thats I get the sim which input signal is sine but the output is triangle.
This is where I first time to using AI to write code to something I am totally unfamiliar (I am bad with python, and absolutely no clue with socket programming). Even so, its not exactly just simple vibe coding where I tell the whole thing and get a ready code. Tried and hoping for vibe coding, but then it hallucinates too much, so I need to really guide each step.
Interesting proof of concept. A couple of thoughts:
I didn’t see that cside.cpp was used at all. Did I miss it?
sine_c..cpp & tri_c.cpp are, I think, identical other than unique evaluation function and instance data struct names. You could have a single DLL. (Change the DLL name in one schematic in one to match the other schematic DLL name to verify.) When loading a DLL into two QSpice simulations, the DLLs are not shared in any way so there’s no need to make them unique. Of course, there might be reason to have separate DLLs if they did different things.
If one simulation terminates early (user cancels the sim or a DLL deliberately terminates), then I think the second simulation will hang with the Python server waiting for a message that will never come. Depending on the use case, adding code to the Python script to terminate if a connection drops might be useful.
Also correct, I originally wanted to use same port for sine_c and tri_c and both of them need to send a different identifier. Anyway, at the end it never work and I decided to use same code with different port access which finally work.
That’s a good idea!
@RDunn , do you know if we can use 2 clients on the same port to connect to one server? It failed when I tried it.
@RDunn
Right now, the suggestion 1,2,3 has been followed through and code has all been updated.
–>github has been updated
and about single port with multiple client, now I can make it work but only with the two clients on two different sch. however if there are two clients in one sch it still not working.
will keep trying about how to get it done, maybe some silly mistake somewhere
Well, before you spend too much time on it, my code demonstrates how to have a single server accept multiple clients on a single port which I understood to be the question. The Server and DLL side to do this are more complicated than using the QSpice Berkeley Sockets stuff. That’s what’s in the referenced paper. I’ll refresh my memory and try to explain further tomorrow.
OK, C-Blocks Basics #12 is specifically about setting up a server that accepts multiple client connections on a single port. You might also want to see #10 & #11.
The primary difference will be in the server connection handling. There is example server code in C++, Java, and Python. You’ll need to strip out much of the message-handling code that you don’t need. You may need to start the server manually before running simulations.
You’ll need to use a privileged port (< 1024, e.g., 666) to allow two components on the same schematic to use the same port. (See footnote in #12 document.) The reason that it works with two schematics is that the two QSpice instances don’t “know about each other.”
