I have a PR38-30_50 board. I’ve noticed (at times) that my Python routine throws an Exception when reading Current values from the board. It is ‘probably’ thrown on the Read. (Yeah, I forgot to check to see if the Exception was thrown on the write or read. If you need that, I’ll get it.)
Tonight, I was using a really old, really bad space heater that was drawing 8A. As the space heater itself was heating up, I noticed that the blower motor was starting to have issues spinning and then would stop at times. It was during these events that the the exceptions were thrown in my Python code.
To make matters more interesting, I noticed that the monitor that was hooked up to my Python board blinked. Yes, blinked. I’ve never seen that issue when the space heater was off. I’m not quite sure of what could be going on; but, it ‘seems’ to be related to grounding perhaps.
Is there any guidance that you can give me that would help stop this issue?
can you share the python exception error?
Are you using a common power supply to power up the python board and current monitor board?
Unfortunately, I was not able to exactly duplicate the issue; but, I did notice two curious things after adding a lot more debugging code.
after receiving the 4 byte array from the board, I typically did a check like:
if (b + b + b == b):
…print everyone is happy…
I noticed that the calc I wrote did not always work and that if I added the following:
if (b + b + b == b):
. . print everyone is happy…
. . i = b + b + b;
. . i = i - 256;
. . j = b;
. . if (i == j):
. . . . print everyone is happy again
I received a batch of the following when there was no current running:
b = 0
b = 0
b = 0
b = 255;
Since I am really busy and in no mood to do the bit banging, I figured I would just code around that and be done with it.
Any thoughts to share about this? Did I miss something in the specs?
something like this could happen… lets say controller was calculating the current and it got interrupted by the i2c communication.
The only i2c communications that I am using is the 1 NCD board.
- I send the write command
- I do the wait
- I send the read command
- I check the crc
What I am doing is not very sophisticated.
I think the readings are fine (IE. the first 3 bytes); but, I’ve had to adjust my code in order to handle two conditions in which the crc calculator is off by 1 bit. Not always; but, let’s say 10% of the overall R/W cycles have this crc issue. Also, when I adjust my code to handle the crc issue, the “bad” current reading is inline with the previous and next “good” R/W cycles. So, I think this is all in the crc calc routine.
By your comment, it appears as if the crc calculator is getting interrupted and not properly finishing the calc. OK, I can sorta buy that; but, the code to do the crc is probably less that 20 bytes. The routine should complete in a few nano seconds. Since it is off by 1 bit, I think there is an issue with the firmware in the crc calculator.
Thanks! We can close the issue unless you want me to do more debugging.