Engine Dashboard plugin

[rgleason]

Dear Steve, I am just the messanger. I suggest you raise these good questions with Mike G. in the Opencpn/Opencpn Issue that I provided above, so that this can get resolved faster. Thank you.

[bdbcat]

Steve...
I'd say it is likely that the indicated code line is the source of the problem.
It is possible, depending upon the order of messages processed, that the member element "wxDateTime tankLevelWatchDog" is not being initialized before use in the "Add()" instruction.
Suggested solution: Initialiize all watchdogs to wxDateTime::Now() in plugin Init() method.


Also, the version of wxWidgets offered in rPi repos (for Buster) is Version 3.0.4.


Thanks
Dave

[stevead]

I've figured out that the underlying problem was an uninitialized variable. I think this specific issue manifests itself upon startup when no engine or tank data is being received.

Although I'm mystified that the wxAssert is being raised and visible to an end user. I thought in release builds asserts were not raised to the end user ?

I haven't received any error reports nor seen the error on any previous versions of the Engine Dashboard on Windows, Linux or MacOS and there is the same uninitialized variable problem for the engine rpm watchdog so I am intrigued as to why MikeG is noticing this now on his RPi build. I'm guessing because he is stepping through with a debugger ?

Nonetheless, an easy fix.

[bdbcat]

Steve...
The way I read is this:


1. "engineWatchDog" is uninitialized at startup, so is invalid.


2. If a plugin timer tick is received before any sK or NMEA update is received, then the method "Notify()" will be called before "engineWatchDog" has been set, as it will be eventually by sK or NMEA update.


3. wxAssert is then raised by

if (wxDateTime::Now() > (engineWatchDog + wxTimeSpan::Seconds(5)))

Dave

[stevead]

Thanks Dave, your analysis is spot on. A silly oversight and an easy fix.

However still mystified as to why the assert is rearing its ugly head in the user's face as I've, perhaps mistakenly, thought wxAsserts were only raised under certain debug conditions.

I've personally never seen this assert message on any of the platforms I have tested on and I quite often start OpenCPN & the plugin before feeding the RPM/XDR data.

[rgleason]

Steve, I have not been keeping up with this. Has Engine Dashboard been updated and pushed to PIM lately? If so we should probably add it to be tested by MacOS users here?
https://www.cruisersforum.com/forums...ng-258613.html

[Aldebaran17]

Originally Posted by stevead

The engine dashboard has at least two customers !

Steve,

it's about to become three. Finally I managed to install my home-built analog engine sensor to NMEA2000 hardware, so I can see a limited set of engine data in OpenCPN: RPM, Fuel level, most importantly temp of the exhaust water (after the mixing elbow) and engine temp (measured at the engine block itself). The two temp sensors are currently implemented as starboard and port engine temp in the NMEA network. Not nice, however I am not aware of more appropriate PGNs.



Is there a way to customise the display? Like changing the range of the analog temp display, say from 10...30 in the case of exhaust temp. Or giving the displays custom names? Or making the digital displays bigger? Or going completely digital? Which will look less cool, but free some display space, so that the chart can be better viewed.
In parallel I have a SignalK dashboard running, which I do not like since it not embedded in OpenCPN. However, it demonstrates that the numbers can be much more readable. At least with my eyes getting older every day.

Maybe you are willing to consider some of my suggestions.

Best,

Manfred

[stevead]

Hi Manfred,

You pose an interesting question. The one NMEA 2000 PGN that relates to engine data, PGN 127489 does not have a field for exhaust temperature, only for engine and oil temperature.

I'm guessing that when you configure your sensors to display the engine temperature as port and the exhaust temperature as starboard, you are configuring the NMEA 2000 device to use the instance number to differentiate the two ?

From a display & conversion perspective, I think it might be possible to add an additional gauge to display exhaust temperature, and the use a NMEA 183 XDR transducer name of EngineExhaust#n as the gauge's input.

The question then becomes how to map a NMEA 2000 PGN to the NMEA 183 XDR sentence. A quick & dirty fix would be to use instance numbers 8 & 9 and override the engine temperature value as an engine exhaust value. A horrible alternative would be to define a proprietary PGN !

Re the gauge display, the Engine Dashboard just uses the existing Dashboard codebase so it's limited to that UI style. (Not very modern I'll admit). It would be possible to change the gauge range, if I remember correctly I just based the limits on what my actual engine gauges displayed.

As you've developed your own sensors & interface to NMEA 2000 do you have any thoughts ?

[Aldebaran17]

Originally Posted by stevead

Hi Manfred,
The question then becomes how to map a NMEA 2000 PGN to the NMEA 183 XDR sentence. A quick & dirty fix would be to use instance numbers 8 & 9 and override the engine temperature value as an engine exhaust value. A horrible alternative would be to define a proprietary PGN !

PGN 130312 maybe the one to go with. It has a tN2kTempSource N2kts_ExhaustGasTemperature=14 and it is recognised by TwoCan.

Originally Posted by stevead

Re the gauge display, the Engine Dashboard just uses the existing Dashboard codebase so it's limited to that UI style. (Not very modern I'll admit). It would be possible to change the gauge range, if I remember correctly I just based the limits on what my actual engine gauges displayed.

I see. A custom graphical display, which can be modified by the user, may be too much work. But, a digital display, just the numeric value, as is built in in Dashboard already, may be much easier to implement in Dashboard Engine as well.

Originally Posted by stevead

As you've developed your own sensors & interface to NMEA 2000 do you have any thoughts ?

Too much honour to me. I did not develop it, just combined two little projects from a german open source project.

[stevead]

