Ni Multisim 14.1 Activation Code
Victorio Galindo
I purchased and downloaded the student edition of circuit design suite v12. When I go to launch the program I am asked to enter the product code/key to activate the product or begin the evaluation mode. I purchased the student edition so I could do more than the evaluation. Where do I find the activation code so I can begin using this for homework assignments?
how do i get the activation key because i collected the software from a friend via a USB flash drive and the activation key was not found in it.....i really need it urgent cause we are given an assignment which we are to submit on this thursday....
I want to analyse a chaotic generator. And I need to make a bifurcation diagram. So I want to make a device, which will change the parameter in cycle and save the peaks of each simulation (of each iteration) and then make a bifurcation diagram. So I want to make it by using c++ code.
So I've found something like "instruction" but it explains the stuff pretty bad (here is the link: -XX/help/375482B-01/multisim/gaintestexample/#wp252103). For example, I want to test the GAINTEST model. So I don't really understand the first and the sixth points. Because when I launch the Vcvars32.bat through the cmd nothing happens. But the first point of the instruction claims that I should somehow set the inviromental variables.
I am trying to model a nano-electro-mechanical device using an XSPICE c code model in Multisim. I am limping along, as the documentation is very thin with only a couple of examples. Through a lot of trial and error, I am starting to have some success.
Part of what is slowing me down is that I can't see what is going on in the inner workings of my model. I don't seem to be able to open a file to write debug information and I can't print to the console or anything. I have created extra ports in the model so that I can spit out various numbers as voltages to look at things like my internal forces, displacements, etc. (I just connect a resistor to ground and probe the voltage) .
The problem is that sometimes when I change a supply voltage or a load resistor just a little bit, the entire simulation output turns to NaNs and I have no way to set breakpoints and look at internal variables or even print messages.
I'm hoping someone out there has some more experience with this knows some tricks that I haven't figured out yet. I have found the quite thin repository of old documentation at Georgia Tech, but does someone know some place to go for better documentation, examples, and tips?
You are definitely touching the less traveled areas of Multisim (in fact, we didn't know if anyone actually use the code modeling). That you are using it is very interesting to me. I'll also pass on some tips about the way SPICE works. Forgive me if you already know these things
Code modeling is of course a way of extending the simulator by creating new primitive types. The advantages of code modeling are you can create models that you would be unable to create using other primitives, and you may get improved performance. The main disadvantage is they are difficult to create and difficult to debug. While not to discourage you from code modeling, I want to point out that Multsim supports behavioural modeling in many standard SPICE models. You can use this to create very complicated models without resorting to code modeling. The Multisim SPICE Reference section of the User Guide gives lots of details (in particular, sections Mathematical Expressions and Arbitrary Source). The other thing is wires in Multisim do not need to represent electrical signals. As far as the simulator is concerned, these are just numerical values which only become voltages/currents when they are displayed in the GUI. You can use wires to represent other concepts, such as torque and angular velocity, pressure and flow rate, etc. You might be able to use this to represent the mechanical aspects of your system. That said, I'll move on to code modeling.
For debugging, you can create a file using code modeling that will output the inner workings of your model, and with some trickery, you can probably get a lot more information if you need. I modified the GAINTEST example to show you how you can create a file to output from your code model:
As you can see at the end, I'm simply writing a 1 to the file everytime the code model is evaluated, but you can of course write anything here. This isn't the most efficient way since the file must be opened repeatedly, but this will ensure that the file is correctly closed. The code also always appends to the file, so you will need to remove the file everytime you simulate to avoid confusing information, or add code to check if the file exists. I do have a couple of tips that I'll pass on as things that caught me when I was testing this.
Also remember that SPICE will evaluate the model multiple times, without moving forward. I did a DC operating point of a very simple circuit containing this code model and there were 23 points. You'll probably want to add time stamps (use the TIME macro).
As for trickery, code modeling uses "macros" to give easy access to some of the C data structures. I case you haven't found it, they are documented on page 32 of the XSPICE Interface Design Document. You can use these for example to get the current time, which will allow you to identify whether the simulator is trying to converge at a particular time step, has moved forward, or even move backward
Lastly, as I said, this is the first I've heard of someone using the code model interface in Multisim. You mention that you've gotten it to work through trial and error. I would be interested to know some of the problems you encountered so that we can make it easier for other users (and maybe even you). I would also be very interested in finding out more of your application because this is the first I've heard of someone trying to model NEMS/MEMS in Multisim.
Thanks for your response. Seeing that you had success opening a file made me dig a little deeper and I found out that my problem was a permissions problem with Windows 7 where I couldn't write the C: drive at the root level. I can now open a file and write debug information which will make a huge difference.
As for using code modeling, I was definitely starting to get the impression that I am pretty lonely out here. I can only find a few spice packages that claim to support it and Multisim was the only one I could find that at least had a step by step example of how to build a model and get it into a schematic.
My model started as a c code subroutine called by my own simulation engine. It has some pretty complicated surface integrals and non-linear equations involving things like feild emmission, tunnelling, van der waals forces, etc. I am ready to start wrapping a lot more circuit elements around it including op-amp models, and my sim engine isn't going to cut it. I thought it would be great to just be able to call my model from spice, and so here we are.
I was aware that the model would be called multiple times for time steps that would not be kept (pretty comon for adaptive time stepping methods), but cm_analog_integrate() seems to take care of this. I created a test variable that always just integrates 1.0, and it is always exactly equal to the simulation time even when the time step is changing a lot.
The biggest problem I have had was that during the DC analysis, spice would sometimes call my model with a zero on one of the inputs (it was strangely unpredictable when it would do it). Of course, buried very deeply, I had a division by this variable. When this happened the entire simulation output would come out as quiet NaNs. The transient analysis would keep running, just contantly turning out NaNs. This was really hard to find without a debugger.
Another problem I had involved getting the pins to map to the symbol correctly. I have a few differential bidirectional ports. It took me a little while to figure out that these automatically built as pin pairs and that I did not have to specify both pins in the interface file. But it really got messy when I tried to mix single ended ports with differential ports, and I could never get that to work. So now I just stick to differential pairs for everything and that looks like it is working.
By the way, for anyone else finding this thread, I have used a package called Powersim in the past that made it quite easy to drop a DLL block in the schematic and call C code. I have used it extensively to simulate power electronics controllers, but it does not have bidirectional ports and is not a true spice package, so it wasn't quite what I needed this time.
I'm a little suprised that there aren't more people using this powerful method of simulating new types of devices. The Georgia Tech documents are really old and aren't even searchable, so I guess it has never quite caught on.
Without the actual model, I can only use psychic degugging, but I can guess why sometimes you are seeing inputs at 0. Multisim will attempt to get DC convergence two different 'advanced' approaches: GMIN stepping and source stepping. What is probably happening is the GMIN failed, and it was trying source stepping. You can see if this is happening by examining the simulation log (Simulate > Simulation Error Log/Audit Trail). Once this is visible, look for the analysis (Operation performed > Output from analysis). Near the top I think you will find a line something like GMIN stepping failed, followed by source stepping started.
Multisim uses its own control language (derived from NUTMEG). It is similar but not identical to SPICE 3f5. If you use the XSPICE command line interface or simulate using XSPICE commands through the COM API, you will need to use this command language. Unfortunately, it is undocumented. You can, however, use Multisim to determine the commands and syntax to send.
Each of the analyses (Simulate > Analyses) shows the commands that are sent to the simulator. You can combine these with the NUTMEG documentation to perform command line simulations. It will require some trial and error, but I have successfully in the past used this information to perform simulations.
c80f0f1006