Multiple Instances doesn't work in 3.2.2

[RhythmDoctor]

I like to run two instances of OpenCPN side-by-side on my screen. One instance is zoomed in to see local features on the chart, the second instance is zoomed out to see AIS targets coming from far away.

On 3.2.0 and earlier versions, I could easily do this by just launching the program twice within Windows. There was no need to use portable mode.

However, on 3.2.2 this capability appers to have been turned off. If I try to launch the program a second time, nothing happens.

I have confirmed this behavior (of both 3.2.0 and 3.2.2) on two separate machines - a Netbook running Windows XP SP3, and a desktop running Windows 7 64 bit. They both had exactly the same behavior - two instances could run without portable mode under 3.2.0, but not with 3.2.2.

Is there a reason this feature was removed or changed? Is this a bug? Before I change all my current batch files to launch in portable mode, will it launch multiple instances in portable mode, or is this feature completely broken in 3.2.2?

[nohal]

RhythmDoctor...
This was intentionally disabled unless you run in portable mode. This "feature" was actually broken until 3.2.2 as unexpected things could have happened when two instances were fighting for the same config files (which does not mean it had to cause problems if you were nice to them as you probably were).

Pavel

[seandepagnier]

Maybe opencpn should connect to self as a client, and if fails start a server.

Then instances could be syncronized by sharing nmea messages, route and waypoints, cached charts, and in opengl mode, could share textures, and display lists etc..

Or opencpn could support multiple chart windows. Maybe actually both ways are prefered as it gives even more flexibility.

[bdbcat]

RhythmDoctor....

This was disabled on 3.2.2 for two reasons:

1. If you have a quick start icon for O on the taskbar, and you accidentally click it twice (as you would for a desktop icon), or click it instaed of an already running instance of O in the taskbar, then you would get two instances of O running at the same time. Which is not good because...

2. Two instances using the same config files and dynamic navobj.xml is bound to get scrambled sooner rather than later. Both instances will crash, and data will be lost.

One of the items on someone's wish list is the ability to have multiple chart canvases open at the same time, without needing multiple instances of O. This may appear on O 3.4 if sufficient demand and resources materialize.

Meanwhile, portable is the way to go. Multiple "portables" in different directories are just fine.

Thanks
Dave

[RhythmDoctor]

Thanks for the guidance. I realize that when you make these changes, there is usually a good reason for it. Now that I know that multiple instances does still work in portable mode, I will invest the time in configuring it. I can envision that having two instances accessing the same config files could cause unpredictable results, so it's the right thing to force use of portable mode.

Count me as someone who would benefit from two canvases running under one instance, but frankly once I have portable mode working I'll be reluctant to change, just as I was reluctant to change from the way I was doing it before. Once I have something working reliably, I'm always reluctant to change it.

[RhythmDoctor]

Originally Posted by nohal

RhythmDoctor...
This was intentionally disabled unless you run in portable mode. This "feature" was actually broken until 3.2.2 as unexpected things could have happened when two instances were fighting for the same config files (which does not mean it had to cause problems if you were nice to them as you probably were).

Pavel

I must confess that I did some not-so-nice things to the opencpn.ini file to get two instances to work with different settings. Basically I created two different .ini files under different names, and had a batch file copy each one to opencpn.ini just before launching each instance. I realize that it had great potential to wreak havoc, but it seemed to work OK for me.

So now that I have decided to set up portable mode to do the two instances more gracefully, I must ask where/how does opencpn store its .ini files? So far I just see the one opencpn.ini file in C:\ProgramData\opencpn (on Windows 7). When I launch the second instance it seems to force me to re-select my Chart folders every time. I cannot find a second opencpn.ini file, and it seems to not save any of the settings for the second instance.

Can I specify the name of an alternate .ini file as a parameter in the command line?

Is there a way I can get the second instance of OpenCPN to save its settings when I quit out of it?

[RhythmDoctor]

OK, to partially answer my prior question I now realize that if I move opencpn.ini from C:\ProgramData\opencpn to C:\Program Files (x86)\OpenCPN, then running portable mode with C:\Program Files (x86)\OpenCPN\opencpn.exe -p causes OpenCPN to load the settings in the .ini file that resides in the same folder. (Note that I have no interest in putting OpenCPN on a USB stick. I just want to put it into two directories on my hard drive so I can launch two instances.)

But if I change any settings, OpenCPN does not save them. Each time I quit and relaunch, it reverts to the prior settings, and also has to rescan/rebuild the chart database.

What am I doing wrong here?

[Viking Sailor]

RD,

To run more then one OpenCPN at a time you need to setup two different folders each with a copy of opencpn.exe and all of its associate files and folders plus a opencpn.bat file. Each of the .bat files will have the single command: opencpn.exe -p

You then execute the .bat file in one of the folders to start the first OpenCPN. Then execute the .bat in the second folder to start the second OpenCPN.

Paul

[RhythmDoctor]

Originally Posted by Viking Sailor

RD,

To run more then one OpenCPN at a time you need to setup two different folders each with a copy of opencpn.exe and all of its associate files and folders plus a opencpn.bat file. Each of the .bat files will have the single command: opencpn.exe -p

You then execute the .bat file in one of the folders to start the first OpenCPN. Then execute the .bat in the second folder to start the second OpenCPN.

