I was trying to use OMNeT++ earlier today but I was unable to get any simulation to run. I tried numerous model simulations but they began hanging at the same place during initialization. I deleted and re-installed OMNeT++, but the problem persists. So even after a fresh install of OMNeT++ v5.5.1 on a Windows 10 v1903 machine, I am unable to run any simulation. This is what I saw when I ran the Aloha sample simulation executable directly after following all the OMNeT++ installation steps:
The Qtenv simulation window starts up but it's completely blank, and I can't actually focus on it, which leads me to believe there's something up with Qt. The program hangs indefinitely at this point. OMNeT++ was configured using the default values found in configure.user.
Any suggestions?
EDIT:
This is the last console output I receive after running QT_LOGGING_RULES="*.debug=true" ./aloha.
This is the last console output I receive after running QT_DEBUG_PLUGINS=1 ./aloha.
Did you connect additional monitor to your computer? Sometimes Windows remember position of an application on non-existed screen. Try to change your screen properties or connect second screen and look for Qtenv window of Aloha simulation.
Besides the above, delete .qtenvrc from samples/aloha.
I am having trouble getting Omnet++, Veins, and Sumo to work together. I am progressing through this tutorial to get started. I am currently on the Final Step and I am getting some error that I was hoping someone had some insight on.
I am installing Omnet++, Veins, and Sumo on a virtual machine in Centos 7. I have been through the installation of these three programs twice and I believe I have correctly completed all the steps, although I am pretty new to linux and could have made a mistake.
Here is a link to a screen shot from Omnet when I run the example code from the Final Step:
The library it failed to load is libosg.so.130. This looks like an Open Scene Graph library. I was getting a very similar error yesterday having to do with a osgEarth library. I was able to get around this by disabling selinux, which was blocking some shared libraries from being accessed. I tried the same solution with libosg with no avail. Is there a different antivirus/firewall on Centos that I should turn off? Or is there another idea I should look into?
Any help would be appreciated! Thanks!
EDIT, SOLUTION: I fixed the error by adding the folder /usr/local/lib64 to my path by editing the bashrc with gedit ~/.bashrc and adding "export PATH=$HOME/omnetpp-5.1.1/bin:$PATH:/path_to_folder" to the bottom of the document.
I am curious about the Lab of Things and i've just started to learn it.
I am studying it in the network lab of my university. We have a z-wave controller stick, 2 on/off switch, 1 dimmer receiver and 1 sensor.
To set and run the platform, i followed the instructions in this link below:
http://www.lab-of-things.com/GettingStartedLoT_Beta1.pdf
While running the source code and adding a z-wave device, I faced an annoying problem here.
After adding the z-wave driver and running the code i saw 4 different device on the dashboard, it looks like below:
I tried to install these nodes and applications but apps are not installed. I think that's why i get an error message like below when i run the platform:
I searched on the internet for this error and i found a discussion like this error but i couldn't apply the solution. In this discussion they say that the applications (alerts, sensor, lights etc.) should be compiled seperately. I tried to do it but Visual Studio still gives the same error.
Here is the link of discussion that i found on the internet:
https://labofthings.codeplex.com/discussions/476781
All answers will be appreciated.
Thank you in advance.
I solved this problem by following these instructions which are written in this link:
https://labofthings.codeplex.com/discussions/476781
" For starters, it looks from the screenshot posted on stackoverflow that you have broken configuration at this point—the access control rules (in output\configs\config\rules.xml) have a reference to module Alerts but that module is not listed in output\configs\config\modules.xml
To fix the config, 1) run reset.bat, which will reset your configuration to default; or 2) fix it manually if you think you understand the semantics.
Then, make sure that the apps you want to use are compiled. Their binaries should show up in output\binaries\pipeline\addin\homeos.hub.apps.alerts.
Then, go through the setup process again, and things should work at this point in time.
A little more on this: we have confirmed that broken configuration will occur when app binaries are not found. We will post a bug fix soon, but for now, the remedy in my original response (reset, compile, then install device) should work. Let us know if you are still seeing issues. "
I hope this would be helpful for someone.
I believe this is similar to the thread: Canon SDK 2.11 on OSX
However the solution there did not work for me. I'm perplexed because I'm not sure how to figure out what has changed. I had some working software, did not work on it over the holiday and now when I open it up to work it fails. Not only my software but the demo app included with the SDK, which I have never changed and indeed used to work just fine.
I have tried with two different cameras (5DmII and 5DmIII) with the same result.
when I try and run the application, the camera is recognized but, as it attempts to open a session it receives a EXC_BAD_ACCESS signal. In each program it happens when a call is made to EdsOpenSession() with this message...
*** -[NSConcreteData release]: message sent to deallocated instance 0x8157af0
Interestingly, when I tried to use the EOS Utility that would crash also. So I updated and now that works great. I followed the suggestion in the above thread and copied the EDSDK.framework from the working bundle to my program and recompiled but I get the same results.
I'm trying to figure out how to contact Canon to get some information but they don't make it easy to get help so I'm appealing to the one group I know is responsive.
The only thing I can think is that sometime over the holiday I updated some critical library without knowing it.
Has anyone else run into and been able to solve this?
I'm running OS X 10.7.5, xcode 4.1, and EDSDK 2.11.3
Solved this. It did turn out to be the same solution as the mentioned link. However, what I was missing was that I needed to also copy the new EDSDK.framework into /Library/Frameworks not just have it in my source directory. This may be because I don't have everything setup correctly in XCode.
I have a program that I run on multiple network PCs. When I compiled the most recent version, it runs extremely slowly on 2 PCs on the network, but runs fine for everyone else.
This used to happen with my old dev PC when I had an additional 2gb RAM installed. When I would remove the additional 2gb and recompile, it would then work fine for everyone.
Now, I am on a completely new machine and am having the same issue. I've tried to rebuild the project after rebooting, but still have the same issue.
For all other PCs, the program loads in about 3-5 seconds. On these 2 PCs, it takes anywhere from 45 seconds to 1.5 mins to load...
One of the PCs is an older Dell Dimension 8200, but the other is a newer OptiPlex that is identical to several other PCs on the network, so this is what is really making it so confusing.
For now, I've had to revert to the old version so it will run correctly for everyone.
Does anyone have any idea of anything to try?
Thanks in advance!!!
Edit:
Ok, it was an exhausting day yesterday trying various things to solve this issue. Here is what I tried and where the problem begins:
Using the new program
Went back to old versions of all updated components, but still had the same issue
Using the old program
I decided to go back to the drawing board and start from the old version of the application and incrementally add the new features a small piece at a time.
Recompiled the old version using the old components - program works fine
Updated to new DevExpress components - program works fine
Updated to new ESBPCS components - program works fine
Updated to new DeepSoftware components - program works fine
Ok, so now we know there is nothing with the component sets I've updated...
Added 1 image to each of 2 image lists - program works fine
Added new database table - program works fine
Added code to open and close the new table - program works fine
Added new action to action list and added a menu item and toolbar button to new action (action does nothing at this point) - program works fine
Added a new BLANK form to the application and added code to open the new form - BAM!!!
So, adding just one form to the application is what's causing the issue! I removed all the code for the opening of the form, commented out the uses clauses and removed the uses entry from the project source and everything is back to normal!
Anybody have any idea about this?
Thanks!
Edit 2:
For #Warren P - here is my .DPR source:
program Scheduler;
uses
ExceptionLog,
Forms,
SchedulerMainUnit in 'SchedulerMainUnit.pas' {FrmMain},
SchedulerDBInfoUnit in 'SchedulerDBInfoUnit.pas' {FrmDBInfo},
SchedulerHistoryUnit in 'SchedulerHistoryUnit.pas' {FrmHistory},
SchedulerOptionsUnit in 'SchedulerOptionsUnit.pas' {FrmOptions},
SchedulerExtVersionUnit in 'SchedulerExtVersionUnit.pas' {FrmExtVersion},
SchedulerSplashUnit in 'SchedulerSplashUnit.pas' {FrmSplash},
SchedulerInfoUnit in 'SchedulerInfoUnit.pas' {FrmInfo},
SchedulerShippedUnit in 'SchedulerShippedUnit.pas' {FrmShipped}; {<-- This is the new form with the issue}
{$R *.res}
begin
Application.Initialize;
Application.Title := 'SmartWool WIP Scheduling Assistant';
Application.CreateForm(TFrmMain, FrmMain);
Application.CreateForm(TFrmDBInfo, FrmDBInfo);
Application.CreateForm(TFrmHistory, FrmHistory);
Application.CreateForm(TFrmOptions, FrmOptions);
Application.CreateForm(TFrmExtVersion, FrmExtVersion);
Application.Run;
end.
And here is the intialization section of the main form to create the splash:
initialization
FrmSplash:=TFrmSplash.Create(Application);
FrmSplash.Show;
FrmSplash.Refresh;
Edit 3:
Anybody??? Please?
It could be that the program is waiting for timeouts when trying to access resources that are not available on that machine such as network drives or Internet hosts.
Try running Process Monitor when starting up your program and look for file open calls. Filter the output so it only shows your process.
http://technet.microsoft.com/en-us/sysinternals/bb896645
Performance problems initially can seem very daunting at first.
I have been on many teams where people have tried to guess at a reason for performance problems. This sometimes works, but is far less effective than actually measuring the code.
When reproducible on a development machine, I would recommend a profiler.
There was a previous question that asked about
Delphi Profiling tools which has several possible tools you could use.
When you can't reproduce the problem on your development machine, then it becomes a bit more difficult, but not impossible. Typically I have found that problems are related to an application dependency that is different, and not performing well. Understanding the external influences on your application can help pinpoint the problem.
Specifically common external problems in some of my applications.
Network
Database
Application Servers
Installation or Data File Location (i.e. Disk Performance)
Virus and Malware Scanners
Other application interring with yours such as a virus.
To monitor for items related to the network (i.e. Database, web services, etc...)
I typically use Wireshark which allows me to see if resources are responding in expected times. My most common problem is poor performing DNS and can found using Wireshark.
You can use the AutoRuns program to determine everything that starts up when your computer does, it's useful in determine differences between machines.
But most of all I have logging that can be turned on in my applications and this allows me to isolate the problem to a specific area of code. This narrowing down to a specific section of code reduces the guessing, and allows you to focus on a few possible problems.
I created a log function for this that I call at specific places (in your case especially during startup). It adds a timestamp to each log text and stores them in a TMemo that is regularly saved. Not only very helpful when debugging, but may also shed some light on your problem.
Are you using code signing - ie Microsoft Authenticode? If so, then outdated certificate authorities on the computers can cause significant delays to startup.
First, I would try to defragment the hard disk. If still slow, I would check the power supply. Maybe your hard disk are getting insufficient energy.
Check if there is the same antivirus software on those 2 problematic computers. If so, then your Delphi application may match byte pattern used in some virus made in Delphi. Update virus definitions to solve it, or report false alarm to antivirus company, or change antivirus software.
Check if there isn't any printer installed on those 2 problematic computers. If it is so, then add any printer and try again.
Idea 1:
One reason I have seen for very slow application load time, is when printing or reporting system components like Developer Express Express Print, are in your application.
The problem I saw when using Developer Express Printing components, is that I had an offline or non-responsive network printer in my list of printers (check the control panel printer icon) that was not responding. Some of those Developer Express components seem to read some information from each printer you have installed, and the solution was to go to those clients, and delete old printers from their control panel, that were no longer being used. Each not-responding network printer added up to 60 seconds for a TCP Timeout, to the startup time of my application.
Update - Idea 2:
Download MS DebugView and install it on the machine that runs slowly. Now go back to your main development PC, open the IDE, open your main project file (right click on the project, view project source in project viewer), this will show you the contents of your main project source file (.dpr). go to the main begin....end. block. Now set a breakpoint on the main begin statement, and single step INTO (not OVER) and you will see all the module initialization sections. In each one add this: OutputDebugString('ModuleName').
Now when you run this inside the Delphi Ide you will see messages, and see how far apart they come in, and understand what is taking a long time to initialize. Instead of installing the delphi ide onto the machine that runs slowly, Debug View (which is less than 400kb single executable) will be run, and it will show you these debug messages, along with a nice time display (##.# seconds) for each message.
MS Debug view is here.
Are you allowing the forms to be constructed on initialization within the DPR source? If so, you may do well to consider whether or not you want those forms sucking up memory the entire time, more-over if you want those forms to be wasting the application's time on load.
A rule of thumb: If the form is used a LOT during the application's execution, allow it to be constructed when the application loads (this will work out faster over-all than constructing the instance "on-demand").
If the form is not used very often at all (for example, a Dialog or an About Box), delete the "Application.CreateForm" line from the DPR source, and instead construct your instance on request...
var
LForm: TfrmAbout;
begin
Application.CreateForm(LForm, TfrmAbout);
try
LForm.ShowModal;
finally
LForm.Free;
end;
end;
Now that form (which may not even be displayed during the program's execution) is not sucking up system resources, and will not slow down the application's load time.
It may not solve your problem 100%, but it should certainly help!