Hi there, 

I have an Axpert Max 7.2 which is running the following firmware versions as read from the commands below. 

QVFW: VERFW:00045.07

QVFW3: VERFW:00012.13

Shouldn't really matter but I am executing the commands over USB using some home-rolled code heavily inspired by the code found here.

I am attempting to read data for the second PV string using the QPIGS2 command but I am running into an issue where the inverter is not returning a response. 

I'm able to run all of the other queries I've tried to run thus far (QPIRI, QMOD, QPIGS, QLED)

Is there something that I need to do differently to read data from the QPIGS2 command or is this potentially an issue that can be resolved with a firmware update, and if so, could someone please point me in the right direction to find the firmware versions?

Some guidance would be greatly appreciated. 

Thanks in advance... 

8 hours ago, spydr97 said:

I am attempting to read data for the second PV string using the QPIGS2 command but I am running into an issue where the inverter is not returning a response. 

There is no special character on the CRC for that command. 

Not all main firmwares handle the QPIGS2 command but 45.07 does. 

Not all display firmwares pass through the QPIGS2 command, but 12.13 does. 

Finally, QPIGS2 is a longer command, 6 characters. When you add two CRCs and a carriage return, that comes to 9 characters. It turns out that in some cases, you have to send such commands in two strings, with no more than 8 characters in each sent string. It's something to do with USB libraries. See the following post, and if interested, two earlier posts:

https://forums.aeva.asn.au/viewtopic.php?p=75802#p75802

Edited December 1, 20241 yr by Coulomb

On 2024/12/01 at 5:08 AM, Coulomb said:

There is no special character on the CRC for that command. 

Not all main firmwares handle the QPIGS2 command but 45.07 does. 

Not all display firmwares pass through the QPIGS2 command, but 12.13 does. 

Finally, QPIGS2 is a longer command, 6 characters. When you add two CRCs and a carriage return, that comes to 9 characters. It turns out that in some cases, you have to send such commands in two strings, with no more than 8 characters in each sent string. It's something to do with USB libraries. See the following post, and if interested, two earlier posts:

https://forums.aeva.asn.au/viewtopic.php?p=75802#p75802

Thanks for the reply @Coulomb.

I had zero success getting the command to work over USB last night, even using the Python code linked directly, so eventually I just switched over to using the RS232 port with a serial to USB adapter instead of the USB port and everything is working perfectly without any other modifications. 

I would never have thought to try that so thanks for the heads up. 

16 hours ago, spydr97 said:

I had zero success getting the command to work over USB last night,

My understanding is that you split the command to send the long command into two, sending just the first 8 characters in the first call, and the remaining (just the carriage return in this case, but sometimes more) in the second.

But avoiding the USB port (and hence the Python USB library) altogether is another way.