question

An interesting design you have created. I do not believe any such design has ever been tested, or that you would get a reliable solution. Yes you can adjust the data instance of certain N2K messages to ensure that things are unique with regards to data being sent from a device. Your also need to consider how configurable, if at all, devices are to receiving data on different data instance and reacting to it. So while you might get one Lynx BMS sending as data instance 0 and the other as data instance 1, what are devices listening doing and expecting.

It is not clear to me from your description why you have two Lynx BMS devices or two Cerbo devices and what the purpose of the dual setup is.

I would personally go back to the drawing board and look at the design decisions that have driven you to such a design. My reasoning for this is simple. If you ever get it working, is it really working and will the messages in a high or low voltage situation arrive at and be processed correctly by the receiving device. It might look on the surface that it is all OK, but reality is a very different beast.

The vessel was originally built with two separate DC buss to power the DC sides of the vessel. The original owner was learn to fly and was flying in older aircraft were a redundant buss was used. The original system had 2 sets of lead acid battery banks that amounted to about 2176 usable(30%DOD) Ahrs. The dual inverters were spilt phased to provide 240v to the AC inverter side. We wanted to match the old system as much as possible along with the space available in the engine room for the batteries. We were able to fit 8 batteries total but with the 5 battery limit on the Victron Lipo we had to settle for 4 batteries in each bank. We were also told that with the set up we currently have we are not able to split phase the inverters. The inverters must be on the same bank in order to spit phase. We started the refit before the Lynx BMS was released and installed the VE.Bus BMS. When you released the Smart BMS we remover the old VE.Bus BMS system and went with the Smart BMS because of the functionality and Bluetooth monitoring. This is why we have the system the way we do. We are still in refit we have the ability to modify the system still. My understand of instances is that the data instance should not matter if the device instance is different for the same equipment. The PGN broadcast can have the same data instance as long as the identifying instance(depending on who's N2K hardware you are using) in Maretron it can vary between the device instant and system instance. I normally try to set my device instant and system instance the same if possible. In N2k system the device instance can be 0-15 and device instance can be 0-252. If the correct protocols are used changing the device instance on the Cerbo should not be a problem. The Cerbo would still receive data once linked with the Smart BMS over the N2K network. Please correct me if I am wrong in this assumption.

I have created a micro N2k network that I will use to test and program different components of the system. I am hoping that if I isolate the Cerbo GX I will be able to program with the Actisence NGT-1. I will post my results after testing.

Wanderbird.

@Wanderbird, So are you planning to have 1 set of 4 batteries, with 1 Lynx BMS, with 1 Cerbo and 1 Quatro, so no sharing of any of those components. If so then why join the VE.Can networks? keep them separate.

The Victron proprietary messages may well have problems as I am not sure you can tell one Cerbo which Lynx BMS it is to follow.

Maybe a schematic might help.

The issue related to a generator setting in one of the Cerbo GX's when I finally mirrored all the setting between the two the problem resolve itself. With the Maretron software you can change the system instance the Maretron uses to ID components on its network. I was able to set each instance for the both the inverters and the BMS. The Device Instance on the both the Cerbo's are the same but by setting the instances for the inverter virtual out put and input the system doesn't seem to care that the Cerbo's are both sharing the same device instance. After changing the generator setting in the Cerbo my Quattro quit disconnecting and now the system has been running for the last week with out an issue. I will finish the installation of the WS500's for both battery systems this next week. I am sure this will add a few issue for us but we should be able to work through them.

A late answer but I feel a very important one. Each NMEA 2000 device is required to have a Unique ID in it's Address Claim Request message. This Unique ID is part of the NAME, the total 64 bits of that AC message. A Cerbo device however, does not have a Unique ID by default, thereby violating the NMEA 2000 standard. So two Cerbo's on one network are thus seen as one device (as will all of its virtual devices be) because they have the exact same NAME, which is illegal on NMEA 2000. You can however switch to 4 different Unique ID's on each Cerbo, allowing a maximum of four Cerbo devices on the NMEA 2000 network. So if you change the Unique ID on one Cerbo, you'll most likely see both devices and all of its virtual devices.

@mhsprang Does this not address the unique ID part of the name.

Further is you scroll down in that menu, there is an option to check that Unique ID numbers are unique.

I have run two VenusOS devices on a single CAN network without any issues, Just changed the Unique Identity number of one of the VenusOS devices.

Yes, it does address the problem, and I did mention it in my original post. But the fact remains that a less technical user can leave these settings default, which violates NMEA 2000 rules. The Unique ID is part of the NAME of a device and the Address Claim procedure compares the numerical value of these NAME's to see who "wins" an address claim. With equal NAME's noone wins and technically no decision can be made about the address assignment. Apparently the Cerbo's can still resolve an Address Claim conflict so apparently they resolve that conflict in a non-standard way.