TzTouchXL not syncing navigation state and user objects, and NavPilot connection issues

[PugSndBoater]

Setup: 4x TxTouchXL units on the same network. Same Navpilot 711C we've used for several years previously with 4x TzTouch2 units. We're having two route/navigation issues that may or may not be related:

1. When I start navigating a route on one TzTouchXL display, it doesn't seem to start navigation on all of the display like I'd expect and like I think used to happen on our older TzTouch2 units. The navigation only starts on the single TzTocuhXL on which we actually started navigating. This behavior/issue happens even if the NAvPilot is off or not involved.

2. TzTochXL and Navpilot seem mostly unaware of each other for some reason. Specifically, if I start navigation via NavPilot using the controls of the TzTouchXL itself (e.g. by using the NavPilot item in the Route side menu), it does activate the Navpilot hardware correctly ("Navpilot activated" banner), but then I immediately get a "NavPilot deactivated" yellow banner on the TzTouchXL. The actual Navpilot itself remains activated (e.g. in Auto mode) but the TzTouchXL seems unaware of the NavPilot's state and is unable to control the NavPilot hardware. Also, if I start navigation via the Navpilot 700 display itself, the TzTouchXL is also unaware it's running. Both things lead me to believe there's some signal from the NavPilot back to the TzTouch units that is missing or failing, but I'm unsure what that may be, since I'm not sure what would be different from our previous TzTouch2 setup where this all worked.

Items I checked. Basically, the same setup we've had for years with the older 4x TzTouch2 displays, so I'm not sure what I'm missing.

• Sync sensors is enabled on the NavPilot, so it's using the same NMEA2K sensors as the TzTouch displays, but I get see these same problems even if I configure the NavPilot sensor selection manually
• TzTouchXls are outputting PGN 129283, 129284, and 129285, so appropriate nav data is on the canbus.
• Navpilot is outputting PGN 127237 (heading/track control) and 127245 (rudder) onto the NMEA2K canbus
• "Navigate with NAvpilot" is on in the Routes setting menu of all 4 TzTouchXLs
• The Navpilot-700 is visible on the TzTouchXL displays (Initial Setup -> Sensor List -> Can Bus Sensor), and the PGN sentences into the Navpilot is happening on its diagnostic display, so they do see each other on the canbus

 

[FishTech]

Can you provide photos of the sensor list? Ensure that all your software versions match. NMEA 2000 instancing is correct?
Under Units - Range (Short), are you using yards? Turn that to meters if so.

 

[PugSndBoater]

Thanks for the help so far.

Sensor List photos attached.

I've tried resetting this sensor list on all displays. No change.

Software versions, specifically of the TZT16X displays, all seem to match, and I believe are the latest (24.22.2)

To clarify, do I want the same System and different Device instances for each TZT16X (e.g. displays are Device instance 0, 1, 2, 3) or do I want the same System and Device instance for everything (e,g, all 0)? For what it's worth, I tried it both ways and saw no behavior difference related to the issues described here either way. I powered off and on all of the displays and the Navpilot after changing the device instances too just to be sure.

The idea that short display-units would matter isn't intuitive as something to try. What's the connection between short display units and anything to do with cross-device communication? I had it set as Feet. I changed it to Meters to try it, though. No behavior difference.

 

[PugSndBoater]

The problem (or at least a problem) may be on the ethernet/IP side. I've been focused on the NMEA2K canbus side, since that's the connection between TzTouchXL and the Navpilot. But contrary to what I thought intially, user objects (i.e. routes, points, boundaries, etc) are NOT syncing between TzTouchXL units over the local network, nor are they syncing to TzCloud. I believe the active navigation route is usually sync'd this way too, which is why I think I need to get this ethernet syncing problem sorted out first, before then diving more into any remaining canbus issues.

Settings changes *are* syncing between TzTouchXL units over the network. And shared ethernet devices like the radar, fish finder, AIS, a FLIR, and 4 Axis IP cameras are available on all TzTouchXL displays so at least some level of the ethernet linking is working properly. IP addresses seem reasonable and non-overlapping on the Device List page.

Each TzTouchXL hardware display seems to have two entries in the Device List, one for TZT16X and one for TZTXFF. Is that expected? Why two? I don't recall that being the case for our four TzTouch2 displays before.

I've tried logging out and back into Timezero services on the TzTouchXLs. No difference.

