Controlling A Case Structure with String Numbers.

[Hobbs23]

Thanks everyone

I ran a simplified version, and as Ben surmised, it stayed all the time in default not recognizing the ".." as aputman described should be the case. 

I shall see what I can find in my LV2009 basic to convert to ..... I32 as altenbach suggested.

I will report back.

[Hobbs23]

Thanks altenbach for you recommendations

So far the only problem I am having with implementing, is getting the conversion process to leave the zero's in place. These form place markers for the tens of GHz column. Is there a common way to get around this or is my choice of using the "Decimal String to Number" not the right one?

[aputman]

Hello Hobbs

You only need the integer values for the case selector, right?  In that case, the leading zeros have no use.  00953 is the same as 953, as far as integers are concerned.  

[Hobbs23]

Yeah.... It killed me to change the meaning to satisfy something that should just work in my mind (I am sure there is a valid reason), but I had come to the same conclusion. It works technically....

...now if I could just figure out how to get the Visa Receive to give me a solid stream. It gives me great numbers, and then the it throws in some squirrely numbers, and the sync of the numbers in my test indicator jump around. This Case Structure we have been tweaking, sees this and goes to default.

No idea. 

[crossrulz]

---

@Hobbs23 wrote:

...now if I could just figure out how to get the Visa Receive to give me a solid stream. It gives me great numbers, and then the it throws in some squirrely numbers, and the sync of the numbers in my test indicator jump around.

---

Sounds like you are using the Bytes At Port to determine how many bytes to read from your serial port.  This is generally a BAD idea.  Use the message protocol!  Does the message end with a termination character such as a Line Feed or Carriage Return?  If so, then just tell the VISA Read to read more bytes than you ever expect and use the termination character end the read (configuration with the Configure Serial Port).

[Hobbs23]

I hear ya crossrulz

You are half right. I only use Bytes at port to determine that something is there. The unit does not use Line Feed or Carriage Return consistently. So as you can imagine I get errors reading something that isn't there. So all I can think of is to query bytes, and if there is, visa read it. I would love something better. All the stuff in here is not intentional, because copying is the result of ignorance... but it is a reason.

[Hobbs23]

You Know

I just added a string indicator on each of those shift register outputs, lined them up and in Marque fashion, the information scrolls across without a jump, or flicker or extraneous information. Meanwhile after it is all concatenated, reversed, and fed into a single indicator, it does all those things.

Ideas? 

[Mark_Yedinak]

The strategy I use for reading variable sized data when I do not know the size or have a termination character is to wait on a read of a single character. I use a long timeout here and throw an error if I receive no data. Depending on your situation you can wait indefinitely. If I get a byte that means I have something there. Good, now let's read the rest of the data. What I do is read chunks of data with a very short timeout. The assumption is that I should get all of the data for this message at one time and would have some break between pieces of data. Some tuning is involved to find the correct timeout value for the block reads that I do. While this is not perfect I have found it works very reliably.

[crossrulz]

---

@Mark_Yedinak wrote:

The strategy I use for reading variable sized data when I do not know the size or have a termination character is to...

---

Ideally, the communication protocol of the instrument should allow you to determine how many bytes you have to read when it does not have a termination character.  This typically involves reading X bytes, checking a message ID, and then reading what should be left of the message based on that message ID.  This is usually needed only for binary/hex data formats.  99.9% of the devices I have ran into that I send ASCII data use a termination character.

[Mark_Yedinak]

---

@crossrulz wrote:

---

@Mark_Yedinak wrote:

The strategy I use for reading variable sized data when I do not know the size or have a termination character is to...

---

Ideally, the communication protocol of the instrument should allow you to determine how many bytes you have to read when it does not have a termination character.  This typically involves reading X bytes, checking a message ID, and then reading what should be left of the message based on that message ID.  This is usually needed only for binary/hex data formats.  99.9% of the devices I have ran into that I send ASCII data use a termination character.

---

It depends on what you are communicating with. In the ideal world everything would have a well defined machine centric protocol. However that is not always the case and when you encounter something that doesn't have a machine interface you need a way to deal with it.

I interface with a printer interface that is more centered on a human on the other end of it than a computer. When requesting data from the printer the amount of data returned can vary greatly. For instance, a request of all the printer settings will return over 900 lines of text with the settings and status information. Each data element gets 1 line. However, the total number of lines will vary depending on the printer model, the FW version and what options are installed. The end data is delimited with line that contains a pair of quotes (""). Neither the TCP VIs nor the VISA VIs allow for a multibyte terminator. If you are reading back JSON or XML you encounter the same issue. There is no easy terminator defined.

So, it is extremely useful to have a tool in your toolbox that allows you to read variable length, unterminated data streams. Not everything one encounters is well defined and well behaved.