diy solar

diy solar

EG4 18kPV Q+A general thread

ksmithaz1 said:
OTOH, None of this looks correct based on the manual. Then again maybe red is (-) who knows? This should probably be in it's own thread as well. "General" 18KPV should be stuff like firmware updates, strange behaviors in edge cases, limits/manual errata and questions. At a glance this looks to be generally wired wrong, and the picture does not show the wires in MPPT1.

View attachment 209249

View attachment 209250
Click to expand...
Yeah, they’re the proper positive/negative, and there was one plugged into mppt 1. Good thinking though.
 
42OhmsPA said:
Don't forget the overhead costs, paying EG4, Lux Power, Signature Solar employees etc.
Click to expand...
I don’t mind paying off the NRE, testing, certifications, software development, customer service, support, etc (and funding them ongoing) as long as the reliability is there (which it appears to be or there would be lots of failures).
 
So how many RS-485 interfaces are there on an 18Kpv and what are they used for? I'd like to talk Modbus to one of a pair of parallel inverters, and I'm still trying to wrap my head around the interfaces.

It looks like the parallel communications uses CAN bus, as does the battery communications.

From the manual:
/*
8.2 Third-Party RS485 Communication

Meters 485B and 485A can be used when a meter is not connected. These two pins can be used to com-municate with the inverter using the RS485 Modbus protocol.

INV485: This interface is shared with the Wi-Fi module. If the Wi-Fi module is not in use, this interface can be used to communicate with the inverter.
*/
Screenshot 2024-04-15 at 8.29.05 AM.png

Has anyone used the Meter 485 interface, and does it work as a Modbus slave as expected?

Thanks!
 
wpns said:
So how many RS-485 interfaces are there on an 18Kpv and what are they used for? I'd like to talk Modbus to one of a pair of parallel inverters, and I'm still trying to wrap my head around the interfaces.

It looks like the parallel communications uses CAN bus, as does the battery communications.

From the manual:
/*
8.2 Third-Party RS485 Communication

Meters 485B and 485A can be used when a meter is not connected. These two pins can be used to com-municate with the inverter using the RS485 Modbus protocol.

INV485: This interface is shared with the Wi-Fi module. If the Wi-Fi module is not in use, this interface can be used to communicate with the inverter.
*/
View attachment 209415

Has anyone used the Meter 485 interface, and does it work as a Modbus slave as expected?

Thanks!
Click to expand...
I'm using 'G', I think it's 19200, . . .
<code>
g.p485_bus2 = mb485_create(g.device_19200,19200);
</code>
Yup
 
[keith@powercontrol] /home/keith/SolarProject/panelmonitor<312>grep bus2 *.c
mb485_poll_id.c: s1812 = mb485_poll_1812(g.p485_bus2,sp);
panelmonitor.c: g.p485_bus2 = mb485_create(g.device_19200,19200);

I'm polling every 20 or 30 seconds. The polling is not super robust. It fails in various ways not in-frequently. I have the inverters set to ID's 6 and 7 (from the display). If any of the data looks hokey I toss the poll. I only have the two inverters on the RS-485 bus. Cable is short. You will notice I open/close on every poll. If I don't it's not reliable. Python code may be more stable, was going to write php library, but I just ran with C.

