OK, simple enough. The Nanopi does not come with a CAN interface on the chip. So one had to be added, and the nature of what was added is the reason for this.
Let me expand a bit… as I always do 
These days chip makers make these really nice things called SOCs, System on Chip, it’s a single chip that has a CPU, some memory, a number of GPIOs, and some other peripherals as well. Many of these SOCs come with a CAN-controller on the chip. For example, the STM32F4 comes with a CAN-controller, while some of the others in the STM32 family do not.
Where the SOC comes with a CAN-controller, you only have to add a CAN-transceiver chip (a little 8-pin thingamabob, usually either an MCP2551 or an ISO1050, or something from that family).
So… some of the Venus platforms have a built-in CAN-controller, and some do not. For those who do not, such as the Nanopi used in the -GX inverters, an external one is added. For the Cerbo, one of the CAN-controllers is on the chip, and the other one is added on. The Cerbo and the Nanopi-based models use the same add-on chip.
The chip that is added on uses the slcan driver: CAN over serial. It is a chip that translates the CAN-communication to serial. You can find such chips at hobbyist places, for plugging directly into a laptop, etc. But this solution is limited in terms of speed and volume, and this is where things go a bit squiffy.
The chip does fine at the relatively low volumes of a CAN-bms battery, but not so well at the higher levels required by CAN-bus MPPTs. As a result, the slcan port is reserved for battery comms. On the Cerbo this has the result that only one of the ports can be used for MPPTs, and on the -GX inverters it means you have to use VE.Direct to the MPPTs, the CAN-bus is only for the battery.