OpenCPN Version 5.8.0 Released

[hoolie]

Well, Mr Prickly, I think Haken''s comment was not to be judgemental but rather to imply your problems may be compounded by having an unnecessarily complex installation.

[Alfange]

Originally Posted by hoolie

Well, Mr Prickly, I think Haken''s comment was not to be judgemental but rather to imply your problems may be compounded by having an unnecessarily complex installation.

OK Mr. Meddlesome

And who are you?
His lawyer or judge of law?

[bdbcat]

ZuZa...


Of course it is not for us or anyone else to stipulate how you use you computer. It is, after all, a Personal Computer, and it has taken 50 years to get to the point where gurus in lab coats are not required in order to run programs.


Having said that, I am almost certain that the reason O58 does not run for you is due to incompatibility of one or more plugins in your directory


C:\Users\ZUZA\AppData\Local\opencpn\plugins

It seems that at least one of the existing managed plugins is not compatible with O58 on your machine. Not at all surprising, due to our ad-hoc testing methodology using volunteer testers with various system configurations.


So, if I were in your shoes, and I wanted to use O58, I would:
1. Make a copy of C:\Users\ZUZA\AppData\Local\opencpn\plugins, saving it for recovery if necessary.
2. Delete the contents of the original C:\Users\ZUZA\AppData\Local\opencpn\plugins.
3. Install O58 in parallel, NOT as an upgrade.
4. Start O58.

5. Reinstall your desired plugins, one-by-one, until you isolate the one that causes OCPN to crash or become unresponsive.


This is a normal debugging method. First rule of debugging:
"Simplify the configuration to the minimum required to reproduce the fault."


Dave

[Alfange]

Originally Posted by bdbcat

ZuZa...


Of course it is not for us or anyone else to stipulate how you use you computer. It is, after all, a Personal Computer, and it has taken 50 years to get to the point where gurus in lab coats are not required in order to run programs.


Having said that, I am almost certain that the reason O58 does not run for you is due to incompatibility of one or more plugins in your directory


C:\Users\ZUZA\AppData\Local\opencpn\plugins

It seems that at least one of the existing managed plugins is not compatible with O58 on your machine. Not at all surprising, due to our ad-hoc testing methodology using volunteer testers with various system configurations.


So, if I were in your shoes, and I wanted to use O58, I would:
1. Make a copy of C:\Users\ZUZA\AppData\Local\opencpn\plugins, saving it for recovery if necessary.
2. Delete the contents of the original C:\Users\ZUZA\AppData\Local\opencpn\plugins.
3. Install O58 in parallel, NOT as an upgrade.
4. Start O58.

5. Reinstall your desired plugins, one-by-one, until you isolate the one that causes OCPN to crash or become unresponsive.


This is a normal debugging method. First rule of debugging:
"Simplify the configuration to the minimum required to reproduce the fault."


Dave

Dave

I thank you for your response and attempt to help and I fully understand what you mentioned, but it is fundamental to know, that not always the most important thing is what is said, but how it is said, just to conclude and not to return to this secondary issue and close this.

Thanks again and all the best to you.

[bdbcat]

Zuza...
Just so I know how to plan the work here, can I assume that you will NOT follow my suggestions for debugging O580?


Either way is OK by me, I just would like to know.


Thanks
Dave

[TritonYawl]

Originally Posted by Hakan

Triton Yawl..
I'm on Win and have tried to reproduce the UDP filter trouble you mentioned.
Though I've not the same set up but on a UDP input connection I'm able to set a filter to "Ignore sentences" and it works as expected. With or without showing the NMEA Debug window. (I ignored DBT and MWV and no data to Dashboard in any case.)

Thank you Hakan for trying to reproduce my issue. Your result is consistent with mine in that the filter prevents opencpn modules/plugins from consuming the filtered sentence regardless of debug window state. Good. My problem, which your test does not show, is that the filter also prevents the sentence from appearing on the internal multiplex bus (as I expect it to), but only when the debug window is shown (which is unexpected).

The simplest test case is to start with a clean install (5.8.0 Flatpak on Fedora 37 in my case) and define two connections as in this settings.conf excerpt:

[Settings/NMEADataSource]
DataConnections=1;1;localhost;9992;0;;4800;1;0;1;WPL;0;;9;0;1;0;1;;1;;0|1;0;localhost;9991;0;;4800;1;2;0;;0;WPL;1;0;1;0;1;;1;;0

The first connection is a receive-only UDP on port 9992, set to ignore any incoming WPL sentence. The second is output-only TCP on port 9991, set to send out WPL sentences that appear on the bus.

Next, on the same host, pipe together two netcat instances to emulate a multiplexer that is receiving sensor data from various sources then broadcasting it all out to interested clients:

nc -l 9991 | nc -u 192.168.2.255 9992

In another shell/terminal, run a netcat client to listen to the UDP broadcast to show what is being broadcast, which we otherwise won't see when the NMEA Debug Window is closed.

nc -ul 192.168.2.255 9992

Now, in the OpenCPN Connections dialog, check Show NMEA Debug Window. Exit from connections dialog, leaving debug window open. Create a waypoint. Right-click*the waypoint and select Send to GPS, then choose*TCP:localhost:9991 and press Send.

The shell/terminal running the netcat client will show a single $ECWPL sentence and the NMEA Debug Window will show a timestamped line like UPD:localhost:9992) $ECWPL,... color coded as Input Message filtered and dropped. Perfect. As expected.

