LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

CRC 32bit

Solved!
Go to solution

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

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 11 of 46
(2,201 Views)

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. 

0 Kudos
Message 12 of 46
(2,196 Views)

@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):

MultipleBytes.PNG

 

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

 

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 13 of 46
(2,189 Views)

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. 

0 Kudos
Message 14 of 46
(2,186 Views)

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

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 15 of 46
(2,181 Views)

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

0 Kudos
Message 16 of 46
(2,178 Views)

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

 

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 17 of 46
(2,169 Views)

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.

0 Kudos
Message 18 of 46
(2,166 Views)

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?

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 19 of 46
(2,162 Views)

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. 

0 Kudos
Message 20 of 46
(2,149 Views)