PGN 130312 maybe the one to go with. It has a tN2kTempSource N2kts_ExhaustGasTemperature=14 and it is recognised by TwoCan.

Thanks Manfred, that seems like the ideal solution. It's a sorry state of affairs when I can't even remember what PGN's TwoCan parses !

So if you can get your sensors to output PGN 130312, with the instance number correctly set (0 for main engine, or if dual engine, the port engine, 1 for starboard engine), with the temperature source = 14 (exhaust), I'll add the parsing code to TwoCan. It will generate a NMEA 183 XDR sentence with the transducer name of "EngineExhaust#n" where n is the instance number.

And hopefully there's enough space (a 32bit int) to add some extra dashboard gauges to display the exhaust temp.

Let's see what we can come up with.

[stevead]

OK, the Engine Dashboard display is all coded for this scenario.

I just want to run some test passes to make sure I haven't introduced any regressions before publishing the next release.

This release will also fix/clarify the NMEA 183 v4.11 XDR standard transducer name for engine hours. The plugin will now accept EngineHours#n which I understand to be used by Yacht Devices gateways in addition to Engine#n which appears to be used by Actisense & Shipmodul gateways.

Unfortunately this next release will break existing dashboards as I had to renumber the gauges to match with the watchdog timers that zero the different sets of gauges. Users will need to edit the dashboard preferences to ensure the correct gauges are displayed.

I've also coded the additional parsing of exhaust temperature for PGN 130312 in the TwoCan plugin, but the next release of that will still be some time away as the next release has a number of new features that require further testing before I publish.

The following sentences:

$ERXDR,P,300000,P,ENGINEOIL#0,C,89.5,C,ENGINE#0,U,13.4,V,ALTERNATOR#0*0A
$ERRPM,E,0,1700,,A*46
$ERXDR,G,1831,,ENGINEHOURS#0,C,54,C,ENGINEEXHAUST#0*01

result in the following display.

[Aldebaran17]

Originally Posted by stevead

OK, the Engine Dashboard display is all coded for this scenario.

Great, thanks. will try it as soon it is available.

May I ask you one more favour: in my case the exhaust water temperature is some 10..15˚C above the water temperature. At engine start identical with outside water temperature. At our latitudes exhaust water temperature stays always well below 40˚C and can go to down to 5˚C (off season, just after engine start). So, the range of the display should rather start at 0˚C. And there is probably no need to go above 50 or 60˚C.

Just run into another small issue: the RPM meter does change its range (max rpm) only after restart of OpenCPN. Even opening and closing of the current dashboard does not help. (version 1.4.1.0 in MacOS Big Sur).

Manfred

[stevead]

Thanks for feedback Manfred.

Just to confirm, engine exhaust temperature from 0 to 60 ?

I don't know of any other sailors who monitor the exhaust temperature so I other than searching the web, I personally have no knowledge of the actual range of the exhaust temperature in other conditions. I would normally expect the exhaust temp to be slightly lower than the engine temperature, due to the cooling nature of a wet exhaust system.

Re "the RPM meter does change its range (max rpm) only after restart". By design, the same goes for changing from single to dual engine, or from 12-24 volt. The gauge range is set when the gauge is instantiated, would be a lot of extra work to change the range at runtime. Sorry.

[Aldebaran17]

Originally Posted by stevead

Thanks for feedback Manfred.

Just to confirm, engine exhaust temperature from 0 to 60 ?

I don't know of any other sailors who monitor the exhaust temperature so I other than searching the web, I personally have no knowledge of the actual range of the exhaust temperature in other conditions. I would normally expect the exhaust temp to be slightly lower than the engine temperature, due to the cooling nature of a wet exhaust system.

You are right: it is not common to monitor the exhaust temp of a wet exhaust cooling system in pleasure boats. But, it is recommended (and used in commercial engines) as the easiest way to get a warning in case the raw water system is clogged or impeller pump not working. If water flow is normal, the water/exhaust/hose temp will be just 10 or 20 degrees above sea water temp, If there is no water running, the temp will go up quickly to 100's of degrees. There are systems available for yachts, e.g. from NASA or Yacht devices. For instance, he manual for NASA EX-1 says:

A cooling water failure can be caused by a temporary blockage of the raw water inlet by a plastic bag or other debris or it could result from a burst pipe or poorly performing water pump. Either way an engine temperature gauge will not give adequate warning. The temperature of the engine block, full of water, will rise very slowly whilst the exhaust gas temperature will rise from a few tens of degrees centigrade to a few hundred degrees centigrade in a matter of seconds.

So: 0..60 degrees would be perfect to have the resolution to see trouble when it is arising.
The water in the inner cooling system (inside the engine block) will have 65˚C or 85˚C depending if it is fresh water or raw water cooled engine.

Originally Posted by stevead

Re "the RPM meter does change its range (max rpm) only after restart". By design, the same goes for changing from single to dual engine, or from 12-24 volt. The gauge range is set when the gauge is instantiated, would be a lot of extra work to change the range at runtime. Sorry.

Well, the font size is changing at runtime. So, I was expecting the other settings will also have an immediate effect. In any case, people, including me, are expecting that changing a parameter will have an immediate effect or a warning pops up: restart software to see effect.

Thanks for your efforts,

Manfred

[Schnapsy]

Hello,

The Engine Dashboard plugin is very handy.

However, the display of the dials takes up space on the screen.

Would it be possible, in a future update, to add the possibility of displaying only the data, as on the classic dashboard which gives the choice of displaying a dial or just the data.

Personally, what mainly matters to me is to display the voltage (in figures) of the battery, and in this case the dial display does not bring me anything more.