I fired up TzProfessional on a laptop on the same 172.31.x.x network. If I create objects like marks in TzPro they sync to all of the TzTouchXLs but not vice versa: if I create a new Mark on a TzTouchXL that mark stays only on that one display and never syncs to anything else (locally or cloud). Likewise if I delete something created in TzPro on a TzTouchXL it is only deleted on that one TzTouchXL and the deletion operation never seems to sync with anything else (locally or cloud).

I can dig into the debugging logs for any given TzTouchXL dislpay using the tool at e.g. http://172.31.252.2:32000/ where I see error messages like below, which may be a red herring but that's what I see.

01-22 18:12:14.393 9209 10150 E FEC : ..\..\src\mxcmd_api.c:453|error: MXCMD: send command error -50, 3, MF003005, cmd: $MXC,MF252002,86,2,MF003005,3,13;SHAREDFILES;06483b70-14b8-4eba-8f51-f61e6ae4175d;unused
01-22 18:12:14.393 9209 10150 E FEC : , master[1]=MF252026
01-22 18:12:14.394 9209 10150 E MaxSea : 2025-01-22 18:12:14 - [ERROR FileSynchronizer] (MaxSea.Core) SynchroApi.SendCommand FAILS - 13;SHAREDFILES;06483b70-14b8-4eba-8f51-f61e6ae4175d;unused
01-22 18:12:14.394 9209 10150 E MaxSea : -----------------------------
01-22 18:12:14.394 9209 10150 E MaxSea : 2025-01-22 18:12:14 - [ERROR FileSynchronizer] (MaxSea.Core) SendQuestionAndWaitAnswer.SendQuestionAndWaitAnswer [2989] : SendCommand failed ([QUESTION|Generic|SHAREDFILES;06483b70-14b8-4eba-8f51-f61e6ae4175d;unused])
01-22 18:12:14.394 9209 10150 E MaxSea : -----------------------------
01-22 18:12:14.395 9209 10150 E MaxSea : 2025-01-22 18:12:14 - [ERROR FileSynchronizer] (MaxSea.Core) FileSynchronizer.GetSharedFiles : Could not get remote Shared File
01-22 18:12:14.395 9209 10150 E MaxSea : -----------------------------
01-22 18:12:14.395 9209 10150 E MaxSea : 2025-01-22 18:12:14 - [ERROR FileSynchronizer] (MaxSea.Core) FileSynchronizer.SynchronizeOnce : Could not get remote SharedFiles

 

[PugSndBoater]

I'm open to any ideas at this point, no matter how crazy. I spent several hours today trying everything I could think of to no avail. As a last-ditch attempt, I disconnected the entire network, took just two of the TzTouchXL displays, and literally just connected them to each other with an ethernet cable. Then I restarted both of them. No other devices. No network. No hub. And they STILL won't sync user objects like routes, points, boundaries, between them. If I create a route, mark, boundary, etc on one display it just refuses to sync the add/delete/edit operation with the other display.

It seems like either some non-obvious misconfiguration got locked in somewhere for reasons unknown and in a place not visible in the settings, or there's a fundamental flaw with LAN/cloud sync in the TzTouchXL software in a multi display configuration. Is anyone else seeing this work or not work? I saw one other forum thread recently which may be similar.

Do I try a complete factory reset of everything, start over, and spend all of the time to reconfigure the entire vessel again? I don't have any particular reason to believe the major time investment of doing a complete reset would solve anything or achieve a different result, but I'm sort of out of other ideas at this point.

 

[jp498]

The MFDs should have different instance numbers in NMEA2000.
They should be connected together with NMEA2000 and with the AP via NMEA2000
The MFDs should also be connected together with ethernet.
As far as syncing, make sure each device is logged into the mytimezero account. Timezero should be version 5 for use with the XL MFDs.
I would not expect two MFDs to connect with just an ethernet cable; a hub/switch may be necessary. The XLs use gigabit ethernet, and the old tzt2's used 100meg ethernet, so make sure whatever you have for a switch does gigabit. If using a managed switch, make sure igmp-snooping is turned on. Doesn't matter on unmanaged hardware.
I am not familiar with that AP; does it require setting a nav source in it's config? (I think Simrads do but the 711c does not)

 

[PugSndBoater]

The MFDs should have different instance numbers in NMEA2000.
They should be connected together with NMEA2000 and with the AP via NMEA2000
The MFDs should also be connected together with ethernet.
As far as syncing, make sure each device is logged into the mytimezero account. Timezero should be version 5 for use with the XL MFDs.
I would not expect two MFDs to connect with just an ethernet cable; a hub/switch may be necessary. The XLs use gigabit ethernet, and the old tzt2's used 100meg ethernet, so make sure whatever you have for a switch does gigabit.
I am not familiar with that AP; does it require setting a nav source in it's config? (I think Simrads so but the 711c does not)

