How can I change a hex value to normal without changing the characters

[altenbach]

---

Omar II wrote:

tbob's snipit assume your data is one way and your VI assumes another.

---

 We don't need to assume anything. The string in the posted example is set to hex display and that's what I was using. 😄

[chuck72352]

Omar,

Yes, it seems to work. The input is hex and the output is nomal.

[Mark_Yedinak]

---

tbob wrote:

---

altenbach wrote:

I don't understand tbobs solution, because it assumes that the input string is in hex formatted normal display while the original problem stated that the input is in hex display. Big difference! (I also don't see why it needs a 100ms wait in the loop, but maybe I am just impatient ;))

---

I didn't notice that the input was a string set to hex display.  I thought it was a regular string.  As for the time delay, that is my standard practice for all loops to not hog the CPU, unless it is very time critical.

---

If that is the case I would use a delay of 0. It will allow LabVIEW to context switch if necessary but it will also process the loop as quickly as possible. For long strings your standard solution will cause a significant delay in the application.

[tbob]

Altenbach is right.  I made an assumption instead of investigating the string control.  It is set to hex display which means the characters in the string are converted to their ASCI equivalent.  Example:  "abcd" in normal display will become "6162 6364" in hex display.  The real data is actually the string "abcd".  The original problem was to convert the hex display "6162 6364" to the string "61 62 63 64".  Same as converting a normal display "abcd" to a normal string indicator "61 62 63 64".

[chuck72352]

Yes, I realized that and made adjustments to the input.

[tbob]

---

Mark Yedinak wrote:

If that is the case I would use a delay of 0. It will allow LabVIEW to context switch if necessary but it will also process the loop as quickly as possible. For long strings your standard solution will cause a significant delay in the application.

---

Who decides what a significant delay is?  It depends upon the application.  It is up to the user to choose the delay time.  It doesn't necessarily have to be 0 or 100.  I used 100 just for an example.  The point is that NI recommends putting in a delay in all loops, even a delay of 0, so that the CPU is not hogged by Labview.  I have seen instances where the execution appeared to run slowly because the front panel was not being updated regularly, due to a loop without a delay.

[Mark_Yedinak]

---

tbob wrote:

---

Mark Yedinak wrote:

If that is the case I would use a delay of 0. It will allow LabVIEW to context switch if necessary but it will also process the loop as quickly as possible. For long strings your standard solution will cause a significant delay in the application.

---

Who decides what a significant delay is?  It depends upon the application.  It is up to the user to choose the delay time.  It doesn't necessarily have to be 0 or 100.  I used 100 just for an example.  The point is that NI recommends putting in a delay in all loops, even a delay of 0, so that the CPU is not hogged by Labview.  I have seen instances where the execution appeared to run slowly because the front panel was not being updated regularly, due to a loop without a delay.

---

From a programmer's perspective I want my applications to run as fast as possible without adding unnecessary and arbitray delays. As I stated a delay of 0 will allow the systemto context switch and meet NI's recommendation for good programming practices. A delay of 100 ms inserted just because WILL introduce an unnecessary and arbitray delay. If the string is 100K, your loop will introduce a delay of 50 seconds into the application. This is a waste of that 50 seconds. If another programmer were trying to inprove performance and didn't use the profiler I doubt the first place they would look would be a subVI named "Insert spaces in string". However with the arbitray 100 ms delay this would be a significant and easy performance improvement.

[tbob]

---

Mark Yedinak wrote:

From a programmer's perspective I want my applications to run as fast as possible without adding unnecessary and arbitray delays. As I stated a delay of 0 will allow the systemto context switch and meet NI's recommendation for good programming practices. A delay of 100 ms inserted just because WILL introduce an unnecessary and arbitray delay. If the string is 100K, your loop will introduce a delay of 50 seconds into the application. This is a waste of that 50 seconds. If another programmer were trying to inprove performance and didn't use the profiler I doubt the first place they would look would be a subVI named "Insert spaces in string". However with the arbitray 100 ms delay this would be a significant and easy performance improvement.

---

Chill out Mark.  It was just an example.  I never said it had to be any specific delay time.  I agree with 0 if you need the speed or if the input string is long.

[Mark_Yedinak]

---

tbob wrote:

---

Mark Yedinak wrote:

From a programmer's perspective I want my applications to run as fast as possible without adding unnecessary and arbitray delays. As I stated a delay of 0 will allow the systemto context switch and meet NI's recommendation for good programming practices. A delay of 100 ms inserted just because WILL introduce an unnecessary and arbitray delay. If the string is 100K, your loop will introduce a delay of 50 seconds into the application. This is a waste of that 50 seconds. If another programmer were trying to inprove performance and didn't use the profiler I doubt the first place they would look would be a subVI named "Insert spaces in string". However with the arbitray 100 ms delay this would be a significant and easy performance improvement.

---

Chill out Mark.  It was just an example.  I never said it had to be any specific delay time.  I agree with 0 if you need the speed or if the input string is long.

---

The only reason I wanted to stress the point is that besides answering the basic questions here we should also strive to teach good programming techniques. A programmer should always be thinking about the big picture and the application as a whole. It would be very easy for new folks to see the comment about always using a delay in a loop and take it to heart. They embrace the concept and code all of their loops with some arbitray value and then wonder why their program runs so slow. In addition, this can lead to others (think managers) that LabVIEW itself is not capable of running fast applications. We should try to instill best practices with all of our replies.

[altenbach]

Even for moderate length strings, I would omit any waits, even 0ms. A tasks switch after each iteration just creates way more overhead that what the delay is trying to solve. Even without a wait, it will allow a task switch at reasonable intervals, but won't get constantly (every few nanoseconds!)distracted on what it's doing. 😉

While I certainly would qualify, let's not turn this into a discussion among grumpy old men. 😄