Axpert - Com Delay & Missing Commands

[KLEVA]

Hi All

Have searched this and the Australia Forum as well as doing my fair share of Google... But to little avail.

I have an Axpert (Mecer branded) 5K with a remote unit (com cable extended to about 40m), purchased in Jan 2016. Remote Unit works fine, but ALL available software has failed to communicate correctly (WatchPower, AICC, SolarMon, etc). I can communicate through a terminal.

Eventually I wrote my own bit of software and saw that there was a delay in getting a response. I had to force my software to wait at least 750ms for QPIGS responses and sometimes would still miss the end of the stream. If I relied purely on the <cr> at the end of responses there were even more failures.

Stuff tried:

• Added 5v supply directly to the Remote Unit - No Difference
• Used the supplied RS232 Cable directly at Invertor - No Difference

As an aside: The Parallel command QPGS1 just returns (QPGS1/? nor does the Q1 command give any data.

Does anyone have any clues/suggestions?

Edit: I have just tied WatchPower using the USB connector and it seems to work perfectly??? Now even more confused...

Edited April 3, 2016 by kleva
Added - USB test info

[Mark]

I removed my remote terminal and all worked well after that... I think the way you daisy chain the connections is very NB.  Haven't tried to sort this as I can do everything through SolarMon.

[KLEVA]

Thanks for the reply Mark. The test I did with the supplied cable was without the Remote Unit.

[Guest]

If everything fails then you have a faulty hardware comms unit. Return it for testing.

[Coulomb]

10 hours ago, kleva said:

As an aside: The Parallel command QPGS1 just returns (QPGS1/? nor does the Q1 command give any data.

Does anyone have any clues/suggestions?

Edit: I have just tied WatchPower using the USB connector and it seems to work perfectly??? Now even more confused...

Well, that's strange. I assume you must be sending CRCs properly, or you would not be getting responses from QPIGS. The "/" in the response for QPGS1 is the first CRC character for that command. (The second is not a question mark but a 0xFB character, which could well display as a question mark depending on your comms software.)  And the QPIGS command has two CRCs with the MSB (Most Significant Bit, bit 7) set, so it can't be a problem with that.

But perhaps you are using software that sometimes gets the CRC wrong. But then it would respond with a NAK. Perhaps you could send to another computer with a serial port and confirm that you are sending a slash (0x3F) and 0xFB for the CRC of the QPGS1 command.

The fact that the USB connector works perfectly suggests that there is something wrong with the serial port: perhaps it is distorting the signal, so that sometimes commands don't work? For example, it might have poor rise time, or the level might be marginal, or there might be noise. A CRO or DSO would help with that. It might help prove what's faulty, or there is a slight chance you might be able to fix it yourself and save time, or just give you confidence that it's not something you're doing wrong.

[KLEVA]

Hi Coulomb. I am fairly sure I am using the CRC correctly (CRC16 XModem), and I am checking if any of the CRC responses are not invalid for the Axpert (0x13, 0x10, 0x28 are invalid as far as I know in the CRC). Here are the results of some commands:

QPIGS + 0xB7 + 0xA9 <CR>
Returns 110 Bytes
-> (Byte 1)0x28 + ...(106 Data Bytes)... + (Byte 108)CRC + (Byte 109)CRC + (Byte 110)0x0D

QMOD + 0x49 + 0xC1 <CR>
Returns 5 Bytes
-> (Byte 1)0x28 + (Byte 2)MODE + (Byte 3)CRC + (Byte 4)CRC + (Byte 5)0x0D
eg: 0x40 0x4C 0x06 0x07 0x0D For Line/Utility Mode

Q1 + 0x1B + 0xFC <CR>
Returns 5 Bytes
-> (Byte 1)0x81 + (Byte 2)0x31 + (Byte 3)0x1B + (Byte 4)0x63 + (Byte 5)0x0D
Note: All "unknown" commands seem to respond like that, last CRC replaced with 0x63 (Question Mark) and no 0x28 at Byte 1

MUCHGC102 + 0x82 + 0xE1 <CR>
Returns 7 Bytes
-> (Byte 1)0x28 + (Byte 2)0x41 + (Byte 3)0x43 + (Byte 4)0x4B + (Byte 5)0x39 + (Byte 6)0x20 + (Byte 7)0x0D
Note: Acknowleged (and confirmed that it had changed the Charging Current)

Where the confusing part comes in is that the MUCHGC command is a parallel command, but other parallel commands are being rejected. QPGS1 responds exactly like Q1 above, last CRC replaced with 0x63.

FYI - Not sure if it helps, but the two QVFW (CPU version) responses are 00072.40 and 00001.24

What I will try this weekend: I received an extra Serial Board with my Remote Unit (designed to replace in the units with only USB). I will change out the existing with the board I have "spare" (it will have to dangle dangerously somewhere as the slots don't line up). If any good comes of that I will post it here.

<EDITS> For future readers not to get confused with the responses below: The original post had 0x40 listed instead of 0x28 for the <left parenthesis> response, this was just a typo

[KLEVA]

PS: Coulomb, JDP & Weber - You guys have done awesome work in figuring this monster out, without all your board posts and information here and on the Australia forum, I wouldn't have known even how to do half the stuff.
PPS: To all the others that contributed to these forums - 2 weeks of Board surfing has taught me more than I ever wanted or needed to know about Solar/Invertors/Batteries/etc and I really wish I had the funds (and roofspace and sun!) to do this properly. My budget was R50k, far too low, but got to start somewhere.

Thanks again
Kevin
PV Kit: 1 x Axpert MKS, 1.4kW PV, 200Ah Battery Bank, 4 hours unshaded Sunlight
Water Kit: 1 x 5000l Municipal Water Jojo, 1 x 400l Rainwater Jojo, 12 tube Water Heater (gets just hot enough with 4 hours sun)

Want: 2 x Axpert MKS, 6kW PV, 800Ah Battery Bank, 8 hours unshaded Sunlight

[KLEVA]

 Also want a wife who remembers that the stove/oven/kettle and iron CAN'T be on at the same time, my Axpert just had heart failure at 07:30!

[Chris Hobson]

4 minutes ago, kleva said:

 Also want a wife who remembers that the stove/oven/kettle and iron CAN'T be on at the same time, my Axpert just had heart failure at 07:30!

"My mother-in-law and wife punishing the system on day 1 with microwave and hair-dryer on at the same time. Need to do solar 101 with missus and her mother again since they have just failed. Still managing to get 1.7 kW from the panels mid -afternoon. I was getting 2.24kW at midday."  - Quote from one of my posts July 2015.

Have run off a gennie for 20 years I would have thought alternate use of appliances would have been second nature apparently not. I scolded her and told her I had not installed a nuclear power plant and there was a finite amount of power available. It is the same the world over.

[Guest]

30 minutes ago, kleva said:

 Also want a wife who remembers that the stove/oven/kettle and iron CAN'T be on at the same time, my Axpert just had heart failure at 07:30!

And as I did not want to go there I put in 2 in parallel lol. 

[___]

5 hours ago, jdp said:

And as I did not want to go there I put in 2 in parallel lol. 

Indeed, on of the main reasons I replaced most of my lights with LED was precisely so I don't have to scold so much about lights that are left on... :-)

[Coulomb]

9 hours ago, kleva said:

Here are the results of some commands:

I can't fault anything of what you're doing, except that you seem to be reporting the first returned byte in decimal, but are using 0xHH indicating that it's hexadecimal.

As far as I can tell, there is no place in the firmware that echoes bad commands as you are seeing them (but that still leaves some chance that there is). The other serial board experiment should shed some light.

[KLEVA]

Um, did I typo something? Sorry, all my results are in bytes in the code so manually translated to the hex, will double check tonight.

[KLEVA]

3 hours ago, kleva said:

Um, did I typo something? Sorry, all my results are in bytes in the code so manually translated to the hex, will double check tonight.

Yup, Sorry Coulomb, was just a typo, should have been 0x28 wherever 0x40 was shown - Have corrected above.

[KLEVA]

Waiting for the weekend to replace the serial, but in the meantime I dabbled with my own software and have the USB working (a bit too late to pass on to JDP, since AICC seems nearly ready after all the hard work that JDP & Manie have been doing).

So as an aside/slight topic change - As soon as the KLEVA™ Solar Monitor is tested properly, it will be made freely available - NB: It is not to replace the awesome and much better tools out there, it is just 1 part of a custom monitoring system: It just captures data from any Com Port/USB to a Database. There will be a guideline to write your own invertor DLL to match (it just needs to know some defaults/settings/commands), and can send that to MySQL/MSSQL/MSAccess/ODBC. Can run on any Windows from Vista, 2000 onwards, can be loaded as a service onto a server.

NB: To use this tool you will still have to write a front-end to make the "pretty" pictures/displays, as I said this is not a replacement for the other systems out there, but they will be free to use it as an interface if they wish, in fact almost ALL credit for the knowledge and effort comes from the users of this and the Australia form.

PS: KLEVA™ - The Trademark brand is only there because KLEVA is a registered trademark and has to be placed on all software I develop, there will be no cost/fees for the monitor software or any related. I wanted a tool to do something that wasn't out there - Use any flavour of Windows (although my old Windows NT machine is not possible), log directly to a database, and have a Device DLL that can be changed.

Expected ver 0.2 (beta) availability - 2/3 weeks

As a teaser (or confuser), feel free to take a look at the current config (semi-readme) file attached (converted to text here for readablility)

KLEVASolarMonitor.conf.txt

[KLEVA]

SBD!!!!!!!!!!!!! (Excrement, Abuse someone via the wrong hole, Generic Frustration)

My spare serial port board was missing - So didn't replace... (Bad move - accusing the WENCH of throwing it away... Divorce level nearly reached 8/10)

Got far too busy with other projects, so I think KLEVA Solar Monitor is slightly behind schedule... My front-end (no innuendo required), although not part of KLEVA Solar Monitor is problematic... Fighting to get a web-service to communicate via com/usb port, that is on another machine (where the monitor is - I make life too challenging)... So the Web Interface can only see the data, but not make changes, and for me this was a higher priority this week.

Tried setting the timing down, but noticed that it was mostly the longer responses that timed out, and that it occurred more often whilst on SBU Mode during the day (kinda like the Invertor had better things to do than update the dispay!)... Still get nothing from the Q1 or Parallel commands, although have yet to build the proper USB structure for anything but the QPIGS.

Also, been fighting with the Solar water side last two days... The collector is nearly 100 (Used a cooking temp thingy), but geyser was down to 45... Think the Thermosyphon is no longer working properly with the lower water pressure, might need a small pump to keep it even...

Now, back on topic - Still looking for somewhere to get temp monitors...