Thanks for the ideas, jp498. My hypothesis here remains that the root problem is a fault of some sort with user object syncing between MFDs, not the AP-MFD connection or the actual ethernet links.

• MFDs have different instance numbers on NMEA2K. Thanks for confirming that the setup we have is indeed correct.
• Autopilot and MFDs are on the same NMEA2K network. They can see the same data on the NMEA2K network. Diagnostic screens on both ends show the expected PGNs flowing. NMEA2K Analyzer software also confirms PGNs flowing.
• All MFDs are logged into the same mytimezero account.
• AP is configured for two MFDs as primary and alternate navigation source.
• No syncing of user objects happens between the MFDs, whether two MFDs are connected directly via an ethernet cable (per experiment above), whether MFDs connected through a hub with only MFDs and nothing else on that hub, or whether the MFDs are on the whole network with all of the Furuno ethernet devices.
• Hubs we use are gigabit (or technically auto-negotiating per port), which worked for the old TzTouch2 and the modern TzTouchXL.
• I think the root problem here is some fault with LAN/cloud user object sharing within the MFDs themselves, not related to the actual ethernet connection. I say that because the ethernet is basically working otherwise. When the MFDs are connected to the whole network, the MFDs are successfully syncing settings changes across all of the MFDs, e.g. display units changes or any setting shared across MFDs (I think settings syncing happens via different mechanism over the ethernet than user object syncing). And all of the MFDs can successfully use other Furuno ethernet devices over the ethernet network (radar, fish finder, AIS, a FLIR camera, and 4 Axis IP cameras). Also, if I run TzPro on a laptop on the network, user objects do sync across all MFDs when added/deleted/edited in TzPro. It's just that any add/edit/delete on the MFDs themselves is never syncd. That's what I think the ethernet connections themselves are just fine and it's some other syncing fault within the MFDs.

 

[PugSndBoater]

I tried using the serviceman menu to factory reset just the User Objects Data on all four MFDs. No difference in behavior. User objects did seem to resync down from the cloud after doing that reset on next startup, but add/delete/edit operations done on the displays themselves still fail to sync across displays or back to the cloud.

 

[JJ Neutron]

The problem (or at least a problem) may be on the ethernet/IP side. I've been focused on the NMEA2K canbus side, since that's the connection between TzTouchXL and the Navpilot. But contrary to what I thought intially, user objects (i.e. routes, points, boundaries, etc) are NOT syncing between TzTouchXL units over the local network, nor are they syncing to TzCloud. I believe the active navigation route is usually sync'd this way too, which is why I think I need to get this ethernet syncing problem sorted out first, before then diving more into any remaining canbus issues.

Settings changes *are* syncing between TzTouchXL units over the network. And shared ethernet devices like the radar, fish finder, AIS, a FLIR, and 4 Axis IP cameras are available on all TzTouchXL displays so at least some level of the ethernet linking is working properly. IP addresses seem reasonable and non-overlapping on the Device List page.

Each TzTouchXL hardware display seems to have two entries in the Device List, one for TZT16X and one for TZTXFF. Is that expected? Why two? I don't recall that being the case for our four TzTouch2 displays before.

I've tried logging out and back into Timezero services on the TzTouchXLs. No difference.

I fired up TzProfessional on a laptop on the same 172.31.x.x network. If I create objects like marks in TzPro they sync to all of the TzTouchXLs but not vice versa: if I create a new Mark on a TzTouchXL that mark stays only on that one display and never syncs to anything else (locally or cloud). Likewise if I delete something created in TzPro on a TzTouchXL it is only deleted on that one TzTouchXL and the deletion operation never seems to sync with anything else (locally or cloud).

I can dig into the debugging logs for any given TzTouchXL dislpay using the tool at e.g. http://172.31.252.2:32000/ where I see error messages like below, which may be a red herring but that's what I see.