Close the NMEA Debug Window. Send the waypoint to GPS TCP:localhost:9991 as before. Note that the netcat client terminal is continuously flooded with $ECWPL lines as fast as they can be printed. Open the NMEA Debug Window. Note that the feedback loop is cut and the output to the netcat client terminal instantly stops. To see a more dramatic example, set RMC for the receive/output filters in the connections then activate a route and watch the traffic slow and flood as the debug window is shown and hidden.

[Aqua_vitae]

Hi,
This is now OK: I removed manually all directories and files related to climatology_pi and weather_routing_pi.
I can now use plugin manager and update plugin catalog.
Regards.
JF

[Alfange]

Originally Posted by bdbcat

Zuza...
Just so I know how to plan the work here, can I assume that you will NOT follow my suggestions for debugging O580?


Either way is OK by me, I just would like to know.


Thanks
Dave

Dave

I will certainly try the procedure you suggested, and let you know the result in due course.
But just to remember, before reinstalling version 5.6.2, I had already completely uninstalled it, and then installed the new version that worked without problems, but as I said before, when editing the file .ini adding the directories of the Charts and groups, crashed everything again, even without other changes of any other kind in the .ini file, nor installed any plugin, keeping only the default configuration of the installation, but of course when uninstalling the program, may have remained old files, and that were not even in use in the previous version, because over the time of use of OpenCPN there were many plugins uninstalled, which even then still remained remnants that I could not totally delete, and that in previous versions, they still appeared in the list of the plugin folder, even though they were uninstalled.

Just to exemplify I attached an image of the current moment, in which are installed only the plugins made available by the default installation of 5.6.2, and see that there is in the list a Plugin that simply can not be deleted, even having deleted that file you recommended, so there would be no way this plugin called "Canadian Tides" could have been installed by me, but it is there, but the system does not accept to reinstall it or delete it.

And as you can see, those Ship coordinates that should appear in the Status bar, in the lower left corner of the image, are still missing, if you have any information about this bug, please mention, or at what point in the file .ini I could fix this error, if that's where the problem resides.

Thanks again.

[bdbcat]

Zuza...
The uninstall of O5.6.2 is evidently not deleting all the plugins in
C:\Users\ZUZA\AppData\Local\opencpn\plugins


So, please do:

1. Make a copy of C:\Users\ZUZA\AppData\Local\opencpn\plugins, saving it for recovery if necessary.
2. Delete the contents of the original C:\Users\ZUZA\AppData\Local\opencpn\plugins.
3. Install O58 in parallel, NOT as an upgrade.
4. Start O58.


Dave

[Gilletarom]

Dave,

I told French users about this new feature: " Peer-to-peer networking functions, allow sharing of objects (routes/tracks/waypoints) between interconnected OpenCPN devices. "

And one of them, who uses OpenCPN very well, immediately asked me this " Hello Gilletarom Can you develop the implementation of the Peer to peer or Pair to peer operation, it is by wifi? Or other ? in short, I saw nothing or saw it badly. THANKS "

And I don't know what to answer.


Is there already a page in the manual that talks about it?


​

[filochard]

Originally Posted by Aqua_vitae

Hi,
This is now OK: I removed manually all directories and files related to climatology_pi and weather_routing_pi.
I can now use plugin manager and update plugin catalog.
Regards.
JF

Hi

For many years, I have been packaging OpenCPN and plugins for a linux distribution
OpenCPN 5.6.2 worked well when everything was built upon wxgtk 3.0
until we rebuilt all the stuff with wxgtk 3.1.5 that caused crashes with some plugins

I had informed the OpenCPN devs in june 2022 that some plugins couldn't be built or work (climatology, weather_routing, s63) if they where built with wxgtk version > 3.0
and even worse : one of them (logbookkonni) could be built with wxgtk 3.1.5 but created crash when it was launched

(this problem had not appeared in flatpack that still used wxgtk 3.0 !)

OpenCPN 5.8.0 is built upon and uses wxgtk 3.2

The source codes of the culprit plugins must be rewritten to be compatible with wxgtk 3.2... and OpenCPN 5.8.0


Hope this will help

[stevead]

Flatpak SocketCAN Permissions

I thought that it would be solved in either OpenCPN or in Flatpak. But that is not the case.

Installed this comand and it works. But I have to go to the Connection menu and then give the command apply. I does not work directly after starting O. Why ?

The command

flatpak override --user --allow=canbus org.opencpn.OpenCPN

needs only to be run once. It should be executed prior to running OpenCPN. It permanently adds the SocketCAN permissions to the flatpak environment for OpenCPN.

The OpenCPN devs have correctly added settings to the OpenCPN build environment however either a bug in the flatpak-build-finish command or some other error is causing these permissions to not be correctly applied during the flatpak OpenCPN installation.

[verkerkbr]

The Pypilot plugin is available in the AMD64 version of Linux Mint Vera.

However not yet in the Raspberry Pi 4 O 5.8 version. Is this plugin not yet available or can the plugin be installed on another way. ?

The Linux versions of 5.8 work great.


Bram

[KoeZt]

My Windows install of 5.8.0 does show the Pypilot plugin. My Odroid N2+ (Aarch64) on Ubuntu 22.04 with Flatpak 5.8.0 does not have the plugin available yet. Any idea when it will be available?

Since I have a Pypilot on board, this, for me, is a show stopper...
Had everything working fine on 5.6.2

[seandepagnier]

I am working on my plugins for 5.8.

I have found some issues in the handling of nmea messages with plugins I am trying to resolve, so even if you get the plugin working the core opencpn needs a few changes to get everything working as well. Otherwise you have to make a connection manually rather than let the plugin autodetect pypilot and forward nmea to it.