Paul

That is exactly what I did. But when I did so, OpenCPN exhibited the behavior I described above:

• OpenCPN did load the settings from the .ini file that was in its folder, but it had to rescan and rebuild the chart database every time I launch
• OpenCPN did not save any changes to the settings for the next launch.

That's the problem that I am trying to fix. I don't see what I am doing wrong.

[Viking Sailor]

There are now two .ini files. One for each instance. Configuration changes must now be made to each instance for them to appear in both .ini files. Or, before starting the second instances you can copy the .ini file from the first folder to the second folder.

[RhythmDoctor]

OK I figured it out. I had created my second OpenCPN folder in C:\Program Files (x86)\OpenCPN2 . I had forgotten that this folder is protected in Windows7, so OpenCPN was not able to write to opencpn.ini. (However, there was no error message to alert me to this.)

I moved the OpenCPN2 folder out into an unprotected folder, and OpenCPN could read and write to the .ini file. It also saved the chart database so it did not have to rescan.

Problem fixed. I'll proceed with tweaking my dual-window configuration of OpenCPN.

[Viking Sailor]

Glad to hear that!

[RhythmDoctor]

Originally Posted by bdbcat

...One of the items on someone's wish list is the ability to have multiple chart canvases open at the same time, without needing multiple instances of O. This may appear on O 3.4 if sufficient demand and resources materialize.

Meanwhile, portable is the way to go. Multiple "portables" in different directories are just fine...

I now have portable mode configured, and each instance runs off its own independent .ini file that I can tweak to optimize my preferences for the left window vs. the right window.

However, I am continuing to have problems getting the second instance to pick up the NMEA data off the UDP stream. I had described this a couple weeks ago in another thread:

Originally Posted by RhythmDoctor

...The first instance of OpenCPN seems to work reliably as shown in my previous posts. But when I launch the second instance, it often fails to receive transmission from the first instance, and it can be quite difficult to get it to "wake up" the UDP port. Sometimes I have to quit and restart the second instance. Sometimes that does not work and I need to go through a complicated sequence of disabling the UDP port, turning off the output, and changing the priority of the UDP port on the second instance (odd, since I've deleted out the COM ports so there really should not be any priorities to resolve). It's complicated enough that I have not been able to come up with a specific procedure that works every time. I just need to fiddle with it...

Sometimes (like today) the second instance launches flawlessly and immediately starts to see the NMEA data on the UDP port. Other times (like yesterday) I have to fiddle with various communications settings for 20-30 minutes before I can get it working.

Based on this experience, I would love to see OpenCPN modified to display two windows while running only one instance. I feel like running two instances is somewhat of a kludge, even when doing it in portable mode.

While the wide screens on today's laptops and netbooks are nice for watching movies, they are lousy for using a realtime chartplotter in look-ahead mode, since you want enough vertical screen space to have a good view of what is directly ahead and what might be coming up behind you. This is why I run two instances side-by-side - I sacrifice nothing in vertical screen space, but gain the ability to see two different zoom levels for a wide view and a closeup detail. So I think making that capability native within one instance of OpenCPN would be a great addition.

Thanks for all your great work so far. This is a great program. I realize that my request for multiple chart windows could add complexity that is outside the appropriate scope for OpenCPN. If that is the case, I understand and will continue to make due with what you provide.

-- Rick

[bdbcat]

Rick...

Lets talk about the UDP data stream from A->B.

Do you have, or know about, something called Wireshark? This is a network analyzer that lets you look at nework traffic, packet by packet, that is occurring on your machine.

What we want to know is this: When you have trouble getting instance B running, is instance A actually transmitting UDP packets?

Recall that UDP is non-connection oriented. This means that there is no server/client relationship, and the sender (A) sends NMEA data strings via UDP in the blind, so to speak. Much like a serial port in this case. So we should see A sending packets with or without B running.

So, we start (A), try (B) and find trouble. Start Wireshark and look at the data stream, looking for UDP packets from (A) with no receiver.

This would be useful information.

Make sense?
Dave

[RhythmDoctor]

Originally Posted by bdbcat

Rick...

Lets talk about the UDP data stream from A->B.

Do you have, or know about, something called Wireshark? This is a network analyzer that lets you look at nework traffic, packet by packet, that is occurring on your machine.

What we want to know is this: When you have trouble getting instance B running, is instance A actually transmitting UDP packets?

Recall that UDP is non-connection oriented. This means that there is no server/client relationship, and the sender (A) sends NMEA data strings via UDP in the blind, so to speak. Much like a serial port in this case. So we should see A sending packets with or without B running.

So, we start (A), try (B) and find trouble. Start Wireshark and look at the data stream, looking for UDP packets from (A) with no receiver.

This would be useful information.

Make sense?
Dave

Yes, makes sense. I'll look for Wireshark and take it down to the boat with me next chance I have.

Obviously I've used the NMEA debug window to confirm similar things, but it sounds like Wireshark would help determine whether the data that instance A is sending out is actually making its way out to the common UDP buss, right?

One detail - Since this is all happening within one computer and I don't want to set up an external router (battery drain) or ad hoc network (too unreliable in my experience), I am using "localhost" instead of a numeric IP address. Will Wireshark accommodate that, or does it look for a specific numeric IP address?