Georgios Dagkakis
Hello,
I am new in
OMNET++ and this is my first question here, so please notify if I did not obey
forum rules.
I am
dealing with simulation of production systems and I have used commercial
packages (simul8, plant) and also SimPy. OMNET++ seems to be a very strong
package and although its primary use lies in the simulation of computer
networks, I think it could be used in production systems also.
I found the
queueinglib library that is focused towards this direction. One thing that bugs
me though is that in this library, the queues always work in a way that if the
queue is full the job is dropped. But in a real production line (most of the
times) if a server wants to forward the job in the following queue and the
queue is full, then the server will get blocked and it will forward the job as
soon as the following queue has a free space.
I suppose
this can be modeled with messages going back and forth. Something like having
the machine to wait and when the queue releases a job it should also send a
message like “I have free space” to its predecessor. I think that it will add
much overhead and complexity though. SimPy has a “waituntil” built in function that
does this operation very neatly.
So my questions are:
- Have I misunderstood something in the way that queueinglib works?
- Is there another library that deals with this issue?
- Is the approach I think of correct or there is something simpler that I just overlooked?
Thank you very much in advance!
Rudolf Hornig
On Wednesday, 27 March 2013 10:13:21 UTC+1, Georgios Dagkakis wrote:
Hello,
I am new in OMNET++ and this is my first question here, so please notify if I did not obey forum rules.
I am dealing with simulation of production systems and I have used commercial packages (simul8, plant) and also SimPy. OMNET++ seems to be a very strong package and although its primary use lies in the simulation of computer networks, I think it could be used in production systems also.
I found the queueinglib library that is focused towards this direction.
One thing that bugs me though is that in this library, the queues always work in a way that if the queue is full the job is dropped. But in a real production line (most of the times) if a server wants to forward the job in the following queue and the queue is full, then the server will get blocked and it will forward the job as soon as the following queue has a free space.
I suppose this can be modeled with messages going back and forth. Something like having the machine to wait and when the queue releases a job it should also send a message like “I have free space” to its predecessor. I think that it will add much overhead and complexity though. SimPy has a “waituntil” built in function that does this operation very neatly.
So my questions are:
- Have I misunderstood something in the way that queueinglib works?
- Is there another library that deals with this issue?
- Is the approach I think of correct or there is something simpler that I just overlooked?
Georgios Dagkakis
Hello Rudolf,
thank you very much for your reply! My main work is in the simulation of manufacturing and logistics systems using SimPy. My dealing in OMNeT++ is side work and has the objective to identify the reasons why it has established success in open source simulation (even if its primary domain is different) and if it could also be used for manufacturing. Given this, I will be more than glad to share my observations and thoughts in this direction and try to code some blocks, but since I have other things that are more urgent for me right now I may get delayed sometimes. Hope this is ok.
About what you propose. Let’s say eg that we have server S1 which is followed by queue Q2 of a given capacity.
Every time S1 finishes a job it would check Q2 capacity. If Q2 has some place available it will forward the job. Else it would pause.
Also every time Q2 gets BACK to the state of receiving an item (meaning it was full and it just forwarded a job) it will check if S1 is blocked waiting to forward a job.
I think this would work, even though it would get complex with more advanced logic (eg if the server can get failures which is common in manufacturing). Also it would still require that a server will be followed by a queue and vice versa.
Comparing SimPy with OMNeT++, the whole architecture is different since it is mostly based in threads getting the control of the program, than exchanging messages. SimPy, being based in Python provides all the convenience that python gives (type casting, list processing etc) and as I said it has also the waituntil function that personally I find very helpful for such operations. Of course all of those add a cost in computational time. Also it is still a very primitive package compared to OMNeT++ (lesser documentation, fewer libraries, no IDE etc).
Please let me know if the example I gave is what you meant and if you think it could work. I am a little “rusty” in c to be honest (spoilt by the easiness of python and Java J), but I will try to implement something like it. As I said it might take a little time though.
Thanks again,
George
--
--
Sent from the OMNeT++ mailing list. To configure your membership,
visit http://groups.google.com/group/omnetpp
---
You received this message because you are subscribed to a topic in the Google Groups "omnetpp" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/omnetpp/D0HRCxh2Ris/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to omnetpp+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Rudolf Hornig
thank you very much for your reply! My main work is in the simulation of manufacturing and logistics systems using SimPy. My dealing in OMNeT++ is side work and has the objective to identify the reasons why it has established success in open source simulation (even if its primary domain is different) and if it could also be used for manufacturing. Given this, I will be more than glad to share my observations and thoughts in this direction and try to code some blocks, but since I have other things that are more urgent for me right now I may get delayed sometimes. Hope this is ok.
About what you propose. Let’s say eg that we have server S1 which is followed by queue Q2 of a given capacity.
Every time S1 finishes a job it would check Q2 capacity. If Q2 has some place available it will forward the job. Else it would pause.
Also every time Q2 gets BACK to the state of receiving an item (meaning it was full and it just forwarded a job) it will check if S1 is blocked waiting to forward a job.
I think this would work, even though it would get complex with more advanced logic (eg if the server can get failures which is common in manufacturing).
Also it would still require that a server will be followed by a queue and vice versa.
Comparing SimPy with OMNeT++, the whole architecture is different since it is mostly based in threads getting the control of the program, than exchanging messages. SimPy, being based in Python provides all the convenience that python gives (type casting, list processing etc) and as I said it has also the waituntil function that personally I find very helpful for such operations.
Of course all of those add a cost in computational time.
Also it is still a very primitive package compared to OMNeT++ (lesser documentation, fewer libraries, no IDE etc).
Please let me know if the example I gave is what you meant and if you think it could work. I am a little “rusty” in c to be honest (spoilt by the easiness of python and Java J), but I will try to implement something like it. As I said it might take a little time though.
Georgios Dagkakis
Hi,thank you very much for your reply! My main work is in the simulation of manufacturing and logistics systems using SimPy. My dealing in OMNeT++ is side work and has the objective to identify the reasons why it has established success in open source simulation (even if its primary domain is different) and if it could also be used for manufacturing. Given this, I will be more than glad to share my observations and thoughts in this direction and try to code some blocks, but since I have other things that are more urgent for me right now I may get delayed sometimes. Hope this is ok.
Fine, there is no reason to rush:) We have also lot of work to do in the core simulator and in INET, but it would be great to have some ongoing discussion on this topic. Maybe it will turn into something useful :)
About what you propose. Let’s say eg that we have server S1 which is followed by queue Q2 of a given capacity.
Every time S1 finishes a job it would check Q2 capacity. If Q2 has some place available it will forward the job. Else it would pause.
Yes. The IPassiveQueue interface already has a length() method, so the queue length can be checked.Also every time Q2 gets BACK to the state of receiving an item (meaning it was full and it just forwarded a job) it will check if S1 is blocked waiting to forward a job.
The IServer interface must be extended with a resume() method, so Q2 could notify S1 to send out the result. (probably there we need also an isPaused or isSuspended method just to check if it must be notified.
I think this would work, even though it would get complex with more advanced logic (eg if the server can get failures which is common in manufacturing).
Also it would still require that a server will be followed by a queue and vice versa.
Yes I see this problem, too. This kind of interaction between the modules implies tight coumpling. In queuinglib we usually allow for a module to have infinite number of inputs (i.e. modules have an input gate array). This mechanism would work only if the S1 and Q2 are directly connected 1:1. It may be a big limitation, but I really don't know whether this is a real world problem or not.
Of course there could be more generic solutions for this problem. Like implementing the sever in a way that it can go into different states by receiving different signals from outside and then implement a separate "controller module" that would contain all the logic of gathering information and sending out signals. I.e. the controller would subscribe to any change (queue length, idle state etc.) both in S1 and Q2 and will contain the logic that decides when to stop the server. This way the pause resume logic would be decoupled from the Queue and Server and you would not need to connect the server and queue directly. (as they would be connected indirectly via the controller module).Of course the whole design depends heavily on the real requirements.Comparing SimPy with OMNeT++, the whole architecture is different since it is mostly based in threads getting the control of the program, than exchanging messages. SimPy, being based in Python provides all the convenience that python gives (type casting, list processing etc) and as I said it has also the waituntil function that personally I find very helpful for such operations.
Something similar to waituntil could be implemented also in queuinglib, the question is how do you describe the conditions that should be met to continue.Of course all of those add a cost in computational time.
Is the speed of the simulation is a concern with PySim? I.e. you are usually run simulations that are complex and big enough to make the simulation too long? (OMNeT++ here could have an edge being in C++)
Also it is still a very primitive package compared to OMNeT++ (lesser documentation, fewer libraries, no IDE etc).
Do you find the GUI the IDE a big advantage?
Please let me know if the example I gave is what you meant and if you think it could work. I am a little “rusty” in c to be honest (spoilt by the easiness of python and Java J), but I will try to implement something like it. As I said it might take a little time though.
Yes, the idea is feasible, but probably not the ultimate solution :) One thing that would be useful for us: could you give a simulation scenario that is complex enough to cover all the requirements that a model should cover? This would allow to start thinking about the design of such a model framework.
Rudolf
Rudolf Hornig
On Tuesday, 2 April 2013 17:31:16 UTC+2, Georgios Dagkakis wrote:
Hi,I will work in a scenario and send it to you in the next few days. The problem is that business systems (ie production/service/logistics) can be highly custom. So it will need some work so that it can include at least many typical logic blocks.
I send now to reply to your other comments:
2013/3/28 Rudolf Hornig <ru...@omnetpp.org>
Hi,thank you very much for your reply! My main work is in the simulation of manufacturing and logistics systems using SimPy. My dealing in OMNeT++ is side work and has the objective to identify the reasons why it has established success in open source simulation (even if its primary domain is different) and if it could also be used for manufacturing. Given this, I will be more than glad to share my observations and thoughts in this direction and try to code some blocks, but since I have other things that are more urgent for me right now I may get delayed sometimes. Hope this is ok.
Fine, there is no reason to rush:) We have also lot of work to do in the core simulator and in INET, but it would be great to have some ongoing discussion on this topic. Maybe it will turn into something useful :)nice, thank you for the understanding. Hopefully it may turn to something interesting and useful.About what you propose. Let’s say eg that we have server S1 which is followed by queue Q2 of a given capacity.
Every time S1 finishes a job it would check Q2 capacity. If Q2 has some place available it will forward the job. Else it would pause.
Yes. The IPassiveQueue interface already has a length() method, so the queue length can be checked.Also every time Q2 gets BACK to the state of receiving an item (meaning it was full and it just forwarded a job) it will check if S1 is blocked waiting to forward a job.
The IServer interface must be extended with a resume() method, so Q2 could notify S1 to send out the result. (probably there we need also an isPaused or isSuspended method just to check if it must be notified.
I think this would work, even though it would get complex with more advanced logic (eg if the server can get failures which is common in manufacturing).
Also it would still require that a server will be followed by a queue and vice versa.
Yes I see this problem, too. This kind of interaction between the modules implies tight coumpling. In queuinglib we usually allow for a module to have infinite number of inputs (i.e. modules have an input gate array). This mechanism would work only if the S1 and Q2 are directly connected 1:1. It may be a big limitation, but I really don't know whether this is a real world problem or not.it would be a problem. In real systems a queue may feed many parallel servers or a server many parallel queues.
Also a queue may be connected to a different block (eg an assembly block), which should be of different type than the server.
I do not know exactly how to handle this in c++ (Python type casting is useful in this)
Of course there could be more generic solutions for this problem. Like implementing the sever in a way that it can go into different states by receiving different signals from outside and then implement a separate "controller module" that would contain all the logic of gathering information and sending out signals. I.e. the controller would subscribe to any change (queue length, idle state etc.) both in S1 and Q2 and will contain the logic that decides when to stop the server. This way the pause resume logic would be decoupled from the Queue and Server and you would not need to connect the server and queue directly. (as they would be connected indirectly via the controller module).Of course the whole design depends heavily on the real requirements.Comparing SimPy with OMNeT++, the whole architecture is different since it is mostly based in threads getting the control of the program, than exchanging messages. SimPy, being based in Python provides all the convenience that python gives (type casting, list processing etc) and as I said it has also the waituntil function that personally I find very helpful for such operations.
Something similar to waituntil could be implemented also in queuinglib, the question is how do you describe the conditions that should be met to continue.Of course all of those add a cost in computational time.
Is the speed of the simulation is a concern with PySim? I.e. you are usually run simulations that are complex and big enough to make the simulation too long? (OMNeT++ here could have an edge being in C++)yes i did some (informal) comparison and OMNeT++ is faster as it was expected since it is based on c++. This happens only in express mode. Animation slows the running very much. I do not consider it as a problem though, since animation is good for debugging where speed is not the ultimate goal.
Also it is still a very primitive package compared to OMNeT++ (lesser documentation, fewer libraries, no IDE etc).
Do you find the GUI the IDE a big advantage?Yes I find that they give easiness. I have a couple of problems with the IDE still (it does not recognize some things I have to set some path variables I believe). Now I implement in the IDE but I run through the commandline
Georgios Dagkakis
Hi,
I begin with a primary list of requirements, below I answer to your other questions.
As I said business systems are governed by a great variety of blocks. To attempt a start I will not give an example system but a list of blocks that are commonly used. I will also focus on a production system. Hopefully this will commence some insight that we will expand in specific models and also to services/logistics.
I will follow the logic of the commercial products Plant simulation (Siemens) and Simul8 (Simul8 corporation). I work in a university and I have access to educational licenses. However a free student license for plant can be obtained here -> https://www.plm.automation.siemens.com/en_us/academic/resources/tecnomatix/simulation-download.cfm? It poses constraints in the number of objects etc, but one can view the blocks and build simple models.
So a list of the most important elements is as follows:
· Moving units (MUs): These can be parts in a production flow, but also other types such as containers where parts are loaded or tracks that carry the parts. I believe they can be modeled using the cMessage class.
· Source: Generates MUs. This can be modeled with the source of queueinglib
· Queues: They are permanent blocks were the MUs wait in order to get into activities. The important thing is that they do not perform any processing to the MUs. The discipline may be FIFO, LIFO etc. These already exist in the queueinglib library. The problem is that they should have the ability to be connected to different objects.
· Activities: These are permanent blocks that process the moving parts in some way or another. Some general issues:
o It may have failures (MTTF and MTTR may be declared).
o Most probably if an activity is blocked (eg following queue is full) it does not dispose the part, but it keeps it until there is an empty space. During that time the activity cannot accept new parts.
o It may have setup times
o It is not necessary that they are linked with queues. It is the most common scenario that between 2 machines a queue would exist, but there are cases that they may be directly linked.
o Because of the generic nature Plant, Simul8 and other software would provide means to customize the receiving and disposing strategy. (Most complex logic can be modeled in some kind of internal coding language the package offers)
They may include the following (among others):
o Machines (SingleProc in Plant): the general machine case. It processes a part.
o Assembly: this assemble two or more different kinds of MUs. Eg in a system we may have a pallet were 5 parts can be loaded. This will happen in the assembly. The logic would be something like: Wait for pallet to arrive. Wait for 5 parts to arrive (load one by one). Forward the pallet to the following queue.
o Dismantle: separates MUs that were previously assembled
o Lines, roads etc: Sometimes it is needed to model lines such as conveyors. Conveyors would carry parts with certain speed and they will have certain length.
· Resource: resources need to be used when activities compete for them. Eg we may have 2 machines that get failures and need a worker to fix them. If this worker is physically one person, then if Machine B gets failure while Machine A is on repairing process, then B should wait for the worker to be available. This would typically modelled as a recourse.
· Drain: Exit point of MUs. This can be modeled with the sink of queueinglib
Of course all of those (except the MUs) can be linked using connections. It is typical that an object may have multiple inputs and multiple outputs. The receiving or disposing strategy may be defined from given options (priority, random, cyclic etc) or be customized through code.
The list above is not by any means complete, but it is hopefully a good start
Also it is still a very primitive package compared to OMNeT++ (lesser documentation, fewer libraries, no IDE etc).
Do you find the GUI the IDE a big advantage?Yes I find that they give easiness. I have a couple of problems with the IDE still (it does not recognize some things I have to set some path variables I believe). Now I implement in the IDE but I run through the commandlineLet me know what is the problem. If you start the IDE from the MINGW command (on windows) or you start it from a shell (on Linux/MAC) where the setenv script was properly sourced, you should not have a problem... If you want to start the IDE using an icon then you will need to add the omnetpp/bin directory at least (and omnetpp/mingw/bin and omnetpp/msys/bin on Windows).
Rudolf
Rudolf Hornig
On Tuesday, 9 April 2013 13:09:12 UTC+2, Georgios Dagkakis wrote:
Hi,
I begin with a primary list of requirements, below I answer to your other questions.
As I said business systems are governed by a great variety of blocks. To attempt a start I will not give an example system but a list of blocks that are commonly used. I will also focus on a production system. Hopefully this will commence some insight that we will expand in specific models and also to services/logistics.
I will follow the logic of the commercial products Plant simulation (Siemens) and Simul8 (Simul8 corporation). I work in a university and I have access to educational licenses. However a free student license for plant can be obtained here -> https://www.plm.automation.siemens.com/en_us/academic/resources/tecnomatix/simulation-download.cfm? It poses constraints in the number of objects etc, but one can view the blocks and build simple models.
So a list of the most important elements is as follows:
· Moving units (MUs): These can be parts in a production flow, but also other types such as containers where parts are loaded or tracks that carry the parts. I believe they can be modeled using the cMessage class.
· Source: Generates MUs. This can be modeled with the source of queueinglib
· Queues: They are permanent blocks were the MUs wait in order to get into activities. The important thing is that they do not perform any processing to the MUs. The discipline may be FIFO, LIFO etc. These already exist in the queueinglib library. The problem is that they should have the ability to be connected to different objects.
· Activities: These are permanent blocks that process the moving parts in some way or another. Some general issues:
o It may have failures (MTTF and MTTR may be declared).
o Most probably if an activity is blocked (eg following queue is full) it does not dispose the part, but it keeps it until there is an empty space. During that time the activity cannot accept new parts.
o It may have setup times
o It is not necessary that they are linked with queues. It is the most common scenario that between 2 machines a queue would exist, but there are cases that they may be directly linked.
o Because of the generic nature Plant, Simul8 and other software would provide means to customize the receiving and disposing strategy. (Most complex logic can be modeled in some kind of internal coding language the package offers)
They may include the following (among others):
o Machines (SingleProc in Plant): the general machine case. It processes a part.
o Assembly: this assemble two or more different kinds of MUs. Eg in a system we may have a pallet were 5 parts can be loaded. This will happen in the assembly. The logic would be something like: Wait for pallet to arrive. Wait for 5 parts to arrive (load one by one). Forward the pallet to the following queue.
o Dismantle: separates MUs that were previously assembled
o Lines, roads etc: Sometimes it is needed to model lines such as conveyors. Conveyors would carry parts with certain speed and they will have certain length.
· Resource: resources need to be used when activities compete for them. Eg we may have 2 machines that get failures and need a worker to fix them. If this worker is physically one person, then if Machine B gets failure while Machine A is on repairing process, then B should wait for the worker to be available. This would typically modelled as a recourse.
· Drain: Exit point of MUs. This can be modeled with the sink of queueinglib
Of course all of those (except the MUs) can be linked using connections. It is typical that an object may have multiple inputs and multiple outputs. The receiving or disposing strategy may be defined from given options (priority, random, cyclic etc) or be customized through code.
The list above is not by any means complete, but it is hopefully a good start
Also it is still a very primitive package compared to OMNeT++ (lesser documentation, fewer libraries, no IDE etc).
Do you find the GUI the IDE a big advantage?Yes I find that they give easiness. I have a couple of problems with the IDE still (it does not recognize some things I have to set some path variables I believe). Now I implement in the IDE but I run through the commandlineLet me know what is the problem. If you start the IDE from the MINGW command (on windows) or you start it from a shell (on Linux/MAC) where the setenv script was properly sourced, you should not have a problem... If you want to start the IDE using an icon then you will need to add the omnetpp/bin directory at least (and omnetpp/mingw/bin and omnetpp/msys/bin on Windows).I have problems with the IDE recognizing certain methods. This has to do mostly with the "Define_Module" method but also with methods of the "string.h" library. So I get errors in the IDE while from the command line I can run my code. I suppose it is sime path variables thing. I have used eclipse with java,android and python so I am not completely new to it. I have also used visual studio with c++ in which I had no such problems regarding the "string.h" library.
Georgios Dagkakis
Hello, see inline:
On Tuesday, 9 April 2013 13:09:12 UTC+2, Georgios Dagkakis wrote:Hi,
I begin with a primary list of requirements, below I answer to your other questions.
As I said business systems are governed by a great variety of blocks. To attempt a start I will not give an example system but a list of blocks that are commonly used. I will also focus on a production system. Hopefully this will commence some insight that we will expand in specific models and also to services/logistics.
This is fine too, and the end we should decide what kind of blocks are needed. If other programs have already provide a usable collections of blocks.I will follow the logic of the commercial products Plant simulation (Siemens) and Simul8 (Simul8 corporation). I work in a university and I have access to educational licenses. However a free student license for plant can be obtained here -> https://www.plm.automation.siemens.com/en_us/academic/resources/tecnomatix/simulation-download.cfm? It poses constraints in the number of objects etc, but one can view the blocks and build simple models.
So a list of the most important elements is as follows:
· Moving units (MUs): These can be parts in a production flow, but also other types such as containers where parts are loaded or tracks that carry the parts. I believe they can be modeled using the cMessage class.
Yes, we have "Jobs" in queueinglib, but they lack some functionality, like the possibility to contain other Jobs. If they could store other jobs, we could more easily model the assembly dissasembly part.
· Source: Generates MUs. This can be modeled with the source of queueinglib
· Queues: They are permanent blocks were the MUs wait in order to get into activities. The important thing is that they do not perform any processing to the MUs. The discipline may be FIFO, LIFO etc. These already exist in the queueinglib library. The problem is that they should have the ability to be connected to different objects.
Yes, PassiveQueues can be used for this, but at the moment they can communicate only with servers directly attached to their output (but they cannot communicate with other queues or servers attached to their input). This could be done relatively easily, but only if they are directly connected. Otherwise we have to find a mechanism how to get the info from one queue/activity to the other...· Activities: These are permanent blocks that process the moving parts in some way or another. Some general issues:
o It may have failures (MTTF and MTTR may be declared).
Servers probably need a state machine and some kind of mechanism to go between them, based on these parameters.o Most probably if an activity is blocked (eg following queue is full) it does not dispose the part, but it keeps it until there is an empty space. During that time the activity cannot accept new parts.
As above mentioned this may be implemented relatively easy.o It may have setup times
Does this mean that you can specify at what time it starts/stops (i.e. the running state should be configurable) ? Or just it goes into operational state after a predetermined time after a failure or start.
o It is not necessary that they are linked with queues. It is the most common scenario that between 2 machines a queue would exist, but there are cases that they may be directly linked.
This should not be a problem as soon as a full queue can request a previous server to suspend the same can be done also between servers. I.e. servers could be chained too.
o Because of the generic nature Plant, Simul8 and other software would provide means to customize the receiving and disposing strategy. (Most complex logic can be modeled in some kind of internal coding language the package offers)
queueinglib also have fetching/sendingAlgorithm and can be easily exteded...
They may include the following (among others):
o Machines (SingleProc in Plant): the general machine case. It processes a part.
o Assembly: this assemble two or more different kinds of MUs. Eg in a system we may have a pallet were 5 parts can be loaded. This will happen in the assembly. The logic would be something like: Wait for pallet to arrive. Wait for 5 parts to arrive (load one by one). Forward the pallet to the following queue.
Something more simple is present right now. We can split a Job into subJobs using the Fork nodes and the reassemble the subJobs at an other place. A more general approach would be needed here to be able to specify different Job types to be required.
o Dismantle: separates MUs that were previously assembled
o Lines, roads etc: Sometimes it is needed to model lines such as conveyors. Conveyors would carry parts with certain speed and they will have certain length.
Delays can be used to model this, but they may be needed to extended to support also pause/resume operation.· Resource: resources need to be used when activities compete for them. Eg we may have 2 machines that get failures and need a worker to fix them. If this worker is physically one person, then if Machine B gets failure while Machine A is on repairing process, then B should wait for the worker to be available. This would typically modelled as a recourse.
resource model is present in queueing lib tough the resources are needed to be able to do the work instead of getting out of a state (i.e. getting fixed), but generally you can define resource pools and take some resource from there for processing the job.· Drain: Exit point of MUs. This can be modeled with the sink of queueinglib
Of course all of those (except the MUs) can be linked using connections. It is typical that an object may have multiple inputs and multiple outputs. The receiving or disposing strategy may be defined from given options (priority, random, cyclic etc) or be customized through code.
Is there some kind of requiremt to have some out of flow communication? i.e. some kind of interrupt mechanism where the inforamtion is not propageted along the connections but rather directly. i.e. the last activity can stop the first one without affecting the rest between them? I assume this is required.
My other question is that OMNeT++ is definitely not suited to plan the physical layout of the whole system or do some neat animations. Do you think this would not be a disadvantage?
Also it is still a very primitive package compared to OMNeT++ (lesser documentation, fewer libraries, no IDE etc).
Do you find the GUI the IDE a big advantage?Yes I find that they give easiness. I have a couple of problems with the IDE still (it does not recognize some things I have to set some path variables I believe). Now I implement in the IDE but I run through the commandlineLet me know what is the problem. If you start the IDE from the MINGW command (on windows) or you start it from a shell (on Linux/MAC) where the setenv script was properly sourced, you should not have a problem... If you want to start the IDE using an icon then you will need to add the omnetpp/bin directory at least (and omnetpp/mingw/bin and omnetpp/msys/bin on Windows).I have problems with the IDE recognizing certain methods. This has to do mostly with the "Define_Module" method but also with methods of the "string.h" library. So I get errors in the IDE while from the command line I can run my code. I suppose it is sime path variables thing. I have used eclipse with java,android and python so I am not completely new to it. I have also used visual studio with c++ in which I had no such problems regarding the "string.h" library.You can ignore this safely. Unfortunately this is an issue in the CDT itself. It sometimes cannot figure out the symbols. You can safely turn off this "feature".See the following post : https://plus.google.com/117818518802135929150/posts/5nJoGBHNz2Y
OMNeT++ 4.3 actually disables this feature by default.
It is definitely a good start,Rudolf
--
