Any interest in XanBus protocol ?

[Yyrkoon]

I am currently in the process of reverse engineering part of the XanBus protocol, and was wondering if anyone else here had interest. XanBus, at least on our inverters, is on the physical layer, CANBus -> ethernet connector. The software layer seems to be NEMA 2000 fast packet, using custom / proprietary PGN values for various aspects of inverter instrumentation. Or, if it is not, it would be very surprising to me. As currently I am able to track various fields related to AC_OUTPUT_STATUS -> RMS voltage, current, and AC frequency. There are also a few unknown fields( to me ), but also there are power related fields which I do not bother with. Since power = v * i . . . and I'd rather deal with that on the remote end.

Anyway, I've written an application in C, that uses the socketCAN API, POSIX IPC Shared memory, and libmongoose to perform hhtp + websocket duties.

The interesting part of this application, at least for me was the POSIX shared memory aspect. In effect, the application is two processes. The IPC server, which reads directly from the CANBus, constructs fast packets out of 8-byte socketCAN frames(varied frame count ), decodes the meaning of the fast packet, and writes this information into the Shared memory file - In the form of a JSON object.

The IPC client, which also acts as an http + websocket server, Just reads the data from the file, and sends it out over websocket to any connected clients. Essentially, just the "man in the middle".

The reason I chose this model(two processes ), is that when initially experimenting with libmongoose, my socketCAN wrapper code stopped working. So instead of trying to figure out what was going on, and reading through *tons* of code. I figured I'd chose this model. Since libmongoose uses a callback to "poll" it's various features. I just figured it was stepping all over the stack.

Anyway, my code is still a work in progress, but is working well enough to output AC_OUTPUT_STATUS fields to a web browser client. A buddy of mine, and myself have reversed the various PGN values well enough to at least track battery status, AC power related status, MPPT controller status etc. *And* we also have a Schneider electric MPPT charge controller. So I can verify that my code works for that. As well as a commbox . . .

The hardware that is reading directly from the inverters is a beaglebone black, using a CANbus cape. Running Debian wheezy.

This project for me is definitely a huge learning experience. Being that this is probably the first major application I've written for / on Linux. I do have many years programming / Linux usage experience - dating back to the early to mid '90's. But have always written code on Windows, for windows, using various languages. This is very exciting for me anyway, but probably less so for others heh.

Would love to hear comments and / or questions if anyone has any.

[OperaHouse]

I bought a Prosine 3000 more than a year ago and was asking if anyone knew an easy way to read the Xanbus.  Haven't en tried turning it on since then.

[Yyrkoon]

I bought a Prosine 3000 more than a year ago and was asking if anyone knew an easy way to read the Xanbus.  Haven't en tried turning it on since then.

I wouldn't say easy, but it is doable. It took my buddy and I . . . I do not know, a month and a half to figure out the various PGN values. Then, we only figured out some of the values. For instance, with the one and only PGN that I'm tracking currently, there are like 3-4 bit fields I'm unable to figure out. But the majority of the important values, I'm able to read.

We also have a commbox, so if I get stuck indefinitely, I may take a gander at the javascript code . . . but man, it's 20,000 lines +. I did glance at it and I started feeling myself devolve immediately . . . it's that bad.

[dgd]

Interesting to read what you are doing with Xanbus.
I am looking at this from a different hardware and software approach.
From the info I have gathered about Schneider's Xanbus it appears to be nothing more complicated than an
rs485 network at the hardware communications layer and a MODBUS stack at the data layer.
These documents from Xantrex show the modbus register map

http://www2.schneider-electric.com/resources/sites/SCHNEIDER_ELECTRIC/content/live/FAQS/229000/FA229511/en_US/ConextXWModbusMap.pdf
and

http://www2.schneider-electric.com/resources/sites/SCHNEIDER_ELECTRIC/content/live/FAQS/229000/FA229511/en_US/ConextSWModbusMap.pdf

Rather than use a Linux system (Cubie2 in my case) I decided to go with a more embedded type processor
and will be using the Arduino DUE, or possibly Mega2560.  The hardware interface to the Schneider inverter will use a low cost rs485 to serial adapter (a few $ on ebay). Reading the relevant modbus registers will use the SimpleModbusMaster lib for Arduino.
Since there are relatively few registers to get a nice dataset of how the inverter is performing I will simply store registers in ram memory refreshing values about every second.
The Arduino can be a simple web server and with 1 second data rate from the inverter (or whatever the inverter can do) then data can be made available via AJAX to a web client. I would leave the page processing to javascript code to format and display using live gauge displays or perhaps highchart or rchart live graphs.

What I would really like to achieve is integrate the inverter data into web pages I already generate to show live and historical data from my Midnite Classic controllers.
Between the Classics, a WBjr on Deltec battery shunt and inverter data its a goal to produce detailed running data on PV and wind turbine power generation, battery status, load power usage, diversion load power availability/consumption and exception events reporting.

Slightly further down the track when I get my Oztules 6Kw inverter built and tested then a simple ARduino based data monitor with running data connected via i2C (or whatever) to the DUE web server. I might consider making a modbus stack for this inverter but thats probably unlikely.

Is your code available? I would be interested in looking at it.
All my C++ DUE/Mega web server code for Midnite Classic is freely available on the Midnite web forum.

dgd

[ve3aam]

Hello to you all.

I came across this site yesterday by accident, but a good one! Maybe I can be of help, with the Zantrex XanBus protocol.

I have three MPPT60-150 charge controllers and two Conext ComBox. Well as luck would have it, one failed during the night...So I started to think about getting back onto my version of an interface.
A couple of years ago, I did just that. Built a CANBus monitor using a PIC18 processor with a monochrome 3x5 display. I was able to monitor the traffic and to display the results onto the screen.
Built an other CANBUS monitor to allow me to send commands and receive packets via CAN to USB interface to function in a windows environment. Just wrote a simple program using Visual Studio 6. (VB) . I do have the PGN's and would like to pick up on this once again. As far as I'm concerned, it is time that WE the community, engineers and hobbyist,  (I'm both) reverse engineer this darn XanBus protocol and make it public... Enough is enough.

My current setup consist of just using the Conex Combox as a bridge/slave (MODBUS rs485) to extrapolate the data in real time and display it on an 3x5 monochrome LCD. Processor is a pic18f4685.
It displays the battery voltage, temperature, input voltages, current, etc and also the load to the battery and other equipment.. Also power in whrs, kwhrs, mwhrs, daily, monthly, yearly, and total.
My second monitor device is a modified laptop dual core processor running winxp64 or vista 64. The device communicates with the Combox being a TCP/MODBUS bridge slave, displaying the data on screen, IN COLOR lol!

So in response to the primary post "Any interest in XanBus protocol?" here I am, and lets get to it!!!

I do like the charge controllers, as they do work very well, but the Combox MODBUS protocol, doesn't allow or provide more data and control the the SCC, that is available on its TI 32-bit processor. Fact is, all past data and faults are save in FLASH, but are not available. The combox does the data login when you plug the units together....etc.

By the way, Microchip also has for sale a couple of CANBUS tools and monitors. The schematics and firmware/software are available for free and download. I did just that, built my own boards, using their stuff as a base. Thought you'd like to know this. And besides, they will ship FREE samples!!! You've got to love that, and Microchip!!!

I should also mention that I've been off-grid for over 8 years. Located on a 100 acres in the middle of a forest. apx 9kw of solar panels, two sets of Panasonic MSE Modular AGM batteries,
(48 - 2v batteries 7.5 tons)  48volt system. Using believe it or not, APC Smart UPS for power conversion. CHEEP and reliable!! 3000w and 5000w units, so 120v and 208 and 240 single phase.
Sure is nice to have all this power to run an air-conditioner and hot water !!

I will help those that request tips and tricks or info...Pictures and other stuff is available...

Cheers
Dale

[DamonHD]

Welcome!

I'm not a fan of closed data (except for security and privacy) or closed protocols either!

Damon

[ve3aam]

Yes, I concur...
The problem with the Conext Combox is that it does allow one to log into it remotely, via the web browser/ethernet built in server! (By the way, it's JAVA! I hate none compiled interpreted code).
So if someone should hack your firewalls, and be able to log into the box, then you might have some issues!!
Changing the parameters will cause damage and possibly render any of the equipment unusable.
Best to control and invoke changes via an other medium, lets say, something simple as serial or USB interface. In my case I would just monitor the telemetry and distribute the data/info.

Dale

[Yyrkoon]

Yes, I concur...
The problem with the Conext Combox is that it does allow one to log into it remotely, via the web browser/ethernet built in server! (By the way, it's JAVA! I hate none compiled interpreted code).
So if someone should hack your firewalls, and be able to log into the box, then you might have some issues!!
Changing the parameters will cause damage and possibly render any of the equipment unusable.
Best to control and invoke changes via an other medium, lets say, something simple as serial or USB interface. In my case I would just monitor the telemetry and distribute the data/info.

Dale

It's actually javascript hehe, big difference. But javascript while much to hate is actually a decent interpreted language if you understand the good parts, and what not to use. The part I do not like about javascript, is that having a good amount of experience with C, I like everything "explicit". Too much in javascript seems to come out of now where, or somehow by "magic". In the end, it's just a different train of thought, when it comes to writing code. Javascript is very solid as an event driven language when used properly. Now days, it is also very fast on modern processors too. Since most now have javascript "acceleration".

As for "hacking firewalls" . . . it's not very likely if you're behind a router with zero outside access. It's not impossible, some claim that DNS poisoning can be used to gain access into such a system. But again it is not very likely.

[Yyrkoon]

Interesting to read what you are doing with Xanbus.
I am looking at this from a different hardware and software approach.
From the info I have gathered about Schneider's Xanbus it appears to be nothing more complicated than an
rs485 network at the hardware communications layer and a MODBUS stack at the data layer.

dgd

Here, on our equipment we're physically connected via an RG-45 connector / cable directly to CANBus. The software layer protocol is NEMA 2000 using a custom( probably proprietary - paid for ) set of PGNs. We've reversed most if not all of the interesting ones for us, and I actually have a very simple Web app via websockets that communicates to the device which decodes the PGNs in real time. Currently, I'm only tracking AC output statistics, but it's bang on with the Commbox output. Actually, my app is currently faster, and more accurate. e.g. they report 60Hz for output, where my app rounds to the hundredth and reports 59.97-59.99Hz

I read about MODBUS some when starting this project, but otherwise do not know much about it.

[Yyrkoon]

Hello to you all.

I came across this site yesterday by accident, but a good one! Maybe I can be of help, with the Zantrex XanBus protocol.

I have three MPPT60-150 charge controllers and two Conext ComBox. Well as luck would have it, one failed during the night...So I started to think about getting back onto my version of an interface.
A couple of years ago, I did just that. Built a CANBus monitor using a PIC18 processor with a monochrome 3x5 display. I was able to monitor the traffic and to display the results onto the screen.
Built an other CANBUS monitor to allow me to send commands and receive packets via CAN to USB interface to function in a windows environment. Just wrote a simple program using Visual Studio 6. (VB) . I do have the PGN's and would like to pick up on this once again. As far as I'm concerned, it is time that WE the community, engineers and hobbyist,  (I'm both) reverse engineer this darn XanBus protocol and make it public... Enough is enough.

My current setup consist of just using the Conex Combox as a bridge/slave (MODBUS rs485) to extrapolate the data in real time and display it on an 3x5 monochrome LCD. Processor is a pic18f4685.
It displays the battery voltage, temperature, input voltages, current, etc and also the load to the battery and other equipment.. Also power in whrs, kwhrs, mwhrs, daily, monthly, yearly, and total.
My second monitor device is a modified laptop dual core processor running winxp64 or vista 64. The device communicates with the Combox being a TCP/MODBUS bridge slave, displaying the data on screen, IN COLOR lol!

So in response to the primary post "Any interest in XanBus protocol?" here I am, and lets get to it!!!

I do like the charge controllers, as they do work very well, but the Combox MODBUS protocol, doesn't allow or provide more data and control the the SCC, that is available on its TI 32-bit processor. Fact is, all past data and faults are save in FLASH, but are not available. The combox does the data login when you plug the units together....etc.

By the way, Microchip also has for sale a couple of CANBUS tools and monitors. The schematics and firmware/software are available for free and download. I did just that, built my own boards, using their stuff as a base. Thought you'd like to know this. And besides, they will ship FREE samples!!! You've got to love that, and Microchip!!!

I should also mention that I've been off-grid for over 8 years. Located on a 100 acres in the middle of a forest. apx 9kw of solar panels, two sets of Panasonic MSE Modular AGM batteries,
(48 - 2v batteries 7.5 tons)  48volt system. Using believe it or not, APC Smart UPS for power conversion. CHEEP and reliable!! 3000w and 5000w units, so 120v and 208 and 240 single phase.
Sure is nice to have all this power to run an air-conditioner and hot water !!

I will help those that request tips and tricks or info...Pictures and other stuff is available...

Cheers
Dale

We've been off grid about as long as you it seems Our system . . .
 
Schneider:
2x Conext SW inverters - Which have a problem running in parallel - trying to figure out why.

Conext Combox
Conext MPPT-60-150 Charge controller

Xantrex XW SCP

Morningstar  TS-MPPT-60 Charge controller

And several Trace C40 / C60 controllers - Of which only one is used now.

~6kW peak worth of panels. Most of the power is from newer 220W panels, but we do have around 1.5kW worth of ~30 year old ARCO 30-40W panels ( freebies ).

Also a couple Southwest windpower Airx turbines that hardly see any duty - don't need them.

No AC here but we do run washer / dryer, fridge, and 2 freezers off the system. As well as a water pump, several computers, lights etc as well. Our "mains" is 240V single phase true sine. Lots of pictures here too, I keep them on google +.
</waggling>

So . . . we have most of the PGNs reversed. My buddy did most of that within reason. I helped answer some questions, but the reversing he did is slightly off in many cases. So I have to trial and error, using packed struct's / unions to confirm everything. Well more correctly, this is for read PGNs, write PGNs - right now I have no interest in. But figure I could read through the *cough* 30k lines of javascript *cough* from the Conext combox, and figure those out. But again, I just want to remotely log, and graph data - for now.

Anyway, I'm using Linux with socketCAN on a beaglebone black + logic supply CANcape. The data rate on the CANBus is 250k, and for one PGN I'm pulling in 2 samples per inverter a second. Picture here: https://picasaweb.google.com/106867156582775247949/August212015?authuser=0&authkey=Gv1sRgCLSm_OuD8N3I3QE&feat=directlink

A picture may "say" a thousand words. But a video is really necessary to show how "fast" this really is. On the bottom where it says "CONNECTED 4" 4 is how many PGN's a second the web app is sampling. 2 per inverter. this is, as fast as it gets. e.g. How fast the actual data is coming off the CANBus.

Anyway, yes, It is my goal to make the PGN information public. Still, I need to double check, and confirm what we have reversed so far. With that said, I'm only interested in a small portion of the data personally. AC statistics, DC statistics. Plus perhaps stuff like battery temp and what not. Not at all interested in making changes remotely via my app. Perhaps in the future.

Happy to discuss the protocol

EDIT:
Ah forgot to mention our battery bank is 12 Rolls S-1380 batteries. So roughly 1050ah @24v nominal. Not as much as I'd like, but it does the job remarkably well.

[Yyrkoon]

Ive also been interested in PIC for a long time, but have never gotten around to learning much. Also I'm only passable with electronics. Typically I know enough about the uC's, or dev-boards to write software for them. In the context of micro-controllers though, I only really know a bit about a small few. MSP430, and some Cortex M3/M4 parts. Mostly TI stuff. I do know of a lot of uC's and PIC has always been an interesting set of uCs to me. Particularly the PIC32's

I might consider an Arduino, or even an Atmel uCs. But to me the prices for the hardware, especially considering what they are do not make sense to me. Considering that freescale, TI, and a few more sell Cortex Mx based boards for less - That can do more, and faster. Also, since my buddy here has been an EE for more than 30 years, and knows how to use Orcad very well. I never have much of a problem getting custom boards designed / made when we're serious about something. So I do not need to worry about a cape, or dev board "interface" so much. Such as with the Arduino boards. Passed that, the wiring IDE to me is revolting . . . I'd rather use an uC that has a gcc compiler and a gnu toolchain.

For this project we're both kind of half heartedly considering selling a multi platform "black box", but that's not really the motivation behind this for us. Mostly, the motivation behind this is the lack of information out there on this topic. We both like a good challenge - and since for me this required a lot of learning / reading . . . I knew it would keep me busy for a while. Plus, you have to admit, it's a pretty cool project if you're into hardware / software hacking.

[Yyrkoon]

Sorry for the multi posts all at one time. But funny story . . . internet got knocked out for a week by lightning - True story -> here's a picture. https://picasaweb.google.com/106867156582775247949/2015081903?authuser=0&feat=directlink "Act of god" realtech ethernet bridge chip decapping

Anyway, this is what I have for the current PGN I'm tracking.

struct ac_output_data{
   unsigned char length;      // 0x49 for AC_OUTPUT_STATUS
   unsigned char unknown[4];
   unsigned char line1[23];   // L1 equivelent to L3
   unsigned char line2[23];   // L2 Equivelent to L3
   int line3             : 8;
   int L3_rms_voltage      : 32;
   int L3_current          : 16;
   int L3_unknown1      : 16;
   int L3_unknown2      : 8;
   int L3_frequency      : 16;
   unsigned char line3_unknown2[11]; // Related to power values.
   unsigned char padding[2];
   unsigned char srcid;      // Stealing a padding char to store sourceid into.    
};

L1, L2, and L3 are not references to inductors. L values are related to line in voltages. Grid, generator, and battery. We know for sure L3 is battery because this is the portion where I'm getting our statistics from. They're accurate.

So how this works on Linux with socketCAN. You get 8 bytes of data per frame. Each frame starts with a sequence number. Like so:
 20 49 03 FC 33 01 01 00
 21 00 00 00 00 00 00 00
 22 00 00 00 FF FF 00 00
 23 00 00 00 00 00 00 00
 24 02 00 00 00 00 00 00
 25 00 00 00 00 00 FF FF
 26 00 00 00 00 00 00 00
 27 00 00 03 DA A4 03 00
 28 2C 06 00 00 09 6F 17
 29 FF FF 7A 01 00 00 57
 2A 01 00 00 08 FF FF FF

So in effect, you're only getting 7 bytes of data related to the inverters. In this case of the above, this PGN is 11 frames, or 88 total bytes of data. 77 Bytes if you discount the frame sequence numbers. Value 0xFF are either reserved or unused. Also if you examine the above frame set closely, you'll notice where the L values start. 01, 02, and 03. Each line in field is 23 bytes each.

You may notice that I do not bother with the power values for L3. The reasoning should be self explanatory, but this information can be gained simply by multiplying volts by amps . . . Not really sure if i care about perceived power, and real power in their data. . . Anyway, if you're good with hex, and know how to convert hexadecimal values to decimal, you'll also probably noticed that these values are fixed point values. scaling factor for voltage, and current is .001, where frequency scaling is .01.

So in the first frame 20 49 03 FC 33 01 01 00 the bolded values here I'm fairly certain is a 32bit bit field, but I have no idea what it is. Aside from that, I'm not sure I care about the rest of the data.

[dgd]

...  I do have the PGN's and would like to pick up on this once again. As far as I'm concerned, it is time that WE the community, engineers and hobbyist,  (I'm both) reverse engineer this darn XanBus protocol and make it public... Enough is enough.

Ok, but I'm not sure that any reverse engineering is necessary.
All the Xantrex docs and other forums that talk about Xanbus mention nothing about Canbus or that Xanbus is some form of (layer 2 with its own framing) Canbus.
Instead Xanbus is just an rs485 (layer 1) network layer and data from each device on the network is available via modbus.
Modbus over rs485 is quite common and there are just lots of examples available in Arduino and rPi forums using various modbus libs to do all the necessary timing/repeat requests and data framing etc.
Unless I'm completely confused I can't see the problems or why its necessary to use some reinvented code to take modbus frames apart.

Anyway borrowed SW will be here soon so I can get an rs485 link to it from an Arduino Mega
using SimpleModbusMaster Lib.

dgd

[ve3aam]

Morning.

I'd like to be able to contact you "Yyrkoon" but I'm new to this posting business! Been using internet for >20 years, but this IS THE FIRST time I've ever joined a POST. Reason was, well because like I said in the beginning, I did a search for the XanBus stuff, and this site came up. So I figured, someone out there has the same question and interest, why not...

Regardless were I'm going with this, being a newbie, is I tried to click onto the your email icon, but no luck...
I do have the COMPLETE from Zantrex, XanBus PGN's if you're interested, in PDF format.!!!

As far as my comment about, JAVA, I hope that I did not or do not offend anyone out there!! Only my opinion and preference.
Yes I was aware that Java script is used with the ComBox. It also appears that the OS is some form of Embedded Linux.

When it come to Linux, I do like LIME...
I've been trying to use it to write pgms, but Linux is still a learning curve. Tried to get some compilers together, but having problems getting some sense of placing all of the files together.
Also do like, PCBSD (UNIX with GUI)

My programming experience is C, C++, VB, some C#, windows API, ADI algebraic assembler(Analog Devices) for ADSP21xxx, TS1,2xx, etc..
Hardware experience, well it's a long list!!

Besides, lets get down to business and CRACK this Xantrex Xanbus! lol...

A previous comment stated that Xanbus was related to MODBUS, sorry this is not the case.
XanBus is just Xantrex version on the CANbus (Controller Area Network bus) Pieces from the J13xx series and NEMA2000...The originator of CANbus was Bosch in Germany back in the eighties to cut down on wire densities in large vehicles, truck etc. Now it a robust standard utilized in many various industries. I use it here to communicate with equipment also use TCPIP embedded controllers that bridge long distances.

Forgot to mention in my intro post, the battery capacity is 2880 AmpHrs. And I must also state that there is absolutely no utilities for miles around here.
Being that I've been a Radio Amateur since the early 70's I needed an area that does not produce or have AC pollution, and besides, erecting a multitude of >150 foot towers does require space...

Cheers
Dale
   

[ve3aam]

"So in the first frame 20 49 03 FC 33 01 01 00 the bolded values here I'm fairly certain is a 32bit bit field, but I have no idea what it is. Aside from that, I'm not sure I care about the rest of the data."

If memory serves me right, the first line indicates length of data, source ID, destination ID, info about the packet, etc. (my info is not in any order)
I just plug in my CANbus monitor, I built a couple of years ago. Uses a dedicated PIC18F4680 controller with CAN built in, that communicates with a PIC18F4550 USB controller...I will get back into this!! Coffee being made, and I will start to look at this once again!

Schneider (Xantrex) is going to send me an other! #2, Conext ModBox to replace the other replacement that crapped out last October!! NOW YOU SEE WHY I'M GETTING BACK INTO THIS! LOL.
The teck support guy in California says that"I'm over working the ComBox" and this is why they fail! I fell of my chair laughing!!! I've been an engineer longer than he's been breathing air!!!
I'm still laughing! No kidding, seriously...
Dale

[ve3aam]

I must correct a couple of errors

XanBus is based on NMEA2000 which is based on SAE J1939. Most messages use NMEA2000's Fast Packet protocol (9 bytes to ~200 bytes).
Only bigger messages such as firmware download use J1939's Multi-Frame protocol.

Most status messages are sent at a rate of 2x per second.  Basic Sts is usually sent 4x per second and ISO Address Claim is sent every second.

Hope this clears some confusion!

Dale

[Yyrkoon]

Actually, I believe there are multiple types of XanBus. rs485, and canbus(rg45) physical layer. ModBus, and NEMA2000 fastpacket software protocol.

And, they're not even remotely the same. CANBus Xanbus for instance, does not use addresses to payload data, but instead uses PGNs, which is not a single value, but a category of values.

[Yyrkoon]

"So in the first frame 20 49 03 FC 33 01 01 00 the bolded values here I'm fairly certain is a 32bit bit field, but I have no idea what it is. Aside from that, I'm not sure I care about the rest of the data."

If memory serves me right, the first line indicates length of data, source ID, destination ID, info about the packet, etc. (my info is not in any order)
I just plug in my CANbus monitor, I built a couple of years ago. Uses a dedicated PIC18F4680 controller with CAN built in, that communicates with a PIC18F4550 USB controller...I will get back into this!! Coffee being made, and I will start to look at this once again!

Schneider (Xantrex) is going to send me an other! #2, Conext ModBox to replace the other replacement that crapped out last October!! NOW YOU SEE WHY I'M GETTING BACK INTO THIS! LOL.
The teck support guy in California says that"I'm over working the ComBox" and this is why they fail! I fell of my chair laughing!!! I've been an engineer longer than he's been breathing air!!!
I'm still laughing! No kidding, seriously...
Dale

We've been dealing with tech support as Schneider for the last couple months. The guy we're dealing with - which is probably the same person isn't always the brightest bulb . . .

So we have two SW's that *were* running in parallel, except that when the second one kicks in it can sometimes start oscillating. After a while, we got tired of dealing with this person, and starting letting the inverters oscillate and logging what they're doing. Turns out the slave for some reason goes negative voltage - As if it's charging the batteries ! Anyway trying to explain this to the guy in tech support is like talking to a brick wall. And supposedly trying to duplicate our setup he's used two inverters, with a single electric heater plugged into it . . resistive load right ? Our load when this happens is largely inductive. A Jet pump, a couple freezers, and a fridge . . .

Anyway, I'm not an EE, but my buddy is, and has been for more than 30 years. Some of the stuff this tech support person comes up with is yes, exactly hilarious . . ."Well, your sdcard must be bad . . ." or some stupid garbage like that - Because god forbid that someone actually finds a bug in their hardware / software.

Anyway, we'll eventually nail down the problem, and then we'll offer to fix it for them for a fee Wouldn't that be funny heh

BTW I sent you a PM with email in it.