Problem
I have a PLC hooked up to several motors (which are all of the same type) via CanOpen. The PLC is programmed using CodeSys with "Structured Text". In order to activate the motors each one has to run through an initialization state machine, for which I have to send some commands in sequence (Power on, activate etc.). But as far as I understand I have to explicitly assign a variable for each boolean which has to be activated (mot1_power_on, mot2_power_on, mot1_enable, mot2_enable etc.).
Question
How to efficiently initialize several (likewise) motors with CodeSys and structured text, where each has to run through a initialization state machine? I find it bad practice to assign a bool for each motor and each variable and then programming the same code several times. How can this task be handled efficiently? Is there a way to pass the motor or some struct to some function, which then performs this task for each of the motors? In C++ I would instantiate a class to perform this task, but how can this be done in CodeSys where I have to explicitly assign a variable for each motor?
Background
I am new to codesys, but I have some background in c/c++, matlab, python and other coding languages.
Having programmed in C++, I will assume you are familiar with object-oriented programming. Function blocks in CODESYS are really similar to classes in OO languages. So go ahead and create a "motors" class with whatever member variable and methods you wish to use. Instantiate this class for each of your motors (either through individual variables or an array), and make sure whatever code needs to run is called, somehow, from your main program.
I expect the part that will not feel as natural is the part about I/O, and this is what you refer to when you say "assign a variable for each boolean". Because in your project, the (probably BIT rather than BOOL) values you need to read and write have hardware addresses (like %I12.3, %Q3.2). Once you have the classes/instances in place, you still need to tell each instance where to find its own I/O. You would rather not use separate global variables for that, which could lead to code duplication, right?
Here is one way to do it:
Create a structure for each I/O memory block you want to address. The simplest case is all inputs variables are together in I/O memory, and all outputs variables are together too, so that means two structures to define. These structures must match the I/O memory layout bit for bit.
Be careful that TRUE/FALSE I/O is generally exposed as BIT values. When you include consecutive BIT members in your structures, CODESYS will pack them inside bytes (whereas BOOL take up at least one full byte). BIT members are very often needed to ensure a structure matches the true layout of values in I/O memory. Be mindful that all types other than BIT are byte-aligned ; as an example, a lonely BIT variable between to BYTE variables will take up a whole byte.
In your function block, declare variables using your structures as a type, with undefined addresses.
inputs AT %I*: MY_INPUTS_STRUCTURE;
outputs AT %Q*: MY_OUTPUTS_STRUCTURE;
These undefined addresses essentially act as references. Each instance of your function block will receive its own, independent reference. In other for that to work, you have, however, to "map" those undefined addresses to hardware addresses. Under CODESYS this can be done in a couple of ways : you can go to the mapping page of the motor in the project and do it for each variable individually, or you can add a VAR_CONFIG to your project, which will allow you to have one mapping per structure (no need to associate each variable in the structure individually).
Note that when mapping whole structures rather than individual variables, you may have byte order (little-endian vs big-endian) issues to deal with when using multi-byte types if the fieldbus byte order differs from the CPU byte order.
It may seem a bit heavy at first, but once you figure it out it really is not, and it allows you to create function blocks with I/O that can be put in libraries and reused in many projects.
I'm working with veins and OMNeT++ in a scenario that has different types of nodes (cars, pedestrians, and others). For evaluation purposes, I'm getting the std::map using the TraCIScenarioManager::getManagedHosts method based on this post (I also answered one of my related questions).
Now, I want to check the type of each node in the scenario. To be clearer, I want to obtain some kind of list that indicates the type of each node (is it a pedestrian? Is it a bus?). Is there any way to obtain this from the map? Is there any attribute that identifies the node type?
I already can identify the type of nodes through messages adding specifics tags to it, but now I need to obtain the type of node independent of the arrival of messages.
I really appreciate any help you can provide.
TraCIScenarioManager::getManagedHosts returns a std::map<std::string, cModule*> which maps each SUMO identifier to one OMNeT++ cModule*. Depending on how cars, buses, etc differ in your simulation, I can think of multiple ways of figuring out what type of SUMO object a host models.
Maybe they are named differently in SUMO? Then you can use the std::string to tell them apart.
Maybe they are named differently in OMNeT++? Then you can use getFullName() of the cModule* to tell them apart.
Maybe they use different C++ classes as models for their application layers? Then you can use something like getSubmodule() of the cModule* to get a pointer to their application layer module and check if a dynamic_cast<ApplicationOfACar*> of this pointer is successful.
I want to implement an protocol with two radios switched on different frequencies. Can I just add an additional PhyLayer80211p module in the Nic80211p module?
If so, how do I address them? If I see it correctly, the findModule method used in Mac1609_4.cc:37 has no attribute to specify which Phy-module he should return. That way i can't specify which of the two radios should be set to RadioState TX (as well as which frequency it is set to).
Would it differ automatically between the two channels if i just send a message two the right gate to the phyModule and set them on seperate frequencies before? e.g.
sendDelayed(mac, RADIODELAY_11P, lowerLayerOut); vs. sendDelayed(mac, RADIODELAY_11P, lowerControlLayerOut);
Any other tips? Thanks!
I've recently just started learning VHDL again after not having touched it for years. The hope is to use it to develop a control system with various sensor interfaces, etc. I'm fairly competent in embedded C, which has been my go-to language for any embedded projects I've had up until this point, which makes learning VHDL all the more frustrating.
Basically, my issue right now, which I see as my biggest barrier in being able to progress with my intended project, is that I don't know how to develop and incorporate a module that I can just pass variables to and call (like a function in C) to carry out some task, i.e. display an integer 0-9999 on a 4 digit 7-segment display.
I know there are components in VHDL, but that seems like such a long winded way of performing one task. Is there a better way of doing this?
It seems to me like after you've done all the digital tutorials, there's a huge gap in the info on how to actually develop a full system in VHDL.
EDIT : further explanation re: third comment at the bottom. Apologies for the length of this!
VHDL has functions and procedures too, just like C. (OK, C calls its procedures "void functions"!) And, just like C, you can call them from sequential code using the same kinds of sequential code constructs (variables, loops, if statements, case-statements which have some similarities to C's switch), and so on.
So far, all this is synthesisable; some other VHDL features are for simulation only (to let you test the synthesisable code). So in simulation you can - like C - open, read and write files, and use pointers (access types) to handle memory. I hope you can see why these parts of VHDL aren't synthesisable!)
But what is different in VHDL is that you need a few extra lines to wrap this sequential code in a process. In C, that happens for you; a typical C program is just a single process (you have to resort to libraries or OS functionality like fork or pthreads if you want multiple processes)
But VHDL can do so much more. You can very easily create multiple processes, interconnect them with signals, wrap them as re-usable components, use "for ... generate" to create multiple processes, and so on. Again, all synthesisable : this imposes some restrictions, for example the size of the hardware (number of processes) cannot be changed while the system is running!
KEY: Understand the rules for signal assignment as opposed to variable assignment. Variables work very much as in C; signals do not! What they do instead is provide safe, synchronised, inter-process communication with no fuss. To see how, you need to understand "postponed assignment", delta cycles, wait statements, and how a process suspends itself and wakes up again.
You seem to be asking two questions here:
(1) - can I use functions as in C? Very much so; you can do better than C by wrapping useful types and related functions, procedures in a package and re-using the package in multiple designs. It's a little like a C++ reusable class with some stronger points, and some weaker.
(2) can I avoid entities, architectures and components altogether in VHDL? You can avoid components (search for "VHDL direct entity instantiation") but at some point you will need entities and architectures.
The least you can get away with is to write a single process that does your job, receiving inputs (clk, count) on signals and transmitting to the LEDs on other signals.
Create an entity with all those signals as ports, and an architecture containing your process, connecting its signals up to the ports. This is easy - it's just boilerplate stuff. On an FPGA, you also need to define the mapping between these ports and the actual pins your LEDs are wired to. Synthesise it and you're done, right? .. not quite.
Create another "testbench" entity with no external ports. This will contain your entity (directly instantiated), a bunch of signals connecting to its ports, and a new process which drives your entity's input ports and watches its output ports. (Best practice is to make the testbench self-checking, and assert when something bad comes out!) Usually "clk" comes from its own one-liner process, and clocks both testbench and entity.
Now you can simulate the testbench and watch your design working (or not!) at any level of detail you want. When it works - synthesise.
EDIT for more information: re: components, procedures, functions.
Entities/components are the main tool (you can ignore components if you wish, I'll deal with entities later).
Procedures and functions usually work together in a single process. If they are refactored into a package they can be re-used in other like-minded processes (e.g. operating on the same datatypes). A common abstraction is a datatype, plus all the functions and procedures operating on it, wrapped in a package - this somewhat resembles a C++ class. Functions also have uses in any declaration area, as initialisers (aka "factory" pattern in software terms)
But the main tool is the entity.
This is a level that is probably unfamiliar to an embedded C programmer, as C basically stops at the level of the process.
If you have written a physical block like an SPI master, as a process, you will wrap that process up in an entity. This will communicate with the rest of the world via ports (which, inside the entity, behave like signals). It can be parameterised via generics (e.g. for memory size, if it is a memory). The entity can wrap several processes, other entities, and other logic that didn't fit neatly into the process (e.g. unclocked logic, where the process was clocked)
To create a system, you will interconnect entities, in "structural HDL code" (useful search term!) - perhaps a whole hierarchy of them - in a top level entity. Which you will typically synthesise into an FPGA.
To test the system via simulation, you will embed that top level entity (=FPGA) in another entity - the testbench - which has no external ports. Instead, the FPGA's ports connect to signals inside the testbench. These signals connect to ... some of them connect to other entities - perhaps models of memories or SPI slave peripherals, so you can simulate SPI transactions ... some of them are driven by a process in the testbench, which feeds your FPGA stimuli and checks its responses, detecting and reporting errors.
Best practice involves a testbench for each entity you create - unit testing, in other words. An SPI master might connect to somebody else's SPI slave and a test process, to start SPI transactions and check for the correct responses. This way, you localise and correct problems at the entity level, instead of attempting to diagnose them from the top level testbench.
A basic example is shown here :
Note that he shows port mapping by both positional association and (later) named association - you can also use both forms for function arguments, as in Ada, but not C which only allows positional association.
What "vhdlguru" doesn't say is that named association is MUCH to be preferred, as positional association is a rich source of confusion and bugs.
Is this starting to help?
Basically there are two possibilities of handing information to an entity:
At runtime
Entities communicate with each other using signals that are defined inside a port statement. For better readability I suggest using std_logic_vector, numeric_std or even better record types where appropriate. See link below.
At synthesis time
If you want to set a parameter of an entity to a fixed value at synthesis time (for instance the size of a fifo) you might want to use a generic statement. See also link below.
I can also recommend reading this paper. It helped me a lot when coping with system that exceed a certain complexity:
A structured VHDL design method
Some simple generalizations for entity/component vs subprogram (function / procedure).
Use an entity when a reusable block of code contains a flip-flop (register).
Use a function do to a calculation. For RTL code, I use functions for small, reusable pieces of combinational logic.
I primarily use procedures for testbenches. I use procedures to apply a single transaction (waveform or interface action) to the design I am testing. For testbenches, I further use procedures to encapsulate frequently used sequences of transactions.
let's say I have created several separate FSM classes inheriting from statechart. Then, I instantiate those objects, and I would like them to be able to trigger events in each other; for example the first FSM would enter a "ON" state and would trigger an event in the second FSM (like process_event(EvSomething()) ).
What would be the best method to do that?
Thank you very much,
Fabrizio
The main motivation for Asynchronous State Machines is exactly the scenario you describe. So, I would suggest you convert your machines into asynchronous ones. See here for an example.