as said before: don't confuse slash display with slashes in strings...
(Simple) slashes in slash code display aren't "for real", they are just used for displaying nonprintable chars.
And that manual in no way says you need to send slashes, it just says "Send "Control+N", followed by a byte from 0-100". So you should send just "0e32" (hex display, or "\0e2" in LV slash display) to set backlight to 50%...
Thanks Gerd for digging that information out of the manual.
DVS, apparently you didn't try the code I posted for you in my reply #3. That should (will?) do exactly what Gerd pointed out in the manual. The only thing I could say that would make that code snapshot clearer is that the \0E I showed as a string constant was in \codes display.
Please try things out before you start debating \ vs. double \ vs. whatever. Basically you've wasted about 10 replies and 4-5 hours by not actually trying the code you were told to try.
That was the key. The string output string appears, as Ravens pointed out, in the case of 50% intensity I get a 2, but by using this method the VISA write sends the correct combination of bits.
Trying to concatenate the strings together misses something, so the output to the display is missing something causing it not to function correctly.
ie: The VISA Write.vi interprets string controls & constants in Normal Mode differently than '\'Mode differently than byte array converted to String.vi output. All three give different results on the display when given the same inputs.
I attached the final code.
Thanks to both of you for your time and help.
GerdE & Ravens Fan,
Likely you are right about what the commands should do, but that is not how it happens to work when using the VISA Write.vi.
Please see my last post, it took me a few minutes to understand what Coq rouge meant but he seems to some how understand that some type of magical trickery happens when the string passes through the VISA Write.vi and there is a method that works well.
As far as wasting time Ravens, I’d say it is you who wasted my time by not considering that you might be wrong or that LabView might have a glitch. Your code snip it is in the attachment that I included with Post 10. I did try your code and it did not work and I had already gone down that road but tried your suggestion any way. I posted it so you might see that I was not blowing off your advice and I tried to explain that to you. If I failed to make you understand I apologize for my short comings.
GerdE, thanks for spending time and digging into the manual. I appreciate your time also.Your commented that, “And that manual in no way says you need to send slashes, it just says "Send "Control+N", followed by a byte from 0-100". So you should send just "0e32" (hex display, or "\0e2" in LV slash display) to set backlight to 50%...” I’d like to point out that on page 13 in the column to the left of where it says to use Control+N it says \014. Here is the link again incase you would like to verify this.http://www.crystalfontz.com/product/CFA632-YFB-KS.html I did send the string you suggest, it is the same as what Ravens suggests and it still doesn’t work. It didn’t work in post 3 on Friday and it still doesn’t work today. Control+N works well in Windows Hyper Terminal but I was unable to find a way to programmatically send a “Control” key stroke followed by “N”. Maybe you could post the solution to that. I did find that using a string control or constant in slash codes mode works if I used the Hex value for the \ decimal value command “\014” and included the “\” before the value, “\0E”. If I did not include the”\” then the display interpreted the command as ASCII and displayed just the letters 0E. I understand where you and Ravens are coming from about the slashes. But I have proven beyond a shadow of a doubt that the slashes have some meaning and change the function of the output of the VISA Write.vi. If you had read my posts thoroughly and likewise looked at my attached code you might have understood what I was trying to tell you. If you understood you may not have assumed that I was ignoring you and tried to help find a different solution. In closing, Coq rouge, Thank you for you time, your patience and your knowledge. GerdE and Ravens, thank you for your time but not for you rudeness. Your attitudes are unacceptable and unwelcome. After discussing this with Premier Tech Support AE’s at NI they are convinced as well that the outputs don’t accurately represent the inputs to the VISA Write.vi and are pursuing the issue further.
I'm glad it's working for you now.
You said "The VISA Write.vi interprets string controls & constants in Normal Mode differently than '\'Mode differently than byte array converted to String.vi output. All three give different results on the display when given the same inputs."
That is not true. VISA Write will interpret a string the same way, no matter what display mode the control is set for. Think about it. If it mattered to a VISA Write, and the data on the string came from some other source besides a control such as other string functions, how would the VISA Write know which way to interpret it because you didn't have a control to tell it.
The only differences between Normal, \codes, and Hex display modes is the way the data is displayed to the user on the front panel. If you start trying to play with the strings so a string looks the same in \codes display like it would in normal display, you would have to create 2 completely different strings to do that, then you get results that just aren't going to work like you want them to.
1. Normal mode is the most human readable, but it can't show special characters such as non-printing or control characters.
2. Hex mode is the format that can show you all characters in a common format of what is being sent, but it is not human readable.
3. \codes is a hybrid of the 2. It shows the data in a mostly human readable format, but also shows the special control characters and non-printing characters.
I simply do not believe that there is any magic involved and that the \ by itself changes anything at all with the VISA Write. I've been using VISA since it was first introduced and have never seen or heard of such a thing. When a string control or constant is set for '\' Codes Display, it forces the next character to be intrepreted in a certain way.
As far as Ctrl-N, all you need is a good ASCII table. You would find that a Ctrl-N is the same thing as 0x0E if using hex display or Byte Array to String or a Typecast. You can also use '\' Code Display and use \0E. Its all the exact same thing.
There is no such thing as a ctrl followed by an N being sent by hyperterminal. When you hit control-N in hyperterminal, you sent the ASCII decimal 14 which is hex 0E. It will look like a box in normal display, a \0E in \codes display and 0E in hex codes display.
The information we presented you I am sure will work as it will yield the same result as you have in the code you presented. I got you that answer in reply #3. Yet you proceeded to argue that it was wrong, that the slashes aren't being done right and it took you until reply #10 to post some real information as to what you were looking for.
I'm sorry you felt we were being rude, but there is nothing more annoying than trying to help some one (anyone with yellow bars are just volunteering) and have them not follow the advice. Or apparently follow it incorrectly and argue the advice was wrong. Perhaps you did try to follow it, but I am sure you didn't follow it correctly.
I would be interested to know who are the "premier Tech support AE's at NI" who are convinced there is a problem with VISA write commands. I've been using LabVIEW with the serial port VISA reads and writes and have never come across a problem with using them once cable types were confirmed, port settings were confirmed, and the ASCII bytes being sent or read matched the protocol of what the instrument wanted.
If you feel my advice was unwelcome, don't worry, I won't give you any more advice.
besides the comments of others about Ctrl+N you should read the manual more carefully!
On page 13 it clearly says:
"The notation "\xxx" is used for “binary” data, where "xxx" is the decimal representation of the number. Use the codes \000
to \255 to include all possible values for a character. This notation is supported by the WinTest Serial LCD Demo
So only the demo software supports this notation, but not the LCD panel itself. This software translate the slash code to bytes as was suggested here in one way or the other too...
You stated it much better than I did,“When a string control or constant is set for '\' Codes Display, it forces the next character to be interpreted in a certain way.”
Forgive my ignorance or short sightedness, but I still don’t understand why the first concatenation works but the 2nd does not.
The easy work around was to use the byte array and then convert everything to a string as below but the concatenation above bugs me.