CRC 32bit

[Norbert_B]

Please post the VI, no image.

From the image: Why are you reading bytes multiple times only to append them afterwords? Why don't you read the whole string in one read command?

You use the error cluster to stop the loop. Does the loop stop before reading all expected bytes (read: is there maybe in error in transmission)?

Norbert

[jay0909]

Hi,

         THe problem is that i have deployed the LV code on Rapsberry pi. Some times i get rad error so to avoid that i used error cluster. Also,  if i read the whole bytes at once i won't be able to recognize the frames, i need this functionality for logging. 

[Norbert_B]

---

@jay0909 wrote:

[...]Also,  if i read the whole bytes at once i won't be able to recognize the frames [...]

---

I am talking about this part of the code screenshot (the inner case frame):

You can easily read all 9 bytes in the beginning at once. The CRC is what i encased in the red rectangle, right?

Norbert

[jay0909]

yes that'S the CRC. i can read all 9 bytes at start before data bytes, but for my logging purpose its not of use , i log the header seperately because for some test purposes. 

[Norbert_B]

Besides that (performance related) discussion: Does the frame of 9+4+X bytes look as expected?

I understand that the frame looks like expected, but the CRC does not. Is that correct?

Norbert

[jay0909]

Yes thats true. its 9 bytes header+data bytes + crc. CRC doesn'T match my calculation.

[Norbert_B]

What does a probe on the last 4 bytes (CRC) show when running the code?

Norbert

[jay0909]

Hi,

           The probe on the last 4 bytes show ascii string but i convert to hex immediately for reading purpose. If you want i can attach it. I'll explain in detail. 

1) I recieve the frame from UART the total number of bytes  is random in the frame (depending on the header id.)

2) In my program i start recieving the frame and segregate according header +data+ crc for my test purposes. But before even segregating the whole frame i need to check the CRC and validate the frame because some time the controller sends garbage some times. 

THe program which i sent you has no crc check yet becos of wrong calculation of the CRC. The example frame which i have from controller'S CRC is not matching my calculated CRC. 

I have any questions . Please let me know.

[Norbert_B]

My understanding of your issue is:

1. You have a controller which is sending frames with arbitrary length. Each frame is prepended with 4 bytes stating the frame length and appended with a CRC32 which is computed by the controller.

2. You use LV to read the frame length, the frame and the CRC32.

Using this, the frame you receive is expected while the CRC32 is not of the expected value.

There are several options:

- You read an incorrect length of the frame. The CRC32 reading adds or is missing bytes because these are mislinked to the frame

- You convert the CRC32 string incorrectly to U32 (Hex)

- The CRC32 transmission uses some swapping in bytes or inverse bit order for bytes (essentially previous option)

- There might be a buffer issue: Are there instances where you flush the receive buffer?

I leave out CRC32 computation errors (e.g. incorrect CRC32MASK) as you state that using other programming languages you can correctly read the CRC32 of the controller.

Please confirm that this understanding is correct. If not, clarify.

Norbert

EDIT: And as i side note: You never shared any code. You only shared a screenshot of a little piece of code showing only a fragment of functionality. However, one additional question: Is this frame/CRC32 issue reproducable? Read: Getting the very same frame/CRC32 combination?

[jay0909]

Yes your understanding is right.  The calculated CRC on labview part is wrong. 

But, I don't read incorrect length because the i use header id to identify the first 2 byte and read the whole frame wrt to data length. 

I cnvert to proper hexbecause i read byte by byte and convert. 

The only format is Little Endian. 

Last option, i am not sure.