Controlling A Case Structure with String Numbers.

[altenbach]

---

Hobbs23 wrote:

.

---

.

On a sidenote, this code is a complete mess. Here are some comments (all the other comments about the use of bytes at port" are still valid! I am only talking about general programming issues):

1. Your outer while loop is a psuedo FOR loop with exactly three iterations. Why not use a FOR loop instead?
2. Your inner small FOR loop can be deleted without any change in code functionality. It iterates only once anyway It basically is a glorified sequence frame with a 15ms wait. Since the wait runs in parallel to the property node, all it does is delay the later case structure. Pointless.
3. You can append the string in a plain shift registers. no need for the history terminals and string reversal.
4. Since if bytes@port=0 will cause the second FOR loop to not iterate, you can even delete the case structure (unless there is something important in the other case, which I doubt. Watch out for the shift register contents, though)
5. Your entire string analysis seems convoluted and fragile.
6. Labeling output indicators as "string" and "boolean" is not self-documenting and too generic.
7. ...

[Hobbs23]

Thanks altenbach

I'm working on implementing your suggestions.

This is good feedback, and yes I have some questions in order to learn, and implement properly.

altenbach wrote: Your outer while loop is a psuedo FOR loop with exactly three iterations. Why not use a FOR loop instead?

Please tell me the high points of having a FOR loop instead of a WHILE loop.

altenbach wrote: Your entire string analysis seems convoluted and fragile.

Indeed I agree, I noticed problems with the leading place holder zero being dropped from the string, and the numbers jumping around after being concatenated that I just dropped that part of the code until I can stabilize things. What you are suggesting may help me do that, then I will clean that up.

Ok, I will clean this up, test, and simplify. (I actually do love learning, and doing this. It is so different than what I normally do.

Thanks

[altenbach]

---

Hobbs23 wrote: 

Please tell me the high points of having a FOR loop instead of a WHILE loop.

---

Use the right tool for the right job:

Use a FOR loop if the number of iterations is known before the loop starts. This allows certain compiler optimizations, especially if you autoindex on the output. The final array size is exactly known and can be allocated correctly from the beginning. No need to check for termination conditions (Yes, in newer versions we can also enable the conditional terminal, but the upper limit on iterations is still known to allow for optimizations)

Use a WHILE loop if the final number of iterations is not known. Each iteration requires checking of the termination condition at additional effort. If you autoindex on an output tunnel, the final array size is not known (could be 1, could be 100M, and could be infinite if the loop never stops, making you run out of memory eventually). This means that the compiler needs to guess on the size and allocate new memory whenever the guess was an underestimate. This is expensive!

[Hobbs23]

Ok That's good enough for me. Ditching the While loop in favor of the FOR Loop.

In dropping the extra elements from the Shift Register, I also loose the readability of the information coming through. The part of the string I use is the first 5 digits on the left. For Example the string comes in like this { ".""."04950"."0720".""."} We watch the String Indicator, and programmatically use those first 5 digits to make changes to the test equipment.

I imagine there is another way to do this, I also assume I am not aware of it! 🙂

[Hobbs23]

Ok, I have been working this for a while. The problems are String indicator visual persistence (the 5 digit number should just sit there and scroll up), then be able to snag the first 5 numbers in each received batch, and use them to determine what frequency I'm on consistently.

I dumped the FOR loop around the Bytes at Port. Dumped the While loop around all that. The History Elements on the Shift Register seem to be the only way I get any persistence at all in my indicator.  The Match String still doesn't work right. What you see is just my last attempt.

Currently out of ideas. I could use another smack I think. 😉

[altenbach]

We don't debug pictures. Attach the VI.

(Still looks completely wrong!)

[aputman]

Have you tried using the Advanced Serial Read and Write VI in the examples folder that ships with Labview?  Get the communication working in that VI first and then integrate it with your app.

• Enter the proper port settings (baud, parity, etc)
• Assume that the instrument uses a termination character ('\n' or 0xA in hex). 
• Determine how many bytes you would expect for a response, add 100 and set this as the number of bytes to read from the port (or use the default 1000 if that is enough bytes).  
• Write a command to the port (if required)
• If necessary, you may need to wait for a bit to allow the device to process your command.
• Read from the port
• What response do you get?

It shouldn't be as hard as you show it to be.  

[aputman]

Actually the wait between write and read is not necessary if your timeout value is large enough for the device to complete the task.  However, keep the timeout value within reason, not too large and not too small......just right.  

[Mark_Yedinak]

There is no reason to read the data 1 byte at a time. A single read with enough bytes specified to contain the full response is all that is needed. Also, the 15 ms delay between each read will really slow the code down. Very inefficient, especially if the response is terminated. If the data is not terminated, you can read the data in chunks, not single bytes, and stop reading once you get a timeout. This timeout would be set to a small value. Prior to reading the chunks you would have a read for a single character with a longer timeout. A timeout on the first read would be a true error. You did not get a response. The timeout on the following reads are simply to provide for a gap indicating the data is most likely complete.

[Hobbs23]

No Termination character yet. They are using them as display formatting in in the same com stream. They said that they need some time to make changes.

That is why I receive one byte at a time.