#define RESP_OFFSET 15
#define REGISTER_COUNT 20
//----------------------------------------------------------------------
// MB485_POLL_1812
// Read status from the inverter
//----------------------------------------------------------------------
STATUS_1812 *mb485_poll_1812(modbus_t *p485, SENSOR *sp) {
int x,ix,address,a;
uint16_t *value;
union {
struct mb_1812request r;
uint8_t rsp[MODBUS_MAX_ADU_LENGTH];
} u;
static union {
STATUS_1812 r;
uint8_t ov[160];
} v;
if(g.verbose) {
log_print(g.log,0,"Reading Inverter\n");
}
memset(v.ov,0,160);
memcpy(&(sp->s1812),&v.r,sizeof(STATUS_1812));
for(address = 0; address < 150; address += REGISTER_COUNT) {
memset(u.rsp,0,MODBUS_MAX_ADU_LENGTH);
u.r.device = sp->sensor_id;
u.r.function = 0x04;
u.r.address = address;
u.r.count = REGISTER_COUNT;
// fprintf(stderr,"Command:\n");
// mbdump(u.rsp,sizeof(u.r));
x = mb485_open(p485,u.r.device);


I only poll 20 registers at a time, 40 is supposedly the limit. I map the return values into a structure/union, one inverter right after another. I record the poll start time as the time for both polls but in can take a few seconds to get the poll completed.

I poll the 9600 bus for my sensors (7), with no difficulty. It did not work well sharing the bus with the 19200 poll. It's supposed to work, but it doesn't.
 
ksmithaz1 said:
[keith@powercontrol] /home/keith/SolarProject/panelmonitor<312>grep bus2 *.c
mb485_poll_id.c: s1812 = mb485_poll_1812(g.p485_bus2,sp);
panelmonitor.c: g.p485_bus2 = mb485_create(g.device_19200,19200);

I'm polling every 20 or 30 seconds. The polling is not super robust. It fails in various ways not in-frequently. I have the inverters set to ID's 6 and 7 (from the display). If any of the data looks hokey I toss the poll. I only have the two inverters on the RS-485 bus. Cable is short. You will notice I open/close on every poll. If I don't it's not reliable. Python code may be more stable, was going to write php library, but I just ran with C.

#define RESP_OFFSET 15
#define REGISTER_COUNT 20
//----------------------------------------------------------------------
// MB485_POLL_1812
// Read status from the inverter
//----------------------------------------------------------------------
STATUS_1812 *mb485_poll_1812(modbus_t *p485, SENSOR *sp) {
int x,ix,address,a;
uint16_t *value;
union {
struct mb_1812request r;
uint8_t rsp[MODBUS_MAX_ADU_LENGTH];
} u;
static union {
STATUS_1812 r;
uint8_t ov[160];
} v;
if(g.verbose) {
log_print(g.log,0,"Reading Inverter\n");
}
memset(v.ov,0,160);
memcpy(&(sp->s1812),&v.r,sizeof(STATUS_1812));
for(address = 0; address < 150; address += REGISTER_COUNT) {
memset(u.rsp,0,MODBUS_MAX_ADU_LENGTH);
u.r.device = sp->sensor_id;
u.r.function = 0x04;
u.r.address = address;
u.r.count = REGISTER_COUNT;
// fprintf(stderr,"Command:\n");
// mbdump(u.rsp,sizeof(u.r));
x = mb485_open(p485,u.r.device);


I only poll 20 registers at a time, 40 is supposedly the limit. I map the return values into a structure/union, one inverter right after another. I record the poll start time as the time for both polls but in can take a few seconds to get the poll completed.

I poll the 9600 bus for my sensors (7), with no difficulty. It did not work well sharing the bus with the 19200 poll. It's supposed to work, but it doesn't.
Click to expand...
Good to know, thanks! Is it possible you are colliding with another master on that bus? I figured worst case I could use something like https://github.com/snhobbs/ModbusSniffer (I've used PyModBus on RPi before and it seems solid) to eavesdrop on the conversation between the LAN or WiFi dongle and the inverter, but I'm still noodling around with the best way to capture everything.
 
wpns said:
Good to know, thanks! Is it possible you are colliding with another master on that bus? I figured worst case I could use something like https://github.com/snhobbs/ModbusSniffer (I've used PyModBus on RPi before and it seems solid) to eavesdrop on the conversation between the LAN or WiFi dongle and the inverter, but I'm still noodling around with the best way to capture everything.
Click to expand...

Let me know what works. RE: Masters, there are only the two inverters and the OrangePi on the wire. On the 9600 bus everything is flawless, I've done all the hardware swap. RS-485 is seriously forgiving, I think I'm using #20 or 22 zip cord. I've got 7 sensors daisy chained on the 96 along with an 8 port relay board. Probably 30 ft of wire and sloppy splicing. The 19.2 bus is maaaybe 7 ft with only the two inverters, and one very neat splice at the first/primary inverter. I'll re-examine the code and update the modbus libraries next go around.

The 'C' program is doing a lot more than just polling, two of the sensors are on the panel feed, and the relays can trigger turning off high current loads based on draw. This seemed like a neat idea, but in practice it's sort of annoying to manage. The only time its a problem is when I'm charging an EV, and EVERYTHING else is on, which has happened, but I think I'd rather just get another inverter, and let it mostly rip. The new openEVSE unit allows me to adjust charging rates on the fly via web api, I'm going to just tie it into the primary sensor and turn it down if my demand get's too high.

Fun to look at the graphs, but I want to be at a point where I don't have to even think about it, it just does what it's supposed to.
 
You must log in or register to reply here.

Similar threads

M
EG4 PowerPro or Ruixu for 18KPV?
2 3
Replies
43
Views
2K
murmeister
murmeister
T
EG4 18kPV AC Couple Questions
2 3
Replies
49
Views
2K
wheisenburg
wheisenburg
rhino
EG4 18kPV array output turning on and off
Replies
15
Views
637
#40Fan
#40Fan
SignatureSolarJess
Signature Solar 6000XP + 18Kpv Customer Code
Replies
5
Views
665
timselectric
T
D
EG4 18KPV grid tie in Southern CA
Replies
2
Views
387
Markus_EG4
Markus_EG4
Back
Top