I am totally new to LabVIEW .I am having the block diagram of M-ary communication system:
How can I create the same project by myself?
Where can i find these components?.A step by step approach is welcomed.
I am getting an error in the above simulation
You have two or more cluster data types wired together, but the clusters have different kinds or numbers of elements.
Cluster FSK system parameters, a cluster of 3 elements,
conflicts with cluster ASK system parameters, a cluster of 2 elements.
please help
In your example the broken wire (black dashed wire with the red cross) is caused by connecting two different (incompatible) data types. The vi to the left is passing out the datatype and the two to the right expect .
I think what has happened here is the RF tookit allows you to use both FSK and ASK as modulation types and the wrong one has been selected. The left vi has a polymorphic selector under the icon which can be used to select different operations. If you can change this from FSK(M) to ASK(M) then this should remove the broken wire.
There is an example on the NI website that my be of use to you. This includes steps to create a working vi: RF Simulation Demo: Amplitude Shift Keying
Related
I am writing an optimization code for a finite-difference radiation solver model. I started to use "src_indices" for connecting parameters rather promoting all the variables. But when I changed the connection, optimization does not calculate derivatives, gives "no impact to objective" error, and successfully terminates optimization after first iteration. Could not find any clue for finding the error in the logs (Bug may be in a completely different reason).
Is there any suggestion where I can start?
I uploaded the code to GitHub https://github.com/TufanAkba/opt_question
The first thing that comes to mind when you mention "design variables have no impact on objective" is that there may be a missing connection. Since this behavior only started after you changed the connection style, I think this is even more likely.
There are a couple of tools you can use to diagnose this. The first is the n2 viewer, which you can launch by typing the following at your command prompt:
openmdao n2 receiver_opt.py
This will launch a browser window that contains a graphical model viewer which is described in detail here. You can use this to explore the structure of your model. To find unconnected inputs in your model, look for any input blocks that are colored orange. These are technically connected to a hidden IndepVarComp called _auto_ivc, and will include design variables, which are set by the optimizer. You will want to look for any that should be connected to other component outputs.
OpenMDAO also has a connection viewer that just shows connections.
openmdao view_connections receiver_opt.py
You can use this tool to just focus on the connections. It is described here. If you choose to use this, just filter to see any connection to _auto_ivc in the source output string to see the unconnected inputs.
If you reach this point, and are satisfied that all the connections are correct, then there are a couple of other possibilities:
Are all of your src_indices correct? Maybe some of them are an empty set, or maybe some create a "degenerate" case. For example, if you have a set of cascading components that each multiply an incoming vector by a diagonal matrix, and if your indices are [0] in one connection, and [4] in another connection, then you've effectively severed the entire model. None of our visualization tools can pick that up, and you will need to inspect the indices manually.
It could also be a derivative problem, though what you describe sounds like connections. In that case, I recommend using check_partials to look for any missing or incorrect derivatives.
Are you computing any derivatives using complex step? It is possible that you are losing the complex part of the calculation through a complex-unsafe operation. Checking your derivatives against 'fd' can help to find these.
When using SUMO to create a grid network, it seems we have to define route for different types of vehicles. But for a large grid network such as 10*10, it would be impossible to manually input the routes for different flow, especially when considering turning at intersections.
My goal is to have a large network, let flow run throught it with certain turning probabilities at intersections. Then I wish I could use traCI to control the signal lights.
There are a few ways as to how you could manage multiple routes:
Define trip and/or flow with to edge and from edge attributes. The DUAROUTER application will find the shortest route possible or the best route possible (if edge-weights are provided)
The above (point 1) can also be achieved if fromTaz/toTaz (Traffic Assignment Zones) are assigned
NOTE - For both point 1 and 2, the via attribute can force the vehicles to travel through a given edge or a given set of edges.
Another way to generate multiple routes is to generate the 10*10 network and to note down (in the program) all the connections (this is done so that SUMO does not throw any no connection errors). A simple program can be written in conjunction with TraCI, that turns the vehicle from a given edge to a different edge on any junction. Given that this will be time consuming, but if your focus is not on the overall simulation time, this approach will be the most apt for you.
Another way is to add rerouter devices on all edges leading to a junction. You can define new destinations and routes here. This will be the easiest solution for a large network.
I have three inputs in merge signals in different time, the out put of merge signals appeared to wait for all signals and outputted them. what I want is to have an output for every signal (on current output) as soon as it inputted.
For example: if I write (1) in initial value. 5,5,5 in all three numeric. with 3 sec time delay, I will have 6,7,and 16 in target 1, target 2, and target 3. And over all 16 on current output. I don't want that to appear at once on current output. I want to have as it appears in target with same time layout.
please see attached photo.
can anyone help me with that.
thanks.
All nodes in LabVIEW fire when all their inputs arrive. This language uses synchronous data flow, not asynchronous (which is the behavior you were describing).
The output of Merge Signals is a single data structure that contains all the input signals — merged, like the name says. :-)
To get the behavior you want, you need some sort of asynchronous communication. In older versions of LabVIEW, I would tell you to create a queue refnum and go look at examples of a producer/consumer pattern.
But in LabVIEW 2016 and later, right click on each of the tunnels coming out of your flat sequence and chose “Create>>Channel Writer...”. In the dialog that appears, choose the Messenger channel. Wire all the outputs of the new nodes together. This creates an asynchronous wire, which draws very differently from your regular wires. On the wire, right click and choose “Create>>Channel Reader...”. Put the reader node inside a For Loop and wire a 3 to the N terminal. Now you have the behavior that as each block finishes, it will send its data to the loop.
Move the Write nodes inside the Flat Sequence if you want to guarantee the enqueue order. If you wait and do the Writes outside, you’ll sometimes get out-of-order data (I.e. when the data generation nodes happen to run quickly).
Side note: I (and most LabVIEW architects) would strongly recommend you avoid using sequence structures as much as possible. They’re a bad habit to get into — lots of writings online about their disadvantages.
I'm currently a Mechanical Engineering student that is looking into a project on Intelligent Manufacturing.
I have been using AnyLogic to explore manufacturing simulation. I have created a basic Jobshop that involves that transportation of material pallets from delivery to storage to processing. My next step is to transition this static scheduling system to a dynamic scheduling system.
I would like to know if there is any way to actively manipulate the simulation whilst it is running? For example, controlling the availability of processing machines in real time or triggering a delivery. So far I have been unable to find any way of manipulating the simulation after it has been run.
Does anybody have experience with real time data input into simulation software?
In your model, you can always add control elements (buttons, check boxes, sliders, etc). By adding these in the models you can control your model on runtime. For instance... if you have a variable X equal to 3 in your model, if you use a button, you can add the code X=4; and the variable X will change its value.
My suggestion is for you to explore the different options in the controls palette and refer yourself to the anylogic help to learn how to use each of them.
These controls must be placed in "main" in order to make changes when the simulation is running. If you place them in the simulation experiment window, then you won't be able to use them on runtime.
Your model will look like this:
I have a vhdl module called 'inner_module', with some input and output ports, e.g.
entity inner_module is
port (input1, input2 : in std_logic;
output1, output2 : out std_logic);
end inner_module;
and I want to include (encapsulate?) it in another module, called 'outer_module', that is a sort of interface to 'inner_module', such that I don't have to deal with all its details.
Suppose that 'outer_module' has input and output ports, as in
entity outer_module is
port(outer_input1: in std_logic;
outer_output1: out std_logic);
end outer_module;
which are elaborated and appropriately feed to inner_module with the architecture part of outer_module. Same for the inner outputs, which are elaborated in order to evaluate outer_output1.
Let's say that signals input1 and output1 are meant to drive an external evm, e.g. a dac evm, that is connected to my main EVM (virtex 6).
After checking syntax, synthetizing, ... I have to associate the ports to the pin (with I/O pin planning), but the only port that can be associated are the ones from the top module, and I don't have access to signal input1 and output1.
I can add input1 and output1 in the entity declaration of outer_module, but I'd like to "hide" the fact that I use these signals in order to drive the dac evm (it could be a lot of signals), and simply have the interface with the previous entity declaration for outer_module. I'd like to associated the signals input1 and output1 to the correct pins but without doing this "from the top module".
Is it possible? Any ideas or references on how to do that? Or do I always have to include all the signals to be associated to pins in the top module?
I can think of a possible solution to this, but I don't think it is a good idea. I think what you are trying to avoid something that you should not. By not passing the "hidden" I/O from your lower level block through the higher level block, you are essentially asking for a global signal/port that you can access from anywhere. There is not a physical reason why you should not be able to do this (i.e. you should be able to connect any signal in your design to an FPGA pin), but it is not how someone would expect your VHDL design to work. "No one" likes "global signals" or variables, because you lose the ability to trace where they came from and where they go.
When you look at your I/O of your top level design, you should be thinking of the I/O as the pins of your target device. Anything that talks with the outside world in your design needs to have a input or output in your top level design.
It is not uncommon for top level designs to be very large for this reason - there are typically lots of interconnect. SDRAM interfaces can quickly blow up the number of signals you have in your top level. Here are some things that you can try to reduce the noise and clutter:
Utilize records to group signals of similar purpose/function when connecting between internal blocks. In your design, the inner_module could have an output port, which has a record type, that contains all the signals that you need to output to your DAC EVM in the top level. I would avoid using records in the port map of your top level design. This may cause confusion with the tools, but this could also be my superstition.
Utilize vectors, arrays (or arrays of arrays) in order to manage multi-dimensional data and/or busses. This can greatly reduce clutter. Instead of having bit0, bit1, bit2, you can have a signal (a vector) called bits and all the elements of the signal will be treated in the same way.
Put modules that talk to the physical/external (i.e. a SDRAM interface) in the top level of your design (or one level down), instead of inside the block that needs to use the interface. This avoids needing to bring the external interface signals through (potentially) many layers of modules to get to where your interface is instanciated.
Utilize a good VHDL editor (I like emacs with vhdlmode) which can greatly reduce the number of copy/paste errors you run into by being able to copy an entity (port map) and paste it as an instanciation, as a list of signals, as a component, etc.
Use record types for your top level ports. Declare the records in a package that can be used at both ends of the connection (e.g. in the FPGA and the simulation model for your DAC).
You can hide the details of the actual signals in the record; if you need to update the record, the top level design needs no changes.
As a port can have only one direction (mode, either in, out or inout) it is common to use a pair of records, one containing all the input signals, another for the outputs.
At the outermost level you may need some experimentation to get the tools (UCF files since you mention Xilinx) to correctly connect FPGA pins to record compponents...