Reading data in multiple case statements

[lafox24]

I am trying to decode parts of my serial data by using case statements in series.  I can read data in the first case statement but not in the second.

The code works if I only use one case statement, so it appears I cant read any data in the second case statement.

I need to read the data at the indicators "FOOTER" and DATA_ARRAY".

Thanks

[altenbach]

You are reading 2 bytes at a time (not 1 as described in the diagram comment) and since you are not using termination characters you'll get garbage if you have a 1 byte frameshift in the data.

Is the string going to the second case structure really "6100"? This is four bytes while you are only reading two to get that value, later displayed in hex format. It is safe to say that the string will never be "6100".

[lafox24]

The check should be for hex string of 6100 (2 bytes).  If I try to read the data from the first case it is always zero, but in the first case it is correct. 

I think the trouble is that when the data is passed to the second case statement it cannot be read.  Why should this be?

[lafox24]

I've tried displaying data after first case and it is always zero, so the problem appears to be passing the MESS data outside of the case statement.

I changed the second case to detect zero and it works.  The second case is always seeing zero.

[AeroSoul]

I'm not exactly sure of what you are trying to read from, but this seems like a horrible execution.

What you should be doing is reading only once and then deciding on what to do with received data.

Don't use things like reading only 2 bytes either, depending on speeds of your applications and hardware you are more than likely to get garbage data. Don't use "bytes at port" function either, it doesn't always work and can give you bad data as well.

If you are trying to react to specific data that you read, try using polling.

This is from one of my programs:

First I write a command and then i read a response. The response is only about 20 bytes long, but i use a term char and instead read a much higher number. If you don't want to use polling then just read a large number of bytes, Labview will give you only as much as it has, which should be your whole data packet, unless you are running the VI really slow.

[crossrulz · Accepted solution]

When it comes to this type of communication, I prefer using a "pyramid" architecture (cascading case structures remind people of the Mayan pyramids).  At each case structure, you have the option of throwing everything away and start back at searching for the sync byte(s).

So first read 1 byte looking for the start of your sync word.  Once you find the correct first byte, read the next byte and make sure it is correct.  If it is, read the rest of your message.  For when deciding what the message type is, I recommend you use the Unflatten From Array to convert it into a U16.  You can then use that value in the next case structure.  Right-click on the case structure and there is an option to set the radix.  I changed it to Hex.

[lafox24]

Thanks I will try reading the whole packet once a header is received, that should make it simpler.  I still don't understand why I can't read that byte outside of the case statement.

[lafox24]

Thanks I will try this also.  Most useful.

[Frozen]

---

@lafox24 wrote:

I still don't understand why I can't read that byte outside of the case statement.

---

Unless I have misunderstood your question, as mentioned earlier, you are reading 2 bytes, but your case statement is expecting 4 bytes.

[RavensFan]

Take your 2 bytes and typecast it to a U16.  Then wire that to a case structure.  Notice the radix is being shown on the string constant and the case structure selector and that they are both set for Hex display.