01-22 18:12:14.393 9209 10150 E FEC : ..\..\src\mxcmd_api.c:453|error: MXCMD: send command error -50, 3, MF003005, cmd: $MXC,MF252002,86,2,MF003005,3,13;SHAREDFILES;06483b70-14b8-4eba-8f51-f61e6ae4175d;unused
01-22 18:12:14.393 9209 10150 E FEC : , master[1]=MF252026
01-22 18:12:14.394 9209 10150 E MaxSea : 2025-01-22 18:12:14 - [ERROR FileSynchronizer] (MaxSea.Core) SynchroApi.SendCommand FAILS - 13;SHAREDFILES;06483b70-14b8-4eba-8f51-f61e6ae4175d;unused
01-22 18:12:14.394 9209 10150 E MaxSea : -----------------------------
01-22 18:12:14.394 9209 10150 E MaxSea : 2025-01-22 18:12:14 - [ERROR FileSynchronizer] (MaxSea.Core) SendQuestionAndWaitAnswer.SendQuestionAndWaitAnswer [2989] : SendCommand failed ([QUESTION|Generic|SHAREDFILES;06483b70-14b8-4eba-8f51-f61e6ae4175d;unused])
01-22 18:12:14.394 9209 10150 E MaxSea : -----------------------------
01-22 18:12:14.395 9209 10150 E MaxSea : 2025-01-22 18:12:14 - [ERROR FileSynchronizer] (MaxSea.Core) FileSynchronizer.GetSharedFiles : Could not get remote Shared File
01-22 18:12:14.395 9209 10150 E MaxSea : -----------------------------
01-22 18:12:14.395 9209 10150 E MaxSea : 2025-01-22 18:12:14 - [ERROR FileSynchronizer] (MaxSea.Core) FileSynchronizer.SynchronizeOnce : Could not get remote SharedFiles

What version of TZ Professional are you running?

 

[PugSndBoater]

I got the user objects part sorted out, thanks to the always great Furuno tech support. Had a phone with Camas guys this afternoon. They walked through 90% of things I'd already tried, and a couple of new things. None of these diagnoses turned up anything, but good to be thorough.

The bad behavior was indeed that LAN syncing of user objects just wasn't happening between our XL displays for unknown reasons, even when cloud syncing was completely disabled (toggled off and logged out of mytimezero) and two XL units were connected directly via ethernet. That config of two displays linked directly to each other by ethernet is perfectly fine, by the way, since they have self-assigned static IP addresses. It's usually not a particularly useful layout in practice of course if you have any more ethernet devices to use also, but it's totally functional in the sense that they see each other and can operate.

Ultimately, we went the full factory reset route, being unable to diagnose or fix the issue. I'm not sure how much of these steps below are required, but, specifically, here's what I did after taking with Camas:

1. Completely isolate two of the four XLs.
2. Use the serviceman menu to fully factory reset both of them.
3. Link them together directly using an ethernet cable.
4. Power them back up fresh and verify before doing anything else that LAN syncing of user objects is now working across the direct ethernet link. It does! Woohoo!
5. Isolate the other two displays from the ethernet network and serviceman factory reset them as well.
6. Set up a special ethernet switch and connect only the four XL displays to it (none of the other ethernet equipment like ais, radar, fish finders, camera were connected).
7. Bring up the other two displays fresh one at a time and verify LAN syncing of user objects still works across all of them, first 3, then all 4. It does now!
8. Power everything down again.
9. Reconnect all equipment (displays, radar, fish finder, AIS, FLIR, cameras, etc) to the permanently installed ethernet switch, power back up the displays and verify LAN syncing still works. It does.
10. Restore all of the vessel configuration to the XLs using photographs of all the menus taken before the factory reset.

What actually was the fault causing LAN syncing not to work? Unkown. We may never figure it out. My best guess is the sync algorithm somehow got a routing table or state table corrupted, if that even makes sense.

With that resolved, I just need to sort out the hopefully smaller issue of why the Navpilot 711C autopilot only starts itself when initiated from one if the four XL displays (when saying "Yes" to "Do you want to navigation with the Navpilot"?). And why the XLs also seem unaware of the Navpilot state. But at least with the user objects syncing across XLs, which includes the active route state, all of that is less of a big deal because I can always manually start the Navpilot from it's screen and pick up the route/next waypoint. I'll fork a new thread on this topic.

 

[FishTech]

Great news!
@PugSndBoater and @jp498 ,
I do want to add one correction to what I see above. Our MFDs need to be on the same instance number or it can confuse some of our systems. We avoid instancing conflict with this by only allowing one of the MFDs, at any given time, to talk common PGNs.

 

[PugSndBoater]

Question though, @FishTech: how do I save the instancing setting? I set them all to 0 in Initial Setup -> Data Sensors -> Sensor List, which seems to work. But every time I power cycle the XLs they revert back to having the different 0,1,2,3 instancing. They seem to refuse to save the instance change back to 0. I tried doing it in N2KAnalyzer too, which also seemed to work, but same issue that after power cycling the XLs they always revert to the different 0,1,2,3 instancing.

 

[FishTech]

It is automatic. Once set, it should hold. If it did not, the power cycle is what SHOULD make it take effect.