LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Hexadecimal String To Number conversion

Solved!
Go to solution

@crossrulz wrote:

wiebe@CARYA wrote:
Start and stop signatures are also an option, but also just make communication failure less likely.

That is all that these communications schemes actually do: make failure less likely. 


Well, also recovering communication if (when) communication failed. Although perhaps that is a subset of making failure less likely.

 

With a binary streams recovering will usually work out (by looking for expected patterns).

 

With end termination characters (that can't occur in the data) or 2 way communication recovering is a lot easier.

0 Kudos
Message 31 of 41
(774 Views)

wiebe@CARYA wrote:

With end termination characters (that can't occur in the data) or 2 way communication recovering is a lot easier.


I fully agree that ASCII protocols (with the termination character) are easier to deal with, especially on the read side with VISA.  Most importantly, it is a lot easier to debug since you are dealing with text instead of random bytes.  But you do lose accuracy unless you use a lot of characters.

 

A 2-way may be a good idea to start the stream (have the PC tell the STM32 to start the data stream and when to stop).


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 32 of 41
(771 Views)

@crossrulz wrote:

wiebe@CARYA wrote:

With end termination characters (that can't occur in the data) or 2 way communication recovering is a lot easier.


I fully agree that ASCII protocols (with the termination character) are easier to deal with, especially on the read side with VISA.  Most importantly, it is a lot easier to debug since you are dealing with text instead of random bytes.  But you do lose accuracy unless you use a lot of characters.

 

A 2-way may be a good idea to start the stream (have the PC tell the STM32 to start the data stream and when to stop).


You can always send the float's flattened bytes encoded as hex strings of course 😁.

0 Kudos
Message 33 of 41
(754 Views)

wiebe@CARYA so you're recommending me to convert my data in string and then send it?

 

@crossrulz I still have a problem with the Unflatten From String.

 

If I put a constant string input, as you showed, it works.

If I continuously send messages from stm32 in input (referred to the scheme below) it works.

But if I stop to sending data from the stm32 leaving the COM open, it return me this error. What I'm doing wrong?

error.PNG

0 Kudos
Message 34 of 41
(734 Views)

You're trying to unflatten an empty string. You should only perform the conversion when you have read in data. (And you should put in checks for your start value to make sure you have all bytes in the correct order.)

 

I'm away from a computer I can test on, but I'm pretty sure if you tried to reproduce that with a constant input that you would get the same error for an empty string input. Probably for any other input of less than 6 bytes (the size of your cluster containing 3 16-bit values) as well.

0 Kudos
Message 35 of 41
(723 Views)

@giomarinna wrote:

What I'm doing wrong? 


You are still using the Bytes At Port to tell the VISA Read how many bytes to read.  That is a major issue.  You really need to better define your protocol.  Did you watch the video I linked to before?

 

Also, if you change the byte order to Little Endian at the Unflatten From String, you will not need to use the Swap Bytes.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 36 of 41
(717 Views)

I watched your video, now I'm trying to improve my project.

I insert a constant with 2 value because I expect 2 byte message. 

From my nucleo board I'm sending this message {0x00AA, 0x0000, 0xFFFF}, element by element.

The Unflatten From String still return me that error.

Cattura1.PNG

0 Kudos
Message 37 of 41
(701 Views)

@giomarinna wrote:

I insert a constant with 2 value because I expect 2 byte message. 

From my nucleo board I'm sending this message {0x00AA, 0x0000, 0xFFFF}, element by element. 


Your message is actually 6 bytes long.  So you should be reading 6 bytes.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 38 of 41
(695 Views)

I worked hard and I improved my code but there is one last problem.

 

I'm sendind this message from my stm32: {0x00AA, 0x0000, 0x98FE, 0x98F9, 0x9919, 0x98F1, 0x9900, 0x98E5, 0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF}; where 0x00AA is the start and then all the info I want to transmit.

These info needs to be processed and this process have sense only if the vector is readed in the correct order: starting from 0x00AA (you will see AA00 into the attached screenshot because transmission swaps the bytes).

 

The problem is that sometimes on labview the vector is received not in the correct order. I tryed to solve this problem continuously sending the vector from my stm32 whilst a 19 value in not sent from labview to my stm32.

The drowback is that sometimes this "syncronizzation" require lots of attempts.

 

I can't understan why labview do not receive the message in the correct order. If I try to send the same message to a classic termial connected to the COM, the vector is always received in the correct way. Any advise?

 

I attach some screenshot which allow you to better understand.

front_pnl.PNG

block_diag.PNG

block_diag_2.PNG

   

 

 

0 Kudos
Message 39 of 41
(659 Views)
Solution
Accepted by topic author giomarinna

I'm not understanding why you are trying to read 32 bytes when searching for your start word.  My original suggestion was to just use 1 byte as your start byte.  If you are going with a start word (2 bytes), then you need an extra step.  Read 1 byte at a time until the 0xAA is read.  Then read 1 byte and verify it is 0x00.  If the verifcation passed, then you can read the rest of the message (30 bytes).

 

You also do not need the VISA Clear if you use this synchronization method.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 40 of 41
